{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-5.15.0-1097-kvm", "linux-image-5.15.0-1097-kvm", "linux-kvm-headers-5.15.0-1097", "linux-modules-5.15.0-1097-kvm", "netplan-generator", "python3-netplan" ], "removed": [ "linux-headers-5.15.0-1096-kvm", "linux-image-5.15.0-1096-kvm", "linux-kvm-headers-5.15.0-1096", "linux-modules-5.15.0-1096-kvm" ], "diff": [ "gir1.2-packagekitglib-1.0", "libcap2", "libcap2-bin", "libnetplan0", "libpackagekit-glib2-18", "libpam-cap", "libpolkit-agent-1-0", "libpolkit-gobject-1-0", "linux-headers-kvm", "linux-image-kvm", "linux-kvm", "netplan.io", "pkexec", "polkitd", "snapd", "xxd" ] } }, "diff": { "deb": [ { "name": "gir1.2-packagekitglib-1.0", "from_version": { "source_package_name": "packagekit", "source_package_version": "1.2.5-2ubuntu3", "version": "1.2.5-2ubuntu3" }, "to_version": { "source_package_name": "packagekit", "source_package_version": "1.2.5-2ubuntu3.1", "version": "1.2.5-2ubuntu3.1" }, "cves": [], "launchpad_bugs_fixed": [ 2148512 ], "changes": [ { "cves": [], "log": [ "", " * SECURITY UPDATE: TOCTOU Race on Transaction Flags (LP: #2148512)", " - debian/patches/Do-not-allow-re-invoking-methods-on-non-new-txn.patch:", " do not allow re-invoking methods on non-new transactions in", " src/pk-transaction.c.", " - CVE number pending", "" ], "package": "packagekit", "version": "1.2.5-2ubuntu3.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [ 2148512 ], "author": "Marc Deslauriers ", "date": "Mon, 20 Apr 2026 08:24:54 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libcap2", "from_version": { "source_package_name": "libcap2", "source_package_version": "1:2.44-1ubuntu0.22.04.2", "version": "1:2.44-1ubuntu0.22.04.2" }, "to_version": { "source_package_name": "libcap2", "source_package_version": "1:2.44-1ubuntu0.22.04.3", "version": "1:2.44-1ubuntu0.22.04.3" }, "cves": [ { "cve": "CVE-2026-4878", "url": "https://ubuntu.com/security/CVE-2026-4878", "cve_description": "A flaw was found in libcap. A local unprivileged user can exploit a Time-of-check-to-time-of-use (TOCTOU) race condition in the `cap_set_file()` function. This allows an attacker with write access to a parent directory to redirect file capability updates to an attacker-controlled file. By doing so, capabilities can be injected into or stripped from unintended executables, leading to privilege escalation.", "cve_priority": "medium", "cve_public_date": "2026-04-09 16:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-4878", "url": "https://ubuntu.com/security/CVE-2026-4878", "cve_description": "A flaw was found in libcap. A local unprivileged user can exploit a Time-of-check-to-time-of-use (TOCTOU) race condition in the `cap_set_file()` function. This allows an attacker with write access to a parent directory to redirect file capability updates to an attacker-controlled file. By doing so, capabilities can be injected into or stripped from unintended executables, leading to privilege escalation.", "cve_priority": "medium", "cve_public_date": "2026-04-09 16:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: potential TOCTOU race condition in cap_set_file()", " - debian/patches/CVE-2026-4878.patch: fix race in libcap/cap_file.c,", " progs/quicktest.sh.", " - CVE-2026-4878", "" ], "package": "libcap2", "version": "1:2.44-1ubuntu0.22.04.3", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 09 Apr 2026 11:04:48 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libcap2-bin", "from_version": { "source_package_name": "libcap2", "source_package_version": "1:2.44-1ubuntu0.22.04.2", "version": "1:2.44-1ubuntu0.22.04.2" }, "to_version": { "source_package_name": "libcap2", "source_package_version": "1:2.44-1ubuntu0.22.04.3", "version": "1:2.44-1ubuntu0.22.04.3" }, "cves": [ { "cve": "CVE-2026-4878", "url": "https://ubuntu.com/security/CVE-2026-4878", "cve_description": "A flaw was found in libcap. A local unprivileged user can exploit a Time-of-check-to-time-of-use (TOCTOU) race condition in the `cap_set_file()` function. This allows an attacker with write access to a parent directory to redirect file capability updates to an attacker-controlled file. By doing so, capabilities can be injected into or stripped from unintended executables, leading to privilege escalation.", "cve_priority": "medium", "cve_public_date": "2026-04-09 16:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-4878", "url": "https://ubuntu.com/security/CVE-2026-4878", "cve_description": "A flaw was found in libcap. A local unprivileged user can exploit a Time-of-check-to-time-of-use (TOCTOU) race condition in the `cap_set_file()` function. This allows an attacker with write access to a parent directory to redirect file capability updates to an attacker-controlled file. By doing so, capabilities can be injected into or stripped from unintended executables, leading to privilege escalation.", "cve_priority": "medium", "cve_public_date": "2026-04-09 16:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: potential TOCTOU race condition in cap_set_file()", " - debian/patches/CVE-2026-4878.patch: fix race in libcap/cap_file.c,", " progs/quicktest.sh.", " - CVE-2026-4878", "" ], "package": "libcap2", "version": "1:2.44-1ubuntu0.22.04.3", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 09 Apr 2026 11:04:48 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libnetplan0", "from_version": { "source_package_name": "netplan.io", "source_package_version": "0.106.1-7ubuntu0.22.04.4", "version": "0.106.1-7ubuntu0.22.04.4" }, "to_version": { "source_package_name": "netplan.io", "source_package_version": "0.107.1-3ubuntu0.22.04.3", "version": "0.107.1-3ubuntu0.22.04.3" }, "cves": [ { "cve": "CVE-2022-4968", "url": "https://ubuntu.com/security/CVE-2022-4968", "cve_description": "netplan leaks the private key of wireguard to local users. Versions after 1.0 are not affected.", "cve_priority": "medium", "cve_public_date": "2024-06-07 01:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2139598, 1988018, 2020409, 2058031 ], "changes": [ { "cves": [], "log": [ "", " * debian/patches/lp2139598-execute-udev-rules-before-sriov-apply-service.patch:", " execute udev rules before starting sriov apply service (LP: #2139598)", "" ], "package": "netplan.io", "version": "0.107.1-3ubuntu0.22.04.3", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2139598 ], "author": "Robert Malz ", "date": "Tue, 03 Mar 2026 12:18:29 +0100" }, { "cves": [], "log": [ "", " * debian/patches/lp1988018: VF-LAG activation", " Fixes the order in which SR-IOV configuration is performed and", " cooperates with VF-LAG activation (LP: #1988018).", " * debian/patches/lp2020409:", " Enables setting the embedded-switch mode without having to define", " virtual functions (LP: #2020409).", " * debian/libnetplan0.symbols: New symbol _netplan_netdef_get_bond_mode.", "" ], "package": "netplan.io", "version": "0.107.1-3ubuntu0.22.04.2", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1988018, 2020409 ], "author": "Danilo Egea Gondolfo ", "date": "Mon, 07 Oct 2024 10:57:38 +0100" }, { "cves": [ { "cve": "CVE-2022-4968", "url": "https://ubuntu.com/security/CVE-2022-4968", "cve_description": "netplan leaks the private key of wireguard to local users. Versions after 1.0 are not affected.", "cve_priority": "medium", "cve_public_date": "2024-06-07 01:15:00 UTC" } ], "log": [ "", " * Backport netplan.io 0.107.1-3 to 22.04 (LP: #2058031):", " - Support for \"dummy\" (`dummy-devices`) interfaces (LP: 1774203) (!361)", " - Support for \"veth\" (`virtual-ethernets`) interfaces (!368)", " - Add Python bindings for libnetplan (!385)", " - netplan: Handle command exceptions (!334)", " - WPA3 (personal) support (LP: 2023238) (!369)", " - Add all the commands to the bash completion file (LP: 1749869) (!326)", " - New submodule for state manipulation (!379)", " - commands/status: show routes from all routing tables (!390)", " - cli:status: Make rich pretty printing optional (!388)", " - libnetplan: expose dhcp4 and dhcp6 properties (!394)", " - Expose macaddress and DNS configuration from the netdef (!395)", " - libnetplan: expose the routes list in the netdef (!397)", " - NetworkManager: Wireguard private key flag support (!371)", " - Add a netplan_parser_load_keyfile() Python binding (!351)", " - keyfile parser: add support for all tunnel types (LP: 2016473) (!360)", " - parse-nm:wg: add support for reading the listen-port property (!372)", " - parse-nm: add support for VRF devices (!398)", " - Vlan keyfile parser support (!370)", " - Netplan docs rework (!333 & !337)", " - docs: Add a short netplan-everywhere howto (!325)", " - doc: make us of sphinx copybutton plugin (!354)", " - doc: Add Ubuntu Code of Conduct 2.0 (!355)", " - doc: Explanation about 00-network-manager-all.yaml (!378)", " - wifi: add support for WPA3-Enterprise (LP: 2029876) (!402)", " - wifi: support WPA2 and WPA3 Personal simultaneously (!404)", " - added mii-monitor-interval example (!411)", " - docs: Add \"Contribute Documentation\" how-to", " - auth: add support for LEAP and EAP-PWD (!415)", " - tests: Add autopkgtest for (LP: 1959570) (!419)", " - wifi: make it possible to have a psk and an eap password simultaneously", " (!416)", " - doc: Set-up some basic Doxygen project (!423)", " - doc: Make Sphinx to handle autodoxygen project, using breathe (!423)", " - doc: create libnetplan apidoc structure (!423)", " - inc: Start documenting public API (!423)", " - doc: Update 'Netplan everywhere' for 23.10 (!418)", " SECURITY UPDATE: weak permissions on secret files, command injection", " - d/p/lp2065738/0014-libnetplan-use-more-restrictive-file-permissions.patch:", " Use more restrictive file permissions to prevent unprivileged users to", " read sensitive data from back end files (LP: 2065738, 1987842)", " - CVE-2022-4968", " - d/p/lp2066258/0015-libnetplan-escape-control-characters.patch:", " Escape control characters in the parser and double quotes in backend", " files.", " - d/p/lp2066258/0016-backends-escape-file-paths.patch:", " Escape special characters in file paths.", " - d/p/lp2066258/0017-backends-escape-semicolons-in-service-units.patch:", " Escape isolated semicolons in systemd service units. (LP: 2066258)", " - debian/netplan-generator.postinst: Add a postinst maintainer script to", " call the generator. It's needed so the file permissions fixes will be", " applied automatically.", " Bug fixes:", " - Fix FTBFS on Fedora and refresh RPM packaging (!323)", " - parser: validate lacp-rate properly (LP: 1745648) (!324)", " - use meson-make-symlink.sh helper instead of install_symlink() (!327)", " - netplan: cli: fix typo from 'unkown' to 'unknown' (!328)", " - Handle duplication during parser second pass (LP: 2007682) (!329)", " - parse:ovs: Ignore deprecated OpenFlow1.6 protocol (LP: 1963735) (!332)", " - dbus: Build the copy path correctly (!331)", " - tests: add new spread based snapd integration test (!330)", " - Use controlled execution environment, to avoid failure if PATH is unset", " (LP: 1959570) (!336)", " - Some refactoring (!338)", " - netplan: adjust the maximum buffer size to 1MB (!340)", " - parse: use \"--\" with systemd-escape (!347)", " - docs: fix bridge parameters types and add examples (!346)", " - vrfs: skip policies parsing if list is NULL (LP: 2016427) (!341)", " - networkd: plug a memory leak (!344)", " - libnetplan: don't try to read from a NULL file (!342)", " - nm: return if write_routes() fails (!345)", " - parse: plug a memory leak (!348)", " - parse: set the backend on nm-devices to NM (!349)", " - parse: don't point to the wrong node on validation (!343)", " - rtd: set the OS and Python versions explicitly (!357)", " - Fix 8021x eap method parsing (LP: 2016625) (!358)", " - CI: update canonical/setup-lxd to v0.1.1 (!359)", " - CI: fix dch after adding the new 0.106.1 tag (!364)", " - Provide frequency to wpa_supplicant in adhoc mode (LP: 2020754) (!363)", " - Improve the coverage of the memory leak tests (!365)", " - Fix keyfile parsing of wireguard config (!366)", " - routes: fix metric rendering (LP: 2023681) (!367)", " - CI: add DebCI integration test (!362)", " - CI: initial NetworkManager autopkgtests (!374)", " - parse-nm: handle cloned-mac-address special cases (LP: 2026230) (!376)", " - Improve autopkgtest stability with systemd 253 & iproute 6.4 (!377)", " - Fixes for minor issues (!380)", " - tests:integration: Adopt for systemd v254 (Closes: #1041310) (!381)", " - parse: Downgrade NM passthrough warning to debug (!384)", " - Don't drop files with just global values (LP: 2027584) (!382)", " - Fixing Coverity issues (!383)", " - CLI: Refactoring to avoid namespace clash with public bindings (!387)", " - tests: fix test coverage report with newer python-coverage (!389)", " - github: add a scheduled action to run Coverity (!391)", " - github: only run the coverity workflow on our repository (!392)", " - Addressing a few issues found (!393)", " - Wireguard fixes (!352)", " - Fix a memory leak, an assert and an error message (!350)", " - ovs: don't allow peers with the same name (!353)", " - CI: make use of the canonical/setup-lxd action (!356)", " - test:ovs: Avoid NetworkManager taking contol, breaking a test", " - parse: allow COMMON_LINK_HANDLERS for VRFs (!401)", " - util: don't return a placeholder netdef in the iterator (!406)", " - tunnels/validation: do not error out if \"local\" is not defined (!407)", " - tests: add some integration tests without the local address (!407)", " - wireguard: ignore empty endpoints (LP: 2038811) (!414)", " - parse: improve the parsing of access-points (LP: 1809994) (!413)", " - wifi: replace the previously defined AP with the new one (!413)", " - doc: spelling check improvements (!417)", " - Fix permissions on folder '/run/NetworkManager/' (!422)", " - cli:try: avoid linting error for type hints (Closes: #1058524) (!422)", " - nm-parse: always read the PSK into the new psk variable (!416)", " - networkd: fix formatting (!424)", " - networkd: replace deprecated CriticalConnection= by KeepConfiguration=", " (!424)", " - networkd: move KeepConfiguration= into [Network] section", " - apply: bring \"lo\" back up if it's managed by NM (!408)", " - apply: don't assume the NM loopback connection is called \"lo\" (!408)", " Packaging restructuring:", " - Split netplan-generator into separate package to make the Python", " dependency optional.", " - Split python3-netplan bindings into a separate package", " * Add patches for bug fixes from netplan.io 1.0-1 and 1.0.1-1:", " - debian/patches/lp2041727:", " Check if ovsdb-server.service is active before displaying warning", " (LP: 2041727) (!421)", " - d/p/0004-tests-assert-generated-.service-files-in-assert_srio.patch,", " d/p/0005-tests-sriov-test-if-the-generated-netplan-rebind-ser.patch,", " d/p/0006-sriov-don-t-generate-duplicate-entries-in-the-rebind.patch:", " Don't generate duplicate entries in the netplan-sriov-rebind.service", " (!437)", " - d/p/0017-emitter-allow-unicode-characters-in-the-emitter.patch.", " Allow non-ascii characters in the YAML emitter (LP: 2071652) (!485).", " - d/p/0018-parse-do-not-escape-all-non-ascii-bytes.patch.", " Don't escape all non-ascii bytes (!486).", " * Drop patches not required for 22.04:", " - debian/patches/python-limited-stable-api.patch", " - d/p/sru-compat/0013-Keep-old-file-permission-for-backwards-compatibility.patch.", " From now on we want libnetplan to create files with tight permissions.", " * Add patches for SRU backwards compatibility:", " - 0014-Demote-lacp-rate-validation-error-to-warning-for-bac.patch:", " Convert the error to a warning in a new validation for the option", " 'lacp-rate' to prevent breaking existing setups", " * debian/control:", " - Drop python3-rich dependency to Suggests", " - Drop build dependency on systemd-dev", " * debian/netplan.io.preinst:", " - This preinst script is intended to cleanup the .pyc files from", " share/netplan/netplan. This directory is supposed to be removed after", " the upgrade from netplan.io 0.106.1 to 0.107.1, as the Python code", " was moved to it's own python3-netplan package, but it's left behind", " due to Python cached files.", " * Drop changes related to usr-merge and not required for 22.04", " - debian/netplan-generator.install", " - debian/netplan-generator.dirs", " - debian/netplan-generator.postinst", " - debian/netplan-generator.preinst", " * d/netplan-generator.lintian-overrides, d/netplan.io.lintian-overrides:", " - Drop overrides file. It wasn't really silencing any lintian warnings.", "" ], "package": "netplan.io", "version": "0.107.1-3ubuntu0.22.04.1", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2058031 ], "author": "Danilo Egea Gondolfo ", "date": "Fri, 16 Aug 2024 17:59:32 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpackagekit-glib2-18", "from_version": { "source_package_name": "packagekit", "source_package_version": "1.2.5-2ubuntu3", "version": "1.2.5-2ubuntu3" }, "to_version": { "source_package_name": "packagekit", "source_package_version": "1.2.5-2ubuntu3.1", "version": "1.2.5-2ubuntu3.1" }, "cves": [], "launchpad_bugs_fixed": [ 2148512 ], "changes": [ { "cves": [], "log": [ "", " * SECURITY UPDATE: TOCTOU Race on Transaction Flags (LP: #2148512)", " - debian/patches/Do-not-allow-re-invoking-methods-on-non-new-txn.patch:", " do not allow re-invoking methods on non-new transactions in", " src/pk-transaction.c.", " - CVE number pending", "" ], "package": "packagekit", "version": "1.2.5-2ubuntu3.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [ 2148512 ], "author": "Marc Deslauriers ", "date": "Mon, 20 Apr 2026 08:24:54 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpam-cap", "from_version": { "source_package_name": "libcap2", "source_package_version": "1:2.44-1ubuntu0.22.04.2", "version": "1:2.44-1ubuntu0.22.04.2" }, "to_version": { "source_package_name": "libcap2", "source_package_version": "1:2.44-1ubuntu0.22.04.3", "version": "1:2.44-1ubuntu0.22.04.3" }, "cves": [ { "cve": "CVE-2026-4878", "url": "https://ubuntu.com/security/CVE-2026-4878", "cve_description": "A flaw was found in libcap. A local unprivileged user can exploit a Time-of-check-to-time-of-use (TOCTOU) race condition in the `cap_set_file()` function. This allows an attacker with write access to a parent directory to redirect file capability updates to an attacker-controlled file. By doing so, capabilities can be injected into or stripped from unintended executables, leading to privilege escalation.", "cve_priority": "medium", "cve_public_date": "2026-04-09 16:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-4878", "url": "https://ubuntu.com/security/CVE-2026-4878", "cve_description": "A flaw was found in libcap. A local unprivileged user can exploit a Time-of-check-to-time-of-use (TOCTOU) race condition in the `cap_set_file()` function. This allows an attacker with write access to a parent directory to redirect file capability updates to an attacker-controlled file. By doing so, capabilities can be injected into or stripped from unintended executables, leading to privilege escalation.", "cve_priority": "medium", "cve_public_date": "2026-04-09 16:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: potential TOCTOU race condition in cap_set_file()", " - debian/patches/CVE-2026-4878.patch: fix race in libcap/cap_file.c,", " progs/quicktest.sh.", " - CVE-2026-4878", "" ], "package": "libcap2", "version": "1:2.44-1ubuntu0.22.04.3", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 09 Apr 2026 11:04:48 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpolkit-agent-1-0", "from_version": { "source_package_name": "policykit-1", "source_package_version": "0.105-33", "version": "0.105-33" }, "to_version": { "source_package_name": "policykit-1", "source_package_version": "0.105-33ubuntu0.1", "version": "0.105-33ubuntu0.1" }, "cves": [ { "cve": "CVE-2025-7519", "url": "https://ubuntu.com/security/CVE-2025-7519", "cve_description": "A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly.", "cve_priority": "low", "cve_public_date": "2025-07-14 14:15:00 UTC" }, { "cve": "CVE-2026-4897", "url": "https://ubuntu.com/security/CVE-2026-4897", "cve_description": "A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the `polkit-agent-helper-1` setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system.", "cve_priority": "medium", "cve_public_date": "2026-03-26 15:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-7519", "url": "https://ubuntu.com/security/CVE-2025-7519", "cve_description": "A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly.", "cve_priority": "low", "cve_public_date": "2025-07-14 14:15:00 UTC" }, { "cve": "CVE-2026-4897", "url": "https://ubuntu.com/security/CVE-2026-4897", "cve_description": "A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the `polkit-agent-helper-1` setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system.", "cve_priority": "medium", "cve_public_date": "2026-03-26 15:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: OOB write via nested elements in XML policy", " - debian/patches/CVE-2025-7519.patch: check depth in", " src/polkitbackend/polkitbackendactionpool.c.", " - CVE-2025-7519", " * SECURITY UPDATE: DoS via excessively long input", " - debian/patches/CVE-2026-4897.patch: fix getline() string overflow in", " src/polkitagent/polkitagenthelperprivate.c.", " - CVE-2026-4897", "" ], "package": "policykit-1", "version": "0.105-33ubuntu0.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 10 Apr 2026 06:59:20 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpolkit-gobject-1-0", "from_version": { "source_package_name": "policykit-1", "source_package_version": "0.105-33", "version": "0.105-33" }, "to_version": { "source_package_name": "policykit-1", "source_package_version": "0.105-33ubuntu0.1", "version": "0.105-33ubuntu0.1" }, "cves": [ { "cve": "CVE-2025-7519", "url": "https://ubuntu.com/security/CVE-2025-7519", "cve_description": "A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly.", "cve_priority": "low", "cve_public_date": "2025-07-14 14:15:00 UTC" }, { "cve": "CVE-2026-4897", "url": "https://ubuntu.com/security/CVE-2026-4897", "cve_description": "A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the `polkit-agent-helper-1` setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system.", "cve_priority": "medium", "cve_public_date": "2026-03-26 15:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-7519", "url": "https://ubuntu.com/security/CVE-2025-7519", "cve_description": "A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly.", "cve_priority": "low", "cve_public_date": "2025-07-14 14:15:00 UTC" }, { "cve": "CVE-2026-4897", "url": "https://ubuntu.com/security/CVE-2026-4897", "cve_description": "A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the `polkit-agent-helper-1` setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system.", "cve_priority": "medium", "cve_public_date": "2026-03-26 15:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: OOB write via nested elements in XML policy", " - debian/patches/CVE-2025-7519.patch: check depth in", " src/polkitbackend/polkitbackendactionpool.c.", " - CVE-2025-7519", " * SECURITY UPDATE: DoS via excessively long input", " - debian/patches/CVE-2026-4897.patch: fix getline() string overflow in", " src/polkitagent/polkitagenthelperprivate.c.", " - CVE-2026-4897", "" ], "package": "policykit-1", "version": "0.105-33ubuntu0.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 10 Apr 2026 06:59:20 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1096.92", "version": "5.15.0.1096.92" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1097.93", "version": "5.15.0.1097.93" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1097", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1097.93", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Austin Rhodes ", "date": "Tue, 07 Apr 2026 09:54:00 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1096.92", "version": "5.15.0.1096.92" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1097.93", "version": "5.15.0.1097.93" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1097", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1097.93", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Austin Rhodes ", "date": "Tue, 07 Apr 2026 09:54:00 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1096.92", "version": "5.15.0.1096.92" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1097.93", "version": "5.15.0.1097.93" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1097", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1097.93", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Austin Rhodes ", "date": "Tue, 07 Apr 2026 09:54:00 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "netplan.io", "from_version": { "source_package_name": "netplan.io", "source_package_version": "0.106.1-7ubuntu0.22.04.4", "version": "0.106.1-7ubuntu0.22.04.4" }, "to_version": { "source_package_name": "netplan.io", "source_package_version": "0.107.1-3ubuntu0.22.04.3", "version": "0.107.1-3ubuntu0.22.04.3" }, "cves": [ { "cve": "CVE-2022-4968", "url": "https://ubuntu.com/security/CVE-2022-4968", "cve_description": "netplan leaks the private key of wireguard to local users. Versions after 1.0 are not affected.", "cve_priority": "medium", "cve_public_date": "2024-06-07 01:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2139598, 1988018, 2020409, 2058031 ], "changes": [ { "cves": [], "log": [ "", " * debian/patches/lp2139598-execute-udev-rules-before-sriov-apply-service.patch:", " execute udev rules before starting sriov apply service (LP: #2139598)", "" ], "package": "netplan.io", "version": "0.107.1-3ubuntu0.22.04.3", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2139598 ], "author": "Robert Malz ", "date": "Tue, 03 Mar 2026 12:18:29 +0100" }, { "cves": [], "log": [ "", " * debian/patches/lp1988018: VF-LAG activation", " Fixes the order in which SR-IOV configuration is performed and", " cooperates with VF-LAG activation (LP: #1988018).", " * debian/patches/lp2020409:", " Enables setting the embedded-switch mode without having to define", " virtual functions (LP: #2020409).", " * debian/libnetplan0.symbols: New symbol _netplan_netdef_get_bond_mode.", "" ], "package": "netplan.io", "version": "0.107.1-3ubuntu0.22.04.2", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1988018, 2020409 ], "author": "Danilo Egea Gondolfo ", "date": "Mon, 07 Oct 2024 10:57:38 +0100" }, { "cves": [ { "cve": "CVE-2022-4968", "url": "https://ubuntu.com/security/CVE-2022-4968", "cve_description": "netplan leaks the private key of wireguard to local users. Versions after 1.0 are not affected.", "cve_priority": "medium", "cve_public_date": "2024-06-07 01:15:00 UTC" } ], "log": [ "", " * Backport netplan.io 0.107.1-3 to 22.04 (LP: #2058031):", " - Support for \"dummy\" (`dummy-devices`) interfaces (LP: 1774203) (!361)", " - Support for \"veth\" (`virtual-ethernets`) interfaces (!368)", " - Add Python bindings for libnetplan (!385)", " - netplan: Handle command exceptions (!334)", " - WPA3 (personal) support (LP: 2023238) (!369)", " - Add all the commands to the bash completion file (LP: 1749869) (!326)", " - New submodule for state manipulation (!379)", " - commands/status: show routes from all routing tables (!390)", " - cli:status: Make rich pretty printing optional (!388)", " - libnetplan: expose dhcp4 and dhcp6 properties (!394)", " - Expose macaddress and DNS configuration from the netdef (!395)", " - libnetplan: expose the routes list in the netdef (!397)", " - NetworkManager: Wireguard private key flag support (!371)", " - Add a netplan_parser_load_keyfile() Python binding (!351)", " - keyfile parser: add support for all tunnel types (LP: 2016473) (!360)", " - parse-nm:wg: add support for reading the listen-port property (!372)", " - parse-nm: add support for VRF devices (!398)", " - Vlan keyfile parser support (!370)", " - Netplan docs rework (!333 & !337)", " - docs: Add a short netplan-everywhere howto (!325)", " - doc: make us of sphinx copybutton plugin (!354)", " - doc: Add Ubuntu Code of Conduct 2.0 (!355)", " - doc: Explanation about 00-network-manager-all.yaml (!378)", " - wifi: add support for WPA3-Enterprise (LP: 2029876) (!402)", " - wifi: support WPA2 and WPA3 Personal simultaneously (!404)", " - added mii-monitor-interval example (!411)", " - docs: Add \"Contribute Documentation\" how-to", " - auth: add support for LEAP and EAP-PWD (!415)", " - tests: Add autopkgtest for (LP: 1959570) (!419)", " - wifi: make it possible to have a psk and an eap password simultaneously", " (!416)", " - doc: Set-up some basic Doxygen project (!423)", " - doc: Make Sphinx to handle autodoxygen project, using breathe (!423)", " - doc: create libnetplan apidoc structure (!423)", " - inc: Start documenting public API (!423)", " - doc: Update 'Netplan everywhere' for 23.10 (!418)", " SECURITY UPDATE: weak permissions on secret files, command injection", " - d/p/lp2065738/0014-libnetplan-use-more-restrictive-file-permissions.patch:", " Use more restrictive file permissions to prevent unprivileged users to", " read sensitive data from back end files (LP: 2065738, 1987842)", " - CVE-2022-4968", " - d/p/lp2066258/0015-libnetplan-escape-control-characters.patch:", " Escape control characters in the parser and double quotes in backend", " files.", " - d/p/lp2066258/0016-backends-escape-file-paths.patch:", " Escape special characters in file paths.", " - d/p/lp2066258/0017-backends-escape-semicolons-in-service-units.patch:", " Escape isolated semicolons in systemd service units. (LP: 2066258)", " - debian/netplan-generator.postinst: Add a postinst maintainer script to", " call the generator. It's needed so the file permissions fixes will be", " applied automatically.", " Bug fixes:", " - Fix FTBFS on Fedora and refresh RPM packaging (!323)", " - parser: validate lacp-rate properly (LP: 1745648) (!324)", " - use meson-make-symlink.sh helper instead of install_symlink() (!327)", " - netplan: cli: fix typo from 'unkown' to 'unknown' (!328)", " - Handle duplication during parser second pass (LP: 2007682) (!329)", " - parse:ovs: Ignore deprecated OpenFlow1.6 protocol (LP: 1963735) (!332)", " - dbus: Build the copy path correctly (!331)", " - tests: add new spread based snapd integration test (!330)", " - Use controlled execution environment, to avoid failure if PATH is unset", " (LP: 1959570) (!336)", " - Some refactoring (!338)", " - netplan: adjust the maximum buffer size to 1MB (!340)", " - parse: use \"--\" with systemd-escape (!347)", " - docs: fix bridge parameters types and add examples (!346)", " - vrfs: skip policies parsing if list is NULL (LP: 2016427) (!341)", " - networkd: plug a memory leak (!344)", " - libnetplan: don't try to read from a NULL file (!342)", " - nm: return if write_routes() fails (!345)", " - parse: plug a memory leak (!348)", " - parse: set the backend on nm-devices to NM (!349)", " - parse: don't point to the wrong node on validation (!343)", " - rtd: set the OS and Python versions explicitly (!357)", " - Fix 8021x eap method parsing (LP: 2016625) (!358)", " - CI: update canonical/setup-lxd to v0.1.1 (!359)", " - CI: fix dch after adding the new 0.106.1 tag (!364)", " - Provide frequency to wpa_supplicant in adhoc mode (LP: 2020754) (!363)", " - Improve the coverage of the memory leak tests (!365)", " - Fix keyfile parsing of wireguard config (!366)", " - routes: fix metric rendering (LP: 2023681) (!367)", " - CI: add DebCI integration test (!362)", " - CI: initial NetworkManager autopkgtests (!374)", " - parse-nm: handle cloned-mac-address special cases (LP: 2026230) (!376)", " - Improve autopkgtest stability with systemd 253 & iproute 6.4 (!377)", " - Fixes for minor issues (!380)", " - tests:integration: Adopt for systemd v254 (Closes: #1041310) (!381)", " - parse: Downgrade NM passthrough warning to debug (!384)", " - Don't drop files with just global values (LP: 2027584) (!382)", " - Fixing Coverity issues (!383)", " - CLI: Refactoring to avoid namespace clash with public bindings (!387)", " - tests: fix test coverage report with newer python-coverage (!389)", " - github: add a scheduled action to run Coverity (!391)", " - github: only run the coverity workflow on our repository (!392)", " - Addressing a few issues found (!393)", " - Wireguard fixes (!352)", " - Fix a memory leak, an assert and an error message (!350)", " - ovs: don't allow peers with the same name (!353)", " - CI: make use of the canonical/setup-lxd action (!356)", " - test:ovs: Avoid NetworkManager taking contol, breaking a test", " - parse: allow COMMON_LINK_HANDLERS for VRFs (!401)", " - util: don't return a placeholder netdef in the iterator (!406)", " - tunnels/validation: do not error out if \"local\" is not defined (!407)", " - tests: add some integration tests without the local address (!407)", " - wireguard: ignore empty endpoints (LP: 2038811) (!414)", " - parse: improve the parsing of access-points (LP: 1809994) (!413)", " - wifi: replace the previously defined AP with the new one (!413)", " - doc: spelling check improvements (!417)", " - Fix permissions on folder '/run/NetworkManager/' (!422)", " - cli:try: avoid linting error for type hints (Closes: #1058524) (!422)", " - nm-parse: always read the PSK into the new psk variable (!416)", " - networkd: fix formatting (!424)", " - networkd: replace deprecated CriticalConnection= by KeepConfiguration=", " (!424)", " - networkd: move KeepConfiguration= into [Network] section", " - apply: bring \"lo\" back up if it's managed by NM (!408)", " - apply: don't assume the NM loopback connection is called \"lo\" (!408)", " Packaging restructuring:", " - Split netplan-generator into separate package to make the Python", " dependency optional.", " - Split python3-netplan bindings into a separate package", " * Add patches for bug fixes from netplan.io 1.0-1 and 1.0.1-1:", " - debian/patches/lp2041727:", " Check if ovsdb-server.service is active before displaying warning", " (LP: 2041727) (!421)", " - d/p/0004-tests-assert-generated-.service-files-in-assert_srio.patch,", " d/p/0005-tests-sriov-test-if-the-generated-netplan-rebind-ser.patch,", " d/p/0006-sriov-don-t-generate-duplicate-entries-in-the-rebind.patch:", " Don't generate duplicate entries in the netplan-sriov-rebind.service", " (!437)", " - d/p/0017-emitter-allow-unicode-characters-in-the-emitter.patch.", " Allow non-ascii characters in the YAML emitter (LP: 2071652) (!485).", " - d/p/0018-parse-do-not-escape-all-non-ascii-bytes.patch.", " Don't escape all non-ascii bytes (!486).", " * Drop patches not required for 22.04:", " - debian/patches/python-limited-stable-api.patch", " - d/p/sru-compat/0013-Keep-old-file-permission-for-backwards-compatibility.patch.", " From now on we want libnetplan to create files with tight permissions.", " * Add patches for SRU backwards compatibility:", " - 0014-Demote-lacp-rate-validation-error-to-warning-for-bac.patch:", " Convert the error to a warning in a new validation for the option", " 'lacp-rate' to prevent breaking existing setups", " * debian/control:", " - Drop python3-rich dependency to Suggests", " - Drop build dependency on systemd-dev", " * debian/netplan.io.preinst:", " - This preinst script is intended to cleanup the .pyc files from", " share/netplan/netplan. This directory is supposed to be removed after", " the upgrade from netplan.io 0.106.1 to 0.107.1, as the Python code", " was moved to it's own python3-netplan package, but it's left behind", " due to Python cached files.", " * Drop changes related to usr-merge and not required for 22.04", " - debian/netplan-generator.install", " - debian/netplan-generator.dirs", " - debian/netplan-generator.postinst", " - debian/netplan-generator.preinst", " * d/netplan-generator.lintian-overrides, d/netplan.io.lintian-overrides:", " - Drop overrides file. It wasn't really silencing any lintian warnings.", "" ], "package": "netplan.io", "version": "0.107.1-3ubuntu0.22.04.1", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2058031 ], "author": "Danilo Egea Gondolfo ", "date": "Fri, 16 Aug 2024 17:59:32 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "pkexec", "from_version": { "source_package_name": "policykit-1", "source_package_version": "0.105-33", "version": "0.105-33" }, "to_version": { "source_package_name": "policykit-1", "source_package_version": "0.105-33ubuntu0.1", "version": "0.105-33ubuntu0.1" }, "cves": [ { "cve": "CVE-2025-7519", "url": "https://ubuntu.com/security/CVE-2025-7519", "cve_description": "A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly.", "cve_priority": "low", "cve_public_date": "2025-07-14 14:15:00 UTC" }, { "cve": "CVE-2026-4897", "url": "https://ubuntu.com/security/CVE-2026-4897", "cve_description": "A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the `polkit-agent-helper-1` setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system.", "cve_priority": "medium", "cve_public_date": "2026-03-26 15:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-7519", "url": "https://ubuntu.com/security/CVE-2025-7519", "cve_description": "A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly.", "cve_priority": "low", "cve_public_date": "2025-07-14 14:15:00 UTC" }, { "cve": "CVE-2026-4897", "url": "https://ubuntu.com/security/CVE-2026-4897", "cve_description": "A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the `polkit-agent-helper-1` setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system.", "cve_priority": "medium", "cve_public_date": "2026-03-26 15:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: OOB write via nested elements in XML policy", " - debian/patches/CVE-2025-7519.patch: check depth in", " src/polkitbackend/polkitbackendactionpool.c.", " - CVE-2025-7519", " * SECURITY UPDATE: DoS via excessively long input", " - debian/patches/CVE-2026-4897.patch: fix getline() string overflow in", " src/polkitagent/polkitagenthelperprivate.c.", " - CVE-2026-4897", "" ], "package": "policykit-1", "version": "0.105-33ubuntu0.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 10 Apr 2026 06:59:20 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "polkitd", "from_version": { "source_package_name": "policykit-1", "source_package_version": "0.105-33", "version": "0.105-33" }, "to_version": { "source_package_name": "policykit-1", "source_package_version": "0.105-33ubuntu0.1", "version": "0.105-33ubuntu0.1" }, "cves": [ { "cve": "CVE-2025-7519", "url": "https://ubuntu.com/security/CVE-2025-7519", "cve_description": "A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly.", "cve_priority": "low", "cve_public_date": "2025-07-14 14:15:00 UTC" }, { "cve": "CVE-2026-4897", "url": "https://ubuntu.com/security/CVE-2026-4897", "cve_description": "A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the `polkit-agent-helper-1` setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system.", "cve_priority": "medium", "cve_public_date": "2026-03-26 15:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-7519", "url": "https://ubuntu.com/security/CVE-2025-7519", "cve_description": "A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly.", "cve_priority": "low", "cve_public_date": "2025-07-14 14:15:00 UTC" }, { "cve": "CVE-2026-4897", "url": "https://ubuntu.com/security/CVE-2026-4897", "cve_description": "A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the `polkit-agent-helper-1` setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system.", "cve_priority": "medium", "cve_public_date": "2026-03-26 15:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: OOB write via nested elements in XML policy", " - debian/patches/CVE-2025-7519.patch: check depth in", " src/polkitbackend/polkitbackendactionpool.c.", " - CVE-2025-7519", " * SECURITY UPDATE: DoS via excessively long input", " - debian/patches/CVE-2026-4897.patch: fix getline() string overflow in", " src/polkitagent/polkitagenthelperprivate.c.", " - CVE-2026-4897", "" ], "package": "policykit-1", "version": "0.105-33ubuntu0.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 10 Apr 2026 06:59:20 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "snapd", "from_version": { "source_package_name": "snapd", "source_package_version": "2.73+ubuntu22.04.1", "version": "2.73+ubuntu22.04.1" }, "to_version": { "source_package_name": "snapd", "source_package_version": "2.74.1+ubuntu22.04.4", "version": "2.74.1+ubuntu22.04.4" }, "cves": [ { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2138629, 2141328, 2139611, 2139300, 2139099, 2141607, 2116949, 2068493, 2134364, 2124239, 2122054, 2117558, 1916244, 2121238, 2117121, 2112626, 2114704 ], "changes": [ { "cves": [ { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" } ], "log": [ " ", " * New upstream release, LP: #2138629", " - FDE: secboot fixes", " - Security: CVE-2026-3888", " - Packaging: fix deb package version number", " - Packaging: fix autopkgtest failure to install spread", " - Packaging: revert dropping transitional packages", "" ], "package": "snapd", "version": "2.74.1+ubuntu22.04.4", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2138629 ], "author": "Ernest Lotter ", "date": "Thu, 02 Apr 2026 08:44:00 +0200" }, { "cves": [], "log": [ "", " - FDE: measure DeployedMode and AuditMode variables if they appear", " as disabled in the event log to avoid a potential reseal-failure", " boot loop", " - LP: #2141328 FDE: reuse preinstall check context during install to", " account for user-ignored errors", " - LP: #2139611 FDE: fix db updates by allowing multiple payloads", " - LP: #2139300 snap-confine: add CAP_SYS_RESOURCE to allow raising", " memory lock limit when required", " - LP: #2139099 snap-confine: bump the max element count of the BPF", " map used to store IDs of allowed/matched devices to 1000", " - LP: #2141607 Desktop: revert change that caused user daemons", " declaring the desktop plug to implicitly depend on graphical-", " session.target", " - Interfaces: Added pidfd_open and memfd_secret to seccomp template", " - Interfaces: camera | add locking permission for /dev/video", "" ], "package": "snapd", "version": "2.74.1+ubuntu22.04", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2141328, 2139611, 2139300, 2139099, 2141607 ], "author": "Ernest Lotter ", "date": "Thu, 12 Feb 2026 21:27:23 +0200" }, { "cves": [], "log": [ "", " - FDE: use new activation API from secboot", " - FDE: use activation API also with non keydata keys", " - FDE: ignore internal recovery key expiration during install", " - FDE: support adding/removing PINs post-installation", " - FDE: support changing PINs post-installation", " - FDE: support adding a recovery key post-installation", " - FDE: provide activation status via new endpoint v2/system-", " info/storage-encrypted", " - FDE: support sealing and resealing using the preinstall check", " result", " - FDE: disable passphrase support during install", " - FDE: add keyboard configuration helpers", " - FDE: lazily inject keyboard layout configuration in kernel cmdline", " - FDE: enable pin tries and limits PIN entry attempts to 3", " - FDE: extend secureboot endpoint to accept DB, KEK, and PK", " - FDE: simplify /v2/system-volumes keyslots handling by allowing", " name-only entries, implicitly expanding to all system containers", " - FDE: support extra non-system key slot names to support agents", " such as Landscape to set dedicated recovery keys", " - FDE: initialize fde state after device state", " - FDE: use device node to find the storage container and keys", " - FDE: provide user visible name for disk based on ID_MODEL", " - FDE: update secboot in snapd with latest additions and fixes", " - core-initrd: add systemd service for setting plymouth keyboard", " layout and X11 keyboard layouts", " - core-initrd: set plymouth cleartext toggle option", " - core-initrd: fix plymouth missing font issue", " - core-initrd: update dependency from libteec1 to libteec2", " - core-initrd: add new dlopened libs", " - LP: #2116949 Preseeding: add support for preseeding of hybrid", " systems via the installer API$", " - Preseeding: check whether a path is a mountpoint before remounting", " - Confdb: support tagging paths as secret in storage schemas", " - Confdb: support filtering on placeholder sub-keys", " - Confdb: support filtering in API and confdbstate", " - Confdb: support field filtering on reads", " - Confdb: support \"parameters\" stanza and check filters against them", " - Confdb: add support for '--with' contraints", " - Confdb: parsing fixes and error handling improvements", " - Assertions: restrict serials to new format in confdb-control", " - Assertions: add verify signature function", " - Remote device management: modify request-message assertion to", " expose its time constraints for remote device management", " - Remote device management: support polling of store messages", " - Remote device management: add signing of response messages with", " device key", " - Prompting: enable notify protocol v5 and test prompt restoration", " after snapd restart", " - snap: change malformed '--channel=' warning to error", " - snap: add 'snap report-issue' command to get the available contact", " details for the specified snap", " - snap: add 'snap version --verbose' flag to include information on", " snap binaries origin", " - snap: create the XDG_RUNTIME_DIR folder", " - LP: #2068493 snap: add support for 'snap refresh --tracking'", " - snapctl: add '--tracking' flag to 'snapctl refresh'", " - Reexec: include the info filepath in the version compare debug log", " - Reexec: add support for forcing reexec into and older snapd snap", " by setting SNAP_REEXEC=force in the environment", " - snap-confine: correct error message related to snap-confine group", " policy validation", " - snap-confine: ensure we only mount existing directories", " - LP: #2134364 snap-confine: handle potential race when creating", " /tmp/snap-private-tmp when lacking systemd-tmpfiles support", " - snap-confine: filter plus characters from security tags", " - Desktop: use desktop file IDs as desktop IDs", " - Desktop: store the common ID in the desktop file", " - Desktop: allow graphical daemons to show icons in the dock", " - Desktop: change user daemons with desktop plug defined to depend", " on graphical-session.target", " - dm-verity for essential snaps: made change to prerequisite struct", " - Cross-distro: modify SELinux profile to allow connecting to squid", " proxy", " - Cross-distro: add support for migrating snap mount directory", " - Packaging: drop ubuntu-14.04 packaging", " - Packaging: drop ubuntu-{14.04,16.04} transitional binary packages", " - Packaging: remove desktop files and state lock file during snapd", " purge", " - Packaging: fix inhibition hint file being left behind on failed", " unlink-current-snap", " - Disallow timeouts < 1us in systemd units", " - Add snap-store to the user-daemons support overrides", " - Support for SuccessExitStatus= generation for systemd daemon", " - Make standby output more verbose", " - Add prepare-serial-request hook", " - Try to discard snap mount namespaces when no processes are running", " during snap updates", " - Improve handling of snap downloads cache by introducing periodic", " cleanup with more aggressive policy", " - Interfaces: mediatek-accel | create new interface", " - Interfaces: nvidia-video-driver-libs | create new interface", " - Interfaces: *-driver-libs | accept component paths", " - Interfaces: desktop-legacy, unity7 | remove workaround for slash", " filtering in ibus address", " - Interfaces: fwupd | allow writing reboot notification in /run", " - Interfaces: add 'install' coreutil to base AppArmor template", " - Interfaces: u2f-devices | add apparmor permissions to allow the", " use of the libfido2 library in snaps", " - Interfaces: u2f-devices | add support for Thetis security key", " - Interfaces: add AppArmor workaround for mmap MAP_HUGETLB", " - Interfaces: timeserver-control | manage per-link ntp settings via", " systemd-networkd", "" ], "package": "snapd", "version": "2.74+ubuntu22.04", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2116949, 2068493, 2134364 ], "author": "Ernest Lotter ", "date": "Tue, 20 Jan 2026 18:54:17 +0200" }, { "cves": [], "log": [ "", " * New upstream release, LP: #2124239", " - FDE: support replacing TPM protected keys at runtime via the", " /v2/system-volumes endpoint", " - FDE: support secboot preinstall check fix actions for 25.10+", " hybrid installs via the /v2/system/{label} endpoint", " - FDE: tweak polkit message to remove jargon", " - FDE: ensure proper sealing with kernel command line defaults", " - FDE: provide generic reseal function", " - FDE: support using OPTEE for protecting keys, as an alternative to", " existing fde-setup hooks (Ubuntu Core only)", " - Confdb: 'snapctl get --view' supports passing default values", " - Confdb: content sub-rules in confdb-schemas inherit their parent", " rule's \"access\"", " - Confdb: make confdb error kinds used in API more generic", " - Confdb: fully support lists and indexed paths (including unset)", " - Prompting: add notice backend for prompting types (unused for now)", " - Prompting: include request cgroup in prompt", " - Prompting: handle unsupported xattrs", " - Prompting: add permission mapping for the camera interface", " - Notices: read notices from state without state lock", " - Notices: add methods to get notice fields and create, reoccur, and", " deepcopy notice", " - Notices: add notice manager to coordinate separate notice backends", " - Notices: support draining notices from state when notice backend", " registered as producer of a particular notice type", " - Notices: query notice manager from daemon instead of querying", " state for notices directly", " - Packaging: Ubuntu | ignore .git directory", " - Packaging: FIPS | bump deb Go FIPS to 1.23", " - Packaging: snap | bump FIPS toolchain to 1.23", " - Packaging: debian | sync most upstream changes", " - Packaging: debian-sid | depends on libcap2-bin for postint", " - Packaging: Fedora | drop fakeroot", " - Packaging: snap | modify snapd.mk to pass build tags when running", " unit tests", " - Packaging: snap | modify snapd.mk to pass nooptee build tag", " - Packaging: modify Makefile.am to fix snap-confine install profile", " with 'make hack'", " - Packaging: modify Makefile.am to fix out-of-tree use of 'make", " hack'", " - LP: #2122054 Snap installation: skip snap icon download when", " running in a cloud or using a proxy store", " - Snap installation: add timeout to http client when downloading", " snap icon", " - Snap installation: use http(s) proxy for icon downloads", " - LP: #2117558 snap-confine: fix error message with /root/snap not", " accessible", " - snap-confine: fix non-suid limitation by switching to root:root to", " operate v1 freezer", " - core-initrd: do not use writable-paths when not available", " - core-initrd: remove debian folder", " - LP: #1916244 Interfaces: gpio-chardev | re-enable the gpio-chardev", " interface now with the more robust gpio-aggregator configfs kernel", " interface", " - Interfaces: gpio-chardev | exclusive snap connections, raise a", " conflict when both gpio-chardev and gpio are connected", " - Interfaces: gpio-chardev | fix gpio-aggregator module load order", " - Interfaces: ros-snapd-support | grant access to /v2/changes", " - Interfaces: uda-driver-libs, egl-driver-libs, gbm-driver-libs,", " opengl-driver-libs, opengles-driver-libs | new interfaces to", " support nvidia driver components", " - Interfaces: microstack-support | allow DPDK (hugepage related", " permissions)", " - Interfaces: system-observe | allow reading additional files in", " /proc, needed by node-exporter", " - Interfaces: u2f | add Cano Key, Thesis FIDO2 BioFP+ Security Key", " and Kensington VeriMark DT Fingerprint Key to device list", " - Interfaces: snap-interfaces-requests-control | allow shell API", " control", " - Interfaces: fwupd | allow access to Intel CVS sysfs", " - Interfaces: hardware-observe | allow read access to Kernel", " Samepage Merging (KSM)", " - Interfaces: xilinx-dma | support Multi Queue DMA (QDMA) IP", " - Interfaces: spi | relax sysfs permission rules to allow access to", " SPI device node attributes", " - Interfaces: content | introduce compatibility label", " - LP: #2121238 Interfaces: do not expose Kerberos tickets for", " classic snaps", " - Interfaces: ssh-public-keys | allow ro access to public host keys", " with ssh-key", " - Interfaces: Modify AppArmor template to allow listing systemd", " credentials and invoking systemd-creds", " - Interfaces: modify AppArmor template with workarounds for Go 1.35", " cgroup aware GOMAXPROCS", " - Interfaces: modify seccomp template to allow landlock_*", " - Prevent snap hooks from running while relevant snaps are unlinked", " - Make refreshes wait before unlinking snaps if running hooks can be", " affected", " - Fix systemd unit generation by moving \"WantedBy=\" from section", " \"unit\" to \"install\"", " - Add opt-in logging support for snap-update-ns", " - Unhide 'snap help' sign and export-key under Development category", " - LP: #2117121 Cleanly support socket activation for classic snap", " - Add architecture to 'snap version' output", " - Add 'snap debug api' option to disable authentication through", " auth.json", " - Show grade in notes for 'snap info --verbose'", " - Fix preseeding failure due to scan-disk issue on RPi", " - Support 'snap debug api' queries to user session agents", " - LP: #2112626 Improve progress reporting for snap install/refresh", " - Drop legacy BAMF_DESKTOP_FILE_HINT in desktop files", " - Fix /v2/apps error for root user when user services are present", " - LP: #2114704 Extend output to indicate when snap data snapshot was", " created during remove", " - Improve how we handle emmc volumes", " - Improve handling of system-user extra assertions", "" ], "package": "snapd", "version": "2.72", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2124239, 2122054, 2117558, 1916244, 2121238, 2117121, 2112626, 2114704 ], "author": "Ernest Lotter ", "date": "Thu, 18 Sep 2025 10:00:54 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "xxd", "from_version": { "source_package_name": "vim", "source_package_version": "2:8.2.3995-1ubuntu2.26", "version": "2:8.2.3995-1ubuntu2.26" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:8.2.3995-1ubuntu2.27", "version": "2:8.2.3995-1ubuntu2.27" }, "cves": [ { "cve": "CVE-2026-33412", "url": "https://ubuntu.com/security/CVE-2026-33412", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0202, a command injection vulnerability exists in Vim's glob() function on Unix-like systems. By including a newline character (\\n) in a pattern passed to glob(), an attacker may be able to execute arbitrary shell commands. This vulnerability depends on the user's 'shell' setting. This issue has been patched in version 9.2.0202.", "cve_priority": "medium", "cve_public_date": "2026-03-24 20:16:00 UTC" }, { "cve": "CVE-2026-34982", "url": "https://ubuntu.com/security/CVE-2026-34982", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0276, a modeline sandbox bypass in Vim allows arbitrary OS command execution when a user opens a crafted file. The `complete`, `guitabtooltip` and `printheader` options are missing the `P_MLE` flag, allowing a modeline to be executed. Additionally, the `mapset()` function lacks a `check_secure()` call, allowing it to be abused from sandboxed expressions. Commit 9.2.0276 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-04-06 16:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-33412", "url": "https://ubuntu.com/security/CVE-2026-33412", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0202, a command injection vulnerability exists in Vim's glob() function on Unix-like systems. By including a newline character (\\n) in a pattern passed to glob(), an attacker may be able to execute arbitrary shell commands. This vulnerability depends on the user's 'shell' setting. This issue has been patched in version 9.2.0202.", "cve_priority": "medium", "cve_public_date": "2026-03-24 20:16:00 UTC" }, { "cve": "CVE-2026-34982", "url": "https://ubuntu.com/security/CVE-2026-34982", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0276, a modeline sandbox bypass in Vim allows arbitrary OS command execution when a user opens a crafted file. The `complete`, `guitabtooltip` and `printheader` options are missing the `P_MLE` flag, allowing a modeline to be executed. Additionally, the `mapset()` function lacks a `check_secure()` call, allowing it to be abused from sandboxed expressions. Commit 9.2.0276 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-04-06 16:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Command injection in glob.", " - debian/patches/CVE-2026-33412.patch: Add newline to SHELL_SPECIAL in", " src/os_unix.c.", " - CVE-2026-33412", " * SECURITY UPDATE: Security bypass in modeline.", " - debian/patches/CVE-2026-34982.patch: Disallow modeset while in secure", " mode in src/optiondefs.h.", " - CVE-2026-34982", "" ], "package": "vim", "version": "2:8.2.3995-1ubuntu2.27", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Kyle Kernick ", "date": "Mon, 06 Apr 2026 14:13:36 -0600" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-5.15.0-1097-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1096.101", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1097.102", "version": "5.15.0-1097.102" }, "cves": [ { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2026-23170", "url": "https://ubuntu.com/security/CVE-2026-23170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imx/tve: fix probe device leak Make sure to drop the reference taken to the DDC device during probe on probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23075", "url": "https://ubuntu.com/security/CVE-2026-23075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In esd_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback esd_usb_read_bulk_callback(), the URBs are processed and resubmitted. In esd_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in esd_usb_close(). Fix the memory leak by anchoring the URB in the esd_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-38408", "url": "https://ubuntu.com/security/CVE-2025-38408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: genirq/irq_sim: Initialize work context pointers properly Initialize `ops` member's pointers properly by using kzalloc() instead of kmalloc() when allocating the simulation work context. Otherwise the pointers contain random content leading to invalid dereferencing.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2023-54207", "url": "https://ubuntu.com/security/CVE-2023-54207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: Correct devm device reference for hidinput input_dev name Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management. Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string.", "cve_priority": "medium", "cve_public_date": "2025-12-30 13:16:00 UTC" }, { "cve": "CVE-2023-53520", "url": "https://ubuntu.com/security/CVE-2023-53520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix hci_suspend_sync crash If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.", "cve_priority": "medium", "cve_public_date": "2025-10-01 12:15:00 UTC" }, { "cve": "CVE-2025-38125", "url": "https://ubuntu.com/security/CVE-2025-38125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring EST If the ptp_rate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0. Prevent this division by 0 by adding the corresponding check and error code.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-40164", "url": "https://ubuntu.com/security/CVE-2025-40164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix using smp_processor_id() in preemptible code warnings Syzbot reported the following warning: BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879 caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary) Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f For historical and portability reasons, the netif_rx() is usually run in the softirq or interrupt context, this commit therefore add local_bh_disable/enable() protection in the usbnet_resume_rx().", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-38232", "url": "https://ubuntu.com/security/CVE-2025-38232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix race between nfsd registration and exports_proc As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd. Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd for 5.4 kernel ARM64: CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0 CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 PC is at : exports_net_open+0x50/0x68 [nfsd] Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248 Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu(). and same is happening on latest 6.14 kernel as well: [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]--- It reproduced simply with below script: while [ 1 ] do /exportfs -r done & while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done & So exporting interfaces to user space shall be done at last and cleanup at first place. With change there is no Kernel OOPs.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2023-53662", "url": "https://ubuntu.com/security/CVE-2023-53662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup} If the filename casefolding fails, we'll be leaking memory from the fscrypt_name struct, namely from the 'crypto_buf.name' member. Make sure we free it in the error path on both ext4_fname_setup_filename() and ext4_fname_prepare_lookup() functions.", "cve_priority": "medium", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2025-38057", "url": "https://ubuntu.com/security/CVE-2025-38057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: fix skb leaks A few error paths are missing a kfree_skb.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2023-53421", "url": "https://ubuntu.com/security/CVE-2023-53421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats() When blkg_alloc() is called to allocate a blkcg_gq structure with the associated blkg_iostat_set's, there are 2 fields within blkg_iostat_set that requires proper initialization - blkg & sync. The former field was introduced by commit 3b8cc6298724 (\"blk-cgroup: Optimize blkcg_rstat_flush()\") while the later one was introduced by commit f73316482977 (\"blk-cgroup: reimplement basic IO stats using cgroup rstat\"). Unfortunately those fields in the blkg_iostat_set's are not properly re-initialized when they are cleared in v1's blkcg_reset_stats(). This can lead to a kernel panic due to NULL pointer access of the blkg pointer. The missing initialization of sync is less problematic and can be a problem in a debug kernel due to missing lockdep initialization. Fix these problems by re-initializing them after memory clearing.", "cve_priority": "medium", "cve_public_date": "2025-09-18 16:15:00 UTC" }, { "cve": "CVE-2025-68365", "url": "https://ubuntu.com/security/CVE-2025-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Initialize allocated memory before use KMSAN reports: Multiple uninitialized values detected: - KMSAN: uninit-value in ntfs_read_hdr (3) - KMSAN: uninit-value in bcmp (3) Memory is allocated by __getname(), which is a wrapper for kmem_cache_alloc(). This memory is used before being properly cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to properly allocate and clear memory before use.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68817", "url": "https://ubuntu.com/security/CVE-2025-68817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency Under high concurrency, A tree-connection object (tcon) is freed on a disconnect path while another path still holds a reference and later executes *_put()/write on it.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2022-50390", "url": "https://ubuntu.com/security/CVE-2022-50390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATED Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c ttm_bo_move_memcpy+0x3b4/0x460 [ttm] bo_driver_move+0x32/0x40 [drm_vram_helper] ttm_bo_handle_move_mem+0x118/0x200 [ttm] ttm_bo_validate+0xfa/0x220 [ttm] drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper] drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper] drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper] drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper] drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper] drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper] drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper] drm_atomic_commit+0x9c/0x160 [drm] drm_client_modeset_commit_atomic+0x33a/0x380 [drm] drm_client_modeset_commit_locked+0x77/0x220 [drm] drm_client_modeset_commit+0x31/0x60 [drm] __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper] drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper] fbcon_init+0x316/0x790 visual_init+0x113/0x1d0 do_bind_con_driver+0x2a3/0x5c0 do_take_over_console+0xa9/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ", "cve_priority": "medium", "cve_public_date": "2025-09-18 14:15:00 UTC" }, { "cve": "CVE-2025-68211", "url": "https://ubuntu.com/security/CVE-2025-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksm: use range-walk function to jump over holes in scan_get_next_rmap_item Currently, scan_get_next_rmap_item() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages. This patch replaces the per-address lookup with a range walk using walk_page_range(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1]. Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page: #include #include #include /* 32 TiB */ const size_t size = 32ul * 1024 * 1024 * 1024 * 1024; int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror(\"mmap() failed\\n\"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0; } $ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-23093", "url": "https://ubuntu.com/security/CVE-2026-23093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbd: fix dma_unmap_sg() nents The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23078", "url": "https://ubuntu.com/security/CVE-2026-23078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Fix buffer overflow in config retrieval The scarlett2_usb_get_config() function has a logic error in the endianness conversion code that can cause buffer overflows when count > 1. The code checks `if (size == 2)` where `size` is the total buffer size in bytes, then loops `count` times treating each element as u16 (2 bytes). This causes the loop to access `count * 2` bytes when the buffer only has `size` bytes allocated. Fix by checking the element size (config_item->size) instead of the total buffer size. This ensures the endianness conversion matches the actual element type.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71186", "url": "https://ubuntu.com/security/CVE-2025-71186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: stm32: dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71197", "url": "https://ubuntu.com/security/CVE-2025-71197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: therm: Fix off-by-one buffer overflow in alarms_store The sysfs buffer passed to alarms_store() is allocated with 'size + 1' bytes and a NUL terminator is appended. However, the 'size' argument does not account for this extra byte. The original code then allocated 'size' bytes and used strcpy() to copy 'buf', which always writes one byte past the allocated buffer since strcpy() copies until the NUL terminator at index 'size'. Fix this by parsing the 'buf' parameter directly using simple_strtoll() without allocating any intermediate memory or string copying. This removes the overflow while simplifying the code.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23087", "url": "https://ubuntu.com/security/CVE-2026-23087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Fix potential memory leak in scsiback_remove() Memory allocated for struct vscsiblk_info in scsiback_probe() is not freed in scsiback_remove() leading to potential memory leaks on remove, as well as in the scsiback_probe() error paths. Fix that by freeing it in scsiback_remove().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-40149", "url": "https://ubuntu.com/security/CVE-2025-40149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock(). get_netdev_for_sock() is called during setsockopt(), so not under RCU. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the only ->ndo_sk_get_lower_dev() user is bond_sk_get_lower_dev(), which uses RCU.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-23167", "url": "https://ubuntu.com/security/CVE-2026-23167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix race between rfkill and nci_unregister_device(). syzbot reported the splat below [0] without a repro. It indicates that struct nci_dev.cmd_wq had been destroyed before nci_close_device() was called via rfkill. nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which (I think) was called from virtual_ncidev_close() when syzbot close()d an fd of virtual_ncidev. The problem is that nci_unregister_device() destroys nci_dev.cmd_wq first and then calls nfc_unregister_device(), which removes the device from rfkill by rfkill_unregister(). So, the device is still visible via rfkill even after nci_dev.cmd_wq is destroyed. Let's unregister the device from rfkill first in nci_unregister_device(). Note that we cannot call nfc_unregister_device() before nci_close_device() because 1) nfc_unregister_device() calls device_del() which frees all memory allocated by devm_kzalloc() and linked to ndev->conn_info_list 2) nci_rx_work() could try to queue nci_conn_info to ndev->conn_info_list which could be leaked Thus, nfc_unregister_device() is split into two functions so we can remove rfkill interfaces only before nci_close_device(). [0]: DEBUG_LOCKS_WARN_ON(1) WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349 Modules linked in: CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline] RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187 Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f RSP: 0018:ffffc9000c767680 EFLAGS: 00010046 RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000 RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0 RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4 R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2 R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30 FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0 Call Trace: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ksys_write+0x150/0x270 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa59b39acb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9 RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007 RBP: 00007fa59b408bf7 R08: ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23150", "url": "https://ubuntu.com/security/CVE-2026-23150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame(). syzbot reported various memory leaks related to NFC, struct nfc_llcp_sock, sk_buff, nfc_dev, etc. [0] The leading log hinted that nfc_llcp_send_ui_frame() failed to allocate skb due to sock_error(sk) being -ENXIO. ENXIO is set by nfc_llcp_socket_release() when struct nfc_llcp_local is destroyed by local_cleanup(). The problem is that there is no synchronisation between nfc_llcp_send_ui_frame() and local_cleanup(), and skb could be put into local->tx_queue after it was purged in local_cleanup(): CPU1 CPU2 ---- ---- nfc_llcp_send_ui_frame() local_cleanup() |- do { ' |- pdu = nfc_alloc_send_skb(..., &err) | . | |- nfc_llcp_socket_release(local, false, ENXIO); | |- skb_queue_purge(&local->tx_queue); | | ' | |- skb_queue_tail(&local->tx_queue, pdu); | ... | |- pdu = nfc_alloc_send_skb(..., &err) | ^._________________________________.' local_cleanup() is called for struct nfc_llcp_local only after nfc_llcp_remove_local() unlinks it from llcp_devices. If we hold local->tx_queue.lock then, we can synchronise the thread and nfc_llcp_send_ui_frame(). Let's do that and check list_empty(&local->list) before queuing skb to local->tx_queue in nfc_llcp_send_ui_frame(). [0]: [ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6) [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak) BUG: memory leak unreferenced object 0xffff8881272f6800 (size 1024): comm \"syz.0.17\", pid 6096, jiffies 4294942766 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc da58d84d): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658 kmalloc_noprof include/linux/slab.h:961 [inline] sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239 sk_alloc+0x36/0x360 net/core/sock.c:2295 nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31 __sock_create+0x1a9/0x340 net/socket.c:1605 sock_create net/socket.c:1663 [inline] __sys_socket_create net/socket.c:1700 [inline] __sys_socket+0xb9/0x1a0 net/socket.c:1747 __do_sys_socket net/socket.c:1761 [inline] __se_sys_socket net/socket.c:1759 [inline] __x64_sys_socket+0x1b/0x30 net/socket.c:1759 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: memory leak unreferenced object 0xffff88810fbd9800 (size 240): comm \"syz.0.17\", pid 6096, jiffies 4294942850 hex dump (first 32 bytes): 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h....... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'.... backtrace (crc 6cc652b1): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/sk ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23164", "url": "https://ubuntu.com/security/CVE-2026-23164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rocker: fix memory leak in rocker_world_port_post_fini() In rocker_world_port_pre_init(), rocker_port->wpriv is allocated with kzalloc(wops->port_priv_size, GFP_KERNEL). However, in rocker_world_port_post_fini(), the memory is only freed when wops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv); Since rocker_ofdpa_ops does not implement port_post_fini callback (it is NULL), the wpriv memory allocated for each port is never freed when ports are removed. This leads to a memory leak of sizeof(struct ofdpa_port) bytes per port on every device removal. Fix this by always calling kfree(rocker_port->wpriv) regardless of whether the port_post_fini callback exists.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23146", "url": "https://ubuntu.com/security/CVE-2026-23146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling hci_uart_register_dev(), which calls proto->open() to initialize hu->priv. However, if a TTY write wakeup occurs during this window, hci_uart_tx_wakeup() may schedule write_work before hu->priv is initialized, leading to a NULL pointer dereference in hci_uart_write_work() when proto->dequeue() accesses hu->priv. The race condition is: CPU0 CPU1 ---- ---- hci_uart_set_proto() set_bit(HCI_UART_PROTO_INIT) hci_uart_register_dev() tty write wakeup hci_uart_tty_wakeup() hci_uart_tx_wakeup() schedule_work(&hu->write_work) proto->open(hu) // initializes hu->priv hci_uart_write_work() hci_uart_dequeue() proto->dequeue(hu) // accesses hu->priv (NULL!) Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open() succeeds, ensuring hu->priv is initialized before any work can be scheduled.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-38591", "url": "https://ubuntu.com/security/CVE-2025-38591", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject narrower access to pointer ctx fields The following BPF program, simplified from a syzkaller repro, causes a kernel warning: r0 = *(u8 *)(r1 + 169); exit; With pointer field sk being at offset 168 in __sk_buff. This access is detected as a narrower read in bpf_skb_is_valid_access because it doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed and later proceeds to bpf_convert_ctx_access. Note that for the \"is_narrower_load\" case in the convert_ctx_accesses(), the insn->off is aligned, so the cnt may not be 0 because it matches the offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However, the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1) This patch fixes that to return a proper \"invalid bpf_context access off=X size=Y\" error on the load instruction. The same issue affects multiple other fields in context structures that allow narrow access. Some other non-affected fields (for sk_msg, sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for consistency. Note this syzkaller crash was reported in the \"Closes\" link below, which used to be about a different bug, fixed in commit fce7bd8e385a (\"bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()\"). Because syzbot somehow confused the two bugs, the new crash and repro didn't get reported to the mailing list.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-68725", "url": "https://ubuntu.com/security/CVE-2025-68725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do not let BPF test infra emit invalid GSO types to stack Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled. We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place. The checks were added in 121d57af308d (\"gso: validate gso_type in GSO handlers\") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2026-23097", "url": "https://ubuntu.com/security/CVE-2026-23097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: migrate: correct lock ordering for hugetlb file folios Syzbot has found a deadlock (analyzed by Lance Yang): 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock! The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing i_mmap_lock to cover the calls to remove_migration_ptes() too. This is (mostly) how it used to be after commit c0d0381ade79. That was removed by 336bf30eb765 for both file & anon hugetlb pages when it should only have been removed for anon hugetlb pages.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23108", "url": "https://ubuntu.com/security/CVE-2026-23108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback usb_8dev_read_bulk_callback(), the URBs are processed and resubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the usb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23080", "url": "https://ubuntu.com/security/CVE-2026-23080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In mcba_usb_probe() -> mcba_usb_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback mcba_usb_read_bulk_callback(), the URBs are processed and resubmitted. In mcba_usb_close() -> mcba_urb_unlink() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the mcba_usb_read_bulk_callback()to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23061", "url": "https://ubuntu.com/security/CVE-2026-23061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In kvaser_usb_set_{,data_}bittiming() -> kvaser_usb_setup_rx_urbs(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback kvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. In kvaser_usb_remove_interfaces() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the kvaser_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23058", "url": "https://ubuntu.com/security/CVE-2026-23058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In ems_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In ems_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in ems_usb_close(). Fix the memory leak by anchoring the URB in the ems_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23085", "url": "https://ubuntu.com/security/CVE-2026-23085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Avoid truncating memory addresses On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23098", "url": "https://ubuntu.com/security/CVE-2026-23098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netrom: fix double-free in nr_route_frame() In nr_route_frame(), old_skb is immediately freed without checking if nr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL, the caller function will free old_skb again, causing a double-free bug. Therefore, to prevent this, we need to modify it to check whether nr_neigh->ax25 is NULL before freeing old_skb.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23063", "url": "https://ubuntu.com/security/CVE-2026-23063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: ensure safe queue release with state management Directly calling `put_queue` carries risks since it cannot guarantee that resources of `uacce_queue` have been fully released beforehand. So adding a `stop_queue` operation for the UACCE_CMD_PUT_Q command and leaving the `put_queue` operation to the final resource release ensures safety. Queue states are defined as follows: - UACCE_Q_ZOMBIE: Initial state - UACCE_Q_INIT: After opening `uacce` - UACCE_Q_STARTED: After `start` is issued via `ioctl` When executing `poweroff -f` in virt while accelerator are still working, `uacce_fops_release` and `uacce_remove` may execute concurrently. This can cause `uacce_put_queue` within `uacce_fops_release` to access a NULL `ops` pointer. Therefore, add state checks to prevent accessing freed pointers.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23056", "url": "https://ubuntu.com/security/CVE-2026-23056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: implement mremap in uacce_vm_ops to return -EPERM The current uacce_vm_ops does not support the mremap operation of vm_operations_struct. Implement .mremap to return -EPERM to remind users. The reason we need to explicitly disable mremap is that when the driver does not implement .mremap, it uses the default mremap method. This could lead to a risk scenario: An application might first mmap address p1, then mremap to p2, followed by munmap(p1), and finally munmap(p2). Since the default mremap copies the original vma's vm_private_data (i.e., q) to the new vma, both munmap operations would trigger vma_close, causing q->qfr to be freed twice(qfr will be set to null here, so repeated release is ok).", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23096", "url": "https://ubuntu.com/security/CVE-2026-23096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: fix cdev handling in the cleanup path When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23091", "url": "https://ubuntu.com/security/CVE-2026-23091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix device leak on output open() Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close(). Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23090", "url": "https://ubuntu.com/security/CVE-2026-23090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: core: fix device reference leak on report present Slimbus devices can be allocated dynamically upon reception of report-present messages. Make sure to drop the reference taken when looking up already registered devices. Note that this requires taking an extra reference in case the device has not yet been registered and has to be allocated.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23128", "url": "https://ubuntu.com/security/CVE-2026-23128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Set __nocfi on swsusp_arch_resume() A DABT is reported[1] on an android based system when resume from hiberate. This happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*() and does not have a CFI hash, but swsusp_arch_resume() will attempt to verify the CFI hash when calling a copy of swsusp_arch_suspend_exit(). Given that there's an existing requirement that the entrypoint to swsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text section, we cannot fix this by marking swsusp_arch_suspend_exit() with SYM_FUNC_*(). The simplest fix for now is to disable the CFI check in swsusp_arch_resume(). Mark swsusp_arch_resume() as __nocfi to disable the CFI check. [1] [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc [ 22.991934][ T1] Mem abort info: [ 22.991934][ T1] ESR = 0x0000000096000007 [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [ 22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][ T1] FSC = 0x07: level 3 translation fault [ 22.991934][ T1] Data abort info: [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 22.991934][ T1] Dumping ftrace buffer: [ 22.991934][ T1] (ftrace buffer empty) [ 22.991934][ T1] Modules linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419 [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT) [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344 [ 22.991934][ T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000 [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820 [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000 [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058 [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004 [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000 [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000 [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530 [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000 [ 22.991934][ T1] Call trace: [ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] hibernation_restore+0x158/0x18c [ 22.991934][ T1] load_image_and_restore+0xb0/0xec [ 22.991934][ T1] software_resume+0xf4/0x19c [ 22.991934][ T1] software_resume_initcall+0x34/0x78 [ 22.991934][ T1] do_one_initcall+0xe8/0x370 [ 22.991934][ T1] do_initcall_level+0xc8/0x19c [ 22.991934][ T1] do_initcalls+0x70/0xc0 [ 22.991934][ T1] do_basic_setup+0x1c/0x28 [ 22.991934][ T1] kernel_init_freeable+0xe0/0x148 [ 22.991934][ T1] kernel_init+0x20/0x1a8 [ 22.991934][ T1] ret_from_fork+0x10/0x20 [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110) [catalin.marinas@arm.com: commit log updated by Mark Rutland]", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23073", "url": "https://ubuntu.com/security/CVE-2026-23073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: Fix memory corruption due to not set vif driver data size The struct ieee80211_vif contains trailing space for vif driver data, when struct ieee80211_vif is allocated, the total memory size that is allocated is sizeof(struct ieee80211_vif) + size of vif driver data. The size of vif driver data is set by each WiFi driver as needed. The RSI911x driver does not set vif driver data size, no trailing space for vif driver data is therefore allocated past struct ieee80211_vif . The RSI911x driver does however use the vif driver data to store its vif driver data structure \"struct vif_priv\". An access to vif->drv_priv leads to access out of struct ieee80211_vif bounds and corruption of some memory. In case of the failure observed locally, rsi_mac80211_add_interface() would write struct vif_priv *vif_info = (struct vif_priv *)vif->drv_priv; vif_info->vap_id = vap_idx. This write corrupts struct fq_tin member struct list_head new_flows . The flow = list_first_entry(head, struct fq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus address, which when accessed causes a crash. The trigger is very simple, boot the machine with init=/bin/sh , mount devtmpfs, sysfs, procfs, and then do \"ip link set wlan0 up\", \"sleep 1\", \"ip link set wlan0 down\" and the crash occurs. Fix this by setting the correct size of vif driver data, which is the size of \"struct vif_priv\", so that memory is allocated and the driver can store its driver data in it, instead of corrupting memory around it.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23133", "url": "https://ubuntu.com/security/CVE-2026-23133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: fix dma_free_coherent() pointer dma_alloc_coherent() allocates a DMA mapped buffer and stores the addresses in XXX_unaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23089", "url": "https://ubuntu.com/security/CVE-2026-23089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free() When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees mixer->id_elems but the controls already added to the card still reference the freed memory. Later when snd_card_register() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read. Call trace: get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381 snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ... snd_card_register+0x4ed/0x6d0 sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025 Fix by calling snd_ctl_remove() for all mixer controls before freeing id_elems. We save the next pointer first because snd_ctl_remove() frees the current element.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23076", "url": "https://ubuntu.com/security/CVE-2026-23076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix potential OOB access in audio mixer handling In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixer_index() and sum_index()). As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]' After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field. This patch addresses those OOB accesses by adding the proper initializations of the loop indices.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71199", "url": "https://ubuntu.com/security/CVE-2025-71199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver at91_adc_interrupt can call at91_adc_touch_data_handler function to start the work by schedule_work(&st->touch_st.workq). If we remove the module which will call at91_adc_remove to make cleanup, it will free indio_dev through iio_device_unregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | at91_adc_workq_handler at91_adc_remove | iio_device_unregister(indio_dev) | //free indio_dev a bit later | | iio_push_to_buffers(indio_dev) | //use indio_dev Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91_adc_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23101", "url": "https://ubuntu.com/security/CVE-2026-23101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: led-class: Only Add LED to leds_list when it is fully ready Before this change the LED was added to leds_list before led_init_core() gets called adding it the list before led_classdev.set_brightness_work gets initialized. This leaves a window where led_trigger_register() of a LED's default trigger will call led_trigger_set() which calls led_set_brightness() which in turn will end up queueing the *uninitialized* led_classdev.set_brightness_work. This race gets hit by the lenovo-thinkpad-t14s EC driver which registers 2 LEDs with a default trigger provided by snd_ctl_led.ko in quick succession. The first led_classdev_register() causes an async modprobe of snd_ctl_led to run and that async modprobe manages to exactly hit the window where the second LED is on the leds_list without led_init_core() being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998 Close the race window by moving the adding of the LED to leds_list to after the led_init_core() call.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23064", "url": "https://ubuntu.com/security/CVE-2026-23064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: avoid possible NULL deref tcf_ife_encode() must make sure ife_encode() does not return NULL. syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166 CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full) Call Trace: ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23119", "url": "https://ubuntu.com/security/CVE-2026-23119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: provide a net pointer to __skb_flow_dissect() After 3cbf4ffba5ee (\"net: plumb network namespace into __skb_flow_dissect\") we have to provide a net pointer to __skb_flow_dissect(), either via skb->dev, skb->sk, or a user provided pointer. In the following case, syzbot was able to cook a bare skb. WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053 Call Trace: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23084", "url": "https://ubuntu.com/security/CVE-2026-23084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list When the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() is set to false, the driver may request the PMAC_ID from the firmware of the network card, and this function will store that PMAC_ID at the provided address pmac_id. This is the contract of this function. However, there is a location within the driver where both pmac_id_valid == false and pmac_id == NULL are being passed. This could result in dereferencing a NULL pointer. To resolve this issue, it is necessary to pass the address of a stub variable to the function.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23124", "url": "https://ubuntu.com/security/CVE-2026-23124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: annotate data-race in ndisc_router_discovery() syzbot found that ndisc_router_discovery() could read and write in6_dev->ra_mtu without holding a lock [1] This looks fine, IFLA_INET6_RA_MTU is best effort. Add READ_ONCE()/WRITE_ONCE() to document the race. Note that we might also reject illegal MTU values (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch. [1] BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... value changed: 0x00000000 -> 0xe5400659", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23121", "url": "https://ubuntu.com/security/CVE-2026-23121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mISDN: annotate data-race around dev->work dev->work can re read locklessly in mISDN_read() and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations. BUG: KCSAN: data-race in mISDN_ioctl / mISDN_read write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [inline] vfs_readv+0x3fb/0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [inline] __se_sys_readv fs/read_write.c:1162 [inline] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000 -> 0x00000001", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23071", "url": "https://ubuntu.com/security/CVE-2026-23071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: Fix race condition in hwspinlock irqsave routine Previously, the address of the shared member '&map->spinlock_flags' was passed directly to 'hwspin_lock_timeout_irqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shared flags variable, potentially corrupting the state for the current lock owner. Fix this by using a local stack variable 'flags' to store the IRQ state temporarily.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23105", "url": "https://ubuntu.com/security/CVE-2026-23105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag This is more of a preventive patch to make the code more consistent and to prevent possible exploits that employ child qlen manipulations on qfq. use cl_is_active instead of relying on the child qdisc's qlen to determine class activation.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23103", "url": "https://ubuntu.com/security/CVE-2026-23103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close) This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause: 1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock. 2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23120", "url": "https://ubuntu.com/security/CVE-2026-23120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: avoid one data-race in l2tp_tunnel_del_work() We should read sk->sk_socket only when dealing with kernel sockets. syzbot reported the following data-race: BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 value changed: 0xffff88811b818000 -> 0x0000000000000000", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23083", "url": "https://ubuntu.com/security/CVE-2026-23083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Don't allow 0 for FOU_ATTR_IPPROTO. fou_udp_recv() has the same problem mentioned in the previous patch. If FOU_ATTR_IPPROTO is set to 0, skb is not freed by fou_udp_recv() nor \"resubmit\"-ted in ip_protocol_deliver_rcu(). Let's forbid 0 for FOU_ATTR_IPPROTO.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23095", "url": "https://ubuntu.com/security/CVE-2026-23095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: Fix skb memleak with inner IP protocol 0. syzbot reported skb memleak below. [0] The repro generated a GUE packet with its inner protocol 0. gue_udp_recv() returns -guehdr->proto_ctype for \"resubmit\" in ip_protocol_deliver_rcu(), but this only works with non-zero protocol number. Let's drop such packets. Note that 0 is a valid number (IPv6 Hop-by-Hop Option). I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT [0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm \"syz.0.17\", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23125", "url": "https://ubuntu.com/security/CVE-2026-23125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key initialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127 The issue is triggered when sctp_auth_asoc_init_active_key() fails in sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the command sequence is currently: - SCTP_CMD_PEER_INIT - SCTP_CMD_TIMER_STOP (T1_INIT) - SCTP_CMD_TIMER_START (T1_COOKIE) - SCTP_CMD_NEW_STATE (COOKIE_ECHOED) - SCTP_CMD_ASSOC_SHKEY - SCTP_CMD_GEN_COOKIE_ECHO If SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while asoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL to be queued by sctp_datamsg_from_user(). Since command interpretation stops on failure, no COOKIE_ECHO should been sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As a result, the DATA chunk can be transmitted together with the COOKIE_ECHO in sctp_outq_flush_data(), leading to the observed issue. Similar to the other places where it calls sctp_auth_asoc_init_active_key() right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting T1_COOKIE. This ensures that if shared key generation fails, authenticated DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT, giving the client another chance to process INIT_ACK and retry key setup.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23099", "url": "https://ubuntu.com/security/CVE-2026-23099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: limit BOND_MODE_8023AD to Ethernet devices BOND_MODE_8023AD makes sense for ARPHRD_ETHER only. syzbot reported: BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline] BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497 CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [inline] __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [inline] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e The buggy address belongs to the variable: lacpdu_mcast_addr+0x0/0x40", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71194", "url": "https://ubuntu.com/security/CVE-2025-71194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock in wait_current_trans() due to ignored transaction type When wait_current_trans() is called during start_transaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfs_blocked_trans_types[] array already defines which transaction types should wait for which transaction states, but this check was missing in wait_current_trans(). This can lead to a deadlock scenario involving two transactions and pending ordered extents: 1. Transaction A is in TRANS_STATE_COMMIT_DOING state 2. A worker processing an ordered extent calls start_transaction() with TRANS_JOIN 3. join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes 5. A new Transaction B is created (TRANS_STATE_RUNNING) 6. The ordered extent from step 2 is added to Transaction B's pending ordered extents 7. Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START 8. The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[] 10. Transaction B is waiting for pending ordered extents to complete 11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B This can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!) Task bstore_kv_sync in btrfs_commit_transaction waiting for ordered extents: __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Task kworker in wait_current_trans waiting for transaction commit: Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30 Fix this by passing the transaction type to wait_current_trans() and checking btrfs_blocked_trans_types[cur_trans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71185", "url": "https://ubuntu.com/security/CVE-2025-71185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23026", "url": "https://ubuntu.com/security/CVE-2026-23026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config() Fix a memory leak in gpi_peripheral_config() where the original memory pointed to by gchan->config could be lost if krealloc() fails. The issue occurs when: 1. gchan->config points to previously allocated memory 2. krealloc() fails and returns NULL 3. The function directly assigns NULL to gchan->config, losing the reference to the original memory 4. The original memory becomes unreachable and cannot be freed Fix this by using a temporary variable to hold the krealloc() result and only updating gchan->config when the allocation succeeds. Found via static analysis and code review.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71188", "url": "https://ubuntu.com/security/CVE-2025-71188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: lpc18xx-dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71163", "url": "https://ubuntu.com/security/CVE-2025-71163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix device leaks on compat bind and unbind Make sure to drop the reference taken when looking up the idxd device as part of the compat bind and unbind sysfs interface.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2025-71190", "url": "https://ubuntu.com/security/CVE-2025-71190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: bcm-sba-raid: fix device leak on probe Make sure to drop the reference taken when looking up the mailbox device during probe on probe failures and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71191", "url": "https://ubuntu.com/security/CVE-2025-71191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: at_hdmac: fix device leak on of_dma_xlate() Make sure to drop the reference taken when looking up the DMA platform device during of_dma_xlate() when releasing channel resources. Note that commit 3832b78b3ec2 (\"dmaengine: at_hdmac: add missing put_device() call in at_dma_xlate()\") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23049", "url": "https://ubuntu.com/security/CVE-2026-23049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel The connector type for the DataImage SCF0700C48GGU18 panel is missing and devm_drm_panel_bridge_add() requires connector type to be set. This leads to a warning and a backtrace in the kernel log and panel does not work: \" WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8 \" The warning is triggered by a check for valid connector type in devm_drm_panel_bridge_add(). If there is no valid connector type set for a panel, the warning is printed and panel is not added. Fill in the missing connector type to fix the warning and make the panel operational once again.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23145", "url": "https://ubuntu.com/security/CVE-2026-23145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref The error branch for ext4_xattr_inode_update_ref forget to release the refcount for iloc.bh. Find this when review code.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-22997", "url": "https://ubuntu.com/security/CVE-2026-22997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is called only when the timer is enabled, we need to call j1939_session_deactivate_activate_next() if we cancelled the timer. Otherwise, refcount for j1939_session leaks, which will later appear as | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2. problem.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23033", "url": "https://ubuntu.com/security/CVE-2026-23033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: omap-dma: fix dma_pool resource leak in error paths The dma_pool created by dma_pool_create() is not destroyed when dma_async_device_register() or of_dma_controller_register() fails, causing a resource leak in the probe error paths. Add dma_pool_destroy() in both error paths to properly release the allocated dma_pool resource.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71196", "url": "https://ubuntu.com/security/CVE-2025-71196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: stm32-usphyc: Fix off by one in probe() The \"index\" variable is used as an index into the usbphyc->phys[] array which has usbphyc->nphys elements. So if it is equal to usbphyc->nphys then it is one element out of bounds. The \"index\" comes from the device tree so it's data that we trust and it's unlikely to be wrong, however it's obviously still worth fixing the bug. Change the > to >=.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71162", "url": "https://ubuntu.com/security/CVE-2025-71162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: tegra-adma: Fix use-after-free A use-after-free bug exists in the Tegra ADMA driver when audio streams are terminated, particularly during XRUN conditions. The issue occurs when the DMA buffer is freed by tegra_adma_terminate_all() before the vchan completion tasklet finishes accessing it. The race condition follows this sequence: 1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegra_adma_terminate_all() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchan_complete() which attempts to access the already-freed memory Since tasklets can execute at any time after being scheduled, there is no guarantee that the buffer will remain valid when vchan_complete() runs. Fix this by properly synchronizing the virtual channel completion: - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegra_adma_synchronize() that calls vchan_synchronize() which kills any pending tasklets and frees any terminated descriptors. Crash logs: [ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0 [ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0 [ 337.427562] Call trace: [ 337.427564] dump_backtrace+0x0/0x320 [ 337.427571] show_stack+0x20/0x30 [ 337.427575] dump_stack_lvl+0x68/0x84 [ 337.427584] print_address_description.constprop.0+0x74/0x2b8 [ 337.427590] kasan_report+0x1f4/0x210 [ 337.427598] __asan_load8+0xa0/0xd0 [ 337.427603] vchan_complete+0x124/0x3b0 [ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0 [ 337.427617] tasklet_action+0x30/0x40 [ 337.427623] __do_softirq+0x1a0/0x5c4 [ 337.427628] irq_exit+0x110/0x140 [ 337.427633] handle_domain_irq+0xa4/0xe0 [ 337.427640] gic_handle_irq+0x64/0x160 [ 337.427644] call_on_irq_stack+0x20/0x4c [ 337.427649] do_interrupt_handler+0x7c/0x90 [ 337.427654] el1_interrupt+0x30/0x80 [ 337.427659] el1h_64_irq_handler+0x18/0x30 [ 337.427663] el1h_64_irq+0x7c/0x80 [ 337.427667] cpuidle_enter_state+0xe4/0x540 [ 337.427674] cpuidle_enter+0x54/0x80 [ 337.427679] do_idle+0x2e0/0x380 [ 337.427685] cpu_startup_entry+0x2c/0x70 [ 337.427690] rest_init+0x114/0x130 [ 337.427695] arch_call_rest_init+0x18/0x24 [ 337.427702] start_kernel+0x380/0x3b4 [ 337.427706] __primary_switched+0xc0/0xc8", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22999", "url": "https://ubuntu.com/security/CVE-2026-22999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: do not free existing class in qfq_change_class() Fixes qfq_change_class() error case. cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23011", "url": "https://ubuntu.com/security/CVE-2026-23011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_gre: make ipgre_header() robust Analog to commit db5b4e39c4e6 (\"ip6_gre: make ip6gre_header() robust\") Over the years, syzbot found many ways to crash the kernel in ipgre_header() [1]. This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ipgre device. [1] skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213 Call Trace: skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23001", "url": "https://ubuntu.com/security/CVE-2026-23001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix possible UAF in macvlan_forward_source() Add RCU protection on (struct macvlan_source_entry)->vlan. Whenever macvlan_hash_del_source() is called, we must clear entry->vlan pointer before RCU grace period starts. This allows macvlan_forward_source() to skip over entries queued for freeing. Note that macvlan_dev are already RCU protected, as they are embedded in a standard netdev (netdev_priv(ndev)). https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23003", "url": "https://ubuntu.com/security/CVE-2026-23003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() Blamed commit did not take care of VLAN encapsulations as spotted by syzbot [1]. Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull(). [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22998", "url": "https://ubuntu.com/security/CVE-2026-22998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec Commit efa56305908b (\"nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs. The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command. Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23037", "url": "https://ubuntu.com/security/CVE-2026-23037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: allow partial RX URB allocation to succeed When es58x_alloc_rx_urbs() fails to allocate the requested number of URBs but succeeds in allocating some, it returns an error code. This causes es58x_open() to return early, skipping the cleanup label 'free_urbs', which leads to the anchored URBs being leaked. As pointed out by maintainer Vincent Mailhol, the driver is designed to handle partial URB allocation gracefully. Therefore, partial allocation should not be treated as a fatal error. Modify es58x_alloc_rx_urbs() to return 0 if at least one URB has been allocated, restoring the intended behavior and preventing the leak in es58x_open().", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23038", "url": "https://ubuntu.com/security/CVE-2026-23038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node() In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak. Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23111", "url": "https://ubuntu.com/security/CVE-2026-23111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate() nft_map_catchall_activate() has an inverted element activity check compared to its non-catchall counterpart nft_mapelem_activate() and compared to what is logically required. nft_map_catchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones. Compare the non-catchall activate callback, which is correct: nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; /* skip active, process inactive */ With the buggy catchall version: nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; /* skip inactive, process active */ The consequence is that when a DELSET operation is aborted, nft_setelem_data_activate() is never called for the catchall element. For NFT_GOTO verdict elements, this means nft_data_hold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free. This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIG_USER_NS and CONFIG_NF_TABLES. Fix by removing the negation so the check matches nft_mapelem_activate(): skip active elements, process inactive ones.", "cve_priority": "high", "cve_public_date": "2026-02-13 14:16:00 UTC" }, { "cve": "CVE-2026-23209", "url": "https://ubuntu.com/security/CVE-2026-23209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source(). With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-37849", "url": "https://ubuntu.com/security/CVE-2025-37849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Tear down vGIC on failed vCPU creation If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU. Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.", "cve_priority": "high", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2026-23074", "url": "https://ubuntu.com/security/CVE-2026-23074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Enforce that teql can only be used as root qdisc Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint. Although not important, I will describe the scenario that unearthed this issue for the curious. GangMin Kim managed to concot a scenario as follows: ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s └── class 1:2 (weight=1, lmax=1514) teql GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23060", "url": "https://ubuntu.com/security/CVE-2026-23060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, crypto_authenc_esn_decrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalk_map_and_copy(), leading to a kernel panic (DoS). Add a minimum AAD length check to fail fast on invalid inputs.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143524, 2143539, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143033, 2141276 ], "changes": [ { "cves": [ { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2026-23170", "url": "https://ubuntu.com/security/CVE-2026-23170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imx/tve: fix probe device leak Make sure to drop the reference taken to the DDC device during probe on probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23075", "url": "https://ubuntu.com/security/CVE-2026-23075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In esd_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback esd_usb_read_bulk_callback(), the URBs are processed and resubmitted. In esd_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in esd_usb_close(). Fix the memory leak by anchoring the URB in the esd_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-38408", "url": "https://ubuntu.com/security/CVE-2025-38408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: genirq/irq_sim: Initialize work context pointers properly Initialize `ops` member's pointers properly by using kzalloc() instead of kmalloc() when allocating the simulation work context. Otherwise the pointers contain random content leading to invalid dereferencing.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2023-54207", "url": "https://ubuntu.com/security/CVE-2023-54207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: Correct devm device reference for hidinput input_dev name Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management. Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string.", "cve_priority": "medium", "cve_public_date": "2025-12-30 13:16:00 UTC" }, { "cve": "CVE-2023-53520", "url": "https://ubuntu.com/security/CVE-2023-53520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix hci_suspend_sync crash If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.", "cve_priority": "medium", "cve_public_date": "2025-10-01 12:15:00 UTC" }, { "cve": "CVE-2025-38125", "url": "https://ubuntu.com/security/CVE-2025-38125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring EST If the ptp_rate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0. Prevent this division by 0 by adding the corresponding check and error code.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-40164", "url": "https://ubuntu.com/security/CVE-2025-40164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix using smp_processor_id() in preemptible code warnings Syzbot reported the following warning: BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879 caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary) Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f For historical and portability reasons, the netif_rx() is usually run in the softirq or interrupt context, this commit therefore add local_bh_disable/enable() protection in the usbnet_resume_rx().", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-38232", "url": "https://ubuntu.com/security/CVE-2025-38232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix race between nfsd registration and exports_proc As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd. Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd for 5.4 kernel ARM64: CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0 CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 PC is at : exports_net_open+0x50/0x68 [nfsd] Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248 Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu(). and same is happening on latest 6.14 kernel as well: [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]--- It reproduced simply with below script: while [ 1 ] do /exportfs -r done & while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done & So exporting interfaces to user space shall be done at last and cleanup at first place. With change there is no Kernel OOPs.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2023-53662", "url": "https://ubuntu.com/security/CVE-2023-53662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup} If the filename casefolding fails, we'll be leaking memory from the fscrypt_name struct, namely from the 'crypto_buf.name' member. Make sure we free it in the error path on both ext4_fname_setup_filename() and ext4_fname_prepare_lookup() functions.", "cve_priority": "medium", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2025-38057", "url": "https://ubuntu.com/security/CVE-2025-38057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: fix skb leaks A few error paths are missing a kfree_skb.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2023-53421", "url": "https://ubuntu.com/security/CVE-2023-53421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats() When blkg_alloc() is called to allocate a blkcg_gq structure with the associated blkg_iostat_set's, there are 2 fields within blkg_iostat_set that requires proper initialization - blkg & sync. The former field was introduced by commit 3b8cc6298724 (\"blk-cgroup: Optimize blkcg_rstat_flush()\") while the later one was introduced by commit f73316482977 (\"blk-cgroup: reimplement basic IO stats using cgroup rstat\"). Unfortunately those fields in the blkg_iostat_set's are not properly re-initialized when they are cleared in v1's blkcg_reset_stats(). This can lead to a kernel panic due to NULL pointer access of the blkg pointer. The missing initialization of sync is less problematic and can be a problem in a debug kernel due to missing lockdep initialization. Fix these problems by re-initializing them after memory clearing.", "cve_priority": "medium", "cve_public_date": "2025-09-18 16:15:00 UTC" }, { "cve": "CVE-2025-68365", "url": "https://ubuntu.com/security/CVE-2025-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Initialize allocated memory before use KMSAN reports: Multiple uninitialized values detected: - KMSAN: uninit-value in ntfs_read_hdr (3) - KMSAN: uninit-value in bcmp (3) Memory is allocated by __getname(), which is a wrapper for kmem_cache_alloc(). This memory is used before being properly cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to properly allocate and clear memory before use.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68817", "url": "https://ubuntu.com/security/CVE-2025-68817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency Under high concurrency, A tree-connection object (tcon) is freed on a disconnect path while another path still holds a reference and later executes *_put()/write on it.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2022-50390", "url": "https://ubuntu.com/security/CVE-2022-50390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATED Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c ttm_bo_move_memcpy+0x3b4/0x460 [ttm] bo_driver_move+0x32/0x40 [drm_vram_helper] ttm_bo_handle_move_mem+0x118/0x200 [ttm] ttm_bo_validate+0xfa/0x220 [ttm] drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper] drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper] drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper] drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper] drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper] drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper] drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper] drm_atomic_commit+0x9c/0x160 [drm] drm_client_modeset_commit_atomic+0x33a/0x380 [drm] drm_client_modeset_commit_locked+0x77/0x220 [drm] drm_client_modeset_commit+0x31/0x60 [drm] __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper] drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper] fbcon_init+0x316/0x790 visual_init+0x113/0x1d0 do_bind_con_driver+0x2a3/0x5c0 do_take_over_console+0xa9/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ", "cve_priority": "medium", "cve_public_date": "2025-09-18 14:15:00 UTC" }, { "cve": "CVE-2025-68211", "url": "https://ubuntu.com/security/CVE-2025-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksm: use range-walk function to jump over holes in scan_get_next_rmap_item Currently, scan_get_next_rmap_item() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages. This patch replaces the per-address lookup with a range walk using walk_page_range(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1]. Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page: #include #include #include /* 32 TiB */ const size_t size = 32ul * 1024 * 1024 * 1024 * 1024; int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror(\"mmap() failed\\n\"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0; } $ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-23093", "url": "https://ubuntu.com/security/CVE-2026-23093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbd: fix dma_unmap_sg() nents The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23078", "url": "https://ubuntu.com/security/CVE-2026-23078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Fix buffer overflow in config retrieval The scarlett2_usb_get_config() function has a logic error in the endianness conversion code that can cause buffer overflows when count > 1. The code checks `if (size == 2)` where `size` is the total buffer size in bytes, then loops `count` times treating each element as u16 (2 bytes). This causes the loop to access `count * 2` bytes when the buffer only has `size` bytes allocated. Fix by checking the element size (config_item->size) instead of the total buffer size. This ensures the endianness conversion matches the actual element type.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71186", "url": "https://ubuntu.com/security/CVE-2025-71186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: stm32: dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71197", "url": "https://ubuntu.com/security/CVE-2025-71197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: therm: Fix off-by-one buffer overflow in alarms_store The sysfs buffer passed to alarms_store() is allocated with 'size + 1' bytes and a NUL terminator is appended. However, the 'size' argument does not account for this extra byte. The original code then allocated 'size' bytes and used strcpy() to copy 'buf', which always writes one byte past the allocated buffer since strcpy() copies until the NUL terminator at index 'size'. Fix this by parsing the 'buf' parameter directly using simple_strtoll() without allocating any intermediate memory or string copying. This removes the overflow while simplifying the code.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23087", "url": "https://ubuntu.com/security/CVE-2026-23087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Fix potential memory leak in scsiback_remove() Memory allocated for struct vscsiblk_info in scsiback_probe() is not freed in scsiback_remove() leading to potential memory leaks on remove, as well as in the scsiback_probe() error paths. Fix that by freeing it in scsiback_remove().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-40149", "url": "https://ubuntu.com/security/CVE-2025-40149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock(). get_netdev_for_sock() is called during setsockopt(), so not under RCU. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the only ->ndo_sk_get_lower_dev() user is bond_sk_get_lower_dev(), which uses RCU.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-23167", "url": "https://ubuntu.com/security/CVE-2026-23167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix race between rfkill and nci_unregister_device(). syzbot reported the splat below [0] without a repro. It indicates that struct nci_dev.cmd_wq had been destroyed before nci_close_device() was called via rfkill. nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which (I think) was called from virtual_ncidev_close() when syzbot close()d an fd of virtual_ncidev. The problem is that nci_unregister_device() destroys nci_dev.cmd_wq first and then calls nfc_unregister_device(), which removes the device from rfkill by rfkill_unregister(). So, the device is still visible via rfkill even after nci_dev.cmd_wq is destroyed. Let's unregister the device from rfkill first in nci_unregister_device(). Note that we cannot call nfc_unregister_device() before nci_close_device() because 1) nfc_unregister_device() calls device_del() which frees all memory allocated by devm_kzalloc() and linked to ndev->conn_info_list 2) nci_rx_work() could try to queue nci_conn_info to ndev->conn_info_list which could be leaked Thus, nfc_unregister_device() is split into two functions so we can remove rfkill interfaces only before nci_close_device(). [0]: DEBUG_LOCKS_WARN_ON(1) WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349 Modules linked in: CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline] RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187 Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f RSP: 0018:ffffc9000c767680 EFLAGS: 00010046 RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000 RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0 RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4 R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2 R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30 FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0 Call Trace: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ksys_write+0x150/0x270 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa59b39acb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9 RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007 RBP: 00007fa59b408bf7 R08: ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23150", "url": "https://ubuntu.com/security/CVE-2026-23150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame(). syzbot reported various memory leaks related to NFC, struct nfc_llcp_sock, sk_buff, nfc_dev, etc. [0] The leading log hinted that nfc_llcp_send_ui_frame() failed to allocate skb due to sock_error(sk) being -ENXIO. ENXIO is set by nfc_llcp_socket_release() when struct nfc_llcp_local is destroyed by local_cleanup(). The problem is that there is no synchronisation between nfc_llcp_send_ui_frame() and local_cleanup(), and skb could be put into local->tx_queue after it was purged in local_cleanup(): CPU1 CPU2 ---- ---- nfc_llcp_send_ui_frame() local_cleanup() |- do { ' |- pdu = nfc_alloc_send_skb(..., &err) | . | |- nfc_llcp_socket_release(local, false, ENXIO); | |- skb_queue_purge(&local->tx_queue); | | ' | |- skb_queue_tail(&local->tx_queue, pdu); | ... | |- pdu = nfc_alloc_send_skb(..., &err) | ^._________________________________.' local_cleanup() is called for struct nfc_llcp_local only after nfc_llcp_remove_local() unlinks it from llcp_devices. If we hold local->tx_queue.lock then, we can synchronise the thread and nfc_llcp_send_ui_frame(). Let's do that and check list_empty(&local->list) before queuing skb to local->tx_queue in nfc_llcp_send_ui_frame(). [0]: [ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6) [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak) BUG: memory leak unreferenced object 0xffff8881272f6800 (size 1024): comm \"syz.0.17\", pid 6096, jiffies 4294942766 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc da58d84d): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658 kmalloc_noprof include/linux/slab.h:961 [inline] sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239 sk_alloc+0x36/0x360 net/core/sock.c:2295 nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31 __sock_create+0x1a9/0x340 net/socket.c:1605 sock_create net/socket.c:1663 [inline] __sys_socket_create net/socket.c:1700 [inline] __sys_socket+0xb9/0x1a0 net/socket.c:1747 __do_sys_socket net/socket.c:1761 [inline] __se_sys_socket net/socket.c:1759 [inline] __x64_sys_socket+0x1b/0x30 net/socket.c:1759 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: memory leak unreferenced object 0xffff88810fbd9800 (size 240): comm \"syz.0.17\", pid 6096, jiffies 4294942850 hex dump (first 32 bytes): 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h....... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'.... backtrace (crc 6cc652b1): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/sk ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23164", "url": "https://ubuntu.com/security/CVE-2026-23164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rocker: fix memory leak in rocker_world_port_post_fini() In rocker_world_port_pre_init(), rocker_port->wpriv is allocated with kzalloc(wops->port_priv_size, GFP_KERNEL). However, in rocker_world_port_post_fini(), the memory is only freed when wops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv); Since rocker_ofdpa_ops does not implement port_post_fini callback (it is NULL), the wpriv memory allocated for each port is never freed when ports are removed. This leads to a memory leak of sizeof(struct ofdpa_port) bytes per port on every device removal. Fix this by always calling kfree(rocker_port->wpriv) regardless of whether the port_post_fini callback exists.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23146", "url": "https://ubuntu.com/security/CVE-2026-23146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling hci_uart_register_dev(), which calls proto->open() to initialize hu->priv. However, if a TTY write wakeup occurs during this window, hci_uart_tx_wakeup() may schedule write_work before hu->priv is initialized, leading to a NULL pointer dereference in hci_uart_write_work() when proto->dequeue() accesses hu->priv. The race condition is: CPU0 CPU1 ---- ---- hci_uart_set_proto() set_bit(HCI_UART_PROTO_INIT) hci_uart_register_dev() tty write wakeup hci_uart_tty_wakeup() hci_uart_tx_wakeup() schedule_work(&hu->write_work) proto->open(hu) // initializes hu->priv hci_uart_write_work() hci_uart_dequeue() proto->dequeue(hu) // accesses hu->priv (NULL!) Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open() succeeds, ensuring hu->priv is initialized before any work can be scheduled.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-38591", "url": "https://ubuntu.com/security/CVE-2025-38591", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject narrower access to pointer ctx fields The following BPF program, simplified from a syzkaller repro, causes a kernel warning: r0 = *(u8 *)(r1 + 169); exit; With pointer field sk being at offset 168 in __sk_buff. This access is detected as a narrower read in bpf_skb_is_valid_access because it doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed and later proceeds to bpf_convert_ctx_access. Note that for the \"is_narrower_load\" case in the convert_ctx_accesses(), the insn->off is aligned, so the cnt may not be 0 because it matches the offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However, the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1) This patch fixes that to return a proper \"invalid bpf_context access off=X size=Y\" error on the load instruction. The same issue affects multiple other fields in context structures that allow narrow access. Some other non-affected fields (for sk_msg, sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for consistency. Note this syzkaller crash was reported in the \"Closes\" link below, which used to be about a different bug, fixed in commit fce7bd8e385a (\"bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()\"). Because syzbot somehow confused the two bugs, the new crash and repro didn't get reported to the mailing list.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-68725", "url": "https://ubuntu.com/security/CVE-2025-68725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do not let BPF test infra emit invalid GSO types to stack Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled. We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place. The checks were added in 121d57af308d (\"gso: validate gso_type in GSO handlers\") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2026-23097", "url": "https://ubuntu.com/security/CVE-2026-23097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: migrate: correct lock ordering for hugetlb file folios Syzbot has found a deadlock (analyzed by Lance Yang): 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock! The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing i_mmap_lock to cover the calls to remove_migration_ptes() too. This is (mostly) how it used to be after commit c0d0381ade79. That was removed by 336bf30eb765 for both file & anon hugetlb pages when it should only have been removed for anon hugetlb pages.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23108", "url": "https://ubuntu.com/security/CVE-2026-23108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback usb_8dev_read_bulk_callback(), the URBs are processed and resubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the usb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23080", "url": "https://ubuntu.com/security/CVE-2026-23080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In mcba_usb_probe() -> mcba_usb_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback mcba_usb_read_bulk_callback(), the URBs are processed and resubmitted. In mcba_usb_close() -> mcba_urb_unlink() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the mcba_usb_read_bulk_callback()to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23061", "url": "https://ubuntu.com/security/CVE-2026-23061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In kvaser_usb_set_{,data_}bittiming() -> kvaser_usb_setup_rx_urbs(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback kvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. In kvaser_usb_remove_interfaces() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the kvaser_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23058", "url": "https://ubuntu.com/security/CVE-2026-23058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In ems_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In ems_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in ems_usb_close(). Fix the memory leak by anchoring the URB in the ems_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23085", "url": "https://ubuntu.com/security/CVE-2026-23085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Avoid truncating memory addresses On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23098", "url": "https://ubuntu.com/security/CVE-2026-23098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netrom: fix double-free in nr_route_frame() In nr_route_frame(), old_skb is immediately freed without checking if nr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL, the caller function will free old_skb again, causing a double-free bug. Therefore, to prevent this, we need to modify it to check whether nr_neigh->ax25 is NULL before freeing old_skb.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23063", "url": "https://ubuntu.com/security/CVE-2026-23063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: ensure safe queue release with state management Directly calling `put_queue` carries risks since it cannot guarantee that resources of `uacce_queue` have been fully released beforehand. So adding a `stop_queue` operation for the UACCE_CMD_PUT_Q command and leaving the `put_queue` operation to the final resource release ensures safety. Queue states are defined as follows: - UACCE_Q_ZOMBIE: Initial state - UACCE_Q_INIT: After opening `uacce` - UACCE_Q_STARTED: After `start` is issued via `ioctl` When executing `poweroff -f` in virt while accelerator are still working, `uacce_fops_release` and `uacce_remove` may execute concurrently. This can cause `uacce_put_queue` within `uacce_fops_release` to access a NULL `ops` pointer. Therefore, add state checks to prevent accessing freed pointers.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23056", "url": "https://ubuntu.com/security/CVE-2026-23056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: implement mremap in uacce_vm_ops to return -EPERM The current uacce_vm_ops does not support the mremap operation of vm_operations_struct. Implement .mremap to return -EPERM to remind users. The reason we need to explicitly disable mremap is that when the driver does not implement .mremap, it uses the default mremap method. This could lead to a risk scenario: An application might first mmap address p1, then mremap to p2, followed by munmap(p1), and finally munmap(p2). Since the default mremap copies the original vma's vm_private_data (i.e., q) to the new vma, both munmap operations would trigger vma_close, causing q->qfr to be freed twice(qfr will be set to null here, so repeated release is ok).", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23096", "url": "https://ubuntu.com/security/CVE-2026-23096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: fix cdev handling in the cleanup path When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23091", "url": "https://ubuntu.com/security/CVE-2026-23091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix device leak on output open() Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close(). Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23090", "url": "https://ubuntu.com/security/CVE-2026-23090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: core: fix device reference leak on report present Slimbus devices can be allocated dynamically upon reception of report-present messages. Make sure to drop the reference taken when looking up already registered devices. Note that this requires taking an extra reference in case the device has not yet been registered and has to be allocated.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23128", "url": "https://ubuntu.com/security/CVE-2026-23128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Set __nocfi on swsusp_arch_resume() A DABT is reported[1] on an android based system when resume from hiberate. This happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*() and does not have a CFI hash, but swsusp_arch_resume() will attempt to verify the CFI hash when calling a copy of swsusp_arch_suspend_exit(). Given that there's an existing requirement that the entrypoint to swsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text section, we cannot fix this by marking swsusp_arch_suspend_exit() with SYM_FUNC_*(). The simplest fix for now is to disable the CFI check in swsusp_arch_resume(). Mark swsusp_arch_resume() as __nocfi to disable the CFI check. [1] [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc [ 22.991934][ T1] Mem abort info: [ 22.991934][ T1] ESR = 0x0000000096000007 [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [ 22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][ T1] FSC = 0x07: level 3 translation fault [ 22.991934][ T1] Data abort info: [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 22.991934][ T1] Dumping ftrace buffer: [ 22.991934][ T1] (ftrace buffer empty) [ 22.991934][ T1] Modules linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419 [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT) [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344 [ 22.991934][ T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000 [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820 [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000 [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058 [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004 [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000 [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000 [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530 [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000 [ 22.991934][ T1] Call trace: [ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] hibernation_restore+0x158/0x18c [ 22.991934][ T1] load_image_and_restore+0xb0/0xec [ 22.991934][ T1] software_resume+0xf4/0x19c [ 22.991934][ T1] software_resume_initcall+0x34/0x78 [ 22.991934][ T1] do_one_initcall+0xe8/0x370 [ 22.991934][ T1] do_initcall_level+0xc8/0x19c [ 22.991934][ T1] do_initcalls+0x70/0xc0 [ 22.991934][ T1] do_basic_setup+0x1c/0x28 [ 22.991934][ T1] kernel_init_freeable+0xe0/0x148 [ 22.991934][ T1] kernel_init+0x20/0x1a8 [ 22.991934][ T1] ret_from_fork+0x10/0x20 [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110) [catalin.marinas@arm.com: commit log updated by Mark Rutland]", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23073", "url": "https://ubuntu.com/security/CVE-2026-23073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: Fix memory corruption due to not set vif driver data size The struct ieee80211_vif contains trailing space for vif driver data, when struct ieee80211_vif is allocated, the total memory size that is allocated is sizeof(struct ieee80211_vif) + size of vif driver data. The size of vif driver data is set by each WiFi driver as needed. The RSI911x driver does not set vif driver data size, no trailing space for vif driver data is therefore allocated past struct ieee80211_vif . The RSI911x driver does however use the vif driver data to store its vif driver data structure \"struct vif_priv\". An access to vif->drv_priv leads to access out of struct ieee80211_vif bounds and corruption of some memory. In case of the failure observed locally, rsi_mac80211_add_interface() would write struct vif_priv *vif_info = (struct vif_priv *)vif->drv_priv; vif_info->vap_id = vap_idx. This write corrupts struct fq_tin member struct list_head new_flows . The flow = list_first_entry(head, struct fq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus address, which when accessed causes a crash. The trigger is very simple, boot the machine with init=/bin/sh , mount devtmpfs, sysfs, procfs, and then do \"ip link set wlan0 up\", \"sleep 1\", \"ip link set wlan0 down\" and the crash occurs. Fix this by setting the correct size of vif driver data, which is the size of \"struct vif_priv\", so that memory is allocated and the driver can store its driver data in it, instead of corrupting memory around it.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23133", "url": "https://ubuntu.com/security/CVE-2026-23133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: fix dma_free_coherent() pointer dma_alloc_coherent() allocates a DMA mapped buffer and stores the addresses in XXX_unaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23089", "url": "https://ubuntu.com/security/CVE-2026-23089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free() When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees mixer->id_elems but the controls already added to the card still reference the freed memory. Later when snd_card_register() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read. Call trace: get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381 snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ... snd_card_register+0x4ed/0x6d0 sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025 Fix by calling snd_ctl_remove() for all mixer controls before freeing id_elems. We save the next pointer first because snd_ctl_remove() frees the current element.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23076", "url": "https://ubuntu.com/security/CVE-2026-23076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix potential OOB access in audio mixer handling In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixer_index() and sum_index()). As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]' After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field. This patch addresses those OOB accesses by adding the proper initializations of the loop indices.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71199", "url": "https://ubuntu.com/security/CVE-2025-71199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver at91_adc_interrupt can call at91_adc_touch_data_handler function to start the work by schedule_work(&st->touch_st.workq). If we remove the module which will call at91_adc_remove to make cleanup, it will free indio_dev through iio_device_unregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | at91_adc_workq_handler at91_adc_remove | iio_device_unregister(indio_dev) | //free indio_dev a bit later | | iio_push_to_buffers(indio_dev) | //use indio_dev Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91_adc_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23101", "url": "https://ubuntu.com/security/CVE-2026-23101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: led-class: Only Add LED to leds_list when it is fully ready Before this change the LED was added to leds_list before led_init_core() gets called adding it the list before led_classdev.set_brightness_work gets initialized. This leaves a window where led_trigger_register() of a LED's default trigger will call led_trigger_set() which calls led_set_brightness() which in turn will end up queueing the *uninitialized* led_classdev.set_brightness_work. This race gets hit by the lenovo-thinkpad-t14s EC driver which registers 2 LEDs with a default trigger provided by snd_ctl_led.ko in quick succession. The first led_classdev_register() causes an async modprobe of snd_ctl_led to run and that async modprobe manages to exactly hit the window where the second LED is on the leds_list without led_init_core() being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998 Close the race window by moving the adding of the LED to leds_list to after the led_init_core() call.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23064", "url": "https://ubuntu.com/security/CVE-2026-23064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: avoid possible NULL deref tcf_ife_encode() must make sure ife_encode() does not return NULL. syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166 CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full) Call Trace: ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23119", "url": "https://ubuntu.com/security/CVE-2026-23119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: provide a net pointer to __skb_flow_dissect() After 3cbf4ffba5ee (\"net: plumb network namespace into __skb_flow_dissect\") we have to provide a net pointer to __skb_flow_dissect(), either via skb->dev, skb->sk, or a user provided pointer. In the following case, syzbot was able to cook a bare skb. WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053 Call Trace: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23084", "url": "https://ubuntu.com/security/CVE-2026-23084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list When the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() is set to false, the driver may request the PMAC_ID from the firmware of the network card, and this function will store that PMAC_ID at the provided address pmac_id. This is the contract of this function. However, there is a location within the driver where both pmac_id_valid == false and pmac_id == NULL are being passed. This could result in dereferencing a NULL pointer. To resolve this issue, it is necessary to pass the address of a stub variable to the function.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23124", "url": "https://ubuntu.com/security/CVE-2026-23124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: annotate data-race in ndisc_router_discovery() syzbot found that ndisc_router_discovery() could read and write in6_dev->ra_mtu without holding a lock [1] This looks fine, IFLA_INET6_RA_MTU is best effort. Add READ_ONCE()/WRITE_ONCE() to document the race. Note that we might also reject illegal MTU values (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch. [1] BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... value changed: 0x00000000 -> 0xe5400659", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23121", "url": "https://ubuntu.com/security/CVE-2026-23121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mISDN: annotate data-race around dev->work dev->work can re read locklessly in mISDN_read() and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations. BUG: KCSAN: data-race in mISDN_ioctl / mISDN_read write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [inline] vfs_readv+0x3fb/0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [inline] __se_sys_readv fs/read_write.c:1162 [inline] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000 -> 0x00000001", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23071", "url": "https://ubuntu.com/security/CVE-2026-23071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: Fix race condition in hwspinlock irqsave routine Previously, the address of the shared member '&map->spinlock_flags' was passed directly to 'hwspin_lock_timeout_irqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shared flags variable, potentially corrupting the state for the current lock owner. Fix this by using a local stack variable 'flags' to store the IRQ state temporarily.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23105", "url": "https://ubuntu.com/security/CVE-2026-23105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag This is more of a preventive patch to make the code more consistent and to prevent possible exploits that employ child qlen manipulations on qfq. use cl_is_active instead of relying on the child qdisc's qlen to determine class activation.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23103", "url": "https://ubuntu.com/security/CVE-2026-23103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close) This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause: 1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock. 2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23120", "url": "https://ubuntu.com/security/CVE-2026-23120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: avoid one data-race in l2tp_tunnel_del_work() We should read sk->sk_socket only when dealing with kernel sockets. syzbot reported the following data-race: BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 value changed: 0xffff88811b818000 -> 0x0000000000000000", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23083", "url": "https://ubuntu.com/security/CVE-2026-23083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Don't allow 0 for FOU_ATTR_IPPROTO. fou_udp_recv() has the same problem mentioned in the previous patch. If FOU_ATTR_IPPROTO is set to 0, skb is not freed by fou_udp_recv() nor \"resubmit\"-ted in ip_protocol_deliver_rcu(). Let's forbid 0 for FOU_ATTR_IPPROTO.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23095", "url": "https://ubuntu.com/security/CVE-2026-23095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: Fix skb memleak with inner IP protocol 0. syzbot reported skb memleak below. [0] The repro generated a GUE packet with its inner protocol 0. gue_udp_recv() returns -guehdr->proto_ctype for \"resubmit\" in ip_protocol_deliver_rcu(), but this only works with non-zero protocol number. Let's drop such packets. Note that 0 is a valid number (IPv6 Hop-by-Hop Option). I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT [0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm \"syz.0.17\", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23125", "url": "https://ubuntu.com/security/CVE-2026-23125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key initialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127 The issue is triggered when sctp_auth_asoc_init_active_key() fails in sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the command sequence is currently: - SCTP_CMD_PEER_INIT - SCTP_CMD_TIMER_STOP (T1_INIT) - SCTP_CMD_TIMER_START (T1_COOKIE) - SCTP_CMD_NEW_STATE (COOKIE_ECHOED) - SCTP_CMD_ASSOC_SHKEY - SCTP_CMD_GEN_COOKIE_ECHO If SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while asoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL to be queued by sctp_datamsg_from_user(). Since command interpretation stops on failure, no COOKIE_ECHO should been sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As a result, the DATA chunk can be transmitted together with the COOKIE_ECHO in sctp_outq_flush_data(), leading to the observed issue. Similar to the other places where it calls sctp_auth_asoc_init_active_key() right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting T1_COOKIE. This ensures that if shared key generation fails, authenticated DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT, giving the client another chance to process INIT_ACK and retry key setup.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23099", "url": "https://ubuntu.com/security/CVE-2026-23099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: limit BOND_MODE_8023AD to Ethernet devices BOND_MODE_8023AD makes sense for ARPHRD_ETHER only. syzbot reported: BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline] BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497 CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [inline] __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [inline] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e The buggy address belongs to the variable: lacpdu_mcast_addr+0x0/0x40", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71194", "url": "https://ubuntu.com/security/CVE-2025-71194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock in wait_current_trans() due to ignored transaction type When wait_current_trans() is called during start_transaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfs_blocked_trans_types[] array already defines which transaction types should wait for which transaction states, but this check was missing in wait_current_trans(). This can lead to a deadlock scenario involving two transactions and pending ordered extents: 1. Transaction A is in TRANS_STATE_COMMIT_DOING state 2. A worker processing an ordered extent calls start_transaction() with TRANS_JOIN 3. join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes 5. A new Transaction B is created (TRANS_STATE_RUNNING) 6. The ordered extent from step 2 is added to Transaction B's pending ordered extents 7. Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START 8. The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[] 10. Transaction B is waiting for pending ordered extents to complete 11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B This can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!) Task bstore_kv_sync in btrfs_commit_transaction waiting for ordered extents: __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Task kworker in wait_current_trans waiting for transaction commit: Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30 Fix this by passing the transaction type to wait_current_trans() and checking btrfs_blocked_trans_types[cur_trans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71185", "url": "https://ubuntu.com/security/CVE-2025-71185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23026", "url": "https://ubuntu.com/security/CVE-2026-23026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config() Fix a memory leak in gpi_peripheral_config() where the original memory pointed to by gchan->config could be lost if krealloc() fails. The issue occurs when: 1. gchan->config points to previously allocated memory 2. krealloc() fails and returns NULL 3. The function directly assigns NULL to gchan->config, losing the reference to the original memory 4. The original memory becomes unreachable and cannot be freed Fix this by using a temporary variable to hold the krealloc() result and only updating gchan->config when the allocation succeeds. Found via static analysis and code review.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71188", "url": "https://ubuntu.com/security/CVE-2025-71188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: lpc18xx-dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71163", "url": "https://ubuntu.com/security/CVE-2025-71163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix device leaks on compat bind and unbind Make sure to drop the reference taken when looking up the idxd device as part of the compat bind and unbind sysfs interface.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2025-71190", "url": "https://ubuntu.com/security/CVE-2025-71190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: bcm-sba-raid: fix device leak on probe Make sure to drop the reference taken when looking up the mailbox device during probe on probe failures and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71191", "url": "https://ubuntu.com/security/CVE-2025-71191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: at_hdmac: fix device leak on of_dma_xlate() Make sure to drop the reference taken when looking up the DMA platform device during of_dma_xlate() when releasing channel resources. Note that commit 3832b78b3ec2 (\"dmaengine: at_hdmac: add missing put_device() call in at_dma_xlate()\") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23049", "url": "https://ubuntu.com/security/CVE-2026-23049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel The connector type for the DataImage SCF0700C48GGU18 panel is missing and devm_drm_panel_bridge_add() requires connector type to be set. This leads to a warning and a backtrace in the kernel log and panel does not work: \" WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8 \" The warning is triggered by a check for valid connector type in devm_drm_panel_bridge_add(). If there is no valid connector type set for a panel, the warning is printed and panel is not added. Fill in the missing connector type to fix the warning and make the panel operational once again.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23145", "url": "https://ubuntu.com/security/CVE-2026-23145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref The error branch for ext4_xattr_inode_update_ref forget to release the refcount for iloc.bh. Find this when review code.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-22997", "url": "https://ubuntu.com/security/CVE-2026-22997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is called only when the timer is enabled, we need to call j1939_session_deactivate_activate_next() if we cancelled the timer. Otherwise, refcount for j1939_session leaks, which will later appear as | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2. problem.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23033", "url": "https://ubuntu.com/security/CVE-2026-23033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: omap-dma: fix dma_pool resource leak in error paths The dma_pool created by dma_pool_create() is not destroyed when dma_async_device_register() or of_dma_controller_register() fails, causing a resource leak in the probe error paths. Add dma_pool_destroy() in both error paths to properly release the allocated dma_pool resource.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71196", "url": "https://ubuntu.com/security/CVE-2025-71196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: stm32-usphyc: Fix off by one in probe() The \"index\" variable is used as an index into the usbphyc->phys[] array which has usbphyc->nphys elements. So if it is equal to usbphyc->nphys then it is one element out of bounds. The \"index\" comes from the device tree so it's data that we trust and it's unlikely to be wrong, however it's obviously still worth fixing the bug. Change the > to >=.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71162", "url": "https://ubuntu.com/security/CVE-2025-71162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: tegra-adma: Fix use-after-free A use-after-free bug exists in the Tegra ADMA driver when audio streams are terminated, particularly during XRUN conditions. The issue occurs when the DMA buffer is freed by tegra_adma_terminate_all() before the vchan completion tasklet finishes accessing it. The race condition follows this sequence: 1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegra_adma_terminate_all() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchan_complete() which attempts to access the already-freed memory Since tasklets can execute at any time after being scheduled, there is no guarantee that the buffer will remain valid when vchan_complete() runs. Fix this by properly synchronizing the virtual channel completion: - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegra_adma_synchronize() that calls vchan_synchronize() which kills any pending tasklets and frees any terminated descriptors. Crash logs: [ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0 [ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0 [ 337.427562] Call trace: [ 337.427564] dump_backtrace+0x0/0x320 [ 337.427571] show_stack+0x20/0x30 [ 337.427575] dump_stack_lvl+0x68/0x84 [ 337.427584] print_address_description.constprop.0+0x74/0x2b8 [ 337.427590] kasan_report+0x1f4/0x210 [ 337.427598] __asan_load8+0xa0/0xd0 [ 337.427603] vchan_complete+0x124/0x3b0 [ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0 [ 337.427617] tasklet_action+0x30/0x40 [ 337.427623] __do_softirq+0x1a0/0x5c4 [ 337.427628] irq_exit+0x110/0x140 [ 337.427633] handle_domain_irq+0xa4/0xe0 [ 337.427640] gic_handle_irq+0x64/0x160 [ 337.427644] call_on_irq_stack+0x20/0x4c [ 337.427649] do_interrupt_handler+0x7c/0x90 [ 337.427654] el1_interrupt+0x30/0x80 [ 337.427659] el1h_64_irq_handler+0x18/0x30 [ 337.427663] el1h_64_irq+0x7c/0x80 [ 337.427667] cpuidle_enter_state+0xe4/0x540 [ 337.427674] cpuidle_enter+0x54/0x80 [ 337.427679] do_idle+0x2e0/0x380 [ 337.427685] cpu_startup_entry+0x2c/0x70 [ 337.427690] rest_init+0x114/0x130 [ 337.427695] arch_call_rest_init+0x18/0x24 [ 337.427702] start_kernel+0x380/0x3b4 [ 337.427706] __primary_switched+0xc0/0xc8", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22999", "url": "https://ubuntu.com/security/CVE-2026-22999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: do not free existing class in qfq_change_class() Fixes qfq_change_class() error case. cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23011", "url": "https://ubuntu.com/security/CVE-2026-23011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_gre: make ipgre_header() robust Analog to commit db5b4e39c4e6 (\"ip6_gre: make ip6gre_header() robust\") Over the years, syzbot found many ways to crash the kernel in ipgre_header() [1]. This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ipgre device. [1] skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213 Call Trace: skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23001", "url": "https://ubuntu.com/security/CVE-2026-23001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix possible UAF in macvlan_forward_source() Add RCU protection on (struct macvlan_source_entry)->vlan. Whenever macvlan_hash_del_source() is called, we must clear entry->vlan pointer before RCU grace period starts. This allows macvlan_forward_source() to skip over entries queued for freeing. Note that macvlan_dev are already RCU protected, as they are embedded in a standard netdev (netdev_priv(ndev)). https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23003", "url": "https://ubuntu.com/security/CVE-2026-23003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() Blamed commit did not take care of VLAN encapsulations as spotted by syzbot [1]. Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull(). [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22998", "url": "https://ubuntu.com/security/CVE-2026-22998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec Commit efa56305908b (\"nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs. The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command. Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23037", "url": "https://ubuntu.com/security/CVE-2026-23037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: allow partial RX URB allocation to succeed When es58x_alloc_rx_urbs() fails to allocate the requested number of URBs but succeeds in allocating some, it returns an error code. This causes es58x_open() to return early, skipping the cleanup label 'free_urbs', which leads to the anchored URBs being leaked. As pointed out by maintainer Vincent Mailhol, the driver is designed to handle partial URB allocation gracefully. Therefore, partial allocation should not be treated as a fatal error. Modify es58x_alloc_rx_urbs() to return 0 if at least one URB has been allocated, restoring the intended behavior and preventing the leak in es58x_open().", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23038", "url": "https://ubuntu.com/security/CVE-2026-23038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node() In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak. Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23111", "url": "https://ubuntu.com/security/CVE-2026-23111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate() nft_map_catchall_activate() has an inverted element activity check compared to its non-catchall counterpart nft_mapelem_activate() and compared to what is logically required. nft_map_catchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones. Compare the non-catchall activate callback, which is correct: nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; /* skip active, process inactive */ With the buggy catchall version: nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; /* skip inactive, process active */ The consequence is that when a DELSET operation is aborted, nft_setelem_data_activate() is never called for the catchall element. For NFT_GOTO verdict elements, this means nft_data_hold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free. This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIG_USER_NS and CONFIG_NF_TABLES. Fix by removing the negation so the check matches nft_mapelem_activate(): skip active elements, process inactive ones.", "cve_priority": "high", "cve_public_date": "2026-02-13 14:16:00 UTC" }, { "cve": "CVE-2026-23209", "url": "https://ubuntu.com/security/CVE-2026-23209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source(). With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-37849", "url": "https://ubuntu.com/security/CVE-2025-37849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Tear down vGIC on failed vCPU creation If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU. Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.", "cve_priority": "high", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2026-23074", "url": "https://ubuntu.com/security/CVE-2026-23074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Enforce that teql can only be used as root qdisc Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint. Although not important, I will describe the scenario that unearthed this issue for the curious. GangMin Kim managed to concot a scenario as follows: ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s └── class 1:2 (weight=1, lmax=1514) teql GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23060", "url": "https://ubuntu.com/security/CVE-2026-23060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, crypto_authenc_esn_decrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalk_map_and_copy(), leading to a kernel panic (DoS). Add a minimum AAD length check to fail fast on invalid inputs.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1097.102 -proposed tracker (LP: #2143524)", "", " [ Ubuntu: 5.15.0-176.186 ]", "", " * jammy/linux: 5.15.0-176.186 -proposed tracker (LP: #2143539)", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343)", " - nvmet-tcp: remove boilerplate code", " - SAUCE: Fix skb_vlan_inet_prepare() usage", " - net: update netdev_lock_{type,name}", " - vsock/test: add a final full barrier after run all tests", " - net/mlx5e: Restore destroying state bit after profile cleanup", " - selftests: drv-net: fix RPS mask handling for high CPU numbers", " - ASoC: tlv320adcx140: fix word length", " - textsearch: describe @list member in ts_ops search", " - mm, kfence: describe @slab parameter in __kfence_obj_info()", " - dmaengine: xilinx_dma: Fix uninitialized addr_width when", " \"xlnx,addrwidth\" property is missing", " - phy: broadcom: ns-usb3: Fix Wvoid-pointer-to-enum-cast warning (again)", " - HID: usbhid: paper over wrong bNumDescriptor field", " - ALSA: pcm: Improve the fix for race of buffer access at PCM OSS layer", " - x86/kaslr: Recognize all ZONE_DEVICE users as physaddr consumers", " - phy: rockchip: inno-usb2: fix disconnection in gadget mode", " - phy: rockchip: inno-usb2: fix communication disruption in gadget mode", " - phy: tegra: xusb: Explicitly configure HS_DISCON_LEVEL to 0x7", " - usb: dwc3: Check for USB4 IP_NAME", " - USB: OHCI/UHCI: Add soft dependencies on ehci_platform", " - USB: serial: option: add Telit LE910 MBIM composition", " - USB: serial: ftdi_sio: add support for PICAXE AXE027 cable", " - nvme-pci: disable secondary temp for Wodposit WPBSNM8", " - hrtimer: Fix softirq base check in update_needs_ipi()", " - EDAC/x38: Fix a resource leak in x38_probe1()", " - EDAC/i3200: Fix a resource leak in i3200_probe1()", " - x86/resctrl: Add missing resctrl initialization for Hygon", " - x86/resctrl: Fix memory bandwidth counter width for Hygon", " - mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free", " - drm/nouveau/disp/nv50-: Set lock_core in curs507a_prepare", " - drm/vmwgfx: Fix an error return check in vmw_compat_shader_add()", " - dmaengine: sh: rz-dmac: Fix rz_dmac_terminate_all()", " - dmaengine: ti: dma-crossbar: fix device leak on dra7x route allocation", " - dmaengine: ti: k3-udma: fix device leak on udma lookup", " - posix-clock: introduce posix_clock_context concept", " - Fix memory leak in posix_clock_open()", " - posix-clock: Store file pointer in struct posix_clock_context", " - ptp: Add PHC file mode checks. Allow RO adjtime() without FMODE_WRITE.", " - testptp: add option to shift clock by nanoseconds", " - testptp: Add support for testing ptp_clock_info .adjphase callback", " - selftests/ptp: Add -x option for testing PTP_SYS_OFFSET_EXTENDED", " - selftests/ptp: Add -X option for testing PTP_SYS_OFFSET_PRECISE", " - ptp: add testptp mask test", " - selftest/ptp: update ptp selftest to exercise the gettimex options", " - testptp: Add option to open PHC in readonly mode", " - net: usb: dm9601: remove broken SR9700 support", " - amd-xgbe: avoid misleading per-packet error log", " - netlink: add a proto specification for FOU", " - net: fou: rename the source for linking", " - net: fou: use policy and operation tables generated from the spec", " - comedi: dmm32at: serialize use of paged registers", " - w1: fix redundant counter decrement in w1_attach_slave_device()", " - Revert \"nfc/nci: Add the inconsistency check between the input data", " length and count\"", " - Input: i8042 - add quirks for MECHREVO Wujie 15X Pro", " - Input: i8042 - add quirk for ASUS Zenbook UX425QA_UM425QA", " - scsi: storvsc: Process unsupported MODE_SENSE_10", " - x86/kfence: avoid writing L1TF-vulnerable PTEs", " - staging:iio:adc:ad7280a: Register define cleanup.", " - iio: adc: ad7280a: handle spi_setup() errors in probe()", " - ALSA: usb: Increase volume range that triggers a warning", " - net: hns3: fix wrong GENMASK() for HCLGE_FD_AD_COUNTER_NUM_M", " - net: hns3: fix the HCLGE_FD_AD_NXT_KEY error setting issue", " - usbnet: limit max_mtu based on device's hard_mtu", " - drm/amd/pm: Don't clear SI SMC table when setting power limit", " - drm/amd/pm: Workaround SI powertune issue on Radeon 430 (v2)", " - octeontx2-af: Fix error handling", " - x86: make page fault handling disable interrupts properly", " - of: fix reference count leak in of_alias_scan()", " - iio: adc: ad9467: fix ad9434 vref mask", " - iio: dac: ad5686: add AD5695R to ad5686_chip_info_tbl", " - mmc: rtsx_pci_sdmmc: implement sdmmc_card_busy function", " - wifi: mwifiex: Fix a loop in mwifiex_update_ampdu_rxwinsize()", " - octeontx2: Fix otx2_dma_map_page() error return code", " - slimbus: core: fix runtime PM imbalance on report present", " - perf/x86/intel: Do not enable BTS for guests", " - net/mlx5: Fix memory leak in esw_acl_ingress_lgcy_setup()", " - net: mvpp2: cls: Fix memory leak in mvpp2_ethtool_cls_rule_ins()", " - ipv6: use the right ifindex when replying to icmpv6 from localhost", " - ice: stop counting UDP csum mismatch as rx_errors", " - net/mlx5: Add HW definitions of vport debug counters", " - net/mlx5e: Expose rx_oversize_pkts_buffer counter", " - net/mlx5e: Report rx_discards_phy via rx_dropped", " - net/mlx5e: Account for netdev stats in ndo_get_stats64", " - net: bridge: fix static key check", " - scsi: firewire: sbp-target: Fix overflow in sbp_make_tpg()", " - gpiolib: acpi: use BIT_ULL() for u64 mask in address space handler", " - dma/pool: distinguish between missing and exhausted atomic pools", " - ASoC: fsl: imx-card: Do not force slot width to sample width", " - scsi: be2iscsi: Fix a memory leak in beiscsi_boot_get_sinfo()", " - scsi: qla2xxx: edif: Fix dma_free_coherent() size", " - mptcp: only reset subflow errors when propagated", " - net: Add locking to protect skb->dev access in ip_output", " - comedi: Fix getting range information for subdevices 16 to 255", " - of: platform: Use default match table for /firmware", " - iio: adc: exynos_adc: fix OF populate on driver rebind", " - arm64: dts: rockchip: remove redundant max-link-speed from nanopi-r4s", " - w1: w1_therm: use swap() to make code cleaner", " - dmaengine: stm32: dmamux: fix OF node leak on route allocation failure", " - xfs: set max_agbno to allow sparse alloc of last full inode chunk", " - nvme-fc: rename free_ctrl callback to match name pattern", " - nvme-pci: do not directly handle subsys reset fallout", " - nvme: fix PCIe subsystem reset controller state transition", " - mei: trace: treat reg parameter as string", " - mm/pagewalk: add walk_page_range_vma()", " - wifi: cfg80211: add a work abstraction with special semantics", " - wifi: mac80211: use wiphy work for sdata->work", " - wifi: mac80211: move TDLS work to wiphy work", " - HID: uclogic: Add NULL check in uclogic_input_configured()", " - drm/amdkfd: fix a memory leak in device_queue_manager_init()", " - btrfs: prevent use-after-free on page private data in", " btrfs_subpage_clear_uptodate()", " - net/sched: act_ife: convert comma to semicolon", " - pinctrl: lpass-lpi: implement .get_direction() for the GPIO driver", " - writeback: fix 100% CPU usage when dirtytime_expire_interval is 0", " - mptcp: avoid dup SUB_CLOSED events after disconnect", " - pinctrl: meson: mark the GPIO controller as sleeping", " - wifi: cfg80211: use system_unbound_wq for wiphy work", " - wifi: cfg80211: fix wiphy delayed work queueing", " - wifi: cfg80211: cancel wiphy_work before freeing wiphy", " - wifi: cfg80211: fully move wiphy work to unbound workqueue", " - wifi: cfg80211: init wiphy_work before allocating rfkill fails", " - Linux 5.15.199", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23170", " - drm/imx/tve: fix probe device leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23075", " - can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38408", " - genirq/irq_sim: Initialize work context pointers properly", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2023-54207", " - HID: uclogic: Correct devm device reference for hidinput input_dev name", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2023-53520", " - Bluetooth: Fix hci_suspend_sync crash", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38125", " - net: stmmac: make sure that ptp_rate is not 0 before configuring EST", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-40164", " - usbnet: Fix using smp_processor_id() in preemptible code warnings", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38232", " - NFSD: fix race between nfsd registration and exports_proc", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2023-53662", " - ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup}", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38057", " - espintcp: fix skb leaks", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2023-53421", " - blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68365", " - fs/ntfs3: Initialize allocated memory before use", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68817", " - ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2022-50390", " - drm/ttm: fix undefined behavior in bit shift for", " TTM_TT_FLAG_PRIV_POPULATED", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68211", " - ksm: use range-walk function to jump over holes in", " scan_get_next_rmap_item", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23093", " - ksmbd: smbd: fix dma_unmap_sg() nents", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23078", " - ALSA: scarlett2: Fix buffer overflow in config retrieval", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71186", " - dmaengine: stm32: dmamux: fix device leak on route allocation", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71197", " - w1: therm: Fix off-by-one buffer overflow in alarms_store", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23087", " - scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-40149", " - tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23167", " - nfc: nci: Fix race between rfkill and nci_unregister_device().", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23150", " - nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame().", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23164", " - rocker: fix memory leak in rocker_world_port_post_fini()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23146", " - Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38591", " - bpf: Reject narrower access to pointer ctx fields", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68725", " - bpf: Do not let BPF test infra emit invalid GSO types to stack", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23097", " - migrate: correct lock ordering for hugetlb file folios", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23108", " - can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23080", " - can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23061", " - can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23058", " - can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23085", " - irqchip/gic-v3-its: Avoid truncating memory addresses", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23098", " - netrom: fix double-free in nr_route_frame()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23063", " - uacce: ensure safe queue release with state management", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23056", " - uacce: implement mremap in uacce_vm_ops to return -EPERM", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23096", " - uacce: fix cdev handling in the cleanup path", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23091", " - intel_th: fix device leak on output open()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23090", " - slimbus: core: fix device reference leak on report present", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23128", " - arm64: Set __nocfi on swsusp_arch_resume()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23073", " - wifi: rsi: Fix memory corruption due to not set vif driver data size", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23133", " - wifi: ath10k: fix dma_free_coherent() pointer", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23089", " - ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23076", " - ALSA: ctxfi: Fix potential OOB access in audio mixer handling", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71199", " - iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc", " driver", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23101", " - leds: led-class: Only Add LED to leds_list when it is fully ready", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23064", " - net/sched: act_ife: avoid possible NULL deref", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23119", " - bonding: provide a net pointer to __skb_flow_dissect()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23084", " - be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23124", " - ipv6: annotate data-race in ndisc_router_discovery()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23121", " - mISDN: annotate data-race around dev->work", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23071", " - regmap: Fix race condition in hwspinlock irqsave routine", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23105", " - net/sched: qfq: Use cl_is_active to determine whether class is active in", " qfq_rm_from_ag", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23103", " - ipvlan: Make the addrs_lock be per port", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23120", " - l2tp: avoid one data-race in l2tp_tunnel_del_work()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23083", " - fou: Don't allow 0 for FOU_ATTR_IPPROTO.", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23095", " - gue: Fix skb memleak with inner IP protocol 0.", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23125", " - sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23099", " - bonding: limit BOND_MODE_8023AD to Ethernet devices", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71194", " - btrfs: fix deadlock in wait_current_trans() due to ignored transaction", " type", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71185", " - dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23026", " - dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71188", " - dmaengine: lpc18xx-dmamux: fix device leak on route allocation", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71163", " - dmaengine: idxd: fix device leaks on compat bind and unbind", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71190", " - dmaengine: bcm-sba-raid: fix device leak on probe", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71191", " - dmaengine: at_hdmac: fix device leak on of_dma_xlate()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23049", " - drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23145", " - ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-22997", " - net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session", " upon receiving the second rts", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23033", " - dmaengine: omap-dma: fix dma_pool resource leak in error paths", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71196", " - phy: stm32-usphyc: Fix off by one in probe()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71162", " - dmaengine: tegra-adma: Fix use-after-free", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-22999", " - net/sched: sch_qfq: do not free existing class in qfq_change_class()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23011", " - ipv4: ip_gre: make ipgre_header() robust", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23001", " - macvlan: fix possible UAF in macvlan_forward_source()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23003", " - ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-22998", " - nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23037", " - can: etas_es58x: allow partial RX URB allocation to succeed", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23038", " - pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()", " * ADT test for linux package failed with \"fatal: unable to connect to", " git.launchpad.net\" (LP: #2143033)", " - [Packaging] d/t/ubuntu-regression-suite: use https to clone", " * efi: Fix swapped arguments to bsearch() in efi_status_to_*() SAUCE patch", " (LP: #2141276)", " - SAUCE efi: Fix swapped arguments to bsearch() in efi_status_to_*()", " * CVE-2026-23111", " - netfilter: nf_tables: fix inverted genmask check in", " nft_map_catchall_activate()", " * CVE-2026-23209", " - macvlan: fix error recovery in macvlan_common_newlink()", " * CVE-2025-37849", " - KVM: arm64: vgic: Add a non-locking primitive for", " kvm_vgic_vcpu_destroy()", " - KVM: arm64: Tear down vGIC on failed vCPU creation", " * CVE-2026-23074", " - net/sched: Enforce that teql can only be used as root qdisc", " * CVE-2026-23060", " - crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN", " spec", "" ], "package": "linux-kvm", "version": "5.15.0-1097.102", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2143524, 2143539, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143033, 2141276 ], "author": "Austin Rhodes ", "date": "Tue, 07 Apr 2026 09:50:23 -0400" } ], "notes": "linux-headers-5.15.0-1097-kvm version '5.15.0-1097.102' (source package linux-kvm version '5.15.0-1097.102') was added. linux-headers-5.15.0-1097-kvm version '5.15.0-1097.102' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1096-kvm. As such we can use the source package version of the removed package, '5.15.0-1096.101', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-image-5.15.0-1097-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1096.101", "version": null }, "to_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1097.102", "version": "5.15.0-1097.102" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 5.15.0-1097.102", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed-kvm", "version": "5.15.0-1097.102", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Austin Rhodes ", "date": "Tue, 07 Apr 2026 09:54:09 -0400" } ], "notes": "linux-image-5.15.0-1097-kvm version '5.15.0-1097.102' (source package linux-signed-kvm version '5.15.0-1097.102') was added. linux-image-5.15.0-1097-kvm version '5.15.0-1097.102' has the same source package name, linux-signed-kvm, as removed package linux-image-5.15.0-1096-kvm. As such we can use the source package version of the removed package, '5.15.0-1096.101', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-kvm-headers-5.15.0-1097", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1096.101", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1097.102", "version": "5.15.0-1097.102" }, "cves": [ { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2026-23170", "url": "https://ubuntu.com/security/CVE-2026-23170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imx/tve: fix probe device leak Make sure to drop the reference taken to the DDC device during probe on probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23075", "url": "https://ubuntu.com/security/CVE-2026-23075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In esd_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback esd_usb_read_bulk_callback(), the URBs are processed and resubmitted. In esd_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in esd_usb_close(). Fix the memory leak by anchoring the URB in the esd_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-38408", "url": "https://ubuntu.com/security/CVE-2025-38408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: genirq/irq_sim: Initialize work context pointers properly Initialize `ops` member's pointers properly by using kzalloc() instead of kmalloc() when allocating the simulation work context. Otherwise the pointers contain random content leading to invalid dereferencing.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2023-54207", "url": "https://ubuntu.com/security/CVE-2023-54207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: Correct devm device reference for hidinput input_dev name Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management. Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string.", "cve_priority": "medium", "cve_public_date": "2025-12-30 13:16:00 UTC" }, { "cve": "CVE-2023-53520", "url": "https://ubuntu.com/security/CVE-2023-53520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix hci_suspend_sync crash If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.", "cve_priority": "medium", "cve_public_date": "2025-10-01 12:15:00 UTC" }, { "cve": "CVE-2025-38125", "url": "https://ubuntu.com/security/CVE-2025-38125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring EST If the ptp_rate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0. Prevent this division by 0 by adding the corresponding check and error code.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-40164", "url": "https://ubuntu.com/security/CVE-2025-40164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix using smp_processor_id() in preemptible code warnings Syzbot reported the following warning: BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879 caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary) Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f For historical and portability reasons, the netif_rx() is usually run in the softirq or interrupt context, this commit therefore add local_bh_disable/enable() protection in the usbnet_resume_rx().", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-38232", "url": "https://ubuntu.com/security/CVE-2025-38232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix race between nfsd registration and exports_proc As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd. Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd for 5.4 kernel ARM64: CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0 CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 PC is at : exports_net_open+0x50/0x68 [nfsd] Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248 Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu(). and same is happening on latest 6.14 kernel as well: [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]--- It reproduced simply with below script: while [ 1 ] do /exportfs -r done & while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done & So exporting interfaces to user space shall be done at last and cleanup at first place. With change there is no Kernel OOPs.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2023-53662", "url": "https://ubuntu.com/security/CVE-2023-53662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup} If the filename casefolding fails, we'll be leaking memory from the fscrypt_name struct, namely from the 'crypto_buf.name' member. Make sure we free it in the error path on both ext4_fname_setup_filename() and ext4_fname_prepare_lookup() functions.", "cve_priority": "medium", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2025-38057", "url": "https://ubuntu.com/security/CVE-2025-38057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: fix skb leaks A few error paths are missing a kfree_skb.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2023-53421", "url": "https://ubuntu.com/security/CVE-2023-53421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats() When blkg_alloc() is called to allocate a blkcg_gq structure with the associated blkg_iostat_set's, there are 2 fields within blkg_iostat_set that requires proper initialization - blkg & sync. The former field was introduced by commit 3b8cc6298724 (\"blk-cgroup: Optimize blkcg_rstat_flush()\") while the later one was introduced by commit f73316482977 (\"blk-cgroup: reimplement basic IO stats using cgroup rstat\"). Unfortunately those fields in the blkg_iostat_set's are not properly re-initialized when they are cleared in v1's blkcg_reset_stats(). This can lead to a kernel panic due to NULL pointer access of the blkg pointer. The missing initialization of sync is less problematic and can be a problem in a debug kernel due to missing lockdep initialization. Fix these problems by re-initializing them after memory clearing.", "cve_priority": "medium", "cve_public_date": "2025-09-18 16:15:00 UTC" }, { "cve": "CVE-2025-68365", "url": "https://ubuntu.com/security/CVE-2025-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Initialize allocated memory before use KMSAN reports: Multiple uninitialized values detected: - KMSAN: uninit-value in ntfs_read_hdr (3) - KMSAN: uninit-value in bcmp (3) Memory is allocated by __getname(), which is a wrapper for kmem_cache_alloc(). This memory is used before being properly cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to properly allocate and clear memory before use.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68817", "url": "https://ubuntu.com/security/CVE-2025-68817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency Under high concurrency, A tree-connection object (tcon) is freed on a disconnect path while another path still holds a reference and later executes *_put()/write on it.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2022-50390", "url": "https://ubuntu.com/security/CVE-2022-50390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATED Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c ttm_bo_move_memcpy+0x3b4/0x460 [ttm] bo_driver_move+0x32/0x40 [drm_vram_helper] ttm_bo_handle_move_mem+0x118/0x200 [ttm] ttm_bo_validate+0xfa/0x220 [ttm] drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper] drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper] drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper] drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper] drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper] drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper] drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper] drm_atomic_commit+0x9c/0x160 [drm] drm_client_modeset_commit_atomic+0x33a/0x380 [drm] drm_client_modeset_commit_locked+0x77/0x220 [drm] drm_client_modeset_commit+0x31/0x60 [drm] __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper] drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper] fbcon_init+0x316/0x790 visual_init+0x113/0x1d0 do_bind_con_driver+0x2a3/0x5c0 do_take_over_console+0xa9/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ", "cve_priority": "medium", "cve_public_date": "2025-09-18 14:15:00 UTC" }, { "cve": "CVE-2025-68211", "url": "https://ubuntu.com/security/CVE-2025-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksm: use range-walk function to jump over holes in scan_get_next_rmap_item Currently, scan_get_next_rmap_item() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages. This patch replaces the per-address lookup with a range walk using walk_page_range(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1]. Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page: #include #include #include /* 32 TiB */ const size_t size = 32ul * 1024 * 1024 * 1024 * 1024; int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror(\"mmap() failed\\n\"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0; } $ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-23093", "url": "https://ubuntu.com/security/CVE-2026-23093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbd: fix dma_unmap_sg() nents The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23078", "url": "https://ubuntu.com/security/CVE-2026-23078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Fix buffer overflow in config retrieval The scarlett2_usb_get_config() function has a logic error in the endianness conversion code that can cause buffer overflows when count > 1. The code checks `if (size == 2)` where `size` is the total buffer size in bytes, then loops `count` times treating each element as u16 (2 bytes). This causes the loop to access `count * 2` bytes when the buffer only has `size` bytes allocated. Fix by checking the element size (config_item->size) instead of the total buffer size. This ensures the endianness conversion matches the actual element type.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71186", "url": "https://ubuntu.com/security/CVE-2025-71186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: stm32: dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71197", "url": "https://ubuntu.com/security/CVE-2025-71197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: therm: Fix off-by-one buffer overflow in alarms_store The sysfs buffer passed to alarms_store() is allocated with 'size + 1' bytes and a NUL terminator is appended. However, the 'size' argument does not account for this extra byte. The original code then allocated 'size' bytes and used strcpy() to copy 'buf', which always writes one byte past the allocated buffer since strcpy() copies until the NUL terminator at index 'size'. Fix this by parsing the 'buf' parameter directly using simple_strtoll() without allocating any intermediate memory or string copying. This removes the overflow while simplifying the code.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23087", "url": "https://ubuntu.com/security/CVE-2026-23087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Fix potential memory leak in scsiback_remove() Memory allocated for struct vscsiblk_info in scsiback_probe() is not freed in scsiback_remove() leading to potential memory leaks on remove, as well as in the scsiback_probe() error paths. Fix that by freeing it in scsiback_remove().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-40149", "url": "https://ubuntu.com/security/CVE-2025-40149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock(). get_netdev_for_sock() is called during setsockopt(), so not under RCU. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the only ->ndo_sk_get_lower_dev() user is bond_sk_get_lower_dev(), which uses RCU.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-23167", "url": "https://ubuntu.com/security/CVE-2026-23167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix race between rfkill and nci_unregister_device(). syzbot reported the splat below [0] without a repro. It indicates that struct nci_dev.cmd_wq had been destroyed before nci_close_device() was called via rfkill. nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which (I think) was called from virtual_ncidev_close() when syzbot close()d an fd of virtual_ncidev. The problem is that nci_unregister_device() destroys nci_dev.cmd_wq first and then calls nfc_unregister_device(), which removes the device from rfkill by rfkill_unregister(). So, the device is still visible via rfkill even after nci_dev.cmd_wq is destroyed. Let's unregister the device from rfkill first in nci_unregister_device(). Note that we cannot call nfc_unregister_device() before nci_close_device() because 1) nfc_unregister_device() calls device_del() which frees all memory allocated by devm_kzalloc() and linked to ndev->conn_info_list 2) nci_rx_work() could try to queue nci_conn_info to ndev->conn_info_list which could be leaked Thus, nfc_unregister_device() is split into two functions so we can remove rfkill interfaces only before nci_close_device(). [0]: DEBUG_LOCKS_WARN_ON(1) WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349 Modules linked in: CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline] RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187 Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f RSP: 0018:ffffc9000c767680 EFLAGS: 00010046 RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000 RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0 RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4 R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2 R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30 FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0 Call Trace: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ksys_write+0x150/0x270 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa59b39acb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9 RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007 RBP: 00007fa59b408bf7 R08: ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23150", "url": "https://ubuntu.com/security/CVE-2026-23150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame(). syzbot reported various memory leaks related to NFC, struct nfc_llcp_sock, sk_buff, nfc_dev, etc. [0] The leading log hinted that nfc_llcp_send_ui_frame() failed to allocate skb due to sock_error(sk) being -ENXIO. ENXIO is set by nfc_llcp_socket_release() when struct nfc_llcp_local is destroyed by local_cleanup(). The problem is that there is no synchronisation between nfc_llcp_send_ui_frame() and local_cleanup(), and skb could be put into local->tx_queue after it was purged in local_cleanup(): CPU1 CPU2 ---- ---- nfc_llcp_send_ui_frame() local_cleanup() |- do { ' |- pdu = nfc_alloc_send_skb(..., &err) | . | |- nfc_llcp_socket_release(local, false, ENXIO); | |- skb_queue_purge(&local->tx_queue); | | ' | |- skb_queue_tail(&local->tx_queue, pdu); | ... | |- pdu = nfc_alloc_send_skb(..., &err) | ^._________________________________.' local_cleanup() is called for struct nfc_llcp_local only after nfc_llcp_remove_local() unlinks it from llcp_devices. If we hold local->tx_queue.lock then, we can synchronise the thread and nfc_llcp_send_ui_frame(). Let's do that and check list_empty(&local->list) before queuing skb to local->tx_queue in nfc_llcp_send_ui_frame(). [0]: [ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6) [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak) BUG: memory leak unreferenced object 0xffff8881272f6800 (size 1024): comm \"syz.0.17\", pid 6096, jiffies 4294942766 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc da58d84d): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658 kmalloc_noprof include/linux/slab.h:961 [inline] sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239 sk_alloc+0x36/0x360 net/core/sock.c:2295 nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31 __sock_create+0x1a9/0x340 net/socket.c:1605 sock_create net/socket.c:1663 [inline] __sys_socket_create net/socket.c:1700 [inline] __sys_socket+0xb9/0x1a0 net/socket.c:1747 __do_sys_socket net/socket.c:1761 [inline] __se_sys_socket net/socket.c:1759 [inline] __x64_sys_socket+0x1b/0x30 net/socket.c:1759 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: memory leak unreferenced object 0xffff88810fbd9800 (size 240): comm \"syz.0.17\", pid 6096, jiffies 4294942850 hex dump (first 32 bytes): 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h....... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'.... backtrace (crc 6cc652b1): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/sk ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23164", "url": "https://ubuntu.com/security/CVE-2026-23164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rocker: fix memory leak in rocker_world_port_post_fini() In rocker_world_port_pre_init(), rocker_port->wpriv is allocated with kzalloc(wops->port_priv_size, GFP_KERNEL). However, in rocker_world_port_post_fini(), the memory is only freed when wops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv); Since rocker_ofdpa_ops does not implement port_post_fini callback (it is NULL), the wpriv memory allocated for each port is never freed when ports are removed. This leads to a memory leak of sizeof(struct ofdpa_port) bytes per port on every device removal. Fix this by always calling kfree(rocker_port->wpriv) regardless of whether the port_post_fini callback exists.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23146", "url": "https://ubuntu.com/security/CVE-2026-23146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling hci_uart_register_dev(), which calls proto->open() to initialize hu->priv. However, if a TTY write wakeup occurs during this window, hci_uart_tx_wakeup() may schedule write_work before hu->priv is initialized, leading to a NULL pointer dereference in hci_uart_write_work() when proto->dequeue() accesses hu->priv. The race condition is: CPU0 CPU1 ---- ---- hci_uart_set_proto() set_bit(HCI_UART_PROTO_INIT) hci_uart_register_dev() tty write wakeup hci_uart_tty_wakeup() hci_uart_tx_wakeup() schedule_work(&hu->write_work) proto->open(hu) // initializes hu->priv hci_uart_write_work() hci_uart_dequeue() proto->dequeue(hu) // accesses hu->priv (NULL!) Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open() succeeds, ensuring hu->priv is initialized before any work can be scheduled.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-38591", "url": "https://ubuntu.com/security/CVE-2025-38591", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject narrower access to pointer ctx fields The following BPF program, simplified from a syzkaller repro, causes a kernel warning: r0 = *(u8 *)(r1 + 169); exit; With pointer field sk being at offset 168 in __sk_buff. This access is detected as a narrower read in bpf_skb_is_valid_access because it doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed and later proceeds to bpf_convert_ctx_access. Note that for the \"is_narrower_load\" case in the convert_ctx_accesses(), the insn->off is aligned, so the cnt may not be 0 because it matches the offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However, the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1) This patch fixes that to return a proper \"invalid bpf_context access off=X size=Y\" error on the load instruction. The same issue affects multiple other fields in context structures that allow narrow access. Some other non-affected fields (for sk_msg, sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for consistency. Note this syzkaller crash was reported in the \"Closes\" link below, which used to be about a different bug, fixed in commit fce7bd8e385a (\"bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()\"). Because syzbot somehow confused the two bugs, the new crash and repro didn't get reported to the mailing list.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-68725", "url": "https://ubuntu.com/security/CVE-2025-68725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do not let BPF test infra emit invalid GSO types to stack Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled. We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place. The checks were added in 121d57af308d (\"gso: validate gso_type in GSO handlers\") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2026-23097", "url": "https://ubuntu.com/security/CVE-2026-23097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: migrate: correct lock ordering for hugetlb file folios Syzbot has found a deadlock (analyzed by Lance Yang): 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock! The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing i_mmap_lock to cover the calls to remove_migration_ptes() too. This is (mostly) how it used to be after commit c0d0381ade79. That was removed by 336bf30eb765 for both file & anon hugetlb pages when it should only have been removed for anon hugetlb pages.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23108", "url": "https://ubuntu.com/security/CVE-2026-23108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback usb_8dev_read_bulk_callback(), the URBs are processed and resubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the usb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23080", "url": "https://ubuntu.com/security/CVE-2026-23080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In mcba_usb_probe() -> mcba_usb_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback mcba_usb_read_bulk_callback(), the URBs are processed and resubmitted. In mcba_usb_close() -> mcba_urb_unlink() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the mcba_usb_read_bulk_callback()to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23061", "url": "https://ubuntu.com/security/CVE-2026-23061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In kvaser_usb_set_{,data_}bittiming() -> kvaser_usb_setup_rx_urbs(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback kvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. In kvaser_usb_remove_interfaces() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the kvaser_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23058", "url": "https://ubuntu.com/security/CVE-2026-23058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In ems_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In ems_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in ems_usb_close(). Fix the memory leak by anchoring the URB in the ems_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23085", "url": "https://ubuntu.com/security/CVE-2026-23085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Avoid truncating memory addresses On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23098", "url": "https://ubuntu.com/security/CVE-2026-23098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netrom: fix double-free in nr_route_frame() In nr_route_frame(), old_skb is immediately freed without checking if nr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL, the caller function will free old_skb again, causing a double-free bug. Therefore, to prevent this, we need to modify it to check whether nr_neigh->ax25 is NULL before freeing old_skb.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23063", "url": "https://ubuntu.com/security/CVE-2026-23063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: ensure safe queue release with state management Directly calling `put_queue` carries risks since it cannot guarantee that resources of `uacce_queue` have been fully released beforehand. So adding a `stop_queue` operation for the UACCE_CMD_PUT_Q command and leaving the `put_queue` operation to the final resource release ensures safety. Queue states are defined as follows: - UACCE_Q_ZOMBIE: Initial state - UACCE_Q_INIT: After opening `uacce` - UACCE_Q_STARTED: After `start` is issued via `ioctl` When executing `poweroff -f` in virt while accelerator are still working, `uacce_fops_release` and `uacce_remove` may execute concurrently. This can cause `uacce_put_queue` within `uacce_fops_release` to access a NULL `ops` pointer. Therefore, add state checks to prevent accessing freed pointers.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23056", "url": "https://ubuntu.com/security/CVE-2026-23056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: implement mremap in uacce_vm_ops to return -EPERM The current uacce_vm_ops does not support the mremap operation of vm_operations_struct. Implement .mremap to return -EPERM to remind users. The reason we need to explicitly disable mremap is that when the driver does not implement .mremap, it uses the default mremap method. This could lead to a risk scenario: An application might first mmap address p1, then mremap to p2, followed by munmap(p1), and finally munmap(p2). Since the default mremap copies the original vma's vm_private_data (i.e., q) to the new vma, both munmap operations would trigger vma_close, causing q->qfr to be freed twice(qfr will be set to null here, so repeated release is ok).", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23096", "url": "https://ubuntu.com/security/CVE-2026-23096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: fix cdev handling in the cleanup path When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23091", "url": "https://ubuntu.com/security/CVE-2026-23091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix device leak on output open() Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close(). Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23090", "url": "https://ubuntu.com/security/CVE-2026-23090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: core: fix device reference leak on report present Slimbus devices can be allocated dynamically upon reception of report-present messages. Make sure to drop the reference taken when looking up already registered devices. Note that this requires taking an extra reference in case the device has not yet been registered and has to be allocated.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23128", "url": "https://ubuntu.com/security/CVE-2026-23128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Set __nocfi on swsusp_arch_resume() A DABT is reported[1] on an android based system when resume from hiberate. This happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*() and does not have a CFI hash, but swsusp_arch_resume() will attempt to verify the CFI hash when calling a copy of swsusp_arch_suspend_exit(). Given that there's an existing requirement that the entrypoint to swsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text section, we cannot fix this by marking swsusp_arch_suspend_exit() with SYM_FUNC_*(). The simplest fix for now is to disable the CFI check in swsusp_arch_resume(). Mark swsusp_arch_resume() as __nocfi to disable the CFI check. [1] [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc [ 22.991934][ T1] Mem abort info: [ 22.991934][ T1] ESR = 0x0000000096000007 [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [ 22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][ T1] FSC = 0x07: level 3 translation fault [ 22.991934][ T1] Data abort info: [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 22.991934][ T1] Dumping ftrace buffer: [ 22.991934][ T1] (ftrace buffer empty) [ 22.991934][ T1] Modules linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419 [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT) [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344 [ 22.991934][ T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000 [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820 [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000 [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058 [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004 [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000 [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000 [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530 [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000 [ 22.991934][ T1] Call trace: [ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] hibernation_restore+0x158/0x18c [ 22.991934][ T1] load_image_and_restore+0xb0/0xec [ 22.991934][ T1] software_resume+0xf4/0x19c [ 22.991934][ T1] software_resume_initcall+0x34/0x78 [ 22.991934][ T1] do_one_initcall+0xe8/0x370 [ 22.991934][ T1] do_initcall_level+0xc8/0x19c [ 22.991934][ T1] do_initcalls+0x70/0xc0 [ 22.991934][ T1] do_basic_setup+0x1c/0x28 [ 22.991934][ T1] kernel_init_freeable+0xe0/0x148 [ 22.991934][ T1] kernel_init+0x20/0x1a8 [ 22.991934][ T1] ret_from_fork+0x10/0x20 [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110) [catalin.marinas@arm.com: commit log updated by Mark Rutland]", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23073", "url": "https://ubuntu.com/security/CVE-2026-23073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: Fix memory corruption due to not set vif driver data size The struct ieee80211_vif contains trailing space for vif driver data, when struct ieee80211_vif is allocated, the total memory size that is allocated is sizeof(struct ieee80211_vif) + size of vif driver data. The size of vif driver data is set by each WiFi driver as needed. The RSI911x driver does not set vif driver data size, no trailing space for vif driver data is therefore allocated past struct ieee80211_vif . The RSI911x driver does however use the vif driver data to store its vif driver data structure \"struct vif_priv\". An access to vif->drv_priv leads to access out of struct ieee80211_vif bounds and corruption of some memory. In case of the failure observed locally, rsi_mac80211_add_interface() would write struct vif_priv *vif_info = (struct vif_priv *)vif->drv_priv; vif_info->vap_id = vap_idx. This write corrupts struct fq_tin member struct list_head new_flows . The flow = list_first_entry(head, struct fq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus address, which when accessed causes a crash. The trigger is very simple, boot the machine with init=/bin/sh , mount devtmpfs, sysfs, procfs, and then do \"ip link set wlan0 up\", \"sleep 1\", \"ip link set wlan0 down\" and the crash occurs. Fix this by setting the correct size of vif driver data, which is the size of \"struct vif_priv\", so that memory is allocated and the driver can store its driver data in it, instead of corrupting memory around it.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23133", "url": "https://ubuntu.com/security/CVE-2026-23133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: fix dma_free_coherent() pointer dma_alloc_coherent() allocates a DMA mapped buffer and stores the addresses in XXX_unaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23089", "url": "https://ubuntu.com/security/CVE-2026-23089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free() When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees mixer->id_elems but the controls already added to the card still reference the freed memory. Later when snd_card_register() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read. Call trace: get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381 snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ... snd_card_register+0x4ed/0x6d0 sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025 Fix by calling snd_ctl_remove() for all mixer controls before freeing id_elems. We save the next pointer first because snd_ctl_remove() frees the current element.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23076", "url": "https://ubuntu.com/security/CVE-2026-23076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix potential OOB access in audio mixer handling In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixer_index() and sum_index()). As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]' After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field. This patch addresses those OOB accesses by adding the proper initializations of the loop indices.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71199", "url": "https://ubuntu.com/security/CVE-2025-71199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver at91_adc_interrupt can call at91_adc_touch_data_handler function to start the work by schedule_work(&st->touch_st.workq). If we remove the module which will call at91_adc_remove to make cleanup, it will free indio_dev through iio_device_unregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | at91_adc_workq_handler at91_adc_remove | iio_device_unregister(indio_dev) | //free indio_dev a bit later | | iio_push_to_buffers(indio_dev) | //use indio_dev Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91_adc_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23101", "url": "https://ubuntu.com/security/CVE-2026-23101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: led-class: Only Add LED to leds_list when it is fully ready Before this change the LED was added to leds_list before led_init_core() gets called adding it the list before led_classdev.set_brightness_work gets initialized. This leaves a window where led_trigger_register() of a LED's default trigger will call led_trigger_set() which calls led_set_brightness() which in turn will end up queueing the *uninitialized* led_classdev.set_brightness_work. This race gets hit by the lenovo-thinkpad-t14s EC driver which registers 2 LEDs with a default trigger provided by snd_ctl_led.ko in quick succession. The first led_classdev_register() causes an async modprobe of snd_ctl_led to run and that async modprobe manages to exactly hit the window where the second LED is on the leds_list without led_init_core() being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998 Close the race window by moving the adding of the LED to leds_list to after the led_init_core() call.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23064", "url": "https://ubuntu.com/security/CVE-2026-23064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: avoid possible NULL deref tcf_ife_encode() must make sure ife_encode() does not return NULL. syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166 CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full) Call Trace: ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23119", "url": "https://ubuntu.com/security/CVE-2026-23119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: provide a net pointer to __skb_flow_dissect() After 3cbf4ffba5ee (\"net: plumb network namespace into __skb_flow_dissect\") we have to provide a net pointer to __skb_flow_dissect(), either via skb->dev, skb->sk, or a user provided pointer. In the following case, syzbot was able to cook a bare skb. WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053 Call Trace: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23084", "url": "https://ubuntu.com/security/CVE-2026-23084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list When the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() is set to false, the driver may request the PMAC_ID from the firmware of the network card, and this function will store that PMAC_ID at the provided address pmac_id. This is the contract of this function. However, there is a location within the driver where both pmac_id_valid == false and pmac_id == NULL are being passed. This could result in dereferencing a NULL pointer. To resolve this issue, it is necessary to pass the address of a stub variable to the function.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23124", "url": "https://ubuntu.com/security/CVE-2026-23124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: annotate data-race in ndisc_router_discovery() syzbot found that ndisc_router_discovery() could read and write in6_dev->ra_mtu without holding a lock [1] This looks fine, IFLA_INET6_RA_MTU is best effort. Add READ_ONCE()/WRITE_ONCE() to document the race. Note that we might also reject illegal MTU values (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch. [1] BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... value changed: 0x00000000 -> 0xe5400659", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23121", "url": "https://ubuntu.com/security/CVE-2026-23121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mISDN: annotate data-race around dev->work dev->work can re read locklessly in mISDN_read() and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations. BUG: KCSAN: data-race in mISDN_ioctl / mISDN_read write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [inline] vfs_readv+0x3fb/0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [inline] __se_sys_readv fs/read_write.c:1162 [inline] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000 -> 0x00000001", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23071", "url": "https://ubuntu.com/security/CVE-2026-23071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: Fix race condition in hwspinlock irqsave routine Previously, the address of the shared member '&map->spinlock_flags' was passed directly to 'hwspin_lock_timeout_irqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shared flags variable, potentially corrupting the state for the current lock owner. Fix this by using a local stack variable 'flags' to store the IRQ state temporarily.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23105", "url": "https://ubuntu.com/security/CVE-2026-23105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag This is more of a preventive patch to make the code more consistent and to prevent possible exploits that employ child qlen manipulations on qfq. use cl_is_active instead of relying on the child qdisc's qlen to determine class activation.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23103", "url": "https://ubuntu.com/security/CVE-2026-23103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close) This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause: 1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock. 2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23120", "url": "https://ubuntu.com/security/CVE-2026-23120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: avoid one data-race in l2tp_tunnel_del_work() We should read sk->sk_socket only when dealing with kernel sockets. syzbot reported the following data-race: BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 value changed: 0xffff88811b818000 -> 0x0000000000000000", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23083", "url": "https://ubuntu.com/security/CVE-2026-23083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Don't allow 0 for FOU_ATTR_IPPROTO. fou_udp_recv() has the same problem mentioned in the previous patch. If FOU_ATTR_IPPROTO is set to 0, skb is not freed by fou_udp_recv() nor \"resubmit\"-ted in ip_protocol_deliver_rcu(). Let's forbid 0 for FOU_ATTR_IPPROTO.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23095", "url": "https://ubuntu.com/security/CVE-2026-23095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: Fix skb memleak with inner IP protocol 0. syzbot reported skb memleak below. [0] The repro generated a GUE packet with its inner protocol 0. gue_udp_recv() returns -guehdr->proto_ctype for \"resubmit\" in ip_protocol_deliver_rcu(), but this only works with non-zero protocol number. Let's drop such packets. Note that 0 is a valid number (IPv6 Hop-by-Hop Option). I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT [0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm \"syz.0.17\", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23125", "url": "https://ubuntu.com/security/CVE-2026-23125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key initialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127 The issue is triggered when sctp_auth_asoc_init_active_key() fails in sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the command sequence is currently: - SCTP_CMD_PEER_INIT - SCTP_CMD_TIMER_STOP (T1_INIT) - SCTP_CMD_TIMER_START (T1_COOKIE) - SCTP_CMD_NEW_STATE (COOKIE_ECHOED) - SCTP_CMD_ASSOC_SHKEY - SCTP_CMD_GEN_COOKIE_ECHO If SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while asoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL to be queued by sctp_datamsg_from_user(). Since command interpretation stops on failure, no COOKIE_ECHO should been sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As a result, the DATA chunk can be transmitted together with the COOKIE_ECHO in sctp_outq_flush_data(), leading to the observed issue. Similar to the other places where it calls sctp_auth_asoc_init_active_key() right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting T1_COOKIE. This ensures that if shared key generation fails, authenticated DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT, giving the client another chance to process INIT_ACK and retry key setup.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23099", "url": "https://ubuntu.com/security/CVE-2026-23099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: limit BOND_MODE_8023AD to Ethernet devices BOND_MODE_8023AD makes sense for ARPHRD_ETHER only. syzbot reported: BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline] BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497 CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [inline] __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [inline] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e The buggy address belongs to the variable: lacpdu_mcast_addr+0x0/0x40", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71194", "url": "https://ubuntu.com/security/CVE-2025-71194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock in wait_current_trans() due to ignored transaction type When wait_current_trans() is called during start_transaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfs_blocked_trans_types[] array already defines which transaction types should wait for which transaction states, but this check was missing in wait_current_trans(). This can lead to a deadlock scenario involving two transactions and pending ordered extents: 1. Transaction A is in TRANS_STATE_COMMIT_DOING state 2. A worker processing an ordered extent calls start_transaction() with TRANS_JOIN 3. join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes 5. A new Transaction B is created (TRANS_STATE_RUNNING) 6. The ordered extent from step 2 is added to Transaction B's pending ordered extents 7. Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START 8. The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[] 10. Transaction B is waiting for pending ordered extents to complete 11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B This can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!) Task bstore_kv_sync in btrfs_commit_transaction waiting for ordered extents: __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Task kworker in wait_current_trans waiting for transaction commit: Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30 Fix this by passing the transaction type to wait_current_trans() and checking btrfs_blocked_trans_types[cur_trans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71185", "url": "https://ubuntu.com/security/CVE-2025-71185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23026", "url": "https://ubuntu.com/security/CVE-2026-23026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config() Fix a memory leak in gpi_peripheral_config() where the original memory pointed to by gchan->config could be lost if krealloc() fails. The issue occurs when: 1. gchan->config points to previously allocated memory 2. krealloc() fails and returns NULL 3. The function directly assigns NULL to gchan->config, losing the reference to the original memory 4. The original memory becomes unreachable and cannot be freed Fix this by using a temporary variable to hold the krealloc() result and only updating gchan->config when the allocation succeeds. Found via static analysis and code review.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71188", "url": "https://ubuntu.com/security/CVE-2025-71188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: lpc18xx-dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71163", "url": "https://ubuntu.com/security/CVE-2025-71163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix device leaks on compat bind and unbind Make sure to drop the reference taken when looking up the idxd device as part of the compat bind and unbind sysfs interface.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2025-71190", "url": "https://ubuntu.com/security/CVE-2025-71190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: bcm-sba-raid: fix device leak on probe Make sure to drop the reference taken when looking up the mailbox device during probe on probe failures and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71191", "url": "https://ubuntu.com/security/CVE-2025-71191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: at_hdmac: fix device leak on of_dma_xlate() Make sure to drop the reference taken when looking up the DMA platform device during of_dma_xlate() when releasing channel resources. Note that commit 3832b78b3ec2 (\"dmaengine: at_hdmac: add missing put_device() call in at_dma_xlate()\") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23049", "url": "https://ubuntu.com/security/CVE-2026-23049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel The connector type for the DataImage SCF0700C48GGU18 panel is missing and devm_drm_panel_bridge_add() requires connector type to be set. This leads to a warning and a backtrace in the kernel log and panel does not work: \" WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8 \" The warning is triggered by a check for valid connector type in devm_drm_panel_bridge_add(). If there is no valid connector type set for a panel, the warning is printed and panel is not added. Fill in the missing connector type to fix the warning and make the panel operational once again.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23145", "url": "https://ubuntu.com/security/CVE-2026-23145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref The error branch for ext4_xattr_inode_update_ref forget to release the refcount for iloc.bh. Find this when review code.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-22997", "url": "https://ubuntu.com/security/CVE-2026-22997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is called only when the timer is enabled, we need to call j1939_session_deactivate_activate_next() if we cancelled the timer. Otherwise, refcount for j1939_session leaks, which will later appear as | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2. problem.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23033", "url": "https://ubuntu.com/security/CVE-2026-23033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: omap-dma: fix dma_pool resource leak in error paths The dma_pool created by dma_pool_create() is not destroyed when dma_async_device_register() or of_dma_controller_register() fails, causing a resource leak in the probe error paths. Add dma_pool_destroy() in both error paths to properly release the allocated dma_pool resource.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71196", "url": "https://ubuntu.com/security/CVE-2025-71196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: stm32-usphyc: Fix off by one in probe() The \"index\" variable is used as an index into the usbphyc->phys[] array which has usbphyc->nphys elements. So if it is equal to usbphyc->nphys then it is one element out of bounds. The \"index\" comes from the device tree so it's data that we trust and it's unlikely to be wrong, however it's obviously still worth fixing the bug. Change the > to >=.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71162", "url": "https://ubuntu.com/security/CVE-2025-71162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: tegra-adma: Fix use-after-free A use-after-free bug exists in the Tegra ADMA driver when audio streams are terminated, particularly during XRUN conditions. The issue occurs when the DMA buffer is freed by tegra_adma_terminate_all() before the vchan completion tasklet finishes accessing it. The race condition follows this sequence: 1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegra_adma_terminate_all() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchan_complete() which attempts to access the already-freed memory Since tasklets can execute at any time after being scheduled, there is no guarantee that the buffer will remain valid when vchan_complete() runs. Fix this by properly synchronizing the virtual channel completion: - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegra_adma_synchronize() that calls vchan_synchronize() which kills any pending tasklets and frees any terminated descriptors. Crash logs: [ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0 [ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0 [ 337.427562] Call trace: [ 337.427564] dump_backtrace+0x0/0x320 [ 337.427571] show_stack+0x20/0x30 [ 337.427575] dump_stack_lvl+0x68/0x84 [ 337.427584] print_address_description.constprop.0+0x74/0x2b8 [ 337.427590] kasan_report+0x1f4/0x210 [ 337.427598] __asan_load8+0xa0/0xd0 [ 337.427603] vchan_complete+0x124/0x3b0 [ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0 [ 337.427617] tasklet_action+0x30/0x40 [ 337.427623] __do_softirq+0x1a0/0x5c4 [ 337.427628] irq_exit+0x110/0x140 [ 337.427633] handle_domain_irq+0xa4/0xe0 [ 337.427640] gic_handle_irq+0x64/0x160 [ 337.427644] call_on_irq_stack+0x20/0x4c [ 337.427649] do_interrupt_handler+0x7c/0x90 [ 337.427654] el1_interrupt+0x30/0x80 [ 337.427659] el1h_64_irq_handler+0x18/0x30 [ 337.427663] el1h_64_irq+0x7c/0x80 [ 337.427667] cpuidle_enter_state+0xe4/0x540 [ 337.427674] cpuidle_enter+0x54/0x80 [ 337.427679] do_idle+0x2e0/0x380 [ 337.427685] cpu_startup_entry+0x2c/0x70 [ 337.427690] rest_init+0x114/0x130 [ 337.427695] arch_call_rest_init+0x18/0x24 [ 337.427702] start_kernel+0x380/0x3b4 [ 337.427706] __primary_switched+0xc0/0xc8", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22999", "url": "https://ubuntu.com/security/CVE-2026-22999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: do not free existing class in qfq_change_class() Fixes qfq_change_class() error case. cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23011", "url": "https://ubuntu.com/security/CVE-2026-23011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_gre: make ipgre_header() robust Analog to commit db5b4e39c4e6 (\"ip6_gre: make ip6gre_header() robust\") Over the years, syzbot found many ways to crash the kernel in ipgre_header() [1]. This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ipgre device. [1] skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213 Call Trace: skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23001", "url": "https://ubuntu.com/security/CVE-2026-23001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix possible UAF in macvlan_forward_source() Add RCU protection on (struct macvlan_source_entry)->vlan. Whenever macvlan_hash_del_source() is called, we must clear entry->vlan pointer before RCU grace period starts. This allows macvlan_forward_source() to skip over entries queued for freeing. Note that macvlan_dev are already RCU protected, as they are embedded in a standard netdev (netdev_priv(ndev)). https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23003", "url": "https://ubuntu.com/security/CVE-2026-23003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() Blamed commit did not take care of VLAN encapsulations as spotted by syzbot [1]. Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull(). [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22998", "url": "https://ubuntu.com/security/CVE-2026-22998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec Commit efa56305908b (\"nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs. The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command. Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23037", "url": "https://ubuntu.com/security/CVE-2026-23037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: allow partial RX URB allocation to succeed When es58x_alloc_rx_urbs() fails to allocate the requested number of URBs but succeeds in allocating some, it returns an error code. This causes es58x_open() to return early, skipping the cleanup label 'free_urbs', which leads to the anchored URBs being leaked. As pointed out by maintainer Vincent Mailhol, the driver is designed to handle partial URB allocation gracefully. Therefore, partial allocation should not be treated as a fatal error. Modify es58x_alloc_rx_urbs() to return 0 if at least one URB has been allocated, restoring the intended behavior and preventing the leak in es58x_open().", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23038", "url": "https://ubuntu.com/security/CVE-2026-23038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node() In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak. Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23111", "url": "https://ubuntu.com/security/CVE-2026-23111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate() nft_map_catchall_activate() has an inverted element activity check compared to its non-catchall counterpart nft_mapelem_activate() and compared to what is logically required. nft_map_catchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones. Compare the non-catchall activate callback, which is correct: nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; /* skip active, process inactive */ With the buggy catchall version: nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; /* skip inactive, process active */ The consequence is that when a DELSET operation is aborted, nft_setelem_data_activate() is never called for the catchall element. For NFT_GOTO verdict elements, this means nft_data_hold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free. This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIG_USER_NS and CONFIG_NF_TABLES. Fix by removing the negation so the check matches nft_mapelem_activate(): skip active elements, process inactive ones.", "cve_priority": "high", "cve_public_date": "2026-02-13 14:16:00 UTC" }, { "cve": "CVE-2026-23209", "url": "https://ubuntu.com/security/CVE-2026-23209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source(). With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-37849", "url": "https://ubuntu.com/security/CVE-2025-37849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Tear down vGIC on failed vCPU creation If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU. Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.", "cve_priority": "high", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2026-23074", "url": "https://ubuntu.com/security/CVE-2026-23074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Enforce that teql can only be used as root qdisc Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint. Although not important, I will describe the scenario that unearthed this issue for the curious. GangMin Kim managed to concot a scenario as follows: ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s └── class 1:2 (weight=1, lmax=1514) teql GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23060", "url": "https://ubuntu.com/security/CVE-2026-23060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, crypto_authenc_esn_decrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalk_map_and_copy(), leading to a kernel panic (DoS). Add a minimum AAD length check to fail fast on invalid inputs.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143524, 2143539, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143033, 2141276 ], "changes": [ { "cves": [ { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2026-23170", "url": "https://ubuntu.com/security/CVE-2026-23170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imx/tve: fix probe device leak Make sure to drop the reference taken to the DDC device during probe on probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23075", "url": "https://ubuntu.com/security/CVE-2026-23075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In esd_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback esd_usb_read_bulk_callback(), the URBs are processed and resubmitted. In esd_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in esd_usb_close(). Fix the memory leak by anchoring the URB in the esd_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-38408", "url": "https://ubuntu.com/security/CVE-2025-38408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: genirq/irq_sim: Initialize work context pointers properly Initialize `ops` member's pointers properly by using kzalloc() instead of kmalloc() when allocating the simulation work context. Otherwise the pointers contain random content leading to invalid dereferencing.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2023-54207", "url": "https://ubuntu.com/security/CVE-2023-54207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: Correct devm device reference for hidinput input_dev name Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management. Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string.", "cve_priority": "medium", "cve_public_date": "2025-12-30 13:16:00 UTC" }, { "cve": "CVE-2023-53520", "url": "https://ubuntu.com/security/CVE-2023-53520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix hci_suspend_sync crash If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.", "cve_priority": "medium", "cve_public_date": "2025-10-01 12:15:00 UTC" }, { "cve": "CVE-2025-38125", "url": "https://ubuntu.com/security/CVE-2025-38125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring EST If the ptp_rate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0. Prevent this division by 0 by adding the corresponding check and error code.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-40164", "url": "https://ubuntu.com/security/CVE-2025-40164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix using smp_processor_id() in preemptible code warnings Syzbot reported the following warning: BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879 caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary) Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f For historical and portability reasons, the netif_rx() is usually run in the softirq or interrupt context, this commit therefore add local_bh_disable/enable() protection in the usbnet_resume_rx().", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-38232", "url": "https://ubuntu.com/security/CVE-2025-38232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix race between nfsd registration and exports_proc As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd. Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd for 5.4 kernel ARM64: CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0 CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 PC is at : exports_net_open+0x50/0x68 [nfsd] Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248 Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu(). and same is happening on latest 6.14 kernel as well: [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]--- It reproduced simply with below script: while [ 1 ] do /exportfs -r done & while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done & So exporting interfaces to user space shall be done at last and cleanup at first place. With change there is no Kernel OOPs.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2023-53662", "url": "https://ubuntu.com/security/CVE-2023-53662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup} If the filename casefolding fails, we'll be leaking memory from the fscrypt_name struct, namely from the 'crypto_buf.name' member. Make sure we free it in the error path on both ext4_fname_setup_filename() and ext4_fname_prepare_lookup() functions.", "cve_priority": "medium", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2025-38057", "url": "https://ubuntu.com/security/CVE-2025-38057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: fix skb leaks A few error paths are missing a kfree_skb.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2023-53421", "url": "https://ubuntu.com/security/CVE-2023-53421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats() When blkg_alloc() is called to allocate a blkcg_gq structure with the associated blkg_iostat_set's, there are 2 fields within blkg_iostat_set that requires proper initialization - blkg & sync. The former field was introduced by commit 3b8cc6298724 (\"blk-cgroup: Optimize blkcg_rstat_flush()\") while the later one was introduced by commit f73316482977 (\"blk-cgroup: reimplement basic IO stats using cgroup rstat\"). Unfortunately those fields in the blkg_iostat_set's are not properly re-initialized when they are cleared in v1's blkcg_reset_stats(). This can lead to a kernel panic due to NULL pointer access of the blkg pointer. The missing initialization of sync is less problematic and can be a problem in a debug kernel due to missing lockdep initialization. Fix these problems by re-initializing them after memory clearing.", "cve_priority": "medium", "cve_public_date": "2025-09-18 16:15:00 UTC" }, { "cve": "CVE-2025-68365", "url": "https://ubuntu.com/security/CVE-2025-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Initialize allocated memory before use KMSAN reports: Multiple uninitialized values detected: - KMSAN: uninit-value in ntfs_read_hdr (3) - KMSAN: uninit-value in bcmp (3) Memory is allocated by __getname(), which is a wrapper for kmem_cache_alloc(). This memory is used before being properly cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to properly allocate and clear memory before use.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68817", "url": "https://ubuntu.com/security/CVE-2025-68817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency Under high concurrency, A tree-connection object (tcon) is freed on a disconnect path while another path still holds a reference and later executes *_put()/write on it.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2022-50390", "url": "https://ubuntu.com/security/CVE-2022-50390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATED Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c ttm_bo_move_memcpy+0x3b4/0x460 [ttm] bo_driver_move+0x32/0x40 [drm_vram_helper] ttm_bo_handle_move_mem+0x118/0x200 [ttm] ttm_bo_validate+0xfa/0x220 [ttm] drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper] drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper] drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper] drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper] drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper] drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper] drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper] drm_atomic_commit+0x9c/0x160 [drm] drm_client_modeset_commit_atomic+0x33a/0x380 [drm] drm_client_modeset_commit_locked+0x77/0x220 [drm] drm_client_modeset_commit+0x31/0x60 [drm] __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper] drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper] fbcon_init+0x316/0x790 visual_init+0x113/0x1d0 do_bind_con_driver+0x2a3/0x5c0 do_take_over_console+0xa9/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ", "cve_priority": "medium", "cve_public_date": "2025-09-18 14:15:00 UTC" }, { "cve": "CVE-2025-68211", "url": "https://ubuntu.com/security/CVE-2025-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksm: use range-walk function to jump over holes in scan_get_next_rmap_item Currently, scan_get_next_rmap_item() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages. This patch replaces the per-address lookup with a range walk using walk_page_range(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1]. Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page: #include #include #include /* 32 TiB */ const size_t size = 32ul * 1024 * 1024 * 1024 * 1024; int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror(\"mmap() failed\\n\"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0; } $ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-23093", "url": "https://ubuntu.com/security/CVE-2026-23093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbd: fix dma_unmap_sg() nents The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23078", "url": "https://ubuntu.com/security/CVE-2026-23078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Fix buffer overflow in config retrieval The scarlett2_usb_get_config() function has a logic error in the endianness conversion code that can cause buffer overflows when count > 1. The code checks `if (size == 2)` where `size` is the total buffer size in bytes, then loops `count` times treating each element as u16 (2 bytes). This causes the loop to access `count * 2` bytes when the buffer only has `size` bytes allocated. Fix by checking the element size (config_item->size) instead of the total buffer size. This ensures the endianness conversion matches the actual element type.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71186", "url": "https://ubuntu.com/security/CVE-2025-71186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: stm32: dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71197", "url": "https://ubuntu.com/security/CVE-2025-71197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: therm: Fix off-by-one buffer overflow in alarms_store The sysfs buffer passed to alarms_store() is allocated with 'size + 1' bytes and a NUL terminator is appended. However, the 'size' argument does not account for this extra byte. The original code then allocated 'size' bytes and used strcpy() to copy 'buf', which always writes one byte past the allocated buffer since strcpy() copies until the NUL terminator at index 'size'. Fix this by parsing the 'buf' parameter directly using simple_strtoll() without allocating any intermediate memory or string copying. This removes the overflow while simplifying the code.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23087", "url": "https://ubuntu.com/security/CVE-2026-23087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Fix potential memory leak in scsiback_remove() Memory allocated for struct vscsiblk_info in scsiback_probe() is not freed in scsiback_remove() leading to potential memory leaks on remove, as well as in the scsiback_probe() error paths. Fix that by freeing it in scsiback_remove().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-40149", "url": "https://ubuntu.com/security/CVE-2025-40149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock(). get_netdev_for_sock() is called during setsockopt(), so not under RCU. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the only ->ndo_sk_get_lower_dev() user is bond_sk_get_lower_dev(), which uses RCU.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-23167", "url": "https://ubuntu.com/security/CVE-2026-23167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix race between rfkill and nci_unregister_device(). syzbot reported the splat below [0] without a repro. It indicates that struct nci_dev.cmd_wq had been destroyed before nci_close_device() was called via rfkill. nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which (I think) was called from virtual_ncidev_close() when syzbot close()d an fd of virtual_ncidev. The problem is that nci_unregister_device() destroys nci_dev.cmd_wq first and then calls nfc_unregister_device(), which removes the device from rfkill by rfkill_unregister(). So, the device is still visible via rfkill even after nci_dev.cmd_wq is destroyed. Let's unregister the device from rfkill first in nci_unregister_device(). Note that we cannot call nfc_unregister_device() before nci_close_device() because 1) nfc_unregister_device() calls device_del() which frees all memory allocated by devm_kzalloc() and linked to ndev->conn_info_list 2) nci_rx_work() could try to queue nci_conn_info to ndev->conn_info_list which could be leaked Thus, nfc_unregister_device() is split into two functions so we can remove rfkill interfaces only before nci_close_device(). [0]: DEBUG_LOCKS_WARN_ON(1) WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349 Modules linked in: CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline] RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187 Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f RSP: 0018:ffffc9000c767680 EFLAGS: 00010046 RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000 RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0 RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4 R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2 R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30 FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0 Call Trace: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ksys_write+0x150/0x270 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa59b39acb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9 RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007 RBP: 00007fa59b408bf7 R08: ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23150", "url": "https://ubuntu.com/security/CVE-2026-23150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame(). syzbot reported various memory leaks related to NFC, struct nfc_llcp_sock, sk_buff, nfc_dev, etc. [0] The leading log hinted that nfc_llcp_send_ui_frame() failed to allocate skb due to sock_error(sk) being -ENXIO. ENXIO is set by nfc_llcp_socket_release() when struct nfc_llcp_local is destroyed by local_cleanup(). The problem is that there is no synchronisation between nfc_llcp_send_ui_frame() and local_cleanup(), and skb could be put into local->tx_queue after it was purged in local_cleanup(): CPU1 CPU2 ---- ---- nfc_llcp_send_ui_frame() local_cleanup() |- do { ' |- pdu = nfc_alloc_send_skb(..., &err) | . | |- nfc_llcp_socket_release(local, false, ENXIO); | |- skb_queue_purge(&local->tx_queue); | | ' | |- skb_queue_tail(&local->tx_queue, pdu); | ... | |- pdu = nfc_alloc_send_skb(..., &err) | ^._________________________________.' local_cleanup() is called for struct nfc_llcp_local only after nfc_llcp_remove_local() unlinks it from llcp_devices. If we hold local->tx_queue.lock then, we can synchronise the thread and nfc_llcp_send_ui_frame(). Let's do that and check list_empty(&local->list) before queuing skb to local->tx_queue in nfc_llcp_send_ui_frame(). [0]: [ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6) [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak) BUG: memory leak unreferenced object 0xffff8881272f6800 (size 1024): comm \"syz.0.17\", pid 6096, jiffies 4294942766 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc da58d84d): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658 kmalloc_noprof include/linux/slab.h:961 [inline] sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239 sk_alloc+0x36/0x360 net/core/sock.c:2295 nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31 __sock_create+0x1a9/0x340 net/socket.c:1605 sock_create net/socket.c:1663 [inline] __sys_socket_create net/socket.c:1700 [inline] __sys_socket+0xb9/0x1a0 net/socket.c:1747 __do_sys_socket net/socket.c:1761 [inline] __se_sys_socket net/socket.c:1759 [inline] __x64_sys_socket+0x1b/0x30 net/socket.c:1759 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: memory leak unreferenced object 0xffff88810fbd9800 (size 240): comm \"syz.0.17\", pid 6096, jiffies 4294942850 hex dump (first 32 bytes): 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h....... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'.... backtrace (crc 6cc652b1): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/sk ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23164", "url": "https://ubuntu.com/security/CVE-2026-23164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rocker: fix memory leak in rocker_world_port_post_fini() In rocker_world_port_pre_init(), rocker_port->wpriv is allocated with kzalloc(wops->port_priv_size, GFP_KERNEL). However, in rocker_world_port_post_fini(), the memory is only freed when wops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv); Since rocker_ofdpa_ops does not implement port_post_fini callback (it is NULL), the wpriv memory allocated for each port is never freed when ports are removed. This leads to a memory leak of sizeof(struct ofdpa_port) bytes per port on every device removal. Fix this by always calling kfree(rocker_port->wpriv) regardless of whether the port_post_fini callback exists.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23146", "url": "https://ubuntu.com/security/CVE-2026-23146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling hci_uart_register_dev(), which calls proto->open() to initialize hu->priv. However, if a TTY write wakeup occurs during this window, hci_uart_tx_wakeup() may schedule write_work before hu->priv is initialized, leading to a NULL pointer dereference in hci_uart_write_work() when proto->dequeue() accesses hu->priv. The race condition is: CPU0 CPU1 ---- ---- hci_uart_set_proto() set_bit(HCI_UART_PROTO_INIT) hci_uart_register_dev() tty write wakeup hci_uart_tty_wakeup() hci_uart_tx_wakeup() schedule_work(&hu->write_work) proto->open(hu) // initializes hu->priv hci_uart_write_work() hci_uart_dequeue() proto->dequeue(hu) // accesses hu->priv (NULL!) Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open() succeeds, ensuring hu->priv is initialized before any work can be scheduled.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-38591", "url": "https://ubuntu.com/security/CVE-2025-38591", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject narrower access to pointer ctx fields The following BPF program, simplified from a syzkaller repro, causes a kernel warning: r0 = *(u8 *)(r1 + 169); exit; With pointer field sk being at offset 168 in __sk_buff. This access is detected as a narrower read in bpf_skb_is_valid_access because it doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed and later proceeds to bpf_convert_ctx_access. Note that for the \"is_narrower_load\" case in the convert_ctx_accesses(), the insn->off is aligned, so the cnt may not be 0 because it matches the offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However, the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1) This patch fixes that to return a proper \"invalid bpf_context access off=X size=Y\" error on the load instruction. The same issue affects multiple other fields in context structures that allow narrow access. Some other non-affected fields (for sk_msg, sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for consistency. Note this syzkaller crash was reported in the \"Closes\" link below, which used to be about a different bug, fixed in commit fce7bd8e385a (\"bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()\"). Because syzbot somehow confused the two bugs, the new crash and repro didn't get reported to the mailing list.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-68725", "url": "https://ubuntu.com/security/CVE-2025-68725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do not let BPF test infra emit invalid GSO types to stack Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled. We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place. The checks were added in 121d57af308d (\"gso: validate gso_type in GSO handlers\") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2026-23097", "url": "https://ubuntu.com/security/CVE-2026-23097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: migrate: correct lock ordering for hugetlb file folios Syzbot has found a deadlock (analyzed by Lance Yang): 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock! The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing i_mmap_lock to cover the calls to remove_migration_ptes() too. This is (mostly) how it used to be after commit c0d0381ade79. That was removed by 336bf30eb765 for both file & anon hugetlb pages when it should only have been removed for anon hugetlb pages.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23108", "url": "https://ubuntu.com/security/CVE-2026-23108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback usb_8dev_read_bulk_callback(), the URBs are processed and resubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the usb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23080", "url": "https://ubuntu.com/security/CVE-2026-23080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In mcba_usb_probe() -> mcba_usb_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback mcba_usb_read_bulk_callback(), the URBs are processed and resubmitted. In mcba_usb_close() -> mcba_urb_unlink() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the mcba_usb_read_bulk_callback()to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23061", "url": "https://ubuntu.com/security/CVE-2026-23061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In kvaser_usb_set_{,data_}bittiming() -> kvaser_usb_setup_rx_urbs(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback kvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. In kvaser_usb_remove_interfaces() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the kvaser_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23058", "url": "https://ubuntu.com/security/CVE-2026-23058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In ems_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In ems_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in ems_usb_close(). Fix the memory leak by anchoring the URB in the ems_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23085", "url": "https://ubuntu.com/security/CVE-2026-23085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Avoid truncating memory addresses On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23098", "url": "https://ubuntu.com/security/CVE-2026-23098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netrom: fix double-free in nr_route_frame() In nr_route_frame(), old_skb is immediately freed without checking if nr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL, the caller function will free old_skb again, causing a double-free bug. Therefore, to prevent this, we need to modify it to check whether nr_neigh->ax25 is NULL before freeing old_skb.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23063", "url": "https://ubuntu.com/security/CVE-2026-23063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: ensure safe queue release with state management Directly calling `put_queue` carries risks since it cannot guarantee that resources of `uacce_queue` have been fully released beforehand. So adding a `stop_queue` operation for the UACCE_CMD_PUT_Q command and leaving the `put_queue` operation to the final resource release ensures safety. Queue states are defined as follows: - UACCE_Q_ZOMBIE: Initial state - UACCE_Q_INIT: After opening `uacce` - UACCE_Q_STARTED: After `start` is issued via `ioctl` When executing `poweroff -f` in virt while accelerator are still working, `uacce_fops_release` and `uacce_remove` may execute concurrently. This can cause `uacce_put_queue` within `uacce_fops_release` to access a NULL `ops` pointer. Therefore, add state checks to prevent accessing freed pointers.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23056", "url": "https://ubuntu.com/security/CVE-2026-23056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: implement mremap in uacce_vm_ops to return -EPERM The current uacce_vm_ops does not support the mremap operation of vm_operations_struct. Implement .mremap to return -EPERM to remind users. The reason we need to explicitly disable mremap is that when the driver does not implement .mremap, it uses the default mremap method. This could lead to a risk scenario: An application might first mmap address p1, then mremap to p2, followed by munmap(p1), and finally munmap(p2). Since the default mremap copies the original vma's vm_private_data (i.e., q) to the new vma, both munmap operations would trigger vma_close, causing q->qfr to be freed twice(qfr will be set to null here, so repeated release is ok).", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23096", "url": "https://ubuntu.com/security/CVE-2026-23096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: fix cdev handling in the cleanup path When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23091", "url": "https://ubuntu.com/security/CVE-2026-23091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix device leak on output open() Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close(). Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23090", "url": "https://ubuntu.com/security/CVE-2026-23090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: core: fix device reference leak on report present Slimbus devices can be allocated dynamically upon reception of report-present messages. Make sure to drop the reference taken when looking up already registered devices. Note that this requires taking an extra reference in case the device has not yet been registered and has to be allocated.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23128", "url": "https://ubuntu.com/security/CVE-2026-23128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Set __nocfi on swsusp_arch_resume() A DABT is reported[1] on an android based system when resume from hiberate. This happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*() and does not have a CFI hash, but swsusp_arch_resume() will attempt to verify the CFI hash when calling a copy of swsusp_arch_suspend_exit(). Given that there's an existing requirement that the entrypoint to swsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text section, we cannot fix this by marking swsusp_arch_suspend_exit() with SYM_FUNC_*(). The simplest fix for now is to disable the CFI check in swsusp_arch_resume(). Mark swsusp_arch_resume() as __nocfi to disable the CFI check. [1] [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc [ 22.991934][ T1] Mem abort info: [ 22.991934][ T1] ESR = 0x0000000096000007 [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [ 22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][ T1] FSC = 0x07: level 3 translation fault [ 22.991934][ T1] Data abort info: [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 22.991934][ T1] Dumping ftrace buffer: [ 22.991934][ T1] (ftrace buffer empty) [ 22.991934][ T1] Modules linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419 [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT) [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344 [ 22.991934][ T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000 [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820 [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000 [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058 [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004 [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000 [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000 [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530 [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000 [ 22.991934][ T1] Call trace: [ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] hibernation_restore+0x158/0x18c [ 22.991934][ T1] load_image_and_restore+0xb0/0xec [ 22.991934][ T1] software_resume+0xf4/0x19c [ 22.991934][ T1] software_resume_initcall+0x34/0x78 [ 22.991934][ T1] do_one_initcall+0xe8/0x370 [ 22.991934][ T1] do_initcall_level+0xc8/0x19c [ 22.991934][ T1] do_initcalls+0x70/0xc0 [ 22.991934][ T1] do_basic_setup+0x1c/0x28 [ 22.991934][ T1] kernel_init_freeable+0xe0/0x148 [ 22.991934][ T1] kernel_init+0x20/0x1a8 [ 22.991934][ T1] ret_from_fork+0x10/0x20 [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110) [catalin.marinas@arm.com: commit log updated by Mark Rutland]", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23073", "url": "https://ubuntu.com/security/CVE-2026-23073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: Fix memory corruption due to not set vif driver data size The struct ieee80211_vif contains trailing space for vif driver data, when struct ieee80211_vif is allocated, the total memory size that is allocated is sizeof(struct ieee80211_vif) + size of vif driver data. The size of vif driver data is set by each WiFi driver as needed. The RSI911x driver does not set vif driver data size, no trailing space for vif driver data is therefore allocated past struct ieee80211_vif . The RSI911x driver does however use the vif driver data to store its vif driver data structure \"struct vif_priv\". An access to vif->drv_priv leads to access out of struct ieee80211_vif bounds and corruption of some memory. In case of the failure observed locally, rsi_mac80211_add_interface() would write struct vif_priv *vif_info = (struct vif_priv *)vif->drv_priv; vif_info->vap_id = vap_idx. This write corrupts struct fq_tin member struct list_head new_flows . The flow = list_first_entry(head, struct fq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus address, which when accessed causes a crash. The trigger is very simple, boot the machine with init=/bin/sh , mount devtmpfs, sysfs, procfs, and then do \"ip link set wlan0 up\", \"sleep 1\", \"ip link set wlan0 down\" and the crash occurs. Fix this by setting the correct size of vif driver data, which is the size of \"struct vif_priv\", so that memory is allocated and the driver can store its driver data in it, instead of corrupting memory around it.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23133", "url": "https://ubuntu.com/security/CVE-2026-23133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: fix dma_free_coherent() pointer dma_alloc_coherent() allocates a DMA mapped buffer and stores the addresses in XXX_unaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23089", "url": "https://ubuntu.com/security/CVE-2026-23089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free() When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees mixer->id_elems but the controls already added to the card still reference the freed memory. Later when snd_card_register() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read. Call trace: get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381 snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ... snd_card_register+0x4ed/0x6d0 sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025 Fix by calling snd_ctl_remove() for all mixer controls before freeing id_elems. We save the next pointer first because snd_ctl_remove() frees the current element.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23076", "url": "https://ubuntu.com/security/CVE-2026-23076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix potential OOB access in audio mixer handling In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixer_index() and sum_index()). As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]' After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field. This patch addresses those OOB accesses by adding the proper initializations of the loop indices.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71199", "url": "https://ubuntu.com/security/CVE-2025-71199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver at91_adc_interrupt can call at91_adc_touch_data_handler function to start the work by schedule_work(&st->touch_st.workq). If we remove the module which will call at91_adc_remove to make cleanup, it will free indio_dev through iio_device_unregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | at91_adc_workq_handler at91_adc_remove | iio_device_unregister(indio_dev) | //free indio_dev a bit later | | iio_push_to_buffers(indio_dev) | //use indio_dev Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91_adc_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23101", "url": "https://ubuntu.com/security/CVE-2026-23101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: led-class: Only Add LED to leds_list when it is fully ready Before this change the LED was added to leds_list before led_init_core() gets called adding it the list before led_classdev.set_brightness_work gets initialized. This leaves a window where led_trigger_register() of a LED's default trigger will call led_trigger_set() which calls led_set_brightness() which in turn will end up queueing the *uninitialized* led_classdev.set_brightness_work. This race gets hit by the lenovo-thinkpad-t14s EC driver which registers 2 LEDs with a default trigger provided by snd_ctl_led.ko in quick succession. The first led_classdev_register() causes an async modprobe of snd_ctl_led to run and that async modprobe manages to exactly hit the window where the second LED is on the leds_list without led_init_core() being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998 Close the race window by moving the adding of the LED to leds_list to after the led_init_core() call.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23064", "url": "https://ubuntu.com/security/CVE-2026-23064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: avoid possible NULL deref tcf_ife_encode() must make sure ife_encode() does not return NULL. syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166 CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full) Call Trace: ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23119", "url": "https://ubuntu.com/security/CVE-2026-23119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: provide a net pointer to __skb_flow_dissect() After 3cbf4ffba5ee (\"net: plumb network namespace into __skb_flow_dissect\") we have to provide a net pointer to __skb_flow_dissect(), either via skb->dev, skb->sk, or a user provided pointer. In the following case, syzbot was able to cook a bare skb. WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053 Call Trace: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23084", "url": "https://ubuntu.com/security/CVE-2026-23084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list When the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() is set to false, the driver may request the PMAC_ID from the firmware of the network card, and this function will store that PMAC_ID at the provided address pmac_id. This is the contract of this function. However, there is a location within the driver where both pmac_id_valid == false and pmac_id == NULL are being passed. This could result in dereferencing a NULL pointer. To resolve this issue, it is necessary to pass the address of a stub variable to the function.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23124", "url": "https://ubuntu.com/security/CVE-2026-23124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: annotate data-race in ndisc_router_discovery() syzbot found that ndisc_router_discovery() could read and write in6_dev->ra_mtu without holding a lock [1] This looks fine, IFLA_INET6_RA_MTU is best effort. Add READ_ONCE()/WRITE_ONCE() to document the race. Note that we might also reject illegal MTU values (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch. [1] BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... value changed: 0x00000000 -> 0xe5400659", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23121", "url": "https://ubuntu.com/security/CVE-2026-23121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mISDN: annotate data-race around dev->work dev->work can re read locklessly in mISDN_read() and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations. BUG: KCSAN: data-race in mISDN_ioctl / mISDN_read write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [inline] vfs_readv+0x3fb/0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [inline] __se_sys_readv fs/read_write.c:1162 [inline] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000 -> 0x00000001", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23071", "url": "https://ubuntu.com/security/CVE-2026-23071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: Fix race condition in hwspinlock irqsave routine Previously, the address of the shared member '&map->spinlock_flags' was passed directly to 'hwspin_lock_timeout_irqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shared flags variable, potentially corrupting the state for the current lock owner. Fix this by using a local stack variable 'flags' to store the IRQ state temporarily.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23105", "url": "https://ubuntu.com/security/CVE-2026-23105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag This is more of a preventive patch to make the code more consistent and to prevent possible exploits that employ child qlen manipulations on qfq. use cl_is_active instead of relying on the child qdisc's qlen to determine class activation.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23103", "url": "https://ubuntu.com/security/CVE-2026-23103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close) This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause: 1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock. 2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23120", "url": "https://ubuntu.com/security/CVE-2026-23120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: avoid one data-race in l2tp_tunnel_del_work() We should read sk->sk_socket only when dealing with kernel sockets. syzbot reported the following data-race: BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 value changed: 0xffff88811b818000 -> 0x0000000000000000", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23083", "url": "https://ubuntu.com/security/CVE-2026-23083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Don't allow 0 for FOU_ATTR_IPPROTO. fou_udp_recv() has the same problem mentioned in the previous patch. If FOU_ATTR_IPPROTO is set to 0, skb is not freed by fou_udp_recv() nor \"resubmit\"-ted in ip_protocol_deliver_rcu(). Let's forbid 0 for FOU_ATTR_IPPROTO.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23095", "url": "https://ubuntu.com/security/CVE-2026-23095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: Fix skb memleak with inner IP protocol 0. syzbot reported skb memleak below. [0] The repro generated a GUE packet with its inner protocol 0. gue_udp_recv() returns -guehdr->proto_ctype for \"resubmit\" in ip_protocol_deliver_rcu(), but this only works with non-zero protocol number. Let's drop such packets. Note that 0 is a valid number (IPv6 Hop-by-Hop Option). I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT [0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm \"syz.0.17\", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23125", "url": "https://ubuntu.com/security/CVE-2026-23125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key initialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127 The issue is triggered when sctp_auth_asoc_init_active_key() fails in sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the command sequence is currently: - SCTP_CMD_PEER_INIT - SCTP_CMD_TIMER_STOP (T1_INIT) - SCTP_CMD_TIMER_START (T1_COOKIE) - SCTP_CMD_NEW_STATE (COOKIE_ECHOED) - SCTP_CMD_ASSOC_SHKEY - SCTP_CMD_GEN_COOKIE_ECHO If SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while asoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL to be queued by sctp_datamsg_from_user(). Since command interpretation stops on failure, no COOKIE_ECHO should been sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As a result, the DATA chunk can be transmitted together with the COOKIE_ECHO in sctp_outq_flush_data(), leading to the observed issue. Similar to the other places where it calls sctp_auth_asoc_init_active_key() right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting T1_COOKIE. This ensures that if shared key generation fails, authenticated DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT, giving the client another chance to process INIT_ACK and retry key setup.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23099", "url": "https://ubuntu.com/security/CVE-2026-23099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: limit BOND_MODE_8023AD to Ethernet devices BOND_MODE_8023AD makes sense for ARPHRD_ETHER only. syzbot reported: BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline] BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497 CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [inline] __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [inline] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e The buggy address belongs to the variable: lacpdu_mcast_addr+0x0/0x40", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71194", "url": "https://ubuntu.com/security/CVE-2025-71194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock in wait_current_trans() due to ignored transaction type When wait_current_trans() is called during start_transaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfs_blocked_trans_types[] array already defines which transaction types should wait for which transaction states, but this check was missing in wait_current_trans(). This can lead to a deadlock scenario involving two transactions and pending ordered extents: 1. Transaction A is in TRANS_STATE_COMMIT_DOING state 2. A worker processing an ordered extent calls start_transaction() with TRANS_JOIN 3. join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes 5. A new Transaction B is created (TRANS_STATE_RUNNING) 6. The ordered extent from step 2 is added to Transaction B's pending ordered extents 7. Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START 8. The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[] 10. Transaction B is waiting for pending ordered extents to complete 11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B This can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!) Task bstore_kv_sync in btrfs_commit_transaction waiting for ordered extents: __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Task kworker in wait_current_trans waiting for transaction commit: Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30 Fix this by passing the transaction type to wait_current_trans() and checking btrfs_blocked_trans_types[cur_trans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71185", "url": "https://ubuntu.com/security/CVE-2025-71185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23026", "url": "https://ubuntu.com/security/CVE-2026-23026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config() Fix a memory leak in gpi_peripheral_config() where the original memory pointed to by gchan->config could be lost if krealloc() fails. The issue occurs when: 1. gchan->config points to previously allocated memory 2. krealloc() fails and returns NULL 3. The function directly assigns NULL to gchan->config, losing the reference to the original memory 4. The original memory becomes unreachable and cannot be freed Fix this by using a temporary variable to hold the krealloc() result and only updating gchan->config when the allocation succeeds. Found via static analysis and code review.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71188", "url": "https://ubuntu.com/security/CVE-2025-71188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: lpc18xx-dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71163", "url": "https://ubuntu.com/security/CVE-2025-71163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix device leaks on compat bind and unbind Make sure to drop the reference taken when looking up the idxd device as part of the compat bind and unbind sysfs interface.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2025-71190", "url": "https://ubuntu.com/security/CVE-2025-71190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: bcm-sba-raid: fix device leak on probe Make sure to drop the reference taken when looking up the mailbox device during probe on probe failures and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71191", "url": "https://ubuntu.com/security/CVE-2025-71191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: at_hdmac: fix device leak on of_dma_xlate() Make sure to drop the reference taken when looking up the DMA platform device during of_dma_xlate() when releasing channel resources. Note that commit 3832b78b3ec2 (\"dmaengine: at_hdmac: add missing put_device() call in at_dma_xlate()\") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23049", "url": "https://ubuntu.com/security/CVE-2026-23049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel The connector type for the DataImage SCF0700C48GGU18 panel is missing and devm_drm_panel_bridge_add() requires connector type to be set. This leads to a warning and a backtrace in the kernel log and panel does not work: \" WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8 \" The warning is triggered by a check for valid connector type in devm_drm_panel_bridge_add(). If there is no valid connector type set for a panel, the warning is printed and panel is not added. Fill in the missing connector type to fix the warning and make the panel operational once again.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23145", "url": "https://ubuntu.com/security/CVE-2026-23145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref The error branch for ext4_xattr_inode_update_ref forget to release the refcount for iloc.bh. Find this when review code.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-22997", "url": "https://ubuntu.com/security/CVE-2026-22997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is called only when the timer is enabled, we need to call j1939_session_deactivate_activate_next() if we cancelled the timer. Otherwise, refcount for j1939_session leaks, which will later appear as | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2. problem.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23033", "url": "https://ubuntu.com/security/CVE-2026-23033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: omap-dma: fix dma_pool resource leak in error paths The dma_pool created by dma_pool_create() is not destroyed when dma_async_device_register() or of_dma_controller_register() fails, causing a resource leak in the probe error paths. Add dma_pool_destroy() in both error paths to properly release the allocated dma_pool resource.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71196", "url": "https://ubuntu.com/security/CVE-2025-71196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: stm32-usphyc: Fix off by one in probe() The \"index\" variable is used as an index into the usbphyc->phys[] array which has usbphyc->nphys elements. So if it is equal to usbphyc->nphys then it is one element out of bounds. The \"index\" comes from the device tree so it's data that we trust and it's unlikely to be wrong, however it's obviously still worth fixing the bug. Change the > to >=.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71162", "url": "https://ubuntu.com/security/CVE-2025-71162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: tegra-adma: Fix use-after-free A use-after-free bug exists in the Tegra ADMA driver when audio streams are terminated, particularly during XRUN conditions. The issue occurs when the DMA buffer is freed by tegra_adma_terminate_all() before the vchan completion tasklet finishes accessing it. The race condition follows this sequence: 1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegra_adma_terminate_all() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchan_complete() which attempts to access the already-freed memory Since tasklets can execute at any time after being scheduled, there is no guarantee that the buffer will remain valid when vchan_complete() runs. Fix this by properly synchronizing the virtual channel completion: - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegra_adma_synchronize() that calls vchan_synchronize() which kills any pending tasklets and frees any terminated descriptors. Crash logs: [ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0 [ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0 [ 337.427562] Call trace: [ 337.427564] dump_backtrace+0x0/0x320 [ 337.427571] show_stack+0x20/0x30 [ 337.427575] dump_stack_lvl+0x68/0x84 [ 337.427584] print_address_description.constprop.0+0x74/0x2b8 [ 337.427590] kasan_report+0x1f4/0x210 [ 337.427598] __asan_load8+0xa0/0xd0 [ 337.427603] vchan_complete+0x124/0x3b0 [ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0 [ 337.427617] tasklet_action+0x30/0x40 [ 337.427623] __do_softirq+0x1a0/0x5c4 [ 337.427628] irq_exit+0x110/0x140 [ 337.427633] handle_domain_irq+0xa4/0xe0 [ 337.427640] gic_handle_irq+0x64/0x160 [ 337.427644] call_on_irq_stack+0x20/0x4c [ 337.427649] do_interrupt_handler+0x7c/0x90 [ 337.427654] el1_interrupt+0x30/0x80 [ 337.427659] el1h_64_irq_handler+0x18/0x30 [ 337.427663] el1h_64_irq+0x7c/0x80 [ 337.427667] cpuidle_enter_state+0xe4/0x540 [ 337.427674] cpuidle_enter+0x54/0x80 [ 337.427679] do_idle+0x2e0/0x380 [ 337.427685] cpu_startup_entry+0x2c/0x70 [ 337.427690] rest_init+0x114/0x130 [ 337.427695] arch_call_rest_init+0x18/0x24 [ 337.427702] start_kernel+0x380/0x3b4 [ 337.427706] __primary_switched+0xc0/0xc8", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22999", "url": "https://ubuntu.com/security/CVE-2026-22999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: do not free existing class in qfq_change_class() Fixes qfq_change_class() error case. cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23011", "url": "https://ubuntu.com/security/CVE-2026-23011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_gre: make ipgre_header() robust Analog to commit db5b4e39c4e6 (\"ip6_gre: make ip6gre_header() robust\") Over the years, syzbot found many ways to crash the kernel in ipgre_header() [1]. This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ipgre device. [1] skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213 Call Trace: skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23001", "url": "https://ubuntu.com/security/CVE-2026-23001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix possible UAF in macvlan_forward_source() Add RCU protection on (struct macvlan_source_entry)->vlan. Whenever macvlan_hash_del_source() is called, we must clear entry->vlan pointer before RCU grace period starts. This allows macvlan_forward_source() to skip over entries queued for freeing. Note that macvlan_dev are already RCU protected, as they are embedded in a standard netdev (netdev_priv(ndev)). https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23003", "url": "https://ubuntu.com/security/CVE-2026-23003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() Blamed commit did not take care of VLAN encapsulations as spotted by syzbot [1]. Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull(). [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22998", "url": "https://ubuntu.com/security/CVE-2026-22998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec Commit efa56305908b (\"nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs. The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command. Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23037", "url": "https://ubuntu.com/security/CVE-2026-23037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: allow partial RX URB allocation to succeed When es58x_alloc_rx_urbs() fails to allocate the requested number of URBs but succeeds in allocating some, it returns an error code. This causes es58x_open() to return early, skipping the cleanup label 'free_urbs', which leads to the anchored URBs being leaked. As pointed out by maintainer Vincent Mailhol, the driver is designed to handle partial URB allocation gracefully. Therefore, partial allocation should not be treated as a fatal error. Modify es58x_alloc_rx_urbs() to return 0 if at least one URB has been allocated, restoring the intended behavior and preventing the leak in es58x_open().", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23038", "url": "https://ubuntu.com/security/CVE-2026-23038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node() In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak. Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23111", "url": "https://ubuntu.com/security/CVE-2026-23111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate() nft_map_catchall_activate() has an inverted element activity check compared to its non-catchall counterpart nft_mapelem_activate() and compared to what is logically required. nft_map_catchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones. Compare the non-catchall activate callback, which is correct: nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; /* skip active, process inactive */ With the buggy catchall version: nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; /* skip inactive, process active */ The consequence is that when a DELSET operation is aborted, nft_setelem_data_activate() is never called for the catchall element. For NFT_GOTO verdict elements, this means nft_data_hold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free. This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIG_USER_NS and CONFIG_NF_TABLES. Fix by removing the negation so the check matches nft_mapelem_activate(): skip active elements, process inactive ones.", "cve_priority": "high", "cve_public_date": "2026-02-13 14:16:00 UTC" }, { "cve": "CVE-2026-23209", "url": "https://ubuntu.com/security/CVE-2026-23209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source(). With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-37849", "url": "https://ubuntu.com/security/CVE-2025-37849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Tear down vGIC on failed vCPU creation If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU. Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.", "cve_priority": "high", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2026-23074", "url": "https://ubuntu.com/security/CVE-2026-23074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Enforce that teql can only be used as root qdisc Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint. Although not important, I will describe the scenario that unearthed this issue for the curious. GangMin Kim managed to concot a scenario as follows: ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s └── class 1:2 (weight=1, lmax=1514) teql GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23060", "url": "https://ubuntu.com/security/CVE-2026-23060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, crypto_authenc_esn_decrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalk_map_and_copy(), leading to a kernel panic (DoS). Add a minimum AAD length check to fail fast on invalid inputs.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1097.102 -proposed tracker (LP: #2143524)", "", " [ Ubuntu: 5.15.0-176.186 ]", "", " * jammy/linux: 5.15.0-176.186 -proposed tracker (LP: #2143539)", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343)", " - nvmet-tcp: remove boilerplate code", " - SAUCE: Fix skb_vlan_inet_prepare() usage", " - net: update netdev_lock_{type,name}", " - vsock/test: add a final full barrier after run all tests", " - net/mlx5e: Restore destroying state bit after profile cleanup", " - selftests: drv-net: fix RPS mask handling for high CPU numbers", " - ASoC: tlv320adcx140: fix word length", " - textsearch: describe @list member in ts_ops search", " - mm, kfence: describe @slab parameter in __kfence_obj_info()", " - dmaengine: xilinx_dma: Fix uninitialized addr_width when", " \"xlnx,addrwidth\" property is missing", " - phy: broadcom: ns-usb3: Fix Wvoid-pointer-to-enum-cast warning (again)", " - HID: usbhid: paper over wrong bNumDescriptor field", " - ALSA: pcm: Improve the fix for race of buffer access at PCM OSS layer", " - x86/kaslr: Recognize all ZONE_DEVICE users as physaddr consumers", " - phy: rockchip: inno-usb2: fix disconnection in gadget mode", " - phy: rockchip: inno-usb2: fix communication disruption in gadget mode", " - phy: tegra: xusb: Explicitly configure HS_DISCON_LEVEL to 0x7", " - usb: dwc3: Check for USB4 IP_NAME", " - USB: OHCI/UHCI: Add soft dependencies on ehci_platform", " - USB: serial: option: add Telit LE910 MBIM composition", " - USB: serial: ftdi_sio: add support for PICAXE AXE027 cable", " - nvme-pci: disable secondary temp for Wodposit WPBSNM8", " - hrtimer: Fix softirq base check in update_needs_ipi()", " - EDAC/x38: Fix a resource leak in x38_probe1()", " - EDAC/i3200: Fix a resource leak in i3200_probe1()", " - x86/resctrl: Add missing resctrl initialization for Hygon", " - x86/resctrl: Fix memory bandwidth counter width for Hygon", " - mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free", " - drm/nouveau/disp/nv50-: Set lock_core in curs507a_prepare", " - drm/vmwgfx: Fix an error return check in vmw_compat_shader_add()", " - dmaengine: sh: rz-dmac: Fix rz_dmac_terminate_all()", " - dmaengine: ti: dma-crossbar: fix device leak on dra7x route allocation", " - dmaengine: ti: k3-udma: fix device leak on udma lookup", " - posix-clock: introduce posix_clock_context concept", " - Fix memory leak in posix_clock_open()", " - posix-clock: Store file pointer in struct posix_clock_context", " - ptp: Add PHC file mode checks. Allow RO adjtime() without FMODE_WRITE.", " - testptp: add option to shift clock by nanoseconds", " - testptp: Add support for testing ptp_clock_info .adjphase callback", " - selftests/ptp: Add -x option for testing PTP_SYS_OFFSET_EXTENDED", " - selftests/ptp: Add -X option for testing PTP_SYS_OFFSET_PRECISE", " - ptp: add testptp mask test", " - selftest/ptp: update ptp selftest to exercise the gettimex options", " - testptp: Add option to open PHC in readonly mode", " - net: usb: dm9601: remove broken SR9700 support", " - amd-xgbe: avoid misleading per-packet error log", " - netlink: add a proto specification for FOU", " - net: fou: rename the source for linking", " - net: fou: use policy and operation tables generated from the spec", " - comedi: dmm32at: serialize use of paged registers", " - w1: fix redundant counter decrement in w1_attach_slave_device()", " - Revert \"nfc/nci: Add the inconsistency check between the input data", " length and count\"", " - Input: i8042 - add quirks for MECHREVO Wujie 15X Pro", " - Input: i8042 - add quirk for ASUS Zenbook UX425QA_UM425QA", " - scsi: storvsc: Process unsupported MODE_SENSE_10", " - x86/kfence: avoid writing L1TF-vulnerable PTEs", " - staging:iio:adc:ad7280a: Register define cleanup.", " - iio: adc: ad7280a: handle spi_setup() errors in probe()", " - ALSA: usb: Increase volume range that triggers a warning", " - net: hns3: fix wrong GENMASK() for HCLGE_FD_AD_COUNTER_NUM_M", " - net: hns3: fix the HCLGE_FD_AD_NXT_KEY error setting issue", " - usbnet: limit max_mtu based on device's hard_mtu", " - drm/amd/pm: Don't clear SI SMC table when setting power limit", " - drm/amd/pm: Workaround SI powertune issue on Radeon 430 (v2)", " - octeontx2-af: Fix error handling", " - x86: make page fault handling disable interrupts properly", " - of: fix reference count leak in of_alias_scan()", " - iio: adc: ad9467: fix ad9434 vref mask", " - iio: dac: ad5686: add AD5695R to ad5686_chip_info_tbl", " - mmc: rtsx_pci_sdmmc: implement sdmmc_card_busy function", " - wifi: mwifiex: Fix a loop in mwifiex_update_ampdu_rxwinsize()", " - octeontx2: Fix otx2_dma_map_page() error return code", " - slimbus: core: fix runtime PM imbalance on report present", " - perf/x86/intel: Do not enable BTS for guests", " - net/mlx5: Fix memory leak in esw_acl_ingress_lgcy_setup()", " - net: mvpp2: cls: Fix memory leak in mvpp2_ethtool_cls_rule_ins()", " - ipv6: use the right ifindex when replying to icmpv6 from localhost", " - ice: stop counting UDP csum mismatch as rx_errors", " - net/mlx5: Add HW definitions of vport debug counters", " - net/mlx5e: Expose rx_oversize_pkts_buffer counter", " - net/mlx5e: Report rx_discards_phy via rx_dropped", " - net/mlx5e: Account for netdev stats in ndo_get_stats64", " - net: bridge: fix static key check", " - scsi: firewire: sbp-target: Fix overflow in sbp_make_tpg()", " - gpiolib: acpi: use BIT_ULL() for u64 mask in address space handler", " - dma/pool: distinguish between missing and exhausted atomic pools", " - ASoC: fsl: imx-card: Do not force slot width to sample width", " - scsi: be2iscsi: Fix a memory leak in beiscsi_boot_get_sinfo()", " - scsi: qla2xxx: edif: Fix dma_free_coherent() size", " - mptcp: only reset subflow errors when propagated", " - net: Add locking to protect skb->dev access in ip_output", " - comedi: Fix getting range information for subdevices 16 to 255", " - of: platform: Use default match table for /firmware", " - iio: adc: exynos_adc: fix OF populate on driver rebind", " - arm64: dts: rockchip: remove redundant max-link-speed from nanopi-r4s", " - w1: w1_therm: use swap() to make code cleaner", " - dmaengine: stm32: dmamux: fix OF node leak on route allocation failure", " - xfs: set max_agbno to allow sparse alloc of last full inode chunk", " - nvme-fc: rename free_ctrl callback to match name pattern", " - nvme-pci: do not directly handle subsys reset fallout", " - nvme: fix PCIe subsystem reset controller state transition", " - mei: trace: treat reg parameter as string", " - mm/pagewalk: add walk_page_range_vma()", " - wifi: cfg80211: add a work abstraction with special semantics", " - wifi: mac80211: use wiphy work for sdata->work", " - wifi: mac80211: move TDLS work to wiphy work", " - HID: uclogic: Add NULL check in uclogic_input_configured()", " - drm/amdkfd: fix a memory leak in device_queue_manager_init()", " - btrfs: prevent use-after-free on page private data in", " btrfs_subpage_clear_uptodate()", " - net/sched: act_ife: convert comma to semicolon", " - pinctrl: lpass-lpi: implement .get_direction() for the GPIO driver", " - writeback: fix 100% CPU usage when dirtytime_expire_interval is 0", " - mptcp: avoid dup SUB_CLOSED events after disconnect", " - pinctrl: meson: mark the GPIO controller as sleeping", " - wifi: cfg80211: use system_unbound_wq for wiphy work", " - wifi: cfg80211: fix wiphy delayed work queueing", " - wifi: cfg80211: cancel wiphy_work before freeing wiphy", " - wifi: cfg80211: fully move wiphy work to unbound workqueue", " - wifi: cfg80211: init wiphy_work before allocating rfkill fails", " - Linux 5.15.199", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23170", " - drm/imx/tve: fix probe device leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23075", " - can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38408", " - genirq/irq_sim: Initialize work context pointers properly", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2023-54207", " - HID: uclogic: Correct devm device reference for hidinput input_dev name", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2023-53520", " - Bluetooth: Fix hci_suspend_sync crash", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38125", " - net: stmmac: make sure that ptp_rate is not 0 before configuring EST", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-40164", " - usbnet: Fix using smp_processor_id() in preemptible code warnings", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38232", " - NFSD: fix race between nfsd registration and exports_proc", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2023-53662", " - ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup}", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38057", " - espintcp: fix skb leaks", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2023-53421", " - blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68365", " - fs/ntfs3: Initialize allocated memory before use", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68817", " - ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2022-50390", " - drm/ttm: fix undefined behavior in bit shift for", " TTM_TT_FLAG_PRIV_POPULATED", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68211", " - ksm: use range-walk function to jump over holes in", " scan_get_next_rmap_item", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23093", " - ksmbd: smbd: fix dma_unmap_sg() nents", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23078", " - ALSA: scarlett2: Fix buffer overflow in config retrieval", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71186", " - dmaengine: stm32: dmamux: fix device leak on route allocation", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71197", " - w1: therm: Fix off-by-one buffer overflow in alarms_store", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23087", " - scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-40149", " - tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23167", " - nfc: nci: Fix race between rfkill and nci_unregister_device().", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23150", " - nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame().", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23164", " - rocker: fix memory leak in rocker_world_port_post_fini()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23146", " - Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38591", " - bpf: Reject narrower access to pointer ctx fields", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68725", " - bpf: Do not let BPF test infra emit invalid GSO types to stack", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23097", " - migrate: correct lock ordering for hugetlb file folios", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23108", " - can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23080", " - can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23061", " - can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23058", " - can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23085", " - irqchip/gic-v3-its: Avoid truncating memory addresses", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23098", " - netrom: fix double-free in nr_route_frame()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23063", " - uacce: ensure safe queue release with state management", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23056", " - uacce: implement mremap in uacce_vm_ops to return -EPERM", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23096", " - uacce: fix cdev handling in the cleanup path", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23091", " - intel_th: fix device leak on output open()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23090", " - slimbus: core: fix device reference leak on report present", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23128", " - arm64: Set __nocfi on swsusp_arch_resume()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23073", " - wifi: rsi: Fix memory corruption due to not set vif driver data size", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23133", " - wifi: ath10k: fix dma_free_coherent() pointer", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23089", " - ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23076", " - ALSA: ctxfi: Fix potential OOB access in audio mixer handling", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71199", " - iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc", " driver", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23101", " - leds: led-class: Only Add LED to leds_list when it is fully ready", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23064", " - net/sched: act_ife: avoid possible NULL deref", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23119", " - bonding: provide a net pointer to __skb_flow_dissect()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23084", " - be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23124", " - ipv6: annotate data-race in ndisc_router_discovery()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23121", " - mISDN: annotate data-race around dev->work", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23071", " - regmap: Fix race condition in hwspinlock irqsave routine", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23105", " - net/sched: qfq: Use cl_is_active to determine whether class is active in", " qfq_rm_from_ag", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23103", " - ipvlan: Make the addrs_lock be per port", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23120", " - l2tp: avoid one data-race in l2tp_tunnel_del_work()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23083", " - fou: Don't allow 0 for FOU_ATTR_IPPROTO.", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23095", " - gue: Fix skb memleak with inner IP protocol 0.", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23125", " - sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23099", " - bonding: limit BOND_MODE_8023AD to Ethernet devices", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71194", " - btrfs: fix deadlock in wait_current_trans() due to ignored transaction", " type", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71185", " - dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23026", " - dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71188", " - dmaengine: lpc18xx-dmamux: fix device leak on route allocation", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71163", " - dmaengine: idxd: fix device leaks on compat bind and unbind", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71190", " - dmaengine: bcm-sba-raid: fix device leak on probe", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71191", " - dmaengine: at_hdmac: fix device leak on of_dma_xlate()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23049", " - drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23145", " - ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-22997", " - net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session", " upon receiving the second rts", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23033", " - dmaengine: omap-dma: fix dma_pool resource leak in error paths", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71196", " - phy: stm32-usphyc: Fix off by one in probe()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71162", " - dmaengine: tegra-adma: Fix use-after-free", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-22999", " - net/sched: sch_qfq: do not free existing class in qfq_change_class()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23011", " - ipv4: ip_gre: make ipgre_header() robust", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23001", " - macvlan: fix possible UAF in macvlan_forward_source()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23003", " - ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-22998", " - nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23037", " - can: etas_es58x: allow partial RX URB allocation to succeed", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23038", " - pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()", " * ADT test for linux package failed with \"fatal: unable to connect to", " git.launchpad.net\" (LP: #2143033)", " - [Packaging] d/t/ubuntu-regression-suite: use https to clone", " * efi: Fix swapped arguments to bsearch() in efi_status_to_*() SAUCE patch", " (LP: #2141276)", " - SAUCE efi: Fix swapped arguments to bsearch() in efi_status_to_*()", " * CVE-2026-23111", " - netfilter: nf_tables: fix inverted genmask check in", " nft_map_catchall_activate()", " * CVE-2026-23209", " - macvlan: fix error recovery in macvlan_common_newlink()", " * CVE-2025-37849", " - KVM: arm64: vgic: Add a non-locking primitive for", " kvm_vgic_vcpu_destroy()", " - KVM: arm64: Tear down vGIC on failed vCPU creation", " * CVE-2026-23074", " - net/sched: Enforce that teql can only be used as root qdisc", " * CVE-2026-23060", " - crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN", " spec", "" ], "package": "linux-kvm", "version": "5.15.0-1097.102", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2143524, 2143539, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143033, 2141276 ], "author": "Austin Rhodes ", "date": "Tue, 07 Apr 2026 09:50:23 -0400" } ], "notes": "linux-kvm-headers-5.15.0-1097 version '5.15.0-1097.102' (source package linux-kvm version '5.15.0-1097.102') was added. linux-kvm-headers-5.15.0-1097 version '5.15.0-1097.102' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1096-kvm. As such we can use the source package version of the removed package, '5.15.0-1096.101', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-modules-5.15.0-1097-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1096.101", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1097.102", "version": "5.15.0-1097.102" }, "cves": [ { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2026-23170", "url": "https://ubuntu.com/security/CVE-2026-23170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imx/tve: fix probe device leak Make sure to drop the reference taken to the DDC device during probe on probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23075", "url": "https://ubuntu.com/security/CVE-2026-23075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In esd_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback esd_usb_read_bulk_callback(), the URBs are processed and resubmitted. In esd_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in esd_usb_close(). Fix the memory leak by anchoring the URB in the esd_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-38408", "url": "https://ubuntu.com/security/CVE-2025-38408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: genirq/irq_sim: Initialize work context pointers properly Initialize `ops` member's pointers properly by using kzalloc() instead of kmalloc() when allocating the simulation work context. Otherwise the pointers contain random content leading to invalid dereferencing.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2023-54207", "url": "https://ubuntu.com/security/CVE-2023-54207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: Correct devm device reference for hidinput input_dev name Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management. Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string.", "cve_priority": "medium", "cve_public_date": "2025-12-30 13:16:00 UTC" }, { "cve": "CVE-2023-53520", "url": "https://ubuntu.com/security/CVE-2023-53520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix hci_suspend_sync crash If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.", "cve_priority": "medium", "cve_public_date": "2025-10-01 12:15:00 UTC" }, { "cve": "CVE-2025-38125", "url": "https://ubuntu.com/security/CVE-2025-38125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring EST If the ptp_rate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0. Prevent this division by 0 by adding the corresponding check and error code.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-40164", "url": "https://ubuntu.com/security/CVE-2025-40164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix using smp_processor_id() in preemptible code warnings Syzbot reported the following warning: BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879 caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary) Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f For historical and portability reasons, the netif_rx() is usually run in the softirq or interrupt context, this commit therefore add local_bh_disable/enable() protection in the usbnet_resume_rx().", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-38232", "url": "https://ubuntu.com/security/CVE-2025-38232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix race between nfsd registration and exports_proc As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd. Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd for 5.4 kernel ARM64: CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0 CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 PC is at : exports_net_open+0x50/0x68 [nfsd] Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248 Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu(). and same is happening on latest 6.14 kernel as well: [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]--- It reproduced simply with below script: while [ 1 ] do /exportfs -r done & while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done & So exporting interfaces to user space shall be done at last and cleanup at first place. With change there is no Kernel OOPs.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2023-53662", "url": "https://ubuntu.com/security/CVE-2023-53662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup} If the filename casefolding fails, we'll be leaking memory from the fscrypt_name struct, namely from the 'crypto_buf.name' member. Make sure we free it in the error path on both ext4_fname_setup_filename() and ext4_fname_prepare_lookup() functions.", "cve_priority": "medium", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2025-38057", "url": "https://ubuntu.com/security/CVE-2025-38057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: fix skb leaks A few error paths are missing a kfree_skb.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2023-53421", "url": "https://ubuntu.com/security/CVE-2023-53421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats() When blkg_alloc() is called to allocate a blkcg_gq structure with the associated blkg_iostat_set's, there are 2 fields within blkg_iostat_set that requires proper initialization - blkg & sync. The former field was introduced by commit 3b8cc6298724 (\"blk-cgroup: Optimize blkcg_rstat_flush()\") while the later one was introduced by commit f73316482977 (\"blk-cgroup: reimplement basic IO stats using cgroup rstat\"). Unfortunately those fields in the blkg_iostat_set's are not properly re-initialized when they are cleared in v1's blkcg_reset_stats(). This can lead to a kernel panic due to NULL pointer access of the blkg pointer. The missing initialization of sync is less problematic and can be a problem in a debug kernel due to missing lockdep initialization. Fix these problems by re-initializing them after memory clearing.", "cve_priority": "medium", "cve_public_date": "2025-09-18 16:15:00 UTC" }, { "cve": "CVE-2025-68365", "url": "https://ubuntu.com/security/CVE-2025-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Initialize allocated memory before use KMSAN reports: Multiple uninitialized values detected: - KMSAN: uninit-value in ntfs_read_hdr (3) - KMSAN: uninit-value in bcmp (3) Memory is allocated by __getname(), which is a wrapper for kmem_cache_alloc(). This memory is used before being properly cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to properly allocate and clear memory before use.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68817", "url": "https://ubuntu.com/security/CVE-2025-68817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency Under high concurrency, A tree-connection object (tcon) is freed on a disconnect path while another path still holds a reference and later executes *_put()/write on it.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2022-50390", "url": "https://ubuntu.com/security/CVE-2022-50390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATED Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c ttm_bo_move_memcpy+0x3b4/0x460 [ttm] bo_driver_move+0x32/0x40 [drm_vram_helper] ttm_bo_handle_move_mem+0x118/0x200 [ttm] ttm_bo_validate+0xfa/0x220 [ttm] drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper] drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper] drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper] drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper] drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper] drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper] drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper] drm_atomic_commit+0x9c/0x160 [drm] drm_client_modeset_commit_atomic+0x33a/0x380 [drm] drm_client_modeset_commit_locked+0x77/0x220 [drm] drm_client_modeset_commit+0x31/0x60 [drm] __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper] drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper] fbcon_init+0x316/0x790 visual_init+0x113/0x1d0 do_bind_con_driver+0x2a3/0x5c0 do_take_over_console+0xa9/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ", "cve_priority": "medium", "cve_public_date": "2025-09-18 14:15:00 UTC" }, { "cve": "CVE-2025-68211", "url": "https://ubuntu.com/security/CVE-2025-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksm: use range-walk function to jump over holes in scan_get_next_rmap_item Currently, scan_get_next_rmap_item() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages. This patch replaces the per-address lookup with a range walk using walk_page_range(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1]. Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page: #include #include #include /* 32 TiB */ const size_t size = 32ul * 1024 * 1024 * 1024 * 1024; int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror(\"mmap() failed\\n\"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0; } $ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-23093", "url": "https://ubuntu.com/security/CVE-2026-23093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbd: fix dma_unmap_sg() nents The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23078", "url": "https://ubuntu.com/security/CVE-2026-23078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Fix buffer overflow in config retrieval The scarlett2_usb_get_config() function has a logic error in the endianness conversion code that can cause buffer overflows when count > 1. The code checks `if (size == 2)` where `size` is the total buffer size in bytes, then loops `count` times treating each element as u16 (2 bytes). This causes the loop to access `count * 2` bytes when the buffer only has `size` bytes allocated. Fix by checking the element size (config_item->size) instead of the total buffer size. This ensures the endianness conversion matches the actual element type.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71186", "url": "https://ubuntu.com/security/CVE-2025-71186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: stm32: dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71197", "url": "https://ubuntu.com/security/CVE-2025-71197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: therm: Fix off-by-one buffer overflow in alarms_store The sysfs buffer passed to alarms_store() is allocated with 'size + 1' bytes and a NUL terminator is appended. However, the 'size' argument does not account for this extra byte. The original code then allocated 'size' bytes and used strcpy() to copy 'buf', which always writes one byte past the allocated buffer since strcpy() copies until the NUL terminator at index 'size'. Fix this by parsing the 'buf' parameter directly using simple_strtoll() without allocating any intermediate memory or string copying. This removes the overflow while simplifying the code.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23087", "url": "https://ubuntu.com/security/CVE-2026-23087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Fix potential memory leak in scsiback_remove() Memory allocated for struct vscsiblk_info in scsiback_probe() is not freed in scsiback_remove() leading to potential memory leaks on remove, as well as in the scsiback_probe() error paths. Fix that by freeing it in scsiback_remove().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-40149", "url": "https://ubuntu.com/security/CVE-2025-40149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock(). get_netdev_for_sock() is called during setsockopt(), so not under RCU. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the only ->ndo_sk_get_lower_dev() user is bond_sk_get_lower_dev(), which uses RCU.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-23167", "url": "https://ubuntu.com/security/CVE-2026-23167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix race between rfkill and nci_unregister_device(). syzbot reported the splat below [0] without a repro. It indicates that struct nci_dev.cmd_wq had been destroyed before nci_close_device() was called via rfkill. nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which (I think) was called from virtual_ncidev_close() when syzbot close()d an fd of virtual_ncidev. The problem is that nci_unregister_device() destroys nci_dev.cmd_wq first and then calls nfc_unregister_device(), which removes the device from rfkill by rfkill_unregister(). So, the device is still visible via rfkill even after nci_dev.cmd_wq is destroyed. Let's unregister the device from rfkill first in nci_unregister_device(). Note that we cannot call nfc_unregister_device() before nci_close_device() because 1) nfc_unregister_device() calls device_del() which frees all memory allocated by devm_kzalloc() and linked to ndev->conn_info_list 2) nci_rx_work() could try to queue nci_conn_info to ndev->conn_info_list which could be leaked Thus, nfc_unregister_device() is split into two functions so we can remove rfkill interfaces only before nci_close_device(). [0]: DEBUG_LOCKS_WARN_ON(1) WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349 Modules linked in: CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline] RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187 Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f RSP: 0018:ffffc9000c767680 EFLAGS: 00010046 RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000 RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0 RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4 R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2 R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30 FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0 Call Trace: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ksys_write+0x150/0x270 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa59b39acb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9 RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007 RBP: 00007fa59b408bf7 R08: ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23150", "url": "https://ubuntu.com/security/CVE-2026-23150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame(). syzbot reported various memory leaks related to NFC, struct nfc_llcp_sock, sk_buff, nfc_dev, etc. [0] The leading log hinted that nfc_llcp_send_ui_frame() failed to allocate skb due to sock_error(sk) being -ENXIO. ENXIO is set by nfc_llcp_socket_release() when struct nfc_llcp_local is destroyed by local_cleanup(). The problem is that there is no synchronisation between nfc_llcp_send_ui_frame() and local_cleanup(), and skb could be put into local->tx_queue after it was purged in local_cleanup(): CPU1 CPU2 ---- ---- nfc_llcp_send_ui_frame() local_cleanup() |- do { ' |- pdu = nfc_alloc_send_skb(..., &err) | . | |- nfc_llcp_socket_release(local, false, ENXIO); | |- skb_queue_purge(&local->tx_queue); | | ' | |- skb_queue_tail(&local->tx_queue, pdu); | ... | |- pdu = nfc_alloc_send_skb(..., &err) | ^._________________________________.' local_cleanup() is called for struct nfc_llcp_local only after nfc_llcp_remove_local() unlinks it from llcp_devices. If we hold local->tx_queue.lock then, we can synchronise the thread and nfc_llcp_send_ui_frame(). Let's do that and check list_empty(&local->list) before queuing skb to local->tx_queue in nfc_llcp_send_ui_frame(). [0]: [ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6) [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak) BUG: memory leak unreferenced object 0xffff8881272f6800 (size 1024): comm \"syz.0.17\", pid 6096, jiffies 4294942766 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc da58d84d): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658 kmalloc_noprof include/linux/slab.h:961 [inline] sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239 sk_alloc+0x36/0x360 net/core/sock.c:2295 nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31 __sock_create+0x1a9/0x340 net/socket.c:1605 sock_create net/socket.c:1663 [inline] __sys_socket_create net/socket.c:1700 [inline] __sys_socket+0xb9/0x1a0 net/socket.c:1747 __do_sys_socket net/socket.c:1761 [inline] __se_sys_socket net/socket.c:1759 [inline] __x64_sys_socket+0x1b/0x30 net/socket.c:1759 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: memory leak unreferenced object 0xffff88810fbd9800 (size 240): comm \"syz.0.17\", pid 6096, jiffies 4294942850 hex dump (first 32 bytes): 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h....... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'.... backtrace (crc 6cc652b1): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/sk ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23164", "url": "https://ubuntu.com/security/CVE-2026-23164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rocker: fix memory leak in rocker_world_port_post_fini() In rocker_world_port_pre_init(), rocker_port->wpriv is allocated with kzalloc(wops->port_priv_size, GFP_KERNEL). However, in rocker_world_port_post_fini(), the memory is only freed when wops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv); Since rocker_ofdpa_ops does not implement port_post_fini callback (it is NULL), the wpriv memory allocated for each port is never freed when ports are removed. This leads to a memory leak of sizeof(struct ofdpa_port) bytes per port on every device removal. Fix this by always calling kfree(rocker_port->wpriv) regardless of whether the port_post_fini callback exists.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23146", "url": "https://ubuntu.com/security/CVE-2026-23146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling hci_uart_register_dev(), which calls proto->open() to initialize hu->priv. However, if a TTY write wakeup occurs during this window, hci_uart_tx_wakeup() may schedule write_work before hu->priv is initialized, leading to a NULL pointer dereference in hci_uart_write_work() when proto->dequeue() accesses hu->priv. The race condition is: CPU0 CPU1 ---- ---- hci_uart_set_proto() set_bit(HCI_UART_PROTO_INIT) hci_uart_register_dev() tty write wakeup hci_uart_tty_wakeup() hci_uart_tx_wakeup() schedule_work(&hu->write_work) proto->open(hu) // initializes hu->priv hci_uart_write_work() hci_uart_dequeue() proto->dequeue(hu) // accesses hu->priv (NULL!) Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open() succeeds, ensuring hu->priv is initialized before any work can be scheduled.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-38591", "url": "https://ubuntu.com/security/CVE-2025-38591", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject narrower access to pointer ctx fields The following BPF program, simplified from a syzkaller repro, causes a kernel warning: r0 = *(u8 *)(r1 + 169); exit; With pointer field sk being at offset 168 in __sk_buff. This access is detected as a narrower read in bpf_skb_is_valid_access because it doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed and later proceeds to bpf_convert_ctx_access. Note that for the \"is_narrower_load\" case in the convert_ctx_accesses(), the insn->off is aligned, so the cnt may not be 0 because it matches the offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However, the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1) This patch fixes that to return a proper \"invalid bpf_context access off=X size=Y\" error on the load instruction. The same issue affects multiple other fields in context structures that allow narrow access. Some other non-affected fields (for sk_msg, sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for consistency. Note this syzkaller crash was reported in the \"Closes\" link below, which used to be about a different bug, fixed in commit fce7bd8e385a (\"bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()\"). Because syzbot somehow confused the two bugs, the new crash and repro didn't get reported to the mailing list.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-68725", "url": "https://ubuntu.com/security/CVE-2025-68725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do not let BPF test infra emit invalid GSO types to stack Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled. We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place. The checks were added in 121d57af308d (\"gso: validate gso_type in GSO handlers\") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2026-23097", "url": "https://ubuntu.com/security/CVE-2026-23097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: migrate: correct lock ordering for hugetlb file folios Syzbot has found a deadlock (analyzed by Lance Yang): 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock! The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing i_mmap_lock to cover the calls to remove_migration_ptes() too. This is (mostly) how it used to be after commit c0d0381ade79. That was removed by 336bf30eb765 for both file & anon hugetlb pages when it should only have been removed for anon hugetlb pages.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23108", "url": "https://ubuntu.com/security/CVE-2026-23108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback usb_8dev_read_bulk_callback(), the URBs are processed and resubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the usb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23080", "url": "https://ubuntu.com/security/CVE-2026-23080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In mcba_usb_probe() -> mcba_usb_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback mcba_usb_read_bulk_callback(), the URBs are processed and resubmitted. In mcba_usb_close() -> mcba_urb_unlink() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the mcba_usb_read_bulk_callback()to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23061", "url": "https://ubuntu.com/security/CVE-2026-23061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In kvaser_usb_set_{,data_}bittiming() -> kvaser_usb_setup_rx_urbs(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback kvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. In kvaser_usb_remove_interfaces() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the kvaser_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23058", "url": "https://ubuntu.com/security/CVE-2026-23058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In ems_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In ems_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in ems_usb_close(). Fix the memory leak by anchoring the URB in the ems_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23085", "url": "https://ubuntu.com/security/CVE-2026-23085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Avoid truncating memory addresses On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23098", "url": "https://ubuntu.com/security/CVE-2026-23098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netrom: fix double-free in nr_route_frame() In nr_route_frame(), old_skb is immediately freed without checking if nr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL, the caller function will free old_skb again, causing a double-free bug. Therefore, to prevent this, we need to modify it to check whether nr_neigh->ax25 is NULL before freeing old_skb.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23063", "url": "https://ubuntu.com/security/CVE-2026-23063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: ensure safe queue release with state management Directly calling `put_queue` carries risks since it cannot guarantee that resources of `uacce_queue` have been fully released beforehand. So adding a `stop_queue` operation for the UACCE_CMD_PUT_Q command and leaving the `put_queue` operation to the final resource release ensures safety. Queue states are defined as follows: - UACCE_Q_ZOMBIE: Initial state - UACCE_Q_INIT: After opening `uacce` - UACCE_Q_STARTED: After `start` is issued via `ioctl` When executing `poweroff -f` in virt while accelerator are still working, `uacce_fops_release` and `uacce_remove` may execute concurrently. This can cause `uacce_put_queue` within `uacce_fops_release` to access a NULL `ops` pointer. Therefore, add state checks to prevent accessing freed pointers.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23056", "url": "https://ubuntu.com/security/CVE-2026-23056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: implement mremap in uacce_vm_ops to return -EPERM The current uacce_vm_ops does not support the mremap operation of vm_operations_struct. Implement .mremap to return -EPERM to remind users. The reason we need to explicitly disable mremap is that when the driver does not implement .mremap, it uses the default mremap method. This could lead to a risk scenario: An application might first mmap address p1, then mremap to p2, followed by munmap(p1), and finally munmap(p2). Since the default mremap copies the original vma's vm_private_data (i.e., q) to the new vma, both munmap operations would trigger vma_close, causing q->qfr to be freed twice(qfr will be set to null here, so repeated release is ok).", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23096", "url": "https://ubuntu.com/security/CVE-2026-23096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: fix cdev handling in the cleanup path When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23091", "url": "https://ubuntu.com/security/CVE-2026-23091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix device leak on output open() Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close(). Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23090", "url": "https://ubuntu.com/security/CVE-2026-23090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: core: fix device reference leak on report present Slimbus devices can be allocated dynamically upon reception of report-present messages. Make sure to drop the reference taken when looking up already registered devices. Note that this requires taking an extra reference in case the device has not yet been registered and has to be allocated.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23128", "url": "https://ubuntu.com/security/CVE-2026-23128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Set __nocfi on swsusp_arch_resume() A DABT is reported[1] on an android based system when resume from hiberate. This happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*() and does not have a CFI hash, but swsusp_arch_resume() will attempt to verify the CFI hash when calling a copy of swsusp_arch_suspend_exit(). Given that there's an existing requirement that the entrypoint to swsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text section, we cannot fix this by marking swsusp_arch_suspend_exit() with SYM_FUNC_*(). The simplest fix for now is to disable the CFI check in swsusp_arch_resume(). Mark swsusp_arch_resume() as __nocfi to disable the CFI check. [1] [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc [ 22.991934][ T1] Mem abort info: [ 22.991934][ T1] ESR = 0x0000000096000007 [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [ 22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][ T1] FSC = 0x07: level 3 translation fault [ 22.991934][ T1] Data abort info: [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 22.991934][ T1] Dumping ftrace buffer: [ 22.991934][ T1] (ftrace buffer empty) [ 22.991934][ T1] Modules linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419 [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT) [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344 [ 22.991934][ T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000 [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820 [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000 [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058 [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004 [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000 [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000 [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530 [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000 [ 22.991934][ T1] Call trace: [ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] hibernation_restore+0x158/0x18c [ 22.991934][ T1] load_image_and_restore+0xb0/0xec [ 22.991934][ T1] software_resume+0xf4/0x19c [ 22.991934][ T1] software_resume_initcall+0x34/0x78 [ 22.991934][ T1] do_one_initcall+0xe8/0x370 [ 22.991934][ T1] do_initcall_level+0xc8/0x19c [ 22.991934][ T1] do_initcalls+0x70/0xc0 [ 22.991934][ T1] do_basic_setup+0x1c/0x28 [ 22.991934][ T1] kernel_init_freeable+0xe0/0x148 [ 22.991934][ T1] kernel_init+0x20/0x1a8 [ 22.991934][ T1] ret_from_fork+0x10/0x20 [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110) [catalin.marinas@arm.com: commit log updated by Mark Rutland]", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23073", "url": "https://ubuntu.com/security/CVE-2026-23073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: Fix memory corruption due to not set vif driver data size The struct ieee80211_vif contains trailing space for vif driver data, when struct ieee80211_vif is allocated, the total memory size that is allocated is sizeof(struct ieee80211_vif) + size of vif driver data. The size of vif driver data is set by each WiFi driver as needed. The RSI911x driver does not set vif driver data size, no trailing space for vif driver data is therefore allocated past struct ieee80211_vif . The RSI911x driver does however use the vif driver data to store its vif driver data structure \"struct vif_priv\". An access to vif->drv_priv leads to access out of struct ieee80211_vif bounds and corruption of some memory. In case of the failure observed locally, rsi_mac80211_add_interface() would write struct vif_priv *vif_info = (struct vif_priv *)vif->drv_priv; vif_info->vap_id = vap_idx. This write corrupts struct fq_tin member struct list_head new_flows . The flow = list_first_entry(head, struct fq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus address, which when accessed causes a crash. The trigger is very simple, boot the machine with init=/bin/sh , mount devtmpfs, sysfs, procfs, and then do \"ip link set wlan0 up\", \"sleep 1\", \"ip link set wlan0 down\" and the crash occurs. Fix this by setting the correct size of vif driver data, which is the size of \"struct vif_priv\", so that memory is allocated and the driver can store its driver data in it, instead of corrupting memory around it.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23133", "url": "https://ubuntu.com/security/CVE-2026-23133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: fix dma_free_coherent() pointer dma_alloc_coherent() allocates a DMA mapped buffer and stores the addresses in XXX_unaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23089", "url": "https://ubuntu.com/security/CVE-2026-23089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free() When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees mixer->id_elems but the controls already added to the card still reference the freed memory. Later when snd_card_register() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read. Call trace: get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381 snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ... snd_card_register+0x4ed/0x6d0 sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025 Fix by calling snd_ctl_remove() for all mixer controls before freeing id_elems. We save the next pointer first because snd_ctl_remove() frees the current element.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23076", "url": "https://ubuntu.com/security/CVE-2026-23076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix potential OOB access in audio mixer handling In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixer_index() and sum_index()). As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]' After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field. This patch addresses those OOB accesses by adding the proper initializations of the loop indices.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71199", "url": "https://ubuntu.com/security/CVE-2025-71199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver at91_adc_interrupt can call at91_adc_touch_data_handler function to start the work by schedule_work(&st->touch_st.workq). If we remove the module which will call at91_adc_remove to make cleanup, it will free indio_dev through iio_device_unregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | at91_adc_workq_handler at91_adc_remove | iio_device_unregister(indio_dev) | //free indio_dev a bit later | | iio_push_to_buffers(indio_dev) | //use indio_dev Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91_adc_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23101", "url": "https://ubuntu.com/security/CVE-2026-23101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: led-class: Only Add LED to leds_list when it is fully ready Before this change the LED was added to leds_list before led_init_core() gets called adding it the list before led_classdev.set_brightness_work gets initialized. This leaves a window where led_trigger_register() of a LED's default trigger will call led_trigger_set() which calls led_set_brightness() which in turn will end up queueing the *uninitialized* led_classdev.set_brightness_work. This race gets hit by the lenovo-thinkpad-t14s EC driver which registers 2 LEDs with a default trigger provided by snd_ctl_led.ko in quick succession. The first led_classdev_register() causes an async modprobe of snd_ctl_led to run and that async modprobe manages to exactly hit the window where the second LED is on the leds_list without led_init_core() being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998 Close the race window by moving the adding of the LED to leds_list to after the led_init_core() call.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23064", "url": "https://ubuntu.com/security/CVE-2026-23064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: avoid possible NULL deref tcf_ife_encode() must make sure ife_encode() does not return NULL. syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166 CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full) Call Trace: ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23119", "url": "https://ubuntu.com/security/CVE-2026-23119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: provide a net pointer to __skb_flow_dissect() After 3cbf4ffba5ee (\"net: plumb network namespace into __skb_flow_dissect\") we have to provide a net pointer to __skb_flow_dissect(), either via skb->dev, skb->sk, or a user provided pointer. In the following case, syzbot was able to cook a bare skb. WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053 Call Trace: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23084", "url": "https://ubuntu.com/security/CVE-2026-23084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list When the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() is set to false, the driver may request the PMAC_ID from the firmware of the network card, and this function will store that PMAC_ID at the provided address pmac_id. This is the contract of this function. However, there is a location within the driver where both pmac_id_valid == false and pmac_id == NULL are being passed. This could result in dereferencing a NULL pointer. To resolve this issue, it is necessary to pass the address of a stub variable to the function.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23124", "url": "https://ubuntu.com/security/CVE-2026-23124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: annotate data-race in ndisc_router_discovery() syzbot found that ndisc_router_discovery() could read and write in6_dev->ra_mtu without holding a lock [1] This looks fine, IFLA_INET6_RA_MTU is best effort. Add READ_ONCE()/WRITE_ONCE() to document the race. Note that we might also reject illegal MTU values (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch. [1] BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... value changed: 0x00000000 -> 0xe5400659", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23121", "url": "https://ubuntu.com/security/CVE-2026-23121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mISDN: annotate data-race around dev->work dev->work can re read locklessly in mISDN_read() and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations. BUG: KCSAN: data-race in mISDN_ioctl / mISDN_read write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [inline] vfs_readv+0x3fb/0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [inline] __se_sys_readv fs/read_write.c:1162 [inline] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000 -> 0x00000001", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23071", "url": "https://ubuntu.com/security/CVE-2026-23071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: Fix race condition in hwspinlock irqsave routine Previously, the address of the shared member '&map->spinlock_flags' was passed directly to 'hwspin_lock_timeout_irqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shared flags variable, potentially corrupting the state for the current lock owner. Fix this by using a local stack variable 'flags' to store the IRQ state temporarily.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23105", "url": "https://ubuntu.com/security/CVE-2026-23105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag This is more of a preventive patch to make the code more consistent and to prevent possible exploits that employ child qlen manipulations on qfq. use cl_is_active instead of relying on the child qdisc's qlen to determine class activation.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23103", "url": "https://ubuntu.com/security/CVE-2026-23103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close) This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause: 1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock. 2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23120", "url": "https://ubuntu.com/security/CVE-2026-23120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: avoid one data-race in l2tp_tunnel_del_work() We should read sk->sk_socket only when dealing with kernel sockets. syzbot reported the following data-race: BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 value changed: 0xffff88811b818000 -> 0x0000000000000000", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23083", "url": "https://ubuntu.com/security/CVE-2026-23083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Don't allow 0 for FOU_ATTR_IPPROTO. fou_udp_recv() has the same problem mentioned in the previous patch. If FOU_ATTR_IPPROTO is set to 0, skb is not freed by fou_udp_recv() nor \"resubmit\"-ted in ip_protocol_deliver_rcu(). Let's forbid 0 for FOU_ATTR_IPPROTO.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23095", "url": "https://ubuntu.com/security/CVE-2026-23095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: Fix skb memleak with inner IP protocol 0. syzbot reported skb memleak below. [0] The repro generated a GUE packet with its inner protocol 0. gue_udp_recv() returns -guehdr->proto_ctype for \"resubmit\" in ip_protocol_deliver_rcu(), but this only works with non-zero protocol number. Let's drop such packets. Note that 0 is a valid number (IPv6 Hop-by-Hop Option). I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT [0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm \"syz.0.17\", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23125", "url": "https://ubuntu.com/security/CVE-2026-23125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key initialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127 The issue is triggered when sctp_auth_asoc_init_active_key() fails in sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the command sequence is currently: - SCTP_CMD_PEER_INIT - SCTP_CMD_TIMER_STOP (T1_INIT) - SCTP_CMD_TIMER_START (T1_COOKIE) - SCTP_CMD_NEW_STATE (COOKIE_ECHOED) - SCTP_CMD_ASSOC_SHKEY - SCTP_CMD_GEN_COOKIE_ECHO If SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while asoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL to be queued by sctp_datamsg_from_user(). Since command interpretation stops on failure, no COOKIE_ECHO should been sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As a result, the DATA chunk can be transmitted together with the COOKIE_ECHO in sctp_outq_flush_data(), leading to the observed issue. Similar to the other places where it calls sctp_auth_asoc_init_active_key() right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting T1_COOKIE. This ensures that if shared key generation fails, authenticated DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT, giving the client another chance to process INIT_ACK and retry key setup.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23099", "url": "https://ubuntu.com/security/CVE-2026-23099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: limit BOND_MODE_8023AD to Ethernet devices BOND_MODE_8023AD makes sense for ARPHRD_ETHER only. syzbot reported: BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline] BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497 CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [inline] __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [inline] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e The buggy address belongs to the variable: lacpdu_mcast_addr+0x0/0x40", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71194", "url": "https://ubuntu.com/security/CVE-2025-71194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock in wait_current_trans() due to ignored transaction type When wait_current_trans() is called during start_transaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfs_blocked_trans_types[] array already defines which transaction types should wait for which transaction states, but this check was missing in wait_current_trans(). This can lead to a deadlock scenario involving two transactions and pending ordered extents: 1. Transaction A is in TRANS_STATE_COMMIT_DOING state 2. A worker processing an ordered extent calls start_transaction() with TRANS_JOIN 3. join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes 5. A new Transaction B is created (TRANS_STATE_RUNNING) 6. The ordered extent from step 2 is added to Transaction B's pending ordered extents 7. Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START 8. The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[] 10. Transaction B is waiting for pending ordered extents to complete 11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B This can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!) Task bstore_kv_sync in btrfs_commit_transaction waiting for ordered extents: __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Task kworker in wait_current_trans waiting for transaction commit: Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30 Fix this by passing the transaction type to wait_current_trans() and checking btrfs_blocked_trans_types[cur_trans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71185", "url": "https://ubuntu.com/security/CVE-2025-71185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23026", "url": "https://ubuntu.com/security/CVE-2026-23026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config() Fix a memory leak in gpi_peripheral_config() where the original memory pointed to by gchan->config could be lost if krealloc() fails. The issue occurs when: 1. gchan->config points to previously allocated memory 2. krealloc() fails and returns NULL 3. The function directly assigns NULL to gchan->config, losing the reference to the original memory 4. The original memory becomes unreachable and cannot be freed Fix this by using a temporary variable to hold the krealloc() result and only updating gchan->config when the allocation succeeds. Found via static analysis and code review.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71188", "url": "https://ubuntu.com/security/CVE-2025-71188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: lpc18xx-dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71163", "url": "https://ubuntu.com/security/CVE-2025-71163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix device leaks on compat bind and unbind Make sure to drop the reference taken when looking up the idxd device as part of the compat bind and unbind sysfs interface.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2025-71190", "url": "https://ubuntu.com/security/CVE-2025-71190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: bcm-sba-raid: fix device leak on probe Make sure to drop the reference taken when looking up the mailbox device during probe on probe failures and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71191", "url": "https://ubuntu.com/security/CVE-2025-71191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: at_hdmac: fix device leak on of_dma_xlate() Make sure to drop the reference taken when looking up the DMA platform device during of_dma_xlate() when releasing channel resources. Note that commit 3832b78b3ec2 (\"dmaengine: at_hdmac: add missing put_device() call in at_dma_xlate()\") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23049", "url": "https://ubuntu.com/security/CVE-2026-23049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel The connector type for the DataImage SCF0700C48GGU18 panel is missing and devm_drm_panel_bridge_add() requires connector type to be set. This leads to a warning and a backtrace in the kernel log and panel does not work: \" WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8 \" The warning is triggered by a check for valid connector type in devm_drm_panel_bridge_add(). If there is no valid connector type set for a panel, the warning is printed and panel is not added. Fill in the missing connector type to fix the warning and make the panel operational once again.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23145", "url": "https://ubuntu.com/security/CVE-2026-23145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref The error branch for ext4_xattr_inode_update_ref forget to release the refcount for iloc.bh. Find this when review code.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-22997", "url": "https://ubuntu.com/security/CVE-2026-22997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is called only when the timer is enabled, we need to call j1939_session_deactivate_activate_next() if we cancelled the timer. Otherwise, refcount for j1939_session leaks, which will later appear as | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2. problem.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23033", "url": "https://ubuntu.com/security/CVE-2026-23033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: omap-dma: fix dma_pool resource leak in error paths The dma_pool created by dma_pool_create() is not destroyed when dma_async_device_register() or of_dma_controller_register() fails, causing a resource leak in the probe error paths. Add dma_pool_destroy() in both error paths to properly release the allocated dma_pool resource.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71196", "url": "https://ubuntu.com/security/CVE-2025-71196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: stm32-usphyc: Fix off by one in probe() The \"index\" variable is used as an index into the usbphyc->phys[] array which has usbphyc->nphys elements. So if it is equal to usbphyc->nphys then it is one element out of bounds. The \"index\" comes from the device tree so it's data that we trust and it's unlikely to be wrong, however it's obviously still worth fixing the bug. Change the > to >=.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71162", "url": "https://ubuntu.com/security/CVE-2025-71162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: tegra-adma: Fix use-after-free A use-after-free bug exists in the Tegra ADMA driver when audio streams are terminated, particularly during XRUN conditions. The issue occurs when the DMA buffer is freed by tegra_adma_terminate_all() before the vchan completion tasklet finishes accessing it. The race condition follows this sequence: 1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegra_adma_terminate_all() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchan_complete() which attempts to access the already-freed memory Since tasklets can execute at any time after being scheduled, there is no guarantee that the buffer will remain valid when vchan_complete() runs. Fix this by properly synchronizing the virtual channel completion: - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegra_adma_synchronize() that calls vchan_synchronize() which kills any pending tasklets and frees any terminated descriptors. Crash logs: [ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0 [ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0 [ 337.427562] Call trace: [ 337.427564] dump_backtrace+0x0/0x320 [ 337.427571] show_stack+0x20/0x30 [ 337.427575] dump_stack_lvl+0x68/0x84 [ 337.427584] print_address_description.constprop.0+0x74/0x2b8 [ 337.427590] kasan_report+0x1f4/0x210 [ 337.427598] __asan_load8+0xa0/0xd0 [ 337.427603] vchan_complete+0x124/0x3b0 [ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0 [ 337.427617] tasklet_action+0x30/0x40 [ 337.427623] __do_softirq+0x1a0/0x5c4 [ 337.427628] irq_exit+0x110/0x140 [ 337.427633] handle_domain_irq+0xa4/0xe0 [ 337.427640] gic_handle_irq+0x64/0x160 [ 337.427644] call_on_irq_stack+0x20/0x4c [ 337.427649] do_interrupt_handler+0x7c/0x90 [ 337.427654] el1_interrupt+0x30/0x80 [ 337.427659] el1h_64_irq_handler+0x18/0x30 [ 337.427663] el1h_64_irq+0x7c/0x80 [ 337.427667] cpuidle_enter_state+0xe4/0x540 [ 337.427674] cpuidle_enter+0x54/0x80 [ 337.427679] do_idle+0x2e0/0x380 [ 337.427685] cpu_startup_entry+0x2c/0x70 [ 337.427690] rest_init+0x114/0x130 [ 337.427695] arch_call_rest_init+0x18/0x24 [ 337.427702] start_kernel+0x380/0x3b4 [ 337.427706] __primary_switched+0xc0/0xc8", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22999", "url": "https://ubuntu.com/security/CVE-2026-22999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: do not free existing class in qfq_change_class() Fixes qfq_change_class() error case. cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23011", "url": "https://ubuntu.com/security/CVE-2026-23011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_gre: make ipgre_header() robust Analog to commit db5b4e39c4e6 (\"ip6_gre: make ip6gre_header() robust\") Over the years, syzbot found many ways to crash the kernel in ipgre_header() [1]. This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ipgre device. [1] skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213 Call Trace: skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23001", "url": "https://ubuntu.com/security/CVE-2026-23001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix possible UAF in macvlan_forward_source() Add RCU protection on (struct macvlan_source_entry)->vlan. Whenever macvlan_hash_del_source() is called, we must clear entry->vlan pointer before RCU grace period starts. This allows macvlan_forward_source() to skip over entries queued for freeing. Note that macvlan_dev are already RCU protected, as they are embedded in a standard netdev (netdev_priv(ndev)). https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23003", "url": "https://ubuntu.com/security/CVE-2026-23003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() Blamed commit did not take care of VLAN encapsulations as spotted by syzbot [1]. Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull(). [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22998", "url": "https://ubuntu.com/security/CVE-2026-22998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec Commit efa56305908b (\"nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs. The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command. Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23037", "url": "https://ubuntu.com/security/CVE-2026-23037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: allow partial RX URB allocation to succeed When es58x_alloc_rx_urbs() fails to allocate the requested number of URBs but succeeds in allocating some, it returns an error code. This causes es58x_open() to return early, skipping the cleanup label 'free_urbs', which leads to the anchored URBs being leaked. As pointed out by maintainer Vincent Mailhol, the driver is designed to handle partial URB allocation gracefully. Therefore, partial allocation should not be treated as a fatal error. Modify es58x_alloc_rx_urbs() to return 0 if at least one URB has been allocated, restoring the intended behavior and preventing the leak in es58x_open().", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23038", "url": "https://ubuntu.com/security/CVE-2026-23038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node() In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak. Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23111", "url": "https://ubuntu.com/security/CVE-2026-23111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate() nft_map_catchall_activate() has an inverted element activity check compared to its non-catchall counterpart nft_mapelem_activate() and compared to what is logically required. nft_map_catchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones. Compare the non-catchall activate callback, which is correct: nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; /* skip active, process inactive */ With the buggy catchall version: nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; /* skip inactive, process active */ The consequence is that when a DELSET operation is aborted, nft_setelem_data_activate() is never called for the catchall element. For NFT_GOTO verdict elements, this means nft_data_hold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free. This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIG_USER_NS and CONFIG_NF_TABLES. Fix by removing the negation so the check matches nft_mapelem_activate(): skip active elements, process inactive ones.", "cve_priority": "high", "cve_public_date": "2026-02-13 14:16:00 UTC" }, { "cve": "CVE-2026-23209", "url": "https://ubuntu.com/security/CVE-2026-23209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source(). With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-37849", "url": "https://ubuntu.com/security/CVE-2025-37849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Tear down vGIC on failed vCPU creation If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU. Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.", "cve_priority": "high", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2026-23074", "url": "https://ubuntu.com/security/CVE-2026-23074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Enforce that teql can only be used as root qdisc Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint. Although not important, I will describe the scenario that unearthed this issue for the curious. GangMin Kim managed to concot a scenario as follows: ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s └── class 1:2 (weight=1, lmax=1514) teql GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23060", "url": "https://ubuntu.com/security/CVE-2026-23060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, crypto_authenc_esn_decrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalk_map_and_copy(), leading to a kernel panic (DoS). Add a minimum AAD length check to fail fast on invalid inputs.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143524, 2143539, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143033, 2141276 ], "changes": [ { "cves": [ { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2026-23170", "url": "https://ubuntu.com/security/CVE-2026-23170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imx/tve: fix probe device leak Make sure to drop the reference taken to the DDC device during probe on probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23075", "url": "https://ubuntu.com/security/CVE-2026-23075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In esd_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback esd_usb_read_bulk_callback(), the URBs are processed and resubmitted. In esd_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in esd_usb_close(). Fix the memory leak by anchoring the URB in the esd_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-38408", "url": "https://ubuntu.com/security/CVE-2025-38408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: genirq/irq_sim: Initialize work context pointers properly Initialize `ops` member's pointers properly by using kzalloc() instead of kmalloc() when allocating the simulation work context. Otherwise the pointers contain random content leading to invalid dereferencing.", "cve_priority": "medium", "cve_public_date": "2025-07-25 14:15:00 UTC" }, { "cve": "CVE-2023-54207", "url": "https://ubuntu.com/security/CVE-2023-54207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: Correct devm device reference for hidinput input_dev name Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management. Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string.", "cve_priority": "medium", "cve_public_date": "2025-12-30 13:16:00 UTC" }, { "cve": "CVE-2023-53520", "url": "https://ubuntu.com/security/CVE-2023-53520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix hci_suspend_sync crash If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.", "cve_priority": "medium", "cve_public_date": "2025-10-01 12:15:00 UTC" }, { "cve": "CVE-2025-38125", "url": "https://ubuntu.com/security/CVE-2025-38125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring EST If the ptp_rate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0. Prevent this division by 0 by adding the corresponding check and error code.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-40164", "url": "https://ubuntu.com/security/CVE-2025-40164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix using smp_processor_id() in preemptible code warnings Syzbot reported the following warning: BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879 caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary) Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f For historical and portability reasons, the netif_rx() is usually run in the softirq or interrupt context, this commit therefore add local_bh_disable/enable() protection in the usbnet_resume_rx().", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-38232", "url": "https://ubuntu.com/security/CVE-2025-38232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix race between nfsd registration and exports_proc As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd. Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd for 5.4 kernel ARM64: CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0 CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 PC is at : exports_net_open+0x50/0x68 [nfsd] Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248 Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu(). and same is happening on latest 6.14 kernel as well: [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]--- It reproduced simply with below script: while [ 1 ] do /exportfs -r done & while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done & So exporting interfaces to user space shall be done at last and cleanup at first place. With change there is no Kernel OOPs.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2023-53662", "url": "https://ubuntu.com/security/CVE-2023-53662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup} If the filename casefolding fails, we'll be leaking memory from the fscrypt_name struct, namely from the 'crypto_buf.name' member. Make sure we free it in the error path on both ext4_fname_setup_filename() and ext4_fname_prepare_lookup() functions.", "cve_priority": "medium", "cve_public_date": "2025-10-07 16:15:00 UTC" }, { "cve": "CVE-2025-38057", "url": "https://ubuntu.com/security/CVE-2025-38057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: fix skb leaks A few error paths are missing a kfree_skb.", "cve_priority": "medium", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2023-53421", "url": "https://ubuntu.com/security/CVE-2023-53421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats() When blkg_alloc() is called to allocate a blkcg_gq structure with the associated blkg_iostat_set's, there are 2 fields within blkg_iostat_set that requires proper initialization - blkg & sync. The former field was introduced by commit 3b8cc6298724 (\"blk-cgroup: Optimize blkcg_rstat_flush()\") while the later one was introduced by commit f73316482977 (\"blk-cgroup: reimplement basic IO stats using cgroup rstat\"). Unfortunately those fields in the blkg_iostat_set's are not properly re-initialized when they are cleared in v1's blkcg_reset_stats(). This can lead to a kernel panic due to NULL pointer access of the blkg pointer. The missing initialization of sync is less problematic and can be a problem in a debug kernel due to missing lockdep initialization. Fix these problems by re-initializing them after memory clearing.", "cve_priority": "medium", "cve_public_date": "2025-09-18 16:15:00 UTC" }, { "cve": "CVE-2025-68365", "url": "https://ubuntu.com/security/CVE-2025-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Initialize allocated memory before use KMSAN reports: Multiple uninitialized values detected: - KMSAN: uninit-value in ntfs_read_hdr (3) - KMSAN: uninit-value in bcmp (3) Memory is allocated by __getname(), which is a wrapper for kmem_cache_alloc(). This memory is used before being properly cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to properly allocate and clear memory before use.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68817", "url": "https://ubuntu.com/security/CVE-2025-68817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency Under high concurrency, A tree-connection object (tcon) is freed on a disconnect path while another path still holds a reference and later executes *_put()/write on it.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2022-50390", "url": "https://ubuntu.com/security/CVE-2022-50390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATED Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c ttm_bo_move_memcpy+0x3b4/0x460 [ttm] bo_driver_move+0x32/0x40 [drm_vram_helper] ttm_bo_handle_move_mem+0x118/0x200 [ttm] ttm_bo_validate+0xfa/0x220 [ttm] drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper] drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper] drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper] drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper] drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper] drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper] drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper] drm_atomic_commit+0x9c/0x160 [drm] drm_client_modeset_commit_atomic+0x33a/0x380 [drm] drm_client_modeset_commit_locked+0x77/0x220 [drm] drm_client_modeset_commit+0x31/0x60 [drm] __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper] drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper] fbcon_init+0x316/0x790 visual_init+0x113/0x1d0 do_bind_con_driver+0x2a3/0x5c0 do_take_over_console+0xa9/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ", "cve_priority": "medium", "cve_public_date": "2025-09-18 14:15:00 UTC" }, { "cve": "CVE-2025-68211", "url": "https://ubuntu.com/security/CVE-2025-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksm: use range-walk function to jump over holes in scan_get_next_rmap_item Currently, scan_get_next_rmap_item() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages. This patch replaces the per-address lookup with a range walk using walk_page_range(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1]. Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page: #include #include #include /* 32 TiB */ const size_t size = 32ul * 1024 * 1024 * 1024 * 1024; int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror(\"mmap() failed\\n\"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0; } $ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-23093", "url": "https://ubuntu.com/security/CVE-2026-23093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbd: fix dma_unmap_sg() nents The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23078", "url": "https://ubuntu.com/security/CVE-2026-23078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Fix buffer overflow in config retrieval The scarlett2_usb_get_config() function has a logic error in the endianness conversion code that can cause buffer overflows when count > 1. The code checks `if (size == 2)` where `size` is the total buffer size in bytes, then loops `count` times treating each element as u16 (2 bytes). This causes the loop to access `count * 2` bytes when the buffer only has `size` bytes allocated. Fix by checking the element size (config_item->size) instead of the total buffer size. This ensures the endianness conversion matches the actual element type.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71186", "url": "https://ubuntu.com/security/CVE-2025-71186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: stm32: dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71197", "url": "https://ubuntu.com/security/CVE-2025-71197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: therm: Fix off-by-one buffer overflow in alarms_store The sysfs buffer passed to alarms_store() is allocated with 'size + 1' bytes and a NUL terminator is appended. However, the 'size' argument does not account for this extra byte. The original code then allocated 'size' bytes and used strcpy() to copy 'buf', which always writes one byte past the allocated buffer since strcpy() copies until the NUL terminator at index 'size'. Fix this by parsing the 'buf' parameter directly using simple_strtoll() without allocating any intermediate memory or string copying. This removes the overflow while simplifying the code.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23087", "url": "https://ubuntu.com/security/CVE-2026-23087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Fix potential memory leak in scsiback_remove() Memory allocated for struct vscsiblk_info in scsiback_probe() is not freed in scsiback_remove() leading to potential memory leaks on remove, as well as in the scsiback_probe() error paths. Fix that by freeing it in scsiback_remove().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-40149", "url": "https://ubuntu.com/security/CVE-2025-40149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock(). get_netdev_for_sock() is called during setsockopt(), so not under RCU. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the only ->ndo_sk_get_lower_dev() user is bond_sk_get_lower_dev(), which uses RCU.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-23167", "url": "https://ubuntu.com/security/CVE-2026-23167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix race between rfkill and nci_unregister_device(). syzbot reported the splat below [0] without a repro. It indicates that struct nci_dev.cmd_wq had been destroyed before nci_close_device() was called via rfkill. nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which (I think) was called from virtual_ncidev_close() when syzbot close()d an fd of virtual_ncidev. The problem is that nci_unregister_device() destroys nci_dev.cmd_wq first and then calls nfc_unregister_device(), which removes the device from rfkill by rfkill_unregister(). So, the device is still visible via rfkill even after nci_dev.cmd_wq is destroyed. Let's unregister the device from rfkill first in nci_unregister_device(). Note that we cannot call nfc_unregister_device() before nci_close_device() because 1) nfc_unregister_device() calls device_del() which frees all memory allocated by devm_kzalloc() and linked to ndev->conn_info_list 2) nci_rx_work() could try to queue nci_conn_info to ndev->conn_info_list which could be leaked Thus, nfc_unregister_device() is split into two functions so we can remove rfkill interfaces only before nci_close_device(). [0]: DEBUG_LOCKS_WARN_ON(1) WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349 Modules linked in: CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline] RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187 Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f RSP: 0018:ffffc9000c767680 EFLAGS: 00010046 RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000 RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0 RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4 R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2 R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30 FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0 Call Trace: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ksys_write+0x150/0x270 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa59b39acb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9 RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007 RBP: 00007fa59b408bf7 R08: ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23150", "url": "https://ubuntu.com/security/CVE-2026-23150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame(). syzbot reported various memory leaks related to NFC, struct nfc_llcp_sock, sk_buff, nfc_dev, etc. [0] The leading log hinted that nfc_llcp_send_ui_frame() failed to allocate skb due to sock_error(sk) being -ENXIO. ENXIO is set by nfc_llcp_socket_release() when struct nfc_llcp_local is destroyed by local_cleanup(). The problem is that there is no synchronisation between nfc_llcp_send_ui_frame() and local_cleanup(), and skb could be put into local->tx_queue after it was purged in local_cleanup(): CPU1 CPU2 ---- ---- nfc_llcp_send_ui_frame() local_cleanup() |- do { ' |- pdu = nfc_alloc_send_skb(..., &err) | . | |- nfc_llcp_socket_release(local, false, ENXIO); | |- skb_queue_purge(&local->tx_queue); | | ' | |- skb_queue_tail(&local->tx_queue, pdu); | ... | |- pdu = nfc_alloc_send_skb(..., &err) | ^._________________________________.' local_cleanup() is called for struct nfc_llcp_local only after nfc_llcp_remove_local() unlinks it from llcp_devices. If we hold local->tx_queue.lock then, we can synchronise the thread and nfc_llcp_send_ui_frame(). Let's do that and check list_empty(&local->list) before queuing skb to local->tx_queue in nfc_llcp_send_ui_frame(). [0]: [ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6) [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak) BUG: memory leak unreferenced object 0xffff8881272f6800 (size 1024): comm \"syz.0.17\", pid 6096, jiffies 4294942766 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc da58d84d): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658 kmalloc_noprof include/linux/slab.h:961 [inline] sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239 sk_alloc+0x36/0x360 net/core/sock.c:2295 nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31 __sock_create+0x1a9/0x340 net/socket.c:1605 sock_create net/socket.c:1663 [inline] __sys_socket_create net/socket.c:1700 [inline] __sys_socket+0xb9/0x1a0 net/socket.c:1747 __do_sys_socket net/socket.c:1761 [inline] __se_sys_socket net/socket.c:1759 [inline] __x64_sys_socket+0x1b/0x30 net/socket.c:1759 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: memory leak unreferenced object 0xffff88810fbd9800 (size 240): comm \"syz.0.17\", pid 6096, jiffies 4294942850 hex dump (first 32 bytes): 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h....... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'.... backtrace (crc 6cc652b1): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/sk ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23164", "url": "https://ubuntu.com/security/CVE-2026-23164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rocker: fix memory leak in rocker_world_port_post_fini() In rocker_world_port_pre_init(), rocker_port->wpriv is allocated with kzalloc(wops->port_priv_size, GFP_KERNEL). However, in rocker_world_port_post_fini(), the memory is only freed when wops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv); Since rocker_ofdpa_ops does not implement port_post_fini callback (it is NULL), the wpriv memory allocated for each port is never freed when ports are removed. This leads to a memory leak of sizeof(struct ofdpa_port) bytes per port on every device removal. Fix this by always calling kfree(rocker_port->wpriv) regardless of whether the port_post_fini callback exists.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23146", "url": "https://ubuntu.com/security/CVE-2026-23146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling hci_uart_register_dev(), which calls proto->open() to initialize hu->priv. However, if a TTY write wakeup occurs during this window, hci_uart_tx_wakeup() may schedule write_work before hu->priv is initialized, leading to a NULL pointer dereference in hci_uart_write_work() when proto->dequeue() accesses hu->priv. The race condition is: CPU0 CPU1 ---- ---- hci_uart_set_proto() set_bit(HCI_UART_PROTO_INIT) hci_uart_register_dev() tty write wakeup hci_uart_tty_wakeup() hci_uart_tx_wakeup() schedule_work(&hu->write_work) proto->open(hu) // initializes hu->priv hci_uart_write_work() hci_uart_dequeue() proto->dequeue(hu) // accesses hu->priv (NULL!) Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open() succeeds, ensuring hu->priv is initialized before any work can be scheduled.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-38591", "url": "https://ubuntu.com/security/CVE-2025-38591", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject narrower access to pointer ctx fields The following BPF program, simplified from a syzkaller repro, causes a kernel warning: r0 = *(u8 *)(r1 + 169); exit; With pointer field sk being at offset 168 in __sk_buff. This access is detected as a narrower read in bpf_skb_is_valid_access because it doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed and later proceeds to bpf_convert_ctx_access. Note that for the \"is_narrower_load\" case in the convert_ctx_accesses(), the insn->off is aligned, so the cnt may not be 0 because it matches the offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However, the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1) This patch fixes that to return a proper \"invalid bpf_context access off=X size=Y\" error on the load instruction. The same issue affects multiple other fields in context structures that allow narrow access. Some other non-affected fields (for sk_msg, sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for consistency. Note this syzkaller crash was reported in the \"Closes\" link below, which used to be about a different bug, fixed in commit fce7bd8e385a (\"bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()\"). Because syzbot somehow confused the two bugs, the new crash and repro didn't get reported to the mailing list.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-68725", "url": "https://ubuntu.com/security/CVE-2025-68725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do not let BPF test infra emit invalid GSO types to stack Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled. We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place. The checks were added in 121d57af308d (\"gso: validate gso_type in GSO handlers\") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2026-23097", "url": "https://ubuntu.com/security/CVE-2026-23097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: migrate: correct lock ordering for hugetlb file folios Syzbot has found a deadlock (analyzed by Lance Yang): 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock! The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing i_mmap_lock to cover the calls to remove_migration_ptes() too. This is (mostly) how it used to be after commit c0d0381ade79. That was removed by 336bf30eb765 for both file & anon hugetlb pages when it should only have been removed for anon hugetlb pages.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23108", "url": "https://ubuntu.com/security/CVE-2026-23108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback usb_8dev_read_bulk_callback(), the URBs are processed and resubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the usb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23080", "url": "https://ubuntu.com/security/CVE-2026-23080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In mcba_usb_probe() -> mcba_usb_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback mcba_usb_read_bulk_callback(), the URBs are processed and resubmitted. In mcba_usb_close() -> mcba_urb_unlink() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the mcba_usb_read_bulk_callback()to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23061", "url": "https://ubuntu.com/security/CVE-2026-23061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In kvaser_usb_set_{,data_}bittiming() -> kvaser_usb_setup_rx_urbs(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback kvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. In kvaser_usb_remove_interfaces() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the kvaser_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23058", "url": "https://ubuntu.com/security/CVE-2026-23058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In ems_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In ems_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in ems_usb_close(). Fix the memory leak by anchoring the URB in the ems_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23085", "url": "https://ubuntu.com/security/CVE-2026-23085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Avoid truncating memory addresses On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23098", "url": "https://ubuntu.com/security/CVE-2026-23098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netrom: fix double-free in nr_route_frame() In nr_route_frame(), old_skb is immediately freed without checking if nr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL, the caller function will free old_skb again, causing a double-free bug. Therefore, to prevent this, we need to modify it to check whether nr_neigh->ax25 is NULL before freeing old_skb.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23063", "url": "https://ubuntu.com/security/CVE-2026-23063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: ensure safe queue release with state management Directly calling `put_queue` carries risks since it cannot guarantee that resources of `uacce_queue` have been fully released beforehand. So adding a `stop_queue` operation for the UACCE_CMD_PUT_Q command and leaving the `put_queue` operation to the final resource release ensures safety. Queue states are defined as follows: - UACCE_Q_ZOMBIE: Initial state - UACCE_Q_INIT: After opening `uacce` - UACCE_Q_STARTED: After `start` is issued via `ioctl` When executing `poweroff -f` in virt while accelerator are still working, `uacce_fops_release` and `uacce_remove` may execute concurrently. This can cause `uacce_put_queue` within `uacce_fops_release` to access a NULL `ops` pointer. Therefore, add state checks to prevent accessing freed pointers.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23056", "url": "https://ubuntu.com/security/CVE-2026-23056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: implement mremap in uacce_vm_ops to return -EPERM The current uacce_vm_ops does not support the mremap operation of vm_operations_struct. Implement .mremap to return -EPERM to remind users. The reason we need to explicitly disable mremap is that when the driver does not implement .mremap, it uses the default mremap method. This could lead to a risk scenario: An application might first mmap address p1, then mremap to p2, followed by munmap(p1), and finally munmap(p2). Since the default mremap copies the original vma's vm_private_data (i.e., q) to the new vma, both munmap operations would trigger vma_close, causing q->qfr to be freed twice(qfr will be set to null here, so repeated release is ok).", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23096", "url": "https://ubuntu.com/security/CVE-2026-23096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: fix cdev handling in the cleanup path When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23091", "url": "https://ubuntu.com/security/CVE-2026-23091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix device leak on output open() Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close(). Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23090", "url": "https://ubuntu.com/security/CVE-2026-23090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: core: fix device reference leak on report present Slimbus devices can be allocated dynamically upon reception of report-present messages. Make sure to drop the reference taken when looking up already registered devices. Note that this requires taking an extra reference in case the device has not yet been registered and has to be allocated.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23128", "url": "https://ubuntu.com/security/CVE-2026-23128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Set __nocfi on swsusp_arch_resume() A DABT is reported[1] on an android based system when resume from hiberate. This happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*() and does not have a CFI hash, but swsusp_arch_resume() will attempt to verify the CFI hash when calling a copy of swsusp_arch_suspend_exit(). Given that there's an existing requirement that the entrypoint to swsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text section, we cannot fix this by marking swsusp_arch_suspend_exit() with SYM_FUNC_*(). The simplest fix for now is to disable the CFI check in swsusp_arch_resume(). Mark swsusp_arch_resume() as __nocfi to disable the CFI check. [1] [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc [ 22.991934][ T1] Mem abort info: [ 22.991934][ T1] ESR = 0x0000000096000007 [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [ 22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][ T1] FSC = 0x07: level 3 translation fault [ 22.991934][ T1] Data abort info: [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 22.991934][ T1] Dumping ftrace buffer: [ 22.991934][ T1] (ftrace buffer empty) [ 22.991934][ T1] Modules linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419 [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT) [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344 [ 22.991934][ T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000 [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820 [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000 [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058 [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004 [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000 [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000 [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530 [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000 [ 22.991934][ T1] Call trace: [ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] hibernation_restore+0x158/0x18c [ 22.991934][ T1] load_image_and_restore+0xb0/0xec [ 22.991934][ T1] software_resume+0xf4/0x19c [ 22.991934][ T1] software_resume_initcall+0x34/0x78 [ 22.991934][ T1] do_one_initcall+0xe8/0x370 [ 22.991934][ T1] do_initcall_level+0xc8/0x19c [ 22.991934][ T1] do_initcalls+0x70/0xc0 [ 22.991934][ T1] do_basic_setup+0x1c/0x28 [ 22.991934][ T1] kernel_init_freeable+0xe0/0x148 [ 22.991934][ T1] kernel_init+0x20/0x1a8 [ 22.991934][ T1] ret_from_fork+0x10/0x20 [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110) [catalin.marinas@arm.com: commit log updated by Mark Rutland]", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23073", "url": "https://ubuntu.com/security/CVE-2026-23073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: Fix memory corruption due to not set vif driver data size The struct ieee80211_vif contains trailing space for vif driver data, when struct ieee80211_vif is allocated, the total memory size that is allocated is sizeof(struct ieee80211_vif) + size of vif driver data. The size of vif driver data is set by each WiFi driver as needed. The RSI911x driver does not set vif driver data size, no trailing space for vif driver data is therefore allocated past struct ieee80211_vif . The RSI911x driver does however use the vif driver data to store its vif driver data structure \"struct vif_priv\". An access to vif->drv_priv leads to access out of struct ieee80211_vif bounds and corruption of some memory. In case of the failure observed locally, rsi_mac80211_add_interface() would write struct vif_priv *vif_info = (struct vif_priv *)vif->drv_priv; vif_info->vap_id = vap_idx. This write corrupts struct fq_tin member struct list_head new_flows . The flow = list_first_entry(head, struct fq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus address, which when accessed causes a crash. The trigger is very simple, boot the machine with init=/bin/sh , mount devtmpfs, sysfs, procfs, and then do \"ip link set wlan0 up\", \"sleep 1\", \"ip link set wlan0 down\" and the crash occurs. Fix this by setting the correct size of vif driver data, which is the size of \"struct vif_priv\", so that memory is allocated and the driver can store its driver data in it, instead of corrupting memory around it.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23133", "url": "https://ubuntu.com/security/CVE-2026-23133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: fix dma_free_coherent() pointer dma_alloc_coherent() allocates a DMA mapped buffer and stores the addresses in XXX_unaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23089", "url": "https://ubuntu.com/security/CVE-2026-23089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free() When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees mixer->id_elems but the controls already added to the card still reference the freed memory. Later when snd_card_register() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read. Call trace: get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381 snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ... snd_card_register+0x4ed/0x6d0 sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025 Fix by calling snd_ctl_remove() for all mixer controls before freeing id_elems. We save the next pointer first because snd_ctl_remove() frees the current element.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23076", "url": "https://ubuntu.com/security/CVE-2026-23076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix potential OOB access in audio mixer handling In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixer_index() and sum_index()). As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]' After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field. This patch addresses those OOB accesses by adding the proper initializations of the loop indices.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71199", "url": "https://ubuntu.com/security/CVE-2025-71199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver at91_adc_interrupt can call at91_adc_touch_data_handler function to start the work by schedule_work(&st->touch_st.workq). If we remove the module which will call at91_adc_remove to make cleanup, it will free indio_dev through iio_device_unregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | at91_adc_workq_handler at91_adc_remove | iio_device_unregister(indio_dev) | //free indio_dev a bit later | | iio_push_to_buffers(indio_dev) | //use indio_dev Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91_adc_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23101", "url": "https://ubuntu.com/security/CVE-2026-23101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: led-class: Only Add LED to leds_list when it is fully ready Before this change the LED was added to leds_list before led_init_core() gets called adding it the list before led_classdev.set_brightness_work gets initialized. This leaves a window where led_trigger_register() of a LED's default trigger will call led_trigger_set() which calls led_set_brightness() which in turn will end up queueing the *uninitialized* led_classdev.set_brightness_work. This race gets hit by the lenovo-thinkpad-t14s EC driver which registers 2 LEDs with a default trigger provided by snd_ctl_led.ko in quick succession. The first led_classdev_register() causes an async modprobe of snd_ctl_led to run and that async modprobe manages to exactly hit the window where the second LED is on the leds_list without led_init_core() being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998 Close the race window by moving the adding of the LED to leds_list to after the led_init_core() call.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23064", "url": "https://ubuntu.com/security/CVE-2026-23064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: avoid possible NULL deref tcf_ife_encode() must make sure ife_encode() does not return NULL. syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166 CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full) Call Trace: ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23119", "url": "https://ubuntu.com/security/CVE-2026-23119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: provide a net pointer to __skb_flow_dissect() After 3cbf4ffba5ee (\"net: plumb network namespace into __skb_flow_dissect\") we have to provide a net pointer to __skb_flow_dissect(), either via skb->dev, skb->sk, or a user provided pointer. In the following case, syzbot was able to cook a bare skb. WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053 Call Trace: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23084", "url": "https://ubuntu.com/security/CVE-2026-23084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list When the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() is set to false, the driver may request the PMAC_ID from the firmware of the network card, and this function will store that PMAC_ID at the provided address pmac_id. This is the contract of this function. However, there is a location within the driver where both pmac_id_valid == false and pmac_id == NULL are being passed. This could result in dereferencing a NULL pointer. To resolve this issue, it is necessary to pass the address of a stub variable to the function.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23124", "url": "https://ubuntu.com/security/CVE-2026-23124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: annotate data-race in ndisc_router_discovery() syzbot found that ndisc_router_discovery() could read and write in6_dev->ra_mtu without holding a lock [1] This looks fine, IFLA_INET6_RA_MTU is best effort. Add READ_ONCE()/WRITE_ONCE() to document the race. Note that we might also reject illegal MTU values (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch. [1] BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... value changed: 0x00000000 -> 0xe5400659", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23121", "url": "https://ubuntu.com/security/CVE-2026-23121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mISDN: annotate data-race around dev->work dev->work can re read locklessly in mISDN_read() and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations. BUG: KCSAN: data-race in mISDN_ioctl / mISDN_read write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [inline] vfs_readv+0x3fb/0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [inline] __se_sys_readv fs/read_write.c:1162 [inline] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000 -> 0x00000001", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23071", "url": "https://ubuntu.com/security/CVE-2026-23071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: Fix race condition in hwspinlock irqsave routine Previously, the address of the shared member '&map->spinlock_flags' was passed directly to 'hwspin_lock_timeout_irqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shared flags variable, potentially corrupting the state for the current lock owner. Fix this by using a local stack variable 'flags' to store the IRQ state temporarily.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23105", "url": "https://ubuntu.com/security/CVE-2026-23105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag This is more of a preventive patch to make the code more consistent and to prevent possible exploits that employ child qlen manipulations on qfq. use cl_is_active instead of relying on the child qdisc's qlen to determine class activation.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23103", "url": "https://ubuntu.com/security/CVE-2026-23103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close) This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause: 1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock. 2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23120", "url": "https://ubuntu.com/security/CVE-2026-23120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: avoid one data-race in l2tp_tunnel_del_work() We should read sk->sk_socket only when dealing with kernel sockets. syzbot reported the following data-race: BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 value changed: 0xffff88811b818000 -> 0x0000000000000000", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23083", "url": "https://ubuntu.com/security/CVE-2026-23083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Don't allow 0 for FOU_ATTR_IPPROTO. fou_udp_recv() has the same problem mentioned in the previous patch. If FOU_ATTR_IPPROTO is set to 0, skb is not freed by fou_udp_recv() nor \"resubmit\"-ted in ip_protocol_deliver_rcu(). Let's forbid 0 for FOU_ATTR_IPPROTO.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23095", "url": "https://ubuntu.com/security/CVE-2026-23095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: Fix skb memleak with inner IP protocol 0. syzbot reported skb memleak below. [0] The repro generated a GUE packet with its inner protocol 0. gue_udp_recv() returns -guehdr->proto_ctype for \"resubmit\" in ip_protocol_deliver_rcu(), but this only works with non-zero protocol number. Let's drop such packets. Note that 0 is a valid number (IPv6 Hop-by-Hop Option). I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT [0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm \"syz.0.17\", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23125", "url": "https://ubuntu.com/security/CVE-2026-23125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key initialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127 The issue is triggered when sctp_auth_asoc_init_active_key() fails in sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the command sequence is currently: - SCTP_CMD_PEER_INIT - SCTP_CMD_TIMER_STOP (T1_INIT) - SCTP_CMD_TIMER_START (T1_COOKIE) - SCTP_CMD_NEW_STATE (COOKIE_ECHOED) - SCTP_CMD_ASSOC_SHKEY - SCTP_CMD_GEN_COOKIE_ECHO If SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while asoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL to be queued by sctp_datamsg_from_user(). Since command interpretation stops on failure, no COOKIE_ECHO should been sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As a result, the DATA chunk can be transmitted together with the COOKIE_ECHO in sctp_outq_flush_data(), leading to the observed issue. Similar to the other places where it calls sctp_auth_asoc_init_active_key() right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting T1_COOKIE. This ensures that if shared key generation fails, authenticated DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT, giving the client another chance to process INIT_ACK and retry key setup.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23099", "url": "https://ubuntu.com/security/CVE-2026-23099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: limit BOND_MODE_8023AD to Ethernet devices BOND_MODE_8023AD makes sense for ARPHRD_ETHER only. syzbot reported: BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline] BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497 CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [inline] __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [inline] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e The buggy address belongs to the variable: lacpdu_mcast_addr+0x0/0x40", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71194", "url": "https://ubuntu.com/security/CVE-2025-71194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock in wait_current_trans() due to ignored transaction type When wait_current_trans() is called during start_transaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfs_blocked_trans_types[] array already defines which transaction types should wait for which transaction states, but this check was missing in wait_current_trans(). This can lead to a deadlock scenario involving two transactions and pending ordered extents: 1. Transaction A is in TRANS_STATE_COMMIT_DOING state 2. A worker processing an ordered extent calls start_transaction() with TRANS_JOIN 3. join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes 5. A new Transaction B is created (TRANS_STATE_RUNNING) 6. The ordered extent from step 2 is added to Transaction B's pending ordered extents 7. Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START 8. The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[] 10. Transaction B is waiting for pending ordered extents to complete 11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B This can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!) Task bstore_kv_sync in btrfs_commit_transaction waiting for ordered extents: __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Task kworker in wait_current_trans waiting for transaction commit: Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30 Fix this by passing the transaction type to wait_current_trans() and checking btrfs_blocked_trans_types[cur_trans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71185", "url": "https://ubuntu.com/security/CVE-2025-71185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23026", "url": "https://ubuntu.com/security/CVE-2026-23026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config() Fix a memory leak in gpi_peripheral_config() where the original memory pointed to by gchan->config could be lost if krealloc() fails. The issue occurs when: 1. gchan->config points to previously allocated memory 2. krealloc() fails and returns NULL 3. The function directly assigns NULL to gchan->config, losing the reference to the original memory 4. The original memory becomes unreachable and cannot be freed Fix this by using a temporary variable to hold the krealloc() result and only updating gchan->config when the allocation succeeds. Found via static analysis and code review.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71188", "url": "https://ubuntu.com/security/CVE-2025-71188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: lpc18xx-dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71163", "url": "https://ubuntu.com/security/CVE-2025-71163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix device leaks on compat bind and unbind Make sure to drop the reference taken when looking up the idxd device as part of the compat bind and unbind sysfs interface.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2025-71190", "url": "https://ubuntu.com/security/CVE-2025-71190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: bcm-sba-raid: fix device leak on probe Make sure to drop the reference taken when looking up the mailbox device during probe on probe failures and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71191", "url": "https://ubuntu.com/security/CVE-2025-71191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: at_hdmac: fix device leak on of_dma_xlate() Make sure to drop the reference taken when looking up the DMA platform device during of_dma_xlate() when releasing channel resources. Note that commit 3832b78b3ec2 (\"dmaengine: at_hdmac: add missing put_device() call in at_dma_xlate()\") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23049", "url": "https://ubuntu.com/security/CVE-2026-23049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel The connector type for the DataImage SCF0700C48GGU18 panel is missing and devm_drm_panel_bridge_add() requires connector type to be set. This leads to a warning and a backtrace in the kernel log and panel does not work: \" WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8 \" The warning is triggered by a check for valid connector type in devm_drm_panel_bridge_add(). If there is no valid connector type set for a panel, the warning is printed and panel is not added. Fill in the missing connector type to fix the warning and make the panel operational once again.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23145", "url": "https://ubuntu.com/security/CVE-2026-23145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref The error branch for ext4_xattr_inode_update_ref forget to release the refcount for iloc.bh. Find this when review code.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-22997", "url": "https://ubuntu.com/security/CVE-2026-22997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is called only when the timer is enabled, we need to call j1939_session_deactivate_activate_next() if we cancelled the timer. Otherwise, refcount for j1939_session leaks, which will later appear as | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2. problem.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23033", "url": "https://ubuntu.com/security/CVE-2026-23033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: omap-dma: fix dma_pool resource leak in error paths The dma_pool created by dma_pool_create() is not destroyed when dma_async_device_register() or of_dma_controller_register() fails, causing a resource leak in the probe error paths. Add dma_pool_destroy() in both error paths to properly release the allocated dma_pool resource.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71196", "url": "https://ubuntu.com/security/CVE-2025-71196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: stm32-usphyc: Fix off by one in probe() The \"index\" variable is used as an index into the usbphyc->phys[] array which has usbphyc->nphys elements. So if it is equal to usbphyc->nphys then it is one element out of bounds. The \"index\" comes from the device tree so it's data that we trust and it's unlikely to be wrong, however it's obviously still worth fixing the bug. Change the > to >=.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71162", "url": "https://ubuntu.com/security/CVE-2025-71162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: tegra-adma: Fix use-after-free A use-after-free bug exists in the Tegra ADMA driver when audio streams are terminated, particularly during XRUN conditions. The issue occurs when the DMA buffer is freed by tegra_adma_terminate_all() before the vchan completion tasklet finishes accessing it. The race condition follows this sequence: 1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegra_adma_terminate_all() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchan_complete() which attempts to access the already-freed memory Since tasklets can execute at any time after being scheduled, there is no guarantee that the buffer will remain valid when vchan_complete() runs. Fix this by properly synchronizing the virtual channel completion: - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegra_adma_synchronize() that calls vchan_synchronize() which kills any pending tasklets and frees any terminated descriptors. Crash logs: [ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0 [ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0 [ 337.427562] Call trace: [ 337.427564] dump_backtrace+0x0/0x320 [ 337.427571] show_stack+0x20/0x30 [ 337.427575] dump_stack_lvl+0x68/0x84 [ 337.427584] print_address_description.constprop.0+0x74/0x2b8 [ 337.427590] kasan_report+0x1f4/0x210 [ 337.427598] __asan_load8+0xa0/0xd0 [ 337.427603] vchan_complete+0x124/0x3b0 [ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0 [ 337.427617] tasklet_action+0x30/0x40 [ 337.427623] __do_softirq+0x1a0/0x5c4 [ 337.427628] irq_exit+0x110/0x140 [ 337.427633] handle_domain_irq+0xa4/0xe0 [ 337.427640] gic_handle_irq+0x64/0x160 [ 337.427644] call_on_irq_stack+0x20/0x4c [ 337.427649] do_interrupt_handler+0x7c/0x90 [ 337.427654] el1_interrupt+0x30/0x80 [ 337.427659] el1h_64_irq_handler+0x18/0x30 [ 337.427663] el1h_64_irq+0x7c/0x80 [ 337.427667] cpuidle_enter_state+0xe4/0x540 [ 337.427674] cpuidle_enter+0x54/0x80 [ 337.427679] do_idle+0x2e0/0x380 [ 337.427685] cpu_startup_entry+0x2c/0x70 [ 337.427690] rest_init+0x114/0x130 [ 337.427695] arch_call_rest_init+0x18/0x24 [ 337.427702] start_kernel+0x380/0x3b4 [ 337.427706] __primary_switched+0xc0/0xc8", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22999", "url": "https://ubuntu.com/security/CVE-2026-22999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: do not free existing class in qfq_change_class() Fixes qfq_change_class() error case. cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23011", "url": "https://ubuntu.com/security/CVE-2026-23011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_gre: make ipgre_header() robust Analog to commit db5b4e39c4e6 (\"ip6_gre: make ip6gre_header() robust\") Over the years, syzbot found many ways to crash the kernel in ipgre_header() [1]. This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ipgre device. [1] skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213 Call Trace: skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23001", "url": "https://ubuntu.com/security/CVE-2026-23001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix possible UAF in macvlan_forward_source() Add RCU protection on (struct macvlan_source_entry)->vlan. Whenever macvlan_hash_del_source() is called, we must clear entry->vlan pointer before RCU grace period starts. This allows macvlan_forward_source() to skip over entries queued for freeing. Note that macvlan_dev are already RCU protected, as they are embedded in a standard netdev (netdev_priv(ndev)). https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23003", "url": "https://ubuntu.com/security/CVE-2026-23003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() Blamed commit did not take care of VLAN encapsulations as spotted by syzbot [1]. Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull(). [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22998", "url": "https://ubuntu.com/security/CVE-2026-22998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec Commit efa56305908b (\"nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs. The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command. Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23037", "url": "https://ubuntu.com/security/CVE-2026-23037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: allow partial RX URB allocation to succeed When es58x_alloc_rx_urbs() fails to allocate the requested number of URBs but succeeds in allocating some, it returns an error code. This causes es58x_open() to return early, skipping the cleanup label 'free_urbs', which leads to the anchored URBs being leaked. As pointed out by maintainer Vincent Mailhol, the driver is designed to handle partial URB allocation gracefully. Therefore, partial allocation should not be treated as a fatal error. Modify es58x_alloc_rx_urbs() to return 0 if at least one URB has been allocated, restoring the intended behavior and preventing the leak in es58x_open().", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23038", "url": "https://ubuntu.com/security/CVE-2026-23038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node() In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak. Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23111", "url": "https://ubuntu.com/security/CVE-2026-23111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate() nft_map_catchall_activate() has an inverted element activity check compared to its non-catchall counterpart nft_mapelem_activate() and compared to what is logically required. nft_map_catchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones. Compare the non-catchall activate callback, which is correct: nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; /* skip active, process inactive */ With the buggy catchall version: nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; /* skip inactive, process active */ The consequence is that when a DELSET operation is aborted, nft_setelem_data_activate() is never called for the catchall element. For NFT_GOTO verdict elements, this means nft_data_hold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free. This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIG_USER_NS and CONFIG_NF_TABLES. Fix by removing the negation so the check matches nft_mapelem_activate(): skip active elements, process inactive ones.", "cve_priority": "high", "cve_public_date": "2026-02-13 14:16:00 UTC" }, { "cve": "CVE-2026-23209", "url": "https://ubuntu.com/security/CVE-2026-23209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source(). With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-37849", "url": "https://ubuntu.com/security/CVE-2025-37849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Tear down vGIC on failed vCPU creation If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU. Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.", "cve_priority": "high", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2026-23074", "url": "https://ubuntu.com/security/CVE-2026-23074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Enforce that teql can only be used as root qdisc Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint. Although not important, I will describe the scenario that unearthed this issue for the curious. GangMin Kim managed to concot a scenario as follows: ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s └── class 1:2 (weight=1, lmax=1514) teql GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23060", "url": "https://ubuntu.com/security/CVE-2026-23060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, crypto_authenc_esn_decrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalk_map_and_copy(), leading to a kernel panic (DoS). Add a minimum AAD length check to fail fast on invalid inputs.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1097.102 -proposed tracker (LP: #2143524)", "", " [ Ubuntu: 5.15.0-176.186 ]", "", " * jammy/linux: 5.15.0-176.186 -proposed tracker (LP: #2143539)", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343)", " - nvmet-tcp: remove boilerplate code", " - SAUCE: Fix skb_vlan_inet_prepare() usage", " - net: update netdev_lock_{type,name}", " - vsock/test: add a final full barrier after run all tests", " - net/mlx5e: Restore destroying state bit after profile cleanup", " - selftests: drv-net: fix RPS mask handling for high CPU numbers", " - ASoC: tlv320adcx140: fix word length", " - textsearch: describe @list member in ts_ops search", " - mm, kfence: describe @slab parameter in __kfence_obj_info()", " - dmaengine: xilinx_dma: Fix uninitialized addr_width when", " \"xlnx,addrwidth\" property is missing", " - phy: broadcom: ns-usb3: Fix Wvoid-pointer-to-enum-cast warning (again)", " - HID: usbhid: paper over wrong bNumDescriptor field", " - ALSA: pcm: Improve the fix for race of buffer access at PCM OSS layer", " - x86/kaslr: Recognize all ZONE_DEVICE users as physaddr consumers", " - phy: rockchip: inno-usb2: fix disconnection in gadget mode", " - phy: rockchip: inno-usb2: fix communication disruption in gadget mode", " - phy: tegra: xusb: Explicitly configure HS_DISCON_LEVEL to 0x7", " - usb: dwc3: Check for USB4 IP_NAME", " - USB: OHCI/UHCI: Add soft dependencies on ehci_platform", " - USB: serial: option: add Telit LE910 MBIM composition", " - USB: serial: ftdi_sio: add support for PICAXE AXE027 cable", " - nvme-pci: disable secondary temp for Wodposit WPBSNM8", " - hrtimer: Fix softirq base check in update_needs_ipi()", " - EDAC/x38: Fix a resource leak in x38_probe1()", " - EDAC/i3200: Fix a resource leak in i3200_probe1()", " - x86/resctrl: Add missing resctrl initialization for Hygon", " - x86/resctrl: Fix memory bandwidth counter width for Hygon", " - mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free", " - drm/nouveau/disp/nv50-: Set lock_core in curs507a_prepare", " - drm/vmwgfx: Fix an error return check in vmw_compat_shader_add()", " - dmaengine: sh: rz-dmac: Fix rz_dmac_terminate_all()", " - dmaengine: ti: dma-crossbar: fix device leak on dra7x route allocation", " - dmaengine: ti: k3-udma: fix device leak on udma lookup", " - posix-clock: introduce posix_clock_context concept", " - Fix memory leak in posix_clock_open()", " - posix-clock: Store file pointer in struct posix_clock_context", " - ptp: Add PHC file mode checks. Allow RO adjtime() without FMODE_WRITE.", " - testptp: add option to shift clock by nanoseconds", " - testptp: Add support for testing ptp_clock_info .adjphase callback", " - selftests/ptp: Add -x option for testing PTP_SYS_OFFSET_EXTENDED", " - selftests/ptp: Add -X option for testing PTP_SYS_OFFSET_PRECISE", " - ptp: add testptp mask test", " - selftest/ptp: update ptp selftest to exercise the gettimex options", " - testptp: Add option to open PHC in readonly mode", " - net: usb: dm9601: remove broken SR9700 support", " - amd-xgbe: avoid misleading per-packet error log", " - netlink: add a proto specification for FOU", " - net: fou: rename the source for linking", " - net: fou: use policy and operation tables generated from the spec", " - comedi: dmm32at: serialize use of paged registers", " - w1: fix redundant counter decrement in w1_attach_slave_device()", " - Revert \"nfc/nci: Add the inconsistency check between the input data", " length and count\"", " - Input: i8042 - add quirks for MECHREVO Wujie 15X Pro", " - Input: i8042 - add quirk for ASUS Zenbook UX425QA_UM425QA", " - scsi: storvsc: Process unsupported MODE_SENSE_10", " - x86/kfence: avoid writing L1TF-vulnerable PTEs", " - staging:iio:adc:ad7280a: Register define cleanup.", " - iio: adc: ad7280a: handle spi_setup() errors in probe()", " - ALSA: usb: Increase volume range that triggers a warning", " - net: hns3: fix wrong GENMASK() for HCLGE_FD_AD_COUNTER_NUM_M", " - net: hns3: fix the HCLGE_FD_AD_NXT_KEY error setting issue", " - usbnet: limit max_mtu based on device's hard_mtu", " - drm/amd/pm: Don't clear SI SMC table when setting power limit", " - drm/amd/pm: Workaround SI powertune issue on Radeon 430 (v2)", " - octeontx2-af: Fix error handling", " - x86: make page fault handling disable interrupts properly", " - of: fix reference count leak in of_alias_scan()", " - iio: adc: ad9467: fix ad9434 vref mask", " - iio: dac: ad5686: add AD5695R to ad5686_chip_info_tbl", " - mmc: rtsx_pci_sdmmc: implement sdmmc_card_busy function", " - wifi: mwifiex: Fix a loop in mwifiex_update_ampdu_rxwinsize()", " - octeontx2: Fix otx2_dma_map_page() error return code", " - slimbus: core: fix runtime PM imbalance on report present", " - perf/x86/intel: Do not enable BTS for guests", " - net/mlx5: Fix memory leak in esw_acl_ingress_lgcy_setup()", " - net: mvpp2: cls: Fix memory leak in mvpp2_ethtool_cls_rule_ins()", " - ipv6: use the right ifindex when replying to icmpv6 from localhost", " - ice: stop counting UDP csum mismatch as rx_errors", " - net/mlx5: Add HW definitions of vport debug counters", " - net/mlx5e: Expose rx_oversize_pkts_buffer counter", " - net/mlx5e: Report rx_discards_phy via rx_dropped", " - net/mlx5e: Account for netdev stats in ndo_get_stats64", " - net: bridge: fix static key check", " - scsi: firewire: sbp-target: Fix overflow in sbp_make_tpg()", " - gpiolib: acpi: use BIT_ULL() for u64 mask in address space handler", " - dma/pool: distinguish between missing and exhausted atomic pools", " - ASoC: fsl: imx-card: Do not force slot width to sample width", " - scsi: be2iscsi: Fix a memory leak in beiscsi_boot_get_sinfo()", " - scsi: qla2xxx: edif: Fix dma_free_coherent() size", " - mptcp: only reset subflow errors when propagated", " - net: Add locking to protect skb->dev access in ip_output", " - comedi: Fix getting range information for subdevices 16 to 255", " - of: platform: Use default match table for /firmware", " - iio: adc: exynos_adc: fix OF populate on driver rebind", " - arm64: dts: rockchip: remove redundant max-link-speed from nanopi-r4s", " - w1: w1_therm: use swap() to make code cleaner", " - dmaengine: stm32: dmamux: fix OF node leak on route allocation failure", " - xfs: set max_agbno to allow sparse alloc of last full inode chunk", " - nvme-fc: rename free_ctrl callback to match name pattern", " - nvme-pci: do not directly handle subsys reset fallout", " - nvme: fix PCIe subsystem reset controller state transition", " - mei: trace: treat reg parameter as string", " - mm/pagewalk: add walk_page_range_vma()", " - wifi: cfg80211: add a work abstraction with special semantics", " - wifi: mac80211: use wiphy work for sdata->work", " - wifi: mac80211: move TDLS work to wiphy work", " - HID: uclogic: Add NULL check in uclogic_input_configured()", " - drm/amdkfd: fix a memory leak in device_queue_manager_init()", " - btrfs: prevent use-after-free on page private data in", " btrfs_subpage_clear_uptodate()", " - net/sched: act_ife: convert comma to semicolon", " - pinctrl: lpass-lpi: implement .get_direction() for the GPIO driver", " - writeback: fix 100% CPU usage when dirtytime_expire_interval is 0", " - mptcp: avoid dup SUB_CLOSED events after disconnect", " - pinctrl: meson: mark the GPIO controller as sleeping", " - wifi: cfg80211: use system_unbound_wq for wiphy work", " - wifi: cfg80211: fix wiphy delayed work queueing", " - wifi: cfg80211: cancel wiphy_work before freeing wiphy", " - wifi: cfg80211: fully move wiphy work to unbound workqueue", " - wifi: cfg80211: init wiphy_work before allocating rfkill fails", " - Linux 5.15.199", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23170", " - drm/imx/tve: fix probe device leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23075", " - can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38408", " - genirq/irq_sim: Initialize work context pointers properly", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2023-54207", " - HID: uclogic: Correct devm device reference for hidinput input_dev name", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2023-53520", " - Bluetooth: Fix hci_suspend_sync crash", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38125", " - net: stmmac: make sure that ptp_rate is not 0 before configuring EST", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-40164", " - usbnet: Fix using smp_processor_id() in preemptible code warnings", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38232", " - NFSD: fix race between nfsd registration and exports_proc", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2023-53662", " - ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup}", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38057", " - espintcp: fix skb leaks", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2023-53421", " - blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68365", " - fs/ntfs3: Initialize allocated memory before use", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68817", " - ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2022-50390", " - drm/ttm: fix undefined behavior in bit shift for", " TTM_TT_FLAG_PRIV_POPULATED", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68211", " - ksm: use range-walk function to jump over holes in", " scan_get_next_rmap_item", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23093", " - ksmbd: smbd: fix dma_unmap_sg() nents", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23078", " - ALSA: scarlett2: Fix buffer overflow in config retrieval", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71186", " - dmaengine: stm32: dmamux: fix device leak on route allocation", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71197", " - w1: therm: Fix off-by-one buffer overflow in alarms_store", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23087", " - scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-40149", " - tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23167", " - nfc: nci: Fix race between rfkill and nci_unregister_device().", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23150", " - nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame().", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23164", " - rocker: fix memory leak in rocker_world_port_post_fini()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23146", " - Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-38591", " - bpf: Reject narrower access to pointer ctx fields", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-68725", " - bpf: Do not let BPF test infra emit invalid GSO types to stack", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23097", " - migrate: correct lock ordering for hugetlb file folios", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23108", " - can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23080", " - can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23061", " - can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23058", " - can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23085", " - irqchip/gic-v3-its: Avoid truncating memory addresses", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23098", " - netrom: fix double-free in nr_route_frame()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23063", " - uacce: ensure safe queue release with state management", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23056", " - uacce: implement mremap in uacce_vm_ops to return -EPERM", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23096", " - uacce: fix cdev handling in the cleanup path", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23091", " - intel_th: fix device leak on output open()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23090", " - slimbus: core: fix device reference leak on report present", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23128", " - arm64: Set __nocfi on swsusp_arch_resume()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23073", " - wifi: rsi: Fix memory corruption due to not set vif driver data size", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23133", " - wifi: ath10k: fix dma_free_coherent() pointer", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23089", " - ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23076", " - ALSA: ctxfi: Fix potential OOB access in audio mixer handling", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71199", " - iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc", " driver", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23101", " - leds: led-class: Only Add LED to leds_list when it is fully ready", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23064", " - net/sched: act_ife: avoid possible NULL deref", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23119", " - bonding: provide a net pointer to __skb_flow_dissect()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23084", " - be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23124", " - ipv6: annotate data-race in ndisc_router_discovery()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23121", " - mISDN: annotate data-race around dev->work", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23071", " - regmap: Fix race condition in hwspinlock irqsave routine", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23105", " - net/sched: qfq: Use cl_is_active to determine whether class is active in", " qfq_rm_from_ag", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23103", " - ipvlan: Make the addrs_lock be per port", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23120", " - l2tp: avoid one data-race in l2tp_tunnel_del_work()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23083", " - fou: Don't allow 0 for FOU_ATTR_IPPROTO.", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23095", " - gue: Fix skb memleak with inner IP protocol 0.", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23125", " - sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23099", " - bonding: limit BOND_MODE_8023AD to Ethernet devices", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71194", " - btrfs: fix deadlock in wait_current_trans() due to ignored transaction", " type", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71185", " - dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23026", " - dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71188", " - dmaengine: lpc18xx-dmamux: fix device leak on route allocation", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71163", " - dmaengine: idxd: fix device leaks on compat bind and unbind", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71190", " - dmaengine: bcm-sba-raid: fix device leak on probe", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71191", " - dmaengine: at_hdmac: fix device leak on of_dma_xlate()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23049", " - drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23145", " - ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-22997", " - net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session", " upon receiving the second rts", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23033", " - dmaengine: omap-dma: fix dma_pool resource leak in error paths", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71196", " - phy: stm32-usphyc: Fix off by one in probe()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2025-71162", " - dmaengine: tegra-adma: Fix use-after-free", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-22999", " - net/sched: sch_qfq: do not free existing class in qfq_change_class()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23011", " - ipv4: ip_gre: make ipgre_header() robust", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23001", " - macvlan: fix possible UAF in macvlan_forward_source()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23003", " - ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-22998", " - nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23037", " - can: etas_es58x: allow partial RX URB allocation to succeed", " * Jammy update: v5.15.199 upstream stable release (LP: #2143343) //", " CVE-2026-23038", " - pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()", " * ADT test for linux package failed with \"fatal: unable to connect to", " git.launchpad.net\" (LP: #2143033)", " - [Packaging] d/t/ubuntu-regression-suite: use https to clone", " * efi: Fix swapped arguments to bsearch() in efi_status_to_*() SAUCE patch", " (LP: #2141276)", " - SAUCE efi: Fix swapped arguments to bsearch() in efi_status_to_*()", " * CVE-2026-23111", " - netfilter: nf_tables: fix inverted genmask check in", " nft_map_catchall_activate()", " * CVE-2026-23209", " - macvlan: fix error recovery in macvlan_common_newlink()", " * CVE-2025-37849", " - KVM: arm64: vgic: Add a non-locking primitive for", " kvm_vgic_vcpu_destroy()", " - KVM: arm64: Tear down vGIC on failed vCPU creation", " * CVE-2026-23074", " - net/sched: Enforce that teql can only be used as root qdisc", " * CVE-2026-23060", " - crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN", " spec", "" ], "package": "linux-kvm", "version": "5.15.0-1097.102", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2143524, 2143539, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143343, 2143033, 2141276 ], "author": "Austin Rhodes ", "date": "Tue, 07 Apr 2026 09:50:23 -0400" } ], "notes": "linux-modules-5.15.0-1097-kvm version '5.15.0-1097.102' (source package linux-kvm version '5.15.0-1097.102') was added. linux-modules-5.15.0-1097-kvm version '5.15.0-1097.102' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1096-kvm. As such we can use the source package version of the removed package, '5.15.0-1096.101', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "netplan-generator", "from_version": { "source_package_name": null, "source_package_version": null, "version": null }, "to_version": { "source_package_name": "netplan.io", "source_package_version": "0.107.1-3ubuntu0.22.04.3", "version": "0.107.1-3ubuntu0.22.04.3" }, "cves": [ { "cve": "CVE-2022-4968", "url": "https://ubuntu.com/security/CVE-2022-4968", "cve_description": "netplan leaks the private key of wireguard to local users. Versions after 1.0 are not affected.", "cve_priority": "medium", "cve_public_date": "2024-06-07 01:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2139598, 1988018, 2020409, 2058031 ], "changes": [ { "cves": [], "log": [ "", " * debian/patches/lp2139598-execute-udev-rules-before-sriov-apply-service.patch:", " execute udev rules before starting sriov apply service (LP: #2139598)", "" ], "package": "netplan.io", "version": "0.107.1-3ubuntu0.22.04.3", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2139598 ], "author": "Robert Malz ", "date": "Tue, 03 Mar 2026 12:18:29 +0100" }, { "cves": [], "log": [ "", " * debian/patches/lp1988018: VF-LAG activation", " Fixes the order in which SR-IOV configuration is performed and", " cooperates with VF-LAG activation (LP: #1988018).", " * debian/patches/lp2020409:", " Enables setting the embedded-switch mode without having to define", " virtual functions (LP: #2020409).", " * debian/libnetplan0.symbols: New symbol _netplan_netdef_get_bond_mode.", "" ], "package": "netplan.io", "version": "0.107.1-3ubuntu0.22.04.2", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1988018, 2020409 ], "author": "Danilo Egea Gondolfo ", "date": "Mon, 07 Oct 2024 10:57:38 +0100" }, { "cves": [ { "cve": "CVE-2022-4968", "url": "https://ubuntu.com/security/CVE-2022-4968", "cve_description": "netplan leaks the private key of wireguard to local users. Versions after 1.0 are not affected.", "cve_priority": "medium", "cve_public_date": "2024-06-07 01:15:00 UTC" } ], "log": [ "", " * Backport netplan.io 0.107.1-3 to 22.04 (LP: #2058031):", " - Support for \"dummy\" (`dummy-devices`) interfaces (LP: 1774203) (!361)", " - Support for \"veth\" (`virtual-ethernets`) interfaces (!368)", " - Add Python bindings for libnetplan (!385)", " - netplan: Handle command exceptions (!334)", " - WPA3 (personal) support (LP: 2023238) (!369)", " - Add all the commands to the bash completion file (LP: 1749869) (!326)", " - New submodule for state manipulation (!379)", " - commands/status: show routes from all routing tables (!390)", " - cli:status: Make rich pretty printing optional (!388)", " - libnetplan: expose dhcp4 and dhcp6 properties (!394)", " - Expose macaddress and DNS configuration from the netdef (!395)", " - libnetplan: expose the routes list in the netdef (!397)", " - NetworkManager: Wireguard private key flag support (!371)", " - Add a netplan_parser_load_keyfile() Python binding (!351)", " - keyfile parser: add support for all tunnel types (LP: 2016473) (!360)", " - parse-nm:wg: add support for reading the listen-port property (!372)", " - parse-nm: add support for VRF devices (!398)", " - Vlan keyfile parser support (!370)", " - Netplan docs rework (!333 & !337)", " - docs: Add a short netplan-everywhere howto (!325)", " - doc: make us of sphinx copybutton plugin (!354)", " - doc: Add Ubuntu Code of Conduct 2.0 (!355)", " - doc: Explanation about 00-network-manager-all.yaml (!378)", " - wifi: add support for WPA3-Enterprise (LP: 2029876) (!402)", " - wifi: support WPA2 and WPA3 Personal simultaneously (!404)", " - added mii-monitor-interval example (!411)", " - docs: Add \"Contribute Documentation\" how-to", " - auth: add support for LEAP and EAP-PWD (!415)", " - tests: Add autopkgtest for (LP: 1959570) (!419)", " - wifi: make it possible to have a psk and an eap password simultaneously", " (!416)", " - doc: Set-up some basic Doxygen project (!423)", " - doc: Make Sphinx to handle autodoxygen project, using breathe (!423)", " - doc: create libnetplan apidoc structure (!423)", " - inc: Start documenting public API (!423)", " - doc: Update 'Netplan everywhere' for 23.10 (!418)", " SECURITY UPDATE: weak permissions on secret files, command injection", " - d/p/lp2065738/0014-libnetplan-use-more-restrictive-file-permissions.patch:", " Use more restrictive file permissions to prevent unprivileged users to", " read sensitive data from back end files (LP: 2065738, 1987842)", " - CVE-2022-4968", " - d/p/lp2066258/0015-libnetplan-escape-control-characters.patch:", " Escape control characters in the parser and double quotes in backend", " files.", " - d/p/lp2066258/0016-backends-escape-file-paths.patch:", " Escape special characters in file paths.", " - d/p/lp2066258/0017-backends-escape-semicolons-in-service-units.patch:", " Escape isolated semicolons in systemd service units. (LP: 2066258)", " - debian/netplan-generator.postinst: Add a postinst maintainer script to", " call the generator. It's needed so the file permissions fixes will be", " applied automatically.", " Bug fixes:", " - Fix FTBFS on Fedora and refresh RPM packaging (!323)", " - parser: validate lacp-rate properly (LP: 1745648) (!324)", " - use meson-make-symlink.sh helper instead of install_symlink() (!327)", " - netplan: cli: fix typo from 'unkown' to 'unknown' (!328)", " - Handle duplication during parser second pass (LP: 2007682) (!329)", " - parse:ovs: Ignore deprecated OpenFlow1.6 protocol (LP: 1963735) (!332)", " - dbus: Build the copy path correctly (!331)", " - tests: add new spread based snapd integration test (!330)", " - Use controlled execution environment, to avoid failure if PATH is unset", " (LP: 1959570) (!336)", " - Some refactoring (!338)", " - netplan: adjust the maximum buffer size to 1MB (!340)", " - parse: use \"--\" with systemd-escape (!347)", " - docs: fix bridge parameters types and add examples (!346)", " - vrfs: skip policies parsing if list is NULL (LP: 2016427) (!341)", " - networkd: plug a memory leak (!344)", " - libnetplan: don't try to read from a NULL file (!342)", " - nm: return if write_routes() fails (!345)", " - parse: plug a memory leak (!348)", " - parse: set the backend on nm-devices to NM (!349)", " - parse: don't point to the wrong node on validation (!343)", " - rtd: set the OS and Python versions explicitly (!357)", " - Fix 8021x eap method parsing (LP: 2016625) (!358)", " - CI: update canonical/setup-lxd to v0.1.1 (!359)", " - CI: fix dch after adding the new 0.106.1 tag (!364)", " - Provide frequency to wpa_supplicant in adhoc mode (LP: 2020754) (!363)", " - Improve the coverage of the memory leak tests (!365)", " - Fix keyfile parsing of wireguard config (!366)", " - routes: fix metric rendering (LP: 2023681) (!367)", " - CI: add DebCI integration test (!362)", " - CI: initial NetworkManager autopkgtests (!374)", " - parse-nm: handle cloned-mac-address special cases (LP: 2026230) (!376)", " - Improve autopkgtest stability with systemd 253 & iproute 6.4 (!377)", " - Fixes for minor issues (!380)", " - tests:integration: Adopt for systemd v254 (Closes: #1041310) (!381)", " - parse: Downgrade NM passthrough warning to debug (!384)", " - Don't drop files with just global values (LP: 2027584) (!382)", " - Fixing Coverity issues (!383)", " - CLI: Refactoring to avoid namespace clash with public bindings (!387)", " - tests: fix test coverage report with newer python-coverage (!389)", " - github: add a scheduled action to run Coverity (!391)", " - github: only run the coverity workflow on our repository (!392)", " - Addressing a few issues found (!393)", " - Wireguard fixes (!352)", " - Fix a memory leak, an assert and an error message (!350)", " - ovs: don't allow peers with the same name (!353)", " - CI: make use of the canonical/setup-lxd action (!356)", " - test:ovs: Avoid NetworkManager taking contol, breaking a test", " - parse: allow COMMON_LINK_HANDLERS for VRFs (!401)", " - util: don't return a placeholder netdef in the iterator (!406)", " - tunnels/validation: do not error out if \"local\" is not defined (!407)", " - tests: add some integration tests without the local address (!407)", " - wireguard: ignore empty endpoints (LP: 2038811) (!414)", " - parse: improve the parsing of access-points (LP: 1809994) (!413)", " - wifi: replace the previously defined AP with the new one (!413)", " - doc: spelling check improvements (!417)", " - Fix permissions on folder '/run/NetworkManager/' (!422)", " - cli:try: avoid linting error for type hints (Closes: #1058524) (!422)", " - nm-parse: always read the PSK into the new psk variable (!416)", " - networkd: fix formatting (!424)", " - networkd: replace deprecated CriticalConnection= by KeepConfiguration=", " (!424)", " - networkd: move KeepConfiguration= into [Network] section", " - apply: bring \"lo\" back up if it's managed by NM (!408)", " - apply: don't assume the NM loopback connection is called \"lo\" (!408)", " Packaging restructuring:", " - Split netplan-generator into separate package to make the Python", " dependency optional.", " - Split python3-netplan bindings into a separate package", " * Add patches for bug fixes from netplan.io 1.0-1 and 1.0.1-1:", " - debian/patches/lp2041727:", " Check if ovsdb-server.service is active before displaying warning", " (LP: 2041727) (!421)", " - d/p/0004-tests-assert-generated-.service-files-in-assert_srio.patch,", " d/p/0005-tests-sriov-test-if-the-generated-netplan-rebind-ser.patch,", " d/p/0006-sriov-don-t-generate-duplicate-entries-in-the-rebind.patch:", " Don't generate duplicate entries in the netplan-sriov-rebind.service", " (!437)", " - d/p/0017-emitter-allow-unicode-characters-in-the-emitter.patch.", " Allow non-ascii characters in the YAML emitter (LP: 2071652) (!485).", " - d/p/0018-parse-do-not-escape-all-non-ascii-bytes.patch.", " Don't escape all non-ascii bytes (!486).", " * Drop patches not required for 22.04:", " - debian/patches/python-limited-stable-api.patch", " - d/p/sru-compat/0013-Keep-old-file-permission-for-backwards-compatibility.patch.", " From now on we want libnetplan to create files with tight permissions.", " * Add patches for SRU backwards compatibility:", " - 0014-Demote-lacp-rate-validation-error-to-warning-for-bac.patch:", " Convert the error to a warning in a new validation for the option", " 'lacp-rate' to prevent breaking existing setups", " * debian/control:", " - Drop python3-rich dependency to Suggests", " - Drop build dependency on systemd-dev", " * debian/netplan.io.preinst:", " - This preinst script is intended to cleanup the .pyc files from", " share/netplan/netplan. This directory is supposed to be removed after", " the upgrade from netplan.io 0.106.1 to 0.107.1, as the Python code", " was moved to it's own python3-netplan package, but it's left behind", " due to Python cached files.", " * Drop changes related to usr-merge and not required for 22.04", " - debian/netplan-generator.install", " - debian/netplan-generator.dirs", " - debian/netplan-generator.postinst", " - debian/netplan-generator.preinst", " * d/netplan-generator.lintian-overrides, d/netplan.io.lintian-overrides:", " - Drop overrides file. It wasn't really silencing any lintian warnings.", "" ], "package": "netplan.io", "version": "0.107.1-3ubuntu0.22.04.1", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2058031 ], "author": "Danilo Egea Gondolfo ", "date": "Fri, 16 Aug 2024 17:59:32 +0100" } ], "notes": "For a newly added package only the three most recent changelog entries are shown.", "is_version_downgrade": false }, { "name": "python3-netplan", "from_version": { "source_package_name": null, "source_package_version": null, "version": null }, "to_version": { "source_package_name": "netplan.io", "source_package_version": "0.107.1-3ubuntu0.22.04.3", "version": "0.107.1-3ubuntu0.22.04.3" }, "cves": [ { "cve": "CVE-2022-4968", "url": "https://ubuntu.com/security/CVE-2022-4968", "cve_description": "netplan leaks the private key of wireguard to local users. Versions after 1.0 are not affected.", "cve_priority": "medium", "cve_public_date": "2024-06-07 01:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2139598, 1988018, 2020409, 2058031 ], "changes": [ { "cves": [], "log": [ "", " * debian/patches/lp2139598-execute-udev-rules-before-sriov-apply-service.patch:", " execute udev rules before starting sriov apply service (LP: #2139598)", "" ], "package": "netplan.io", "version": "0.107.1-3ubuntu0.22.04.3", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2139598 ], "author": "Robert Malz ", "date": "Tue, 03 Mar 2026 12:18:29 +0100" }, { "cves": [], "log": [ "", " * debian/patches/lp1988018: VF-LAG activation", " Fixes the order in which SR-IOV configuration is performed and", " cooperates with VF-LAG activation (LP: #1988018).", " * debian/patches/lp2020409:", " Enables setting the embedded-switch mode without having to define", " virtual functions (LP: #2020409).", " * debian/libnetplan0.symbols: New symbol _netplan_netdef_get_bond_mode.", "" ], "package": "netplan.io", "version": "0.107.1-3ubuntu0.22.04.2", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1988018, 2020409 ], "author": "Danilo Egea Gondolfo ", "date": "Mon, 07 Oct 2024 10:57:38 +0100" }, { "cves": [ { "cve": "CVE-2022-4968", "url": "https://ubuntu.com/security/CVE-2022-4968", "cve_description": "netplan leaks the private key of wireguard to local users. Versions after 1.0 are not affected.", "cve_priority": "medium", "cve_public_date": "2024-06-07 01:15:00 UTC" } ], "log": [ "", " * Backport netplan.io 0.107.1-3 to 22.04 (LP: #2058031):", " - Support for \"dummy\" (`dummy-devices`) interfaces (LP: 1774203) (!361)", " - Support for \"veth\" (`virtual-ethernets`) interfaces (!368)", " - Add Python bindings for libnetplan (!385)", " - netplan: Handle command exceptions (!334)", " - WPA3 (personal) support (LP: 2023238) (!369)", " - Add all the commands to the bash completion file (LP: 1749869) (!326)", " - New submodule for state manipulation (!379)", " - commands/status: show routes from all routing tables (!390)", " - cli:status: Make rich pretty printing optional (!388)", " - libnetplan: expose dhcp4 and dhcp6 properties (!394)", " - Expose macaddress and DNS configuration from the netdef (!395)", " - libnetplan: expose the routes list in the netdef (!397)", " - NetworkManager: Wireguard private key flag support (!371)", " - Add a netplan_parser_load_keyfile() Python binding (!351)", " - keyfile parser: add support for all tunnel types (LP: 2016473) (!360)", " - parse-nm:wg: add support for reading the listen-port property (!372)", " - parse-nm: add support for VRF devices (!398)", " - Vlan keyfile parser support (!370)", " - Netplan docs rework (!333 & !337)", " - docs: Add a short netplan-everywhere howto (!325)", " - doc: make us of sphinx copybutton plugin (!354)", " - doc: Add Ubuntu Code of Conduct 2.0 (!355)", " - doc: Explanation about 00-network-manager-all.yaml (!378)", " - wifi: add support for WPA3-Enterprise (LP: 2029876) (!402)", " - wifi: support WPA2 and WPA3 Personal simultaneously (!404)", " - added mii-monitor-interval example (!411)", " - docs: Add \"Contribute Documentation\" how-to", " - auth: add support for LEAP and EAP-PWD (!415)", " - tests: Add autopkgtest for (LP: 1959570) (!419)", " - wifi: make it possible to have a psk and an eap password simultaneously", " (!416)", " - doc: Set-up some basic Doxygen project (!423)", " - doc: Make Sphinx to handle autodoxygen project, using breathe (!423)", " - doc: create libnetplan apidoc structure (!423)", " - inc: Start documenting public API (!423)", " - doc: Update 'Netplan everywhere' for 23.10 (!418)", " SECURITY UPDATE: weak permissions on secret files, command injection", " - d/p/lp2065738/0014-libnetplan-use-more-restrictive-file-permissions.patch:", " Use more restrictive file permissions to prevent unprivileged users to", " read sensitive data from back end files (LP: 2065738, 1987842)", " - CVE-2022-4968", " - d/p/lp2066258/0015-libnetplan-escape-control-characters.patch:", " Escape control characters in the parser and double quotes in backend", " files.", " - d/p/lp2066258/0016-backends-escape-file-paths.patch:", " Escape special characters in file paths.", " - d/p/lp2066258/0017-backends-escape-semicolons-in-service-units.patch:", " Escape isolated semicolons in systemd service units. (LP: 2066258)", " - debian/netplan-generator.postinst: Add a postinst maintainer script to", " call the generator. It's needed so the file permissions fixes will be", " applied automatically.", " Bug fixes:", " - Fix FTBFS on Fedora and refresh RPM packaging (!323)", " - parser: validate lacp-rate properly (LP: 1745648) (!324)", " - use meson-make-symlink.sh helper instead of install_symlink() (!327)", " - netplan: cli: fix typo from 'unkown' to 'unknown' (!328)", " - Handle duplication during parser second pass (LP: 2007682) (!329)", " - parse:ovs: Ignore deprecated OpenFlow1.6 protocol (LP: 1963735) (!332)", " - dbus: Build the copy path correctly (!331)", " - tests: add new spread based snapd integration test (!330)", " - Use controlled execution environment, to avoid failure if PATH is unset", " (LP: 1959570) (!336)", " - Some refactoring (!338)", " - netplan: adjust the maximum buffer size to 1MB (!340)", " - parse: use \"--\" with systemd-escape (!347)", " - docs: fix bridge parameters types and add examples (!346)", " - vrfs: skip policies parsing if list is NULL (LP: 2016427) (!341)", " - networkd: plug a memory leak (!344)", " - libnetplan: don't try to read from a NULL file (!342)", " - nm: return if write_routes() fails (!345)", " - parse: plug a memory leak (!348)", " - parse: set the backend on nm-devices to NM (!349)", " - parse: don't point to the wrong node on validation (!343)", " - rtd: set the OS and Python versions explicitly (!357)", " - Fix 8021x eap method parsing (LP: 2016625) (!358)", " - CI: update canonical/setup-lxd to v0.1.1 (!359)", " - CI: fix dch after adding the new 0.106.1 tag (!364)", " - Provide frequency to wpa_supplicant in adhoc mode (LP: 2020754) (!363)", " - Improve the coverage of the memory leak tests (!365)", " - Fix keyfile parsing of wireguard config (!366)", " - routes: fix metric rendering (LP: 2023681) (!367)", " - CI: add DebCI integration test (!362)", " - CI: initial NetworkManager autopkgtests (!374)", " - parse-nm: handle cloned-mac-address special cases (LP: 2026230) (!376)", " - Improve autopkgtest stability with systemd 253 & iproute 6.4 (!377)", " - Fixes for minor issues (!380)", " - tests:integration: Adopt for systemd v254 (Closes: #1041310) (!381)", " - parse: Downgrade NM passthrough warning to debug (!384)", " - Don't drop files with just global values (LP: 2027584) (!382)", " - Fixing Coverity issues (!383)", " - CLI: Refactoring to avoid namespace clash with public bindings (!387)", " - tests: fix test coverage report with newer python-coverage (!389)", " - github: add a scheduled action to run Coverity (!391)", " - github: only run the coverity workflow on our repository (!392)", " - Addressing a few issues found (!393)", " - Wireguard fixes (!352)", " - Fix a memory leak, an assert and an error message (!350)", " - ovs: don't allow peers with the same name (!353)", " - CI: make use of the canonical/setup-lxd action (!356)", " - test:ovs: Avoid NetworkManager taking contol, breaking a test", " - parse: allow COMMON_LINK_HANDLERS for VRFs (!401)", " - util: don't return a placeholder netdef in the iterator (!406)", " - tunnels/validation: do not error out if \"local\" is not defined (!407)", " - tests: add some integration tests without the local address (!407)", " - wireguard: ignore empty endpoints (LP: 2038811) (!414)", " - parse: improve the parsing of access-points (LP: 1809994) (!413)", " - wifi: replace the previously defined AP with the new one (!413)", " - doc: spelling check improvements (!417)", " - Fix permissions on folder '/run/NetworkManager/' (!422)", " - cli:try: avoid linting error for type hints (Closes: #1058524) (!422)", " - nm-parse: always read the PSK into the new psk variable (!416)", " - networkd: fix formatting (!424)", " - networkd: replace deprecated CriticalConnection= by KeepConfiguration=", " (!424)", " - networkd: move KeepConfiguration= into [Network] section", " - apply: bring \"lo\" back up if it's managed by NM (!408)", " - apply: don't assume the NM loopback connection is called \"lo\" (!408)", " Packaging restructuring:", " - Split netplan-generator into separate package to make the Python", " dependency optional.", " - Split python3-netplan bindings into a separate package", " * Add patches for bug fixes from netplan.io 1.0-1 and 1.0.1-1:", " - debian/patches/lp2041727:", " Check if ovsdb-server.service is active before displaying warning", " (LP: 2041727) (!421)", " - d/p/0004-tests-assert-generated-.service-files-in-assert_srio.patch,", " d/p/0005-tests-sriov-test-if-the-generated-netplan-rebind-ser.patch,", " d/p/0006-sriov-don-t-generate-duplicate-entries-in-the-rebind.patch:", " Don't generate duplicate entries in the netplan-sriov-rebind.service", " (!437)", " - d/p/0017-emitter-allow-unicode-characters-in-the-emitter.patch.", " Allow non-ascii characters in the YAML emitter (LP: 2071652) (!485).", " - d/p/0018-parse-do-not-escape-all-non-ascii-bytes.patch.", " Don't escape all non-ascii bytes (!486).", " * Drop patches not required for 22.04:", " - debian/patches/python-limited-stable-api.patch", " - d/p/sru-compat/0013-Keep-old-file-permission-for-backwards-compatibility.patch.", " From now on we want libnetplan to create files with tight permissions.", " * Add patches for SRU backwards compatibility:", " - 0014-Demote-lacp-rate-validation-error-to-warning-for-bac.patch:", " Convert the error to a warning in a new validation for the option", " 'lacp-rate' to prevent breaking existing setups", " * debian/control:", " - Drop python3-rich dependency to Suggests", " - Drop build dependency on systemd-dev", " * debian/netplan.io.preinst:", " - This preinst script is intended to cleanup the .pyc files from", " share/netplan/netplan. This directory is supposed to be removed after", " the upgrade from netplan.io 0.106.1 to 0.107.1, as the Python code", " was moved to it's own python3-netplan package, but it's left behind", " due to Python cached files.", " * Drop changes related to usr-merge and not required for 22.04", " - debian/netplan-generator.install", " - debian/netplan-generator.dirs", " - debian/netplan-generator.postinst", " - debian/netplan-generator.preinst", " * d/netplan-generator.lintian-overrides, d/netplan.io.lintian-overrides:", " - Drop overrides file. It wasn't really silencing any lintian warnings.", "" ], "package": "netplan.io", "version": "0.107.1-3ubuntu0.22.04.1", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2058031 ], "author": "Danilo Egea Gondolfo ", "date": "Fri, 16 Aug 2024 17:59:32 +0100" } ], "notes": "For a newly added package only the three most recent changelog entries are shown.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-5.15.0-1096-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1096.101", "version": "5.15.0-1096.101" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-5.15.0-1096-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1096.101", "version": "5.15.0-1096.101" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-kvm-headers-5.15.0-1096", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1096.101", "version": "5.15.0-1096.101" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-modules-5.15.0-1096-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1096.101", "version": "5.15.0-1096.101" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "notes": "Changelog diff for Ubuntu 22.04 jammy image from release image serial 20260408 to 20260422", "from_series": "jammy", "to_series": "jammy", "from_serial": "20260408", "to_serial": "20260422", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }