{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-5.15.0-1111-kvm", "linux-image-5.15.0-1111-kvm", "linux-kvm-headers-5.15.0-1111", "linux-modules-5.15.0-1111-kvm" ], "removed": [ "linux-headers-5.15.0-1109-kvm", "linux-image-5.15.0-1109-kvm", "linux-kvm-headers-5.15.0-1109", "linux-modules-5.15.0-1109-kvm" ], "diff": [ "libbrotli1", "linux-headers-kvm", "linux-image-kvm", "linux-kvm", "snapd", "ubuntu-advantage-tools", "ubuntu-pro-client", "ubuntu-pro-client-l10n" ] } }, "diff": { "deb": [ { "name": "libbrotli1", "from_version": { "source_package_name": "brotli", "source_package_version": "1.0.9-2build6", "version": "1.0.9-2build6" }, "to_version": { "source_package_name": "brotli", "source_package_version": "1.0.9-2ubuntu0.1", "version": "1.0.9-2ubuntu0.1" }, "cves": [ { "cve": "CVE-2026-111497", "url": "https://ubuntu.com/security/CVE-2026-111497", "cve_description": "A buffer overflow vulnerability in the Brotli decoder (c/dec/decode.c) in Google Brotli versions 1.0.3 through 1.2.0 on all platforms allows a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code using a crafted Brotli-compressed stream. Users need to update any Brotli libraries or binaries between 1.0.3 through 1.2.0 to the latest available version: 1.0.10 or 1.1.1 or 1.2.1.", "cve_priority": "high", "cve_public_date": "2026-10-22 14:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-111497", "url": "https://ubuntu.com/security/CVE-2026-111497", "cve_description": "A buffer overflow vulnerability in the Brotli decoder (c/dec/decode.c) in Google Brotli versions 1.0.3 through 1.2.0 on all platforms allows a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code using a crafted Brotli-compressed stream. Users need to update any Brotli libraries or binaries between 1.0.3 through 1.2.0 to the latest available version: 1.0.10 or 1.1.1 or 1.2.1.", "cve_priority": "high", "cve_public_date": "2026-10-22 14:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: DoS or code exec via buffer overflow", " - debian/patches/CVE-2026-111497.patch: Detect and report invalid stream", " earlier. in c/dec/decode.c, c/include/brotli/decode.h.", " - CVE-2026-111497", "" ], "package": "brotli", "version": "1.0.9-2ubuntu0.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Sun, 25 Oct 2026 13:50:48 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1109.105", "version": "5.15.0.1109.105" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1111.107", "version": "5.15.0.1111.107" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1111", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1111.107", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Alessio Faina ", "date": "Fri, 16 Oct 2026 10:17:45 +0200" }, { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1110", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1110.106", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Alessio Faina ", "date": "Mon, 28 Sep 2026 15:12:05 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1109.105", "version": "5.15.0.1109.105" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1111.107", "version": "5.15.0.1111.107" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1111", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1111.107", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Alessio Faina ", "date": "Fri, 16 Oct 2026 10:17:45 +0200" }, { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1110", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1110.106", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Alessio Faina ", "date": "Mon, 28 Sep 2026 15:12:05 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1109.105", "version": "5.15.0.1109.105" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1111.107", "version": "5.15.0.1111.107" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1111", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1111.107", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Alessio Faina ", "date": "Fri, 16 Oct 2026 10:17:45 +0200" }, { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1110", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1110.106", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Alessio Faina ", "date": "Mon, 28 Sep 2026 15:12:05 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "snapd", "from_version": { "source_package_name": "snapd", "source_package_version": "2.76.3+ubuntu22.04.1", "version": "2.76.3+ubuntu22.04.1" }, "to_version": { "source_package_name": "snapd", "source_package_version": "2.77.1+ubuntu22.04.1", "version": "2.77.1+ubuntu22.04.1" }, "cves": [ { "cve": "CVE-2024-5300", "url": "https://ubuntu.com/security/CVE-2024-5300", "cve_description": "An access control bypass and information disclosure vulnerability exists in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules located in /etc/apparmor.d/abstractions/nss-systemd (inherited via ) inadvertently permit strictly confined snap applications, which lack the privileged account-control interface, to interact directly with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. On systems where the systemd-userdbd service is installed and operational, the service fails to distinguish between an unconfined root user on the host system and a restricted root user running within a snap application's sandbox (such as a daemon or configuration hook). Because systemd-userdbd returns \"complete\" user records—including sensitive hashed user passwords from /etc/shadow—when queried by a process running as root, a compromised or malicious strictly confined snap executing code as root can successfully query the Varlink interface to retrieve all system password hashes, bypassing intended snap sandbox restrictions. This issue is mitigated by the fact that systemd-userdbd is not installed by default on standard Ubuntu deployments.", "cve_priority": "medium", "cve_public_date": "2026-07-21 15:16:00 UTC" }, { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" }, { "cve": "CVE-2024-5300", "url": "https://ubuntu.com/security/CVE-2024-5300", "cve_description": "An access control bypass and information disclosure vulnerability exists in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules located in /etc/apparmor.d/abstractions/nss-systemd (inherited via ) inadvertently permit strictly confined snap applications, which lack the privileged account-control interface, to interact directly with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. On systems where the systemd-userdbd service is installed and operational, the service fails to distinguish between an unconfined root user on the host system and a restricted root user running within a snap application's sandbox (such as a daemon or configuration hook). Because systemd-userdbd returns \"complete\" user records—including sensitive hashed user passwords from /etc/shadow—when queried by a process running as root, a compromised or malicious strictly confined snap executing code as root can successfully query the Varlink interface to retrieve all system password hashes, bypassing intended snap sandbox restrictions. This issue is mitigated by the fact that systemd-userdbd is not installed by default on standard Ubuntu deployments.", "cve_priority": "medium", "cve_public_date": "2026-07-21 15:16:00 UTC" }, { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2158102, 2072331, 2110510, 2143934, 2160691, 2161982, 2158301, 2159940, 2157692, 2067006, 2157692, 2067006, 2154498, 2147606, 2148544, 2139213, 2125344, 2150683, 2152908, 1966067, 2110368, 2110368, 2144666, 2146337, 2147207, 2143882 ], "changes": [ { "cves": [], "log": [ "", " * New upstream release, LP: #2158102", " - Fix undo of unlink-component after its snap revision was discarded", " - interfaces: power-control | allow reading all battery state files", "" ], "package": "snapd", "version": "2.77.1+ubuntu22.04.1", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2158102 ], "author": "Ernest Lotter ", "date": "Wed, 02 Sep 2026 14:39:12 +0200" }, { "cves": [], "log": [ "", " - Account for differences in names of the binaries in the snapd FIPS", " build", " - Add code to calculate canonical subject name hash", " - Add commands for debugging or accessing snap mount namespaces", " - Add helpers for listing and iterating device mediation groups", " - Add package ebpf with helpers wrapping eBPF exposed objects with", " dependency on github.com/cilium/ebpf", " - Add secondary prerequisites task that acts as the synchronization", " point, which ensures that a snap's prerequisites are available", " before it's installed", " - Add support for shell conditional syntax in envs", " - Added /usr/share/{man,help,info} to system-packages-doc", " - asserts: add validation-sets confdb-schema builtin", " - asserts: ensure that compatibility labels are strings", " - asserts: extend on-classic constraints to accept \"distro/variant\",", " \"distro/*\", and \"distro/\" under a new snap-declaration format 7", " - asserts: validate serial in newDeviceIDFromString", " - Bump github.com/canonical/go-efilib to v1.8.0 to include fixes for", " efivars probe", " - confdb: add validation-sets handler and fix data loss when writing", " to new schemas or accounts", " - confdb: fix bug on reading uneven lists", " - confdb: literal subkeys are sorted after placeholders", " - confdb: run observe-view-* hooks after commit", " - confdb: support Encode/Decode for builtins", " - confdb: support sign-only external keypair backends", " - core-initrd: add missing libbpf and systemd dlopen dependencies,", " and increase mount burst", " - Drop task logs for delayed effects", " - During snap removal, clear-snap task errors early if there are", " user mounts in snap data dirs", " - Enable reverts to trigger a seed refresh", " - Ensure profiles are setup before running prepare-{slot, plug}*", " hooks", " - Ensure that prereqs created by initial refresh run before create-", " recovery-system", " - Exclude Georgian from translation linting", " - experimental features: graduate layouts, classic-preserves-xdg-", " runtime-dir, refresh-app-awareness, and dbus-activation features", " - experimental features: warn when setting graduated or default-", " enabled experimental features and do not store settings for", " graduated features", " - Expose individual certs as well as c_rehash emulation", " - Extend autogen with explicit --sysconfdir", " - External keypair manager: add shared external key manager", " implementation", " - External keypair manager: refactor GPG and external keypair", " managers to use extKeypairMgrImpl", " - External keypair manager: support external OPENPGP signing in", " ExternalKeypairManager", " - FDE: add post install actions API", " - FDE: add reprovision API", " - FDE: add reprovision recovery key generation API", " - FDE: add reseal check after snapd refresh", " - FDE: allow reprovision without factory reset", " - FDE: change makebootable part of the boot package to not take", " install observers as parameters", " - FDE: extend storage-encrypted system information", " - FDE: make reprovision only seal", " - FDE: remove all tmp keyslots on error", " - FDE: remove check for unchanged authentication options", " - FDE: run post install checks during auto repair", " - Filter seed-refresh based on model and seed presence", " - Fix failing snap remove when there are snapctl created mounts", " under snap global data dirs", " - Fix postNotices to validate before locking state", " - Guard the ensure check from running on classic", " - Implement remodeling fully in terms of updates", " - Implement ShutDown for HookManager", " - Include variables SNAP_APP_NAME, and when applicable", " SNAP_APP_COMMON_ID, SNAP_APP_DESKTOP_FILE and SNAP_APP_BUS_NAME in", " snap application environments", " - interfaces: add xdg-portal-permission-store interface", " - interfaces: allow gtk css in subdirectories", " - interfaces: allow systemd networkd link property changes via D-Bus", " - interfaces: allow the systemd networkctl command", " - interfaces: allow Wine to execute files accessed via the Document", " Portal", " - interfaces: apparmor-observe | add interface", " - interfaces: attempt to fix content with parallel installs", " - interfaces: devlxd | fix access for LXD containers", " - interfaces: docker | allow connecting to system-wide docker on", " classic", " - interfaces: grant default access to memory.high in a snap's cgroup", " - interfaces: iscsi-initiator | allow access to /var/lib/iscsi/nodes", " - interfaces: kernel-sched-ext-control | add the kernel sched-ext", " control interface implementation", " - interfaces: make polkit and upower implicit on Core systems only", " - interfaces: open-iscsi | add missing state paths", " - interfaces: opengl | expose wsl libraries", " - interfaces: u2f-devices | add atkey PID and relative VID support", " - List dir contents on failure to remove snap base data dir", " - List non-snapctl mounts in snap data dirs", " - LP: #2072331 Validate map keys in JSON config values", " - LP: #2110510 Interfaces: allow reading of /proc/self/smaps_rollup", " - LP: #2143934 Interfaces: network-control, network-manager | allow", " missing resolve1 link setters", " - LP: #2160691 Security logging: strip trailing whitespace from", " audit netlink message payload", " - LP: #2161982 Interfaces: vsock | add interface for VM guest", " services", " - Make arguments of debug mount-namespace consistent with other", " debug commands", " - Make bootloader logging less verbose", " - Make cert manager garbage check run after symlink migration", " - Make secondary prerequisite synchronization task handle same-", " change retries", " - mkversion.sh: do describe in worktrees too", " - multi-entry snapd: merge snap and snapd binaries", " - multi-entry snapd: move debug device-cgroup implementation file", " under cmd/snapd/cli", " - multi-entry snapd: move snap-gpio-helper sources around before", " transitioning to multi-entry dispatch", " - multi-entry snapd: move snapd-apparmor sources to a dedicated tool", " location", " - multi-entry snapd: move source files around in preparation for", " snapd/snap merge", " - multi-entry snapd: move the snap-preseed sources around in", " preparation", " - multi-entry snapd: move the sources of snapctl and snap-exec in", " preparation for the multi-entry dispatch", " - Never create seed refresh tasks during a remodel", " - packaging: assign a default label for /tmp/snap-private-tmp and", " set it during installation", " - packaging: build deb with Go 1.23 for noble and jammy, Go 1.22 for", " focal", " - packaging: drop SNAP_TAGS", " - packaging: drop symlinks for opensuse 15.5/15.6 packaging", " - packaging: fix service startup during install and session-agent", " socket handling on Ubuntu 26.04+", " - packaging: fix stderr redirection", " - packaging: restore gbp.conf output directory for Ubuntu 26.04", " builds", " - packaging: switch to apparmor 5.x with 5 ABI", " - packaging: update bundled AppArmor to 5.0.2 and accept the 5.0 ABI", " when running as deb", " - packaging: use a relative symlink for snapctl and update steam-", " support udev rules", " - Preserve component in hook security tags", " - Prevent removal of seed-refresh snaps when seed-refresh is enabled", " - Refactor base-declaration into 1st class builtin assertion", " - Refactor how the is-originating-from-snap-command advisory check", " works", " - Refactor prerequisites task handler to enable proper seed-refresh", " integration", " - Reintroduce fdstore helpers", " - remote device management: add task to validate request messages", " - remote device management: apply management messages, queue", " response messages, and improve sequencing and redelivery handling", " - Remove osutil unused AtomicWriteFollow flag", " - Remove xerrors dependency", " - Reuse existing seed-refresh implementation for free during single-", " path installation", " - Rework how SnapSetup.SnapPath is used", " - seccomp: allow rseq_slice_yield", " - security logging: add seclog API for administrative actions and", " token create/remove events", " - security logging: add security logging for adding, updating and", " removing a snapd user", " - Set target hostname from install-mode", " - snap-confine: improve loading of BPF programs, retry on failures", " to collect verifier logs", " - snap-confine: use profile and flags= in snap-confine and snap-", " update-ns' AppArmor profiles", " - snap-confine: work around kernel mnt_ns_loop() ordering bug on", " 6.18.x", " - snap: add debug command for listing currently mediated devices for", " a given snap", " - snap: fix self-managed cgroup support checks", " - snap: report hidden file access for paths allowed by home when", " prompting is active", " - snap: report read-only file access for paths allowed by system-", " package-doc", " - snapctl async support: add --format json to snap tasks to be", " consistent with snapctl", " - snapctl async support: add snapctl tasks command", " - snapctl async support: async feature negotiation between snap", " client and daemon", " - snapctl async support: fix snapctl is-ready exit codes", " - snapctl async support: re-enable snapctl async functionality", " - snapshots: restore preserves snapctl created mounts", " - snapshots: save excludes all mount points", " - Support ca-certificate.crt only systems like core26", " - Turn on quota-groups by default", " - Use 0755 for certificate generation directories", " - Use CreateTemp for NewAtomicFile tmp file creation", " - Verify cached downloads in the do path and detect obvious", " corruption", "" ], "package": "snapd", "version": "2.77+ubuntu22.04", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2072331, 2110510, 2143934, 2160691, 2161982 ], "author": "Sergio Cazzolato ", "date": "Fri, 24 Jul 2026 20:45:05 -0300" }, { "cves": [], "log": [ "", " * New upstream release, LP: #2158301", " - FDE: support keyboard configuration at install-time for first-boot", " - FDE: re-enable passphrases/PINs at install-time", " - FDE: require volumes authentication if HWROT is missing", " - FDE: bump secboot to rev 457b03a16d19", " - FDE: use new secboot API for reprovision TPM", " - Cross-distro: modify SELinux policy to use", " init_named_socket_activation() for allowing systemd to start snapd", " through socket activation", " - packaging: make sure that usr/bin/snap is built with correct build", " tags on debian sid", " - Ensure profiles are setup before running prepare-{slot, plug}*", " hooks", "" ], "package": "snapd", "version": "2.76.3", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2158301 ], "author": "Katie May ", "date": "Tue, 07 Jul 2026 10:06:48 +0200" }, { "cves": [], "log": [ "", " * New upstream release, LP: #2159940", " - interfaces: steam-support, docker-support | fix mountinfo denial", "" ], "package": "snapd", "version": "2.76.2", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2159940 ], "author": "Katie May ", "date": "Tue, 07 Jul 2026 08:38:51 +0200" }, { "cves": [ { "cve": "CVE-2024-5300", "url": "https://ubuntu.com/security/CVE-2024-5300", "cve_description": "An access control bypass and information disclosure vulnerability exists in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules located in /etc/apparmor.d/abstractions/nss-systemd (inherited via ) inadvertently permit strictly confined snap applications, which lack the privileged account-control interface, to interact directly with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. On systems where the systemd-userdbd service is installed and operational, the service fails to distinguish between an unconfined root user on the host system and a restricted root user running within a snap application's sandbox (such as a daemon or configuration hook). Because systemd-userdbd returns \"complete\" user records—including sensitive hashed user passwords from /etc/shadow—when queried by a process running as root, a compromised or malicious strictly confined snap executing code as root can successfully query the Varlink interface to retrieve all system password hashes, bypassing intended snap sandbox restrictions. This issue is mitigated by the fact that systemd-userdbd is not installed by default on standard Ubuntu deployments.", "cve_priority": "medium", "cve_public_date": "2026-07-21 15:16:00 UTC" }, { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" } ], "log": [ "", " * New upstream release, LP: #2157692", " - LP: #2067006 CVE-2024-5300", " - CVE-2026-3888", "" ], "package": "snapd", "version": "2.76.1", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2157692, 2067006 ], "author": "Ernest Lotter ", "date": "Thu, 25 Jun 2026 13:09:05 +0200" }, { "cves": [ { "cve": "CVE-2024-5300", "url": "https://ubuntu.com/security/CVE-2024-5300", "cve_description": "An access control bypass and information disclosure vulnerability exists in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules located in /etc/apparmor.d/abstractions/nss-systemd (inherited via ) inadvertently permit strictly confined snap applications, which lack the privileged account-control interface, to interact directly with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. On systems where the systemd-userdbd service is installed and operational, the service fails to distinguish between an unconfined root user on the host system and a restricted root user running within a snap application's sandbox (such as a daemon or configuration hook). Because systemd-userdbd returns \"complete\" user records—including sensitive hashed user passwords from /etc/shadow—when queried by a process running as root, a compromised or malicious strictly confined snap executing code as root can successfully query the Varlink interface to retrieve all system password hashes, bypassing intended snap sandbox restrictions. This issue is mitigated by the fact that systemd-userdbd is not installed by default on standard Ubuntu deployments.", "cve_priority": "medium", "cve_public_date": "2026-07-21 15:16:00 UTC" }, { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" } ], "log": [ "", " * New upstream release, LP: #2157692", " - LP: #2067006 CVE-2024-5300", " - CVE-2026-3888", " - SNAPDENG-36017", "" ], "package": "snapd", "version": "2.76.1", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2157692, 2067006 ], "author": "Ernest Lotter ", "date": "Sat, 20 Jun 2026 10:27:54 +0200" }, { "cves": [], "log": [ "", " * New upstream release, LP: #2154498", " - assertions: add helper for validating integrity data", " - assertions: drop incorrect/non-standard Ed25519 support", " - confdb: allow only API admin read access to confdb secrets", " - confdb: block concurrent confdb accesses", " - confdb: block concurrent snapctl accesses to configuration", " database", " - confdb: check for ephemeral data when missing save-view hook on", " commit", " - confdb: ignore not-found errors in confdb-schema refreshes", " - confdb: support --wait-for timeouts when accessing confdb", " - core-initrd: add group referenced in udev rules", " - core-initrd: add libbpf dependency to initramfs", " - core-initrd: add missing libbpf dependency in 24.04 packaging", " - core-initrd: ensure audio is a system group", " - core-initrd: fix /boot/uboot mount with u-boot env in dedicated", " partition", " - core-initrd: increase mount burst from 5 to 128 for faster boot", " - core-initrd: sync partition udev rules with the ones in core-base", " - core-initrd: sync with latest upload to snappy-dev PPA", " - core-initrd: synchronize changelogs with latest PPA upload", " - core-initrd: update changelog with latest PPA upload", " - core-initrd: add nfnetlink module to fix nf netlink", " socket speed regression (Ubuntu Core only)", " - cross-distro: allow snapd to manipulate systemd unit files in", " SELinux policy", " - cross-distro: FIPS bootstrap and dispatch via snap-fips-dispatch", " - desktop: fix common ID selection with multiple desktop plugs", " - FDE: allow user mode on core in secboot TPM handling", " - FDE: bump go-efilib dependency", " - FDE: bump secboot to rev cdcb64992e54 for FDE fixes", " - FDE: deprecate check-pin/passphrase API endpoints", " - LP: #2147606 FDE: give inactive state on classic", " - FDE: improve tracing for OP-TEE probing", " - FDE: move auto-repair logic to overlord/fdestate and provide state", " - FDE: update secboot for TPM/FDE bug fixes including Intel HAP and", " recovery key parsing", " - FDE: use any primary key matching digest when adding a keyslot", " - FDE: use ignore action for preinstall check in VM", " - interfaces: bluez | drop explicit deny send_destination in D-Bus", " configuration", " - interfaces: conditionally deny /proc/self/mountinfo to suppress Go", " 1.25+ denials", " - interfaces: custom-device | fix for-device validation panic on", " non-string value", " - interfaces: disallow auto-connect to parallel installs", " - interfaces: docker | make plug implicit on classic systems", " - interfaces: ignore errors in disconnect hooks during explicit snap", " disconnect", " - interfaces: mediatek-accel | add plug interface base declaration", " - interfaces: microceph-support | suppress noisy sudo denial audit", " logs", " - interfaces: podman | add new interface for podman socket access", " - interfaces: pulseaudio | fix security tag syntax inconsistency", " - interfaces: raw-usb | allow USB device enumeration on Fairphone 5", " with NexDock", " - interfaces: restore auto-connections on failed refresh undo", " - LP: #2148544 interfaces: bool-file | support deep SoC sysfs paths", " for LED brightness", " - LP: #2139213 packaging: make Ubuntu 16.04 packaging dep17", " compliant", " - packaging: add cross-distro build script and instructions", " - packaging: add openSUSE 16.0 spread support", " - packaging: Debian build improvements", " - packaging: default openSUSE to /var/lib/snapd/snap and sync from", " downstream", " - packaging: drop transitional packages only for Ubuntu 26.04", " (Resolute)", " - packaging: fix Launchpad FIPS build detection for snapd-fips job", " - packaging: refactor and clean up snapd.mk, standardize test-data", " directories", " - packaging: switch to golang-github-chai2010-gettext-go-dev", " - packaging: update bundled AppArmor 4.1.7 (snapd snap only)", " - prompting: escape paths in prompt constraints", " - prompting: improve API error handling and validation", " - prompting: improve error message when no handler service is", " present", " - prompting: re-enable the prompting notice backend", " - prompting: respond with full user-allowed permission set", " - prompting: validate permissions while unmarshalling", " - remote device management: implement dispatch-mgmt-messages task", " with sequencing support", " - LP: #2125344 snap: avoid empty channel forwarding message", " - LP: #2150683 snap: clarify snap install help text for --classic", " and --devmode", " - LP: #2152908 snap: print complex attributes in snap interface", " --attrs output", " - snap: add run-inhibit hint and inhibit info when a snap is", " disabled", " - snap: allow removing a snap and its base at the same time", " - snap: display detailed component information in snap info", " - snap: extend AlreadyInstalledError to multiple snaps and", " components", " - snap: extend set-quota command options description with accepted", " value formats", " - snap: implement snap delta command for computing snap deltas", " - snap: improve consistency for snap install when some snaps are", " already installed", " - snap: show hint in snap list that a snap has components", " - snap-confine: allow inheriting unix sockets from snaps", " - snap-confine: allow linking to libm in AppArmor profile", " - snap-confine: fix out-of-bounds read in mountinfo parser for", " partial escape sequences", " - snap-confine: harden bpffs mount with nosuid, nodev, noexec flags", " - snap-confine: remove experimental persistent per-user mount", " namespace feature", " - snap-confine: set FD_CLOEXEC on file descriptors returned by BPF", " helpers", " - snap-confine: support transparent_hugepage in AppArmor profile", " - snap-confine: use strchr after NUL-terminating in infofile parser", " - snap-update-ns: switch to a multi-pass process for constructing", " and updating mount namespaces", " - RemoveMountUnitFile now unmounts even if mount unit file is", " missing", " - Add explicit mount phase during single-reboot refresh to fix undo", " of kernel refreshes", " - Add security audit logging subsystem", " - Add base prioritized AppArmmor snippets for strictly confined or", " jailed snaps", " - Allow openshell snap to use experimental daemon-scope: user", " - Allow configuring mount unit options based on filesystem type", " - Allow equals signs in uevent values in netlink parser", " - Also bind-mount directories modified by kmod backend during", " preseed", " - Clean up potentially corrupted files during snap download undo", " - Complete the bootloader environment implementation", " - Copy integrity data files during snap install", " - Create hook for seed refresh mode", " - Create removal tasks for old seed-refresh seeds", " - Dispatch systemctl commands asynchronously when calling Stop()", " - Ensure /tmp/.X11-unix created inside mount namespace has correct", " permissions", " - Ensure exclusive changes conflict with refresh/revert", " - Ensure existing snap confinement flags are not dropped when", " installing or removing components", " - Export ubuntu-boot-state filename constant from bootloader package", " - Fix duplicate removal of apps under $SNAP_MOUNT_DIR/bin", " - Fix integration between prerequisites task and seed-refresh mode", " - Fix split-refresh overwriting provided lane", " - Fix use of umask in GetListener for socket activation", " - Ignore net.ErrClosed during daemon shutdown", " - Implement ResolveValidationSetsEnforcementError in terms of one", " call", " - Improve snapctl install consistency when components are already", " installed", " - Inject seed creation tasks into snap refresh flow", " - Introduce system options for custom certificates on Ubuntu Core", " - Keep idle services with activation units stopped on reload", " - List snap components in snap-debug-info via debug-tools", " - Look at gadget.yaml instead of marker file to determine ubootpart", " usage", " - LP: #1966067 Skip redundant xdg-settings confirmation prompt when", " setting is already correct", " - LP: #2110368 Fix component installation for private snaps via", " snapctl", " - LP: #2110368 Fix download of private snap components by setting", " UserID", " - LP: #2144666 Fix mount namespace updates with synthetic bind", " mounts on same target paths", " - LP: #2146337 Improve handling of failed downloads and retain", " partial files for resume", " - LP: #2147207 Fix snap enable/disable cycle forgetting components", " - Make run-inhibit hint for kill-snap-apps task based on kill reason", " - Merge content-provider prerequisite updates into seed-refresh", " - Move SortServices into Backend.StartServices", " - Move state to client change conversion to ctlcmd package", " - Omit misleading \"try to refresh snapd\" suggestion for ISA-related", " errors", " - Only create link-component tasks when needed during refresh to", " existing revision", " - Reconfigure piboot bootloader on gadget refreshes to preserve", " os_prefix", " - Reduce the number of AppArmor profile regenerations during snap", " operations", " - Refactor seed-refresh ownership to devicestate", " - Regenerate certificate database on remodels", " - Remove obsolete FIXME comment in VersionCompare", " - Remove unused GenerateDmVerityData helper from snap/integrity", " - Rename and document error type for ISA assumes flags", " - Restart snapd from daemon.Stop to improve restart reliability", " - Restart stopped services on error in stopSnapServices for", " transactionality", " - Simplify certificate-db updates on model-base refresh/installs", " - Support racing Loop and Stop correctly in overlord", " - Support sending file descriptors to systemd via sd_notify", " - Unroll CPU-heavy recursive function in snap state handlers", " - Update seccomp syscalls list for kernel 7.1.0", " - Use change ID to prevent nested seed-refresh spawned by", " prerequisites", " - Validate content interface plug target directories exist for", " core26+ snaps", " - Validate layout paths exist in snap tree for snaps using bare or", " core26+", "" ], "package": "snapd", "version": "2.76", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2154498, 2147606, 2148544, 2139213, 2125344, 2150683, 2152908, 1966067, 2110368, 2110368, 2144666, 2146337, 2147207 ], "author": "Ernest Lotter ", "date": "Thu, 28 May 2026 20:00:16 +0200" }, { "cves": [], "log": [ "", " * New upstream release, LP: #2143882", " - Interfaces: network-setup-*| allow running python binaries from", " the base on UC26+", " - Cross-distro: modify SELinux policy to allow mounting on", " /var/snap//", " - Fix potential task deadlock by considering all tasks in a lane", " that might be waiting for a reboot when processing delayed", " security backend effects", "" ], "package": "snapd", "version": "2.75.2", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2143882 ], "author": "Katie May ", "date": "Mon, 30 Mar 2026 17:06:36 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "ubuntu-advantage-tools", "from_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "37.2ubuntu~22.04.1", "version": "37.2ubuntu~22.04.1" }, "to_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "38ubuntu0~22.04", "version": "38ubuntu0~22.04" }, "cves": [ { "cve": "CVE-2026-9494", "url": "https://ubuntu.com/security/CVE-2026-9494", "cve_description": "An information disclosure vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client validates Ubuntu Pro APT credentials by executing /usr/lib/apt/apt-helper using the download-file command. During this process, the secret bearer token is embedded directly in the cleartext URL component passed via the command-line arguments (argv), resulting in a URL format such as https://bearer:@esm.ubuntu.com/.../. On systems utilizing a default-mounted /proc file system where process-hiding mitigations (such as hidepid) are disabled, an unprivileged local attacker can monitor system processes and read the sensitive bearer token directly from /proc/cmdline while the helper process is actively running. This leaked token can subsequently be used to gain unauthorized access to the victim's Ubuntu Pro or Expanded Security Maintenance (ESM) repositories.", "cve_priority": "medium", "cve_public_date": "2026-07-16 13:16:00 UTC" }, { "cve": "CVE-2026-11386", "url": "https://ubuntu.com/security/CVE-2026-11386", "cve_description": "An input validation and injection vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client constructs APT source files (such as /etc/apt/sources.list.d/ubuntu-.list or their DEB822 equivalents) using data received directly from the contract server response via the directives.suites[] and directives.aptURL fields. Because the client utilizes Python's str.format() to write these files without performing escaping, validation, or newline character filtering, a malicious or tampered contract response containing embedded newline (\\n) characters can successfully inject arbitrary, attacker-controlled deb configuration lines into root-owned APT sources. When combined with the unvalidated additionalPackages[] field—which is passed positionally into a root-executed apt-get install command—an attacker capable of spoofing or manipulating the contract response (e.g., via a compromised internal infrastructure, an intercepted connection utilizing a trusted CA, or local logical bugs) can force the client to fetch and install malicious packages. This ultimately leads to arbitrary code execution with root privileges on the affected system. This component is preinstalled on supported Ubuntu Server releases and auto-attaches by default on cloud provider Ubuntu Pro images.", "cve_priority": "high", "cve_public_date": "2026-07-16 13:16:00 UTC" }, { "cve": "CVE-2026-12391", "url": "https://ubuntu.com/security/CVE-2026-12391", "cve_description": "An insecure symlink following vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools) within the pro collect-logs command framework. The utility creates or utilizes predictable temporary file paths or user-accessible log directories when gathering diagnostic information without verifying the file type or ownership. An unprivileged local attacker can exploit this behavior by creating a symbolic link (symlink) at a predictable destination path pointing to an arbitrary, root-readable file (such as /etc/shadow or private files within /root). When a root administrator or operator subsequently executes the pro collect-logs command, the tool follows the user-controlled symlink, reads the target file, and compresses its contents into the resulting diagnostic support archive. Because the output archive remains readable by the unprivileged user, the attacker can extract and read the sensitive root-owned files, leading to a complete information disclosure of system secrets.", "cve_priority": "medium", "cve_public_date": "2026-07-16 13:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2131292, 2129712 ], "changes": [ { "cves": [ { "cve": "CVE-2026-9494", "url": "https://ubuntu.com/security/CVE-2026-9494", "cve_description": "An information disclosure vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client validates Ubuntu Pro APT credentials by executing /usr/lib/apt/apt-helper using the download-file command. During this process, the secret bearer token is embedded directly in the cleartext URL component passed via the command-line arguments (argv), resulting in a URL format such as https://bearer:@esm.ubuntu.com/.../. On systems utilizing a default-mounted /proc file system where process-hiding mitigations (such as hidepid) are disabled, an unprivileged local attacker can monitor system processes and read the sensitive bearer token directly from /proc/cmdline while the helper process is actively running. This leaked token can subsequently be used to gain unauthorized access to the victim's Ubuntu Pro or Expanded Security Maintenance (ESM) repositories.", "cve_priority": "medium", "cve_public_date": "2026-07-16 13:16:00 UTC" }, { "cve": "CVE-2026-11386", "url": "https://ubuntu.com/security/CVE-2026-11386", "cve_description": "An input validation and injection vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client constructs APT source files (such as /etc/apt/sources.list.d/ubuntu-.list or their DEB822 equivalents) using data received directly from the contract server response via the directives.suites[] and directives.aptURL fields. Because the client utilizes Python's str.format() to write these files without performing escaping, validation, or newline character filtering, a malicious or tampered contract response containing embedded newline (\\n) characters can successfully inject arbitrary, attacker-controlled deb configuration lines into root-owned APT sources. When combined with the unvalidated additionalPackages[] field—which is passed positionally into a root-executed apt-get install command—an attacker capable of spoofing or manipulating the contract response (e.g., via a compromised internal infrastructure, an intercepted connection utilizing a trusted CA, or local logical bugs) can force the client to fetch and install malicious packages. This ultimately leads to arbitrary code execution with root privileges on the affected system. This component is preinstalled on supported Ubuntu Server releases and auto-attaches by default on cloud provider Ubuntu Pro images.", "cve_priority": "high", "cve_public_date": "2026-07-16 13:16:00 UTC" }, { "cve": "CVE-2026-12391", "url": "https://ubuntu.com/security/CVE-2026-12391", "cve_description": "An insecure symlink following vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools) within the pro collect-logs command framework. The utility creates or utilizes predictable temporary file paths or user-accessible log directories when gathering diagnostic information without verifying the file type or ownership. An unprivileged local attacker can exploit this behavior by creating a symbolic link (symlink) at a predictable destination path pointing to an arbitrary, root-readable file (such as /etc/shadow or private files within /root). When a root administrator or operator subsequently executes the pro collect-logs command, the tool follows the user-controlled symlink, reads the target file, and compresses its contents into the resulting diagnostic support archive. Because the output archive remains readable by the unprivileged user, the attacker can extract and read the sensitive root-owned files, leading to a complete information disclosure of system secrets.", "cve_priority": "medium", "cve_public_date": "2026-07-16 13:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Information disclosure", " - Remove credentials out of argv into apt's own auth.conf.d facility.", " - CVE-2026-9494", " * SECURITY UPDATE: Improper input validation", " - enforce StrictStringDataValue to applicable fields in directives", " - reject newline, carriage return, spaces, and shell meta characters", " in StrictStringDataValue", " - CVE-2026-11386", " * SECURITY UPDATE: Symlink attack", " - reject symlink log files in user-controlled directory trees during", " pro collect-logs", " - restrict pro collect-logs generated support archive permission to", " root only", " - CVE-2026-12391", "" ], "package": "ubuntu-advantage-tools", "version": "37.2ubuntu~22.04.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Eduardo Barretto ", "date": "Mon, 06 Jul 2026 15:36:19 +0200" }, { "cves": [], "log": [ "", " * d/apparmor/ubuntu_pro_esm_cache.jinja2: fix \"DENIED\" messages when", " devicetree exists (LP: #2131292)", "" ], "package": "ubuntu-advantage-tools", "version": "37.2ubuntu~22.04", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2131292 ], "author": "Renan Rodrigo ", "date": "Tue, 07 Apr 2026 15:24:25 -0300" }, { "cves": [], "log": [ "", " * Backport 37.1ubuntu0 to jammy (LP: #2129712)", "" ], "package": "ubuntu-advantage-tools", "version": "37.1ubuntu0~22.04", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2129712 ], "author": "Renan Rodrigo ", "date": "Mon, 27 Oct 2025 09:42:11 -0300" } ], "notes": null, "is_version_downgrade": true }, { "name": "ubuntu-pro-client", "from_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "37.2ubuntu~22.04.1", "version": "37.2ubuntu~22.04.1" }, "to_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "38ubuntu0~22.04", "version": "38ubuntu0~22.04" }, "cves": [ { "cve": "CVE-2026-9494", "url": "https://ubuntu.com/security/CVE-2026-9494", "cve_description": "An information disclosure vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client validates Ubuntu Pro APT credentials by executing /usr/lib/apt/apt-helper using the download-file command. During this process, the secret bearer token is embedded directly in the cleartext URL component passed via the command-line arguments (argv), resulting in a URL format such as https://bearer:@esm.ubuntu.com/.../. On systems utilizing a default-mounted /proc file system where process-hiding mitigations (such as hidepid) are disabled, an unprivileged local attacker can monitor system processes and read the sensitive bearer token directly from /proc/cmdline while the helper process is actively running. This leaked token can subsequently be used to gain unauthorized access to the victim's Ubuntu Pro or Expanded Security Maintenance (ESM) repositories.", "cve_priority": "medium", "cve_public_date": "2026-07-16 13:16:00 UTC" }, { "cve": "CVE-2026-11386", "url": "https://ubuntu.com/security/CVE-2026-11386", "cve_description": "An input validation and injection vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client constructs APT source files (such as /etc/apt/sources.list.d/ubuntu-.list or their DEB822 equivalents) using data received directly from the contract server response via the directives.suites[] and directives.aptURL fields. Because the client utilizes Python's str.format() to write these files without performing escaping, validation, or newline character filtering, a malicious or tampered contract response containing embedded newline (\\n) characters can successfully inject arbitrary, attacker-controlled deb configuration lines into root-owned APT sources. When combined with the unvalidated additionalPackages[] field—which is passed positionally into a root-executed apt-get install command—an attacker capable of spoofing or manipulating the contract response (e.g., via a compromised internal infrastructure, an intercepted connection utilizing a trusted CA, or local logical bugs) can force the client to fetch and install malicious packages. This ultimately leads to arbitrary code execution with root privileges on the affected system. This component is preinstalled on supported Ubuntu Server releases and auto-attaches by default on cloud provider Ubuntu Pro images.", "cve_priority": "high", "cve_public_date": "2026-07-16 13:16:00 UTC" }, { "cve": "CVE-2026-12391", "url": "https://ubuntu.com/security/CVE-2026-12391", "cve_description": "An insecure symlink following vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools) within the pro collect-logs command framework. The utility creates or utilizes predictable temporary file paths or user-accessible log directories when gathering diagnostic information without verifying the file type or ownership. An unprivileged local attacker can exploit this behavior by creating a symbolic link (symlink) at a predictable destination path pointing to an arbitrary, root-readable file (such as /etc/shadow or private files within /root). When a root administrator or operator subsequently executes the pro collect-logs command, the tool follows the user-controlled symlink, reads the target file, and compresses its contents into the resulting diagnostic support archive. Because the output archive remains readable by the unprivileged user, the attacker can extract and read the sensitive root-owned files, leading to a complete information disclosure of system secrets.", "cve_priority": "medium", "cve_public_date": "2026-07-16 13:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2131292, 2129712 ], "changes": [ { "cves": [ { "cve": "CVE-2026-9494", "url": "https://ubuntu.com/security/CVE-2026-9494", "cve_description": "An information disclosure vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client validates Ubuntu Pro APT credentials by executing /usr/lib/apt/apt-helper using the download-file command. During this process, the secret bearer token is embedded directly in the cleartext URL component passed via the command-line arguments (argv), resulting in a URL format such as https://bearer:@esm.ubuntu.com/.../. On systems utilizing a default-mounted /proc file system where process-hiding mitigations (such as hidepid) are disabled, an unprivileged local attacker can monitor system processes and read the sensitive bearer token directly from /proc/cmdline while the helper process is actively running. This leaked token can subsequently be used to gain unauthorized access to the victim's Ubuntu Pro or Expanded Security Maintenance (ESM) repositories.", "cve_priority": "medium", "cve_public_date": "2026-07-16 13:16:00 UTC" }, { "cve": "CVE-2026-11386", "url": "https://ubuntu.com/security/CVE-2026-11386", "cve_description": "An input validation and injection vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client constructs APT source files (such as /etc/apt/sources.list.d/ubuntu-.list or their DEB822 equivalents) using data received directly from the contract server response via the directives.suites[] and directives.aptURL fields. Because the client utilizes Python's str.format() to write these files without performing escaping, validation, or newline character filtering, a malicious or tampered contract response containing embedded newline (\\n) characters can successfully inject arbitrary, attacker-controlled deb configuration lines into root-owned APT sources. When combined with the unvalidated additionalPackages[] field—which is passed positionally into a root-executed apt-get install command—an attacker capable of spoofing or manipulating the contract response (e.g., via a compromised internal infrastructure, an intercepted connection utilizing a trusted CA, or local logical bugs) can force the client to fetch and install malicious packages. This ultimately leads to arbitrary code execution with root privileges on the affected system. This component is preinstalled on supported Ubuntu Server releases and auto-attaches by default on cloud provider Ubuntu Pro images.", "cve_priority": "high", "cve_public_date": "2026-07-16 13:16:00 UTC" }, { "cve": "CVE-2026-12391", "url": "https://ubuntu.com/security/CVE-2026-12391", "cve_description": "An insecure symlink following vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools) within the pro collect-logs command framework. The utility creates or utilizes predictable temporary file paths or user-accessible log directories when gathering diagnostic information without verifying the file type or ownership. An unprivileged local attacker can exploit this behavior by creating a symbolic link (symlink) at a predictable destination path pointing to an arbitrary, root-readable file (such as /etc/shadow or private files within /root). When a root administrator or operator subsequently executes the pro collect-logs command, the tool follows the user-controlled symlink, reads the target file, and compresses its contents into the resulting diagnostic support archive. Because the output archive remains readable by the unprivileged user, the attacker can extract and read the sensitive root-owned files, leading to a complete information disclosure of system secrets.", "cve_priority": "medium", "cve_public_date": "2026-07-16 13:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Information disclosure", " - Remove credentials out of argv into apt's own auth.conf.d facility.", " - CVE-2026-9494", " * SECURITY UPDATE: Improper input validation", " - enforce StrictStringDataValue to applicable fields in directives", " - reject newline, carriage return, spaces, and shell meta characters", " in StrictStringDataValue", " - CVE-2026-11386", " * SECURITY UPDATE: Symlink attack", " - reject symlink log files in user-controlled directory trees during", " pro collect-logs", " - restrict pro collect-logs generated support archive permission to", " root only", " - CVE-2026-12391", "" ], "package": "ubuntu-advantage-tools", "version": "37.2ubuntu~22.04.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Eduardo Barretto ", "date": "Mon, 06 Jul 2026 15:36:19 +0200" }, { "cves": [], "log": [ "", " * d/apparmor/ubuntu_pro_esm_cache.jinja2: fix \"DENIED\" messages when", " devicetree exists (LP: #2131292)", "" ], "package": "ubuntu-advantage-tools", "version": "37.2ubuntu~22.04", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2131292 ], "author": "Renan Rodrigo ", "date": "Tue, 07 Apr 2026 15:24:25 -0300" }, { "cves": [], "log": [ "", " * Backport 37.1ubuntu0 to jammy (LP: #2129712)", "" ], "package": "ubuntu-advantage-tools", "version": "37.1ubuntu0~22.04", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2129712 ], "author": "Renan Rodrigo ", "date": "Mon, 27 Oct 2025 09:42:11 -0300" } ], "notes": null, "is_version_downgrade": true }, { "name": "ubuntu-pro-client-l10n", "from_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "37.2ubuntu~22.04.1", "version": "37.2ubuntu~22.04.1" }, "to_version": { "source_package_name": "ubuntu-advantage-tools", "source_package_version": "38ubuntu0~22.04", "version": "38ubuntu0~22.04" }, "cves": [ { "cve": "CVE-2026-9494", "url": "https://ubuntu.com/security/CVE-2026-9494", "cve_description": "An information disclosure vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client validates Ubuntu Pro APT credentials by executing /usr/lib/apt/apt-helper using the download-file command. During this process, the secret bearer token is embedded directly in the cleartext URL component passed via the command-line arguments (argv), resulting in a URL format such as https://bearer:@esm.ubuntu.com/.../. On systems utilizing a default-mounted /proc file system where process-hiding mitigations (such as hidepid) are disabled, an unprivileged local attacker can monitor system processes and read the sensitive bearer token directly from /proc/cmdline while the helper process is actively running. This leaked token can subsequently be used to gain unauthorized access to the victim's Ubuntu Pro or Expanded Security Maintenance (ESM) repositories.", "cve_priority": "medium", "cve_public_date": "2026-07-16 13:16:00 UTC" }, { "cve": "CVE-2026-11386", "url": "https://ubuntu.com/security/CVE-2026-11386", "cve_description": "An input validation and injection vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client constructs APT source files (such as /etc/apt/sources.list.d/ubuntu-.list or their DEB822 equivalents) using data received directly from the contract server response via the directives.suites[] and directives.aptURL fields. Because the client utilizes Python's str.format() to write these files without performing escaping, validation, or newline character filtering, a malicious or tampered contract response containing embedded newline (\\n) characters can successfully inject arbitrary, attacker-controlled deb configuration lines into root-owned APT sources. When combined with the unvalidated additionalPackages[] field—which is passed positionally into a root-executed apt-get install command—an attacker capable of spoofing or manipulating the contract response (e.g., via a compromised internal infrastructure, an intercepted connection utilizing a trusted CA, or local logical bugs) can force the client to fetch and install malicious packages. This ultimately leads to arbitrary code execution with root privileges on the affected system. This component is preinstalled on supported Ubuntu Server releases and auto-attaches by default on cloud provider Ubuntu Pro images.", "cve_priority": "high", "cve_public_date": "2026-07-16 13:16:00 UTC" }, { "cve": "CVE-2026-12391", "url": "https://ubuntu.com/security/CVE-2026-12391", "cve_description": "An insecure symlink following vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools) within the pro collect-logs command framework. The utility creates or utilizes predictable temporary file paths or user-accessible log directories when gathering diagnostic information without verifying the file type or ownership. An unprivileged local attacker can exploit this behavior by creating a symbolic link (symlink) at a predictable destination path pointing to an arbitrary, root-readable file (such as /etc/shadow or private files within /root). When a root administrator or operator subsequently executes the pro collect-logs command, the tool follows the user-controlled symlink, reads the target file, and compresses its contents into the resulting diagnostic support archive. Because the output archive remains readable by the unprivileged user, the attacker can extract and read the sensitive root-owned files, leading to a complete information disclosure of system secrets.", "cve_priority": "medium", "cve_public_date": "2026-07-16 13:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2131292, 2129712 ], "changes": [ { "cves": [ { "cve": "CVE-2026-9494", "url": "https://ubuntu.com/security/CVE-2026-9494", "cve_description": "An information disclosure vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client validates Ubuntu Pro APT credentials by executing /usr/lib/apt/apt-helper using the download-file command. During this process, the secret bearer token is embedded directly in the cleartext URL component passed via the command-line arguments (argv), resulting in a URL format such as https://bearer:@esm.ubuntu.com/.../. On systems utilizing a default-mounted /proc file system where process-hiding mitigations (such as hidepid) are disabled, an unprivileged local attacker can monitor system processes and read the sensitive bearer token directly from /proc/cmdline while the helper process is actively running. This leaked token can subsequently be used to gain unauthorized access to the victim's Ubuntu Pro or Expanded Security Maintenance (ESM) repositories.", "cve_priority": "medium", "cve_public_date": "2026-07-16 13:16:00 UTC" }, { "cve": "CVE-2026-11386", "url": "https://ubuntu.com/security/CVE-2026-11386", "cve_description": "An input validation and injection vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client constructs APT source files (such as /etc/apt/sources.list.d/ubuntu-.list or their DEB822 equivalents) using data received directly from the contract server response via the directives.suites[] and directives.aptURL fields. Because the client utilizes Python's str.format() to write these files without performing escaping, validation, or newline character filtering, a malicious or tampered contract response containing embedded newline (\\n) characters can successfully inject arbitrary, attacker-controlled deb configuration lines into root-owned APT sources. When combined with the unvalidated additionalPackages[] field—which is passed positionally into a root-executed apt-get install command—an attacker capable of spoofing or manipulating the contract response (e.g., via a compromised internal infrastructure, an intercepted connection utilizing a trusted CA, or local logical bugs) can force the client to fetch and install malicious packages. This ultimately leads to arbitrary code execution with root privileges on the affected system. This component is preinstalled on supported Ubuntu Server releases and auto-attaches by default on cloud provider Ubuntu Pro images.", "cve_priority": "high", "cve_public_date": "2026-07-16 13:16:00 UTC" }, { "cve": "CVE-2026-12391", "url": "https://ubuntu.com/security/CVE-2026-12391", "cve_description": "An insecure symlink following vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools) within the pro collect-logs command framework. The utility creates or utilizes predictable temporary file paths or user-accessible log directories when gathering diagnostic information without verifying the file type or ownership. An unprivileged local attacker can exploit this behavior by creating a symbolic link (symlink) at a predictable destination path pointing to an arbitrary, root-readable file (such as /etc/shadow or private files within /root). When a root administrator or operator subsequently executes the pro collect-logs command, the tool follows the user-controlled symlink, reads the target file, and compresses its contents into the resulting diagnostic support archive. Because the output archive remains readable by the unprivileged user, the attacker can extract and read the sensitive root-owned files, leading to a complete information disclosure of system secrets.", "cve_priority": "medium", "cve_public_date": "2026-07-16 13:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Information disclosure", " - Remove credentials out of argv into apt's own auth.conf.d facility.", " - CVE-2026-9494", " * SECURITY UPDATE: Improper input validation", " - enforce StrictStringDataValue to applicable fields in directives", " - reject newline, carriage return, spaces, and shell meta characters", " in StrictStringDataValue", " - CVE-2026-11386", " * SECURITY UPDATE: Symlink attack", " - reject symlink log files in user-controlled directory trees during", " pro collect-logs", " - restrict pro collect-logs generated support archive permission to", " root only", " - CVE-2026-12391", "" ], "package": "ubuntu-advantage-tools", "version": "37.2ubuntu~22.04.1", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Eduardo Barretto ", "date": "Mon, 06 Jul 2026 15:36:19 +0200" }, { "cves": [], "log": [ "", " * d/apparmor/ubuntu_pro_esm_cache.jinja2: fix \"DENIED\" messages when", " devicetree exists (LP: #2131292)", "" ], "package": "ubuntu-advantage-tools", "version": "37.2ubuntu~22.04", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2131292 ], "author": "Renan Rodrigo ", "date": "Tue, 07 Apr 2026 15:24:25 -0300" }, { "cves": [], "log": [ "", " * Backport 37.1ubuntu0 to jammy (LP: #2129712)", "" ], "package": "ubuntu-advantage-tools", "version": "37.1ubuntu0~22.04", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2129712 ], "author": "Renan Rodrigo ", "date": "Mon, 27 Oct 2025 09:42:11 -0300" } ], "notes": null, "is_version_downgrade": true } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-5.15.0-1111-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1109.114", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1111.116", "version": "5.15.0-1111.116" }, "cves": [ { "cve": "CVE-2025-68190", "url": "https://ubuntu.com/security/CVE-2025-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked() kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-46242", "url": "https://ubuntu.com/security/CVE-2026-46242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s \"*pprev = next\" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays.", "cve_priority": "high", "cve_public_date": "2026-05-30 13:16:00 UTC" }, { "cve": "CVE-2025-38349", "url": "https://ubuntu.com/security/CVE-2025-38349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: don't decrement ep refcount while still holding the ep mutex Jann Horn points out that epoll is decrementing the ep refcount and then doing a mutex_unlock(&ep->mtx); afterwards. That's very wrong, because it can lead to a use-after-free. That pattern is actually fine for the very last reference, because the code in question will delay the actual call to \"ep_free(ep)\" until after it has unlocked the mutex. But it's wrong for the much subtler \"next to last\" case when somebody *else* may also be dropping their reference and free the ep while we're still using the mutex. Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion. A mutex \"unlock\" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up. See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics: \t\"mutex_unlock() may access the mutex structure even after it has \t internally released the lock already - so it's not safe for \t another context to acquire the mutex and assume that the \t mutex_unlock() context is not using the structure anymore\" So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops _their_ reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it. Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole _point_ of refcounts: unlike mutexes, they are inherently about object lifetimes).", "cve_priority": "high", "cve_public_date": "2025-07-18 08:15:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-80726", "url": "https://ubuntu.com/security/CVE-2026-80726", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-46113", "url": "https://ubuntu.com/security/CVE-2026-46113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, \"KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE\", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the \"correct\" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the \"wrong\" shadow page. However, that was only an imprecision until 2032a93d66fa (\"KVM: MMU: Don't allocate gfns page for direct mmu pages\") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-52988", "url": "https://ubuntu.com/security/CVE-2026-52988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase Publish new hooks in the list into the basechain/flowtable using splice_list_rcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on.", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2023-53231", "url": "https://ubuntu.com/security/CVE-2023-53231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: Fix detection of atomic context Current check for atomic context is not sufficient as z_erofs_decompressqueue_endio can be called under rcu lock from blk_mq_flush_plug_list(). See the stacktrace [1] In such case we should hand off the decompression work for async processing rather than trying to do sync decompression in current context. Patch fixes the detection by checking for rcu_read_lock_any_held() and while at it use more appropriate !in_task() check than in_atomic(). Background: Historically erofs would always schedule a kworker for decompression which would incur the scheduling cost regardless of the context. But z_erofs_decompressqueue_endio() may not always be in atomic context and we could actually benefit from doing the decompression in z_erofs_decompressqueue_endio() if we are in thread context, for example when running with dm-verity. This optimization was later added in patch [2] which has shown improvement in performance benchmarks. ============================================== [1] Problem stacktrace [name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291 [name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi [name:core&]preempt_count: 0, expected: 0 [name:core&]RCU nest depth: 1, expected: 0 CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1 Hardware name: MT6897 (DT) Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4 [2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/", "cve_priority": "medium", "cve_public_date": "2025-09-15 15:15:00 UTC" }, { "cve": "CVE-2023-53707", "url": "https://ubuntu.com/security/CVE-2023-53707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1 The type of size is unsigned int, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later.", "cve_priority": "medium", "cve_public_date": "2025-10-22 14:15:00 UTC" }, { "cve": "CVE-2024-49568", "url": "https://ubuntu.com/security/CVE-2024-49568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg When receiving proposal msg in server, the fields v2_ext_offset/ eid_cnt/ism_gid_cnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2_ext_offset, once exceed the max value, there has the chance to access wrong address, and crash may happen. This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt before using them.", "cve_priority": "high", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2026-89560", "url": "https://ubuntu.com/security/CVE-2026-89560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation Whiteout objects are used in the upper layer of an OverlayFS to indicate that the file with this name does not exist in the unified view, even if it is present in one of the lower layer file systems. For the userspace implementations of OverlayFS (fuse-overlayfs), whiteout objects can be created from userspace as well: * mknod(2) with S_IFCHR and makedev(0, 0) * renameat2(2) with RENAME_WHITEOUT, creating the whiteout in the old place of the moved file. This commit guards whiteout creation in both of these cases with LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered character devices and are not bound to a driver. LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a whiteout object: creating one is the only S_IFCHR creation that the VFS exempts from CAP_MKNOD, so it is as unprivileged as creating a regular file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that expose a kernel interface [1]. For the mknod(2) case, introduce a Landlock erratum. The creation of whiteout objects through mknod(2) was previously guarded using LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using LANDLOCK_ACCESS_FS_MAKE_REG. For the renameat2(2) case, fix a bug: Before this commit, renameat2(2) with RENAME_WHITEOUT would create a directory entry even when all LANDLOCK_ACCESS_FS_MAKE_* rights were denied. This does not affect normal renames within layered OverlayFS mounts: When doing a regular rename() on a mounted fuse-overlayfs, it is the fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT, and only the Landlock domain of that daemon is checked there. Depends-on: 49c9e09d9610 (\"landlock: Fix handling of disconnected directories\") Depends-on: fe72ce6710cb (\"landlock: Add errata documentation section\") [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and add link(2) to the user doc]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2024-41062", "url": "https://ubuntu.com/security/CVE-2024-41062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bluetooth/l2cap: sync sock recv cb and release The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work \t l2cap_sock_release hci_acldata_packet \t l2cap_sock_kill l2cap_recv_frame \t sk_free l2cap_conless_channel \t l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.", "cve_priority": "high", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2022-50406", "url": "https://ubuntu.com/security/CVE-2022-50406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: iomap: fix memory corruption when recording errors during writeback Every now and then I see this crash on arm64: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dm_thin_pool dm_persistent_data XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296). dm_bio_prison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0 dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECT potentially unexpected fatal signal 6. nf_reject_ipv6 potentially unexpected fatal signal 6. ipt_REJECT nf_reject_ipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) ip_tables pc : 000003fd6d7df200 x_tables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wb_workfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseq_set+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : __filemap_set_wb_err+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseq_set+0x1c/0x100 __filemap_set_wb_err+0x24/0xe0 iomap_do_writepage+0x5e4/0xd5c write_cache_pages+0x208/0x674 iomap_writepages+0x34/0x60 xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: ---truncated---", "cve_priority": "low", "cve_public_date": "2025-09-18 16:15:00 UTC" }, { "cve": "CVE-2026-97523", "url": "https://ubuntu.com/security/CVE-2026-97523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close race between scheduler and state change The mptcp scheduler may race with subflow sockets state change: data transmission on the selected socket may fail and a later release could try to use mss_now reset to 0 for a divide operation. Address the issue by explicitly checking for the critical scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97524", "url": "https://ubuntu.com/security/CVE-2026-97524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid unneeded actions on subflow reset Once in a blue moon, the mptcp receive path can recursively call mptcp_data_ready() via state change under unlucky error conditions, and then try to hold the data lock again. Break the recursion loop explicitly checking for the exceptional condition. Add a new flag instead of using an existing one like 'closing', to exit early in subflow_state_change(), and explicitly flush the RX queue at reset time. This avoids unneeded processing to check for available data -- calling get_mapping_status() and more on a dying subflow -- but also in error reporting and worker scheduling. Note that we must consume the currently peeked skb before invoking mptcp_dss_corruption to avoid consuming it again after the eventual reset has freed it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-80833", "url": "https://ubuntu.com/security/CVE-2026-80833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ss support which is one of the only remaining ones. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. Also, it had a buffer overread bug in the line 'memcpy(ctx->seed, d + dlen, ctx->slen);'. There's no point in fixing these bugs separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80834", "url": "https://ubuntu.com/security/CVE-2026-80834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ce support which is one of the only remaining ones. Note that the sun8i-ce support for hwrng remains in place. That is the interface that actually matters. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. There's no point in fixing this separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-74496", "url": "https://ubuntu.com/security/CVE-2026-74496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Fix use-after-free in fou_create() fou_create() publishes struct fou through sk_user_data before adding the new FOU port to the per-netns list. If fou_add_to_port_list() fails, the error path frees fou while it is still reachable through sk_user_data. A concurrent receive can then dereference the freed object in fou_from_sock(). This ordering issue was previously noted in the linked discussion. The failure is reachable when local port 0 is requested. Each socket binds to a different ephemeral port, but fou_cfg_cmp() compares the requested port 0 and reports -EALREADY once an entry already exists. Release the tunnel socket before freeing fou so sk_user_data is cleared first, and defer reclamation with kfree_rcu() to protect concurrent RCU readers. This matches the lifetime handling in fou_release().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-93286", "url": "https://ubuntu.com/security/CVE-2026-93286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: appletalk: fix NULL pointer dereference in aarp_send_ddp() aarp_send_ddp() calls atalk_find_dev_addr(dev) in the LocalTalk fast path without checking for NULL. When the device has no AppleTalk interface configured (dev->atalk_ptr == NULL), this leads to a NULL pointer dereference at the at->s_net access. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:aarp_send_ddp (net/appletalk/aarp.c:552 (discriminator 2)) Call Trace: atalk_sendmsg (net/appletalk/ddp.c:1715) __sys_sendto (net/socket.c:2265 (discriminator 1)) __x64_sys_sendto (net/socket.c:2272) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Add a NULL check consistent with the other callers of atalk_find_dev_addr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93287", "url": "https://ubuntu.com/security/CVE-2026-93287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: reject oversized block transfers in the common path The SMBus block transfer length data->block[0] is validated in i2c_smbus_xfer_emulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbus_xfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked. Add an early validation in __i2c_smbus_xfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback runs. data->block[0] is filled in by the device on SMBus block reads, so the check is scoped to operations where the length is actually supplied by the caller. This is consistent with the existing -EINVAL convention in the emulated path and protects all downstream consumers at once: the smbus_write tracepoint, all native smbus_xfer driver implementations, and the emulated path. Two distinct bugs are fixed by this change: Bug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h) trace_smbus_write() fires before any validation and copies data->block[0]+1 bytes into a 34-byte event buffer. With block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221. BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91 Call Trace: __asan_memcpy+0x23/0x80 trace_event_raw_event_smbus_write+0x27c/0x530 __i2c_smbus_xfer+0x43a/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c) stub_xfer() implements .smbus_xfer directly and only clamps block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With block[0]=0xff and command=0 the loop accesses block[1+i] for i up to 254, far past the 34-byte union. UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44 index 34 is out of range for type '__u8 [34]' Call Trace: __ubsan_handle_out_of_bounds+0xd7/0x120 stub_xfer+0x1971/0x198f [i2c_stub] __i2c_smbus_xfer+0x306/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97931", "url": "https://ubuntu.com/security/CVE-2026-97931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: us122l: Prevent write upgrades for read mappings The hwdep mmap callback rejects read-buffer mappings that are initially writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ. A process that can open the hwdep node O_RDWR can later use mprotect() to make the mapping writable. The read allocation begins with struct usb_stream. Its read_size member is used by the fault handler to decide which pages belong to the read buffer. The read VMA intentionally remains expandable because pcm_usb_stream uses mremap() after reading that size. Changing read_size first can therefore map and access pages beyond the allocation. The same member is also consumed by usb_stream_free(), where changing it can make free_pages_exact() release pages outside the allocation. Clear VM_MAYWRITE for read-buffer mappings after rejecting an initially writable VMA. This keeps the separate output-buffer mapping writable while preventing later permission upgrades.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97568", "url": "https://ubuntu.com/security/CVE-2026-97568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: syncookies: remember the request backup flag Instead of using an uninitialised bit when copying the info in subflow_ulp_clone(). To fix this, no need to extend the join_entry structure: backup is coming from struct mptcp_subflow_request_sock, only one bit. Do the same here by using one bit for both.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97572", "url": "https://ubuntu.com/security/CVE-2026-97572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Propagate RX ring init failures in bnxt_init_nic() bnxt_init_rx_rings() returns an error when bnxt_alloc_one_rx_ring() fails, but bnxt_init_nic() discards that return value and calls bnxt_init_chip(), which enables TPA. If an allocation fails, this could leave rxr->rx_tpa[] partially zeroed and TPA would be enabled over an array with zeroed entries. This would lead to a zeroed DMA address being handed out if the agg_idx is translated to a SW index at a zeroed entry. Fix this by propagating the error out of bnxt_init_nic(). Both callers already check its return value and unwind with bnxt_free_skbs() and bnxt_free_mem(), which tolerate a partially initialized RX ring.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97573", "url": "https://ubuntu.com/security/CVE-2026-97573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset() bnxt_rx_ring_reset() frees the ring buffers and then reallocates them, ignoring the result. bnxt_alloc_one_rx_ring() can fail in bnxt_alloc_one_tpa_info_data(), which returns -ENOMEM on the first failed allocation and leaves the remaining rxr->rx_tpa[] entries zeroed. The error isn't propagated up, so the loop in bnxt_rx_ring_reset continues and at the end the code re-enables TPA with partially unallocated rx_tpa array. This means that when the agg_id from hardware is mapped to a SW index in rxr->rx_tpa[], an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by falling back to a global reset, which is what the existing code already does when other functions fail, but unlike the other failure cases this particular failure has to return because TPA can't be re-enabled since the allocation failed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97576", "url": "https://ubuntu.com/security/CVE-2026-97576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC tile counts The stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from column_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[] and use them as tile-loop bounds, but std_validate_compound() does not bound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling enabled whose tile counts exceed the uAPI array capacity, mirroring the existing compound-control range checks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97582", "url": "https://ubuntu.com/security/CVE-2026-97582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gpio-fan) Fix use-after-free in alarm work fan_alarm_irq_handler() queues fan_data->alarm_work, but nothing cancels it. fan_alarm_notify() dereferences fan_data and its hwmon device. On unbind, devres frees the interrupt, which only waits for the handler itself, and then releases the hwmon device and fan_data, so a pending fan_alarm_notify() can run after those frees. Replace INIT_WORK() with devm_work_autocancel(), registered before devm_request_irq(). The devres cleanup then frees the interrupt first, so no new work can be queued, and cancels the work while fan_data and the hwmon device are still alive. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97592", "url": "https://ubuntu.com/security/CVE-2026-97592", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done. Similar with the buffers which are part of the gcm_sg_walk structs from the variables gw_in and gw_out.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97596", "url": "https://ubuntu.com/security/CVE-2026-97596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reject invalid states in connection template sync records IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6 records.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97598", "url": "https://ubuntu.com/security/CVE-2026-97598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: bound automatic table ID allocation fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment (\"ip rule ... table 0\") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TABLE_MAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable. The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97601", "url": "https://ubuntu.com/security/CVE-2026-97601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97604", "url": "https://ubuntu.com/security/CVE-2026-97604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vfb: defer cleanup until the last reference FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114) Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489) unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97608", "url": "https://ubuntu.com/security/CVE-2026-97608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: unregister loggers before per-net teardown nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL lock nf_log_mutex find logger in loggers[][] net->nf.nf_loggers[pf] = logger unlock nf_log_mutex nf_log_unregister(logger) lock nf_log_mutex loggers[pf][type] = NULL unlock nf_log_mutex synchronize_rcu() module exit returns module core frees backend memory Later, a sysctl read or packet logging operation can dereference the stale per-net logger pointer. Fix this by unregistering the global logger backends before tearing down per-net state. Once the global registrations are gone, later writers can no longer rebind the logger. unregister_pernet_subsys() already waits for an RCU grace period after the pre-exit callback clears the per-net selection, while nf_log_unregister() continues to cover readers of the global logger table. Apply this ordering fix to both nf_log backends that combine per-net teardown with global logger registration.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97611", "url": "https://ubuntu.com/security/CVE-2026-97611", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix use-after-free of the flow table mask array tbl_mask_array_realloc() retires the old mask_array before it stops being reachable: \told = ovsl_dereference(tbl->mask_array); \tif (old) { \t\t... \t\tcall_rcu(&old->rcu, mask_array_rcu_cb); \t} \trcu_assign_pointer(tbl->mask_array, new); call_rcu() only waits for read-side critical sections already in flight. tbl->mask_array still points at old between the call_rcu() and the rcu_assign_pointer(), so a reader entering ovs_flow_tbl_lookup_stats() in that window picks up old in a fresh critical section that the pending grace period does not cover. tbl_mask_array_realloc() runs in process context under ovs_mutex, so the window is preemptible and can outlast the grace period. Then mask_array_rcu_cb() frees old before the swap runs: BUG: KASAN: slab-use-after-free in flow_lookup.constprop.0+0x2bf/0x2f0 Read of size 8 at addr ffff888020b3e018 by task poc/741 flow_lookup.constprop.0+0x2bf/0x2f0 ovs_flow_tbl_lookup_stats+0x4a3/0x5c0 ovs_dp_process_packet+0x19c/0x710 ovs_vport_receive+0x243/0x390 internal_dev_xmit+0x81/0x170 Freed by task 728: kfree+0x16a/0x4e0 rcu_core+0x853/0x1030 Publish the new array before retiring the old one. The kfree_rcu() that call_rcu() replaced ran after the swap.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97612", "url": "https://ubuntu.com/security/CVE-2026-97612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: clear inner_protocol when the last label is popped skb_mpls_push() records the pre-encapsulation network header once, gated on !skb->inner_protocol. skb_mpls_pop() never clears that record, so it outlives the encapsulation it describes. Open vSwitch can then re-push MPLS onto a packet whose inner_network_header still points at the older, deeper offset: push a label, pop every label, recirculate (ovs_flow_key_update() re-derives key->eth.type and resets network_header, but leaves inner_*), then push again. ovs_fragment() trusts the record: \tskb->network_header = skb->inner_network_header; so skb_network_offset() goes negative. The bound check is signed: \tif (skb_network_offset(skb) > MAX_L2_LEN) a negative offset passes it, and prepare_frag() widens the value: \tunsigned int hlen = skb_network_offset(skb); \tmemcpy(&data->l2_data, skb->data, hlen); which is a ~4GiB memcpy out of a 30-byte per-CPU buffer. Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8): BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 prepare_frag+0x3df/0x4e0 ovs_fragment+0x589/0x7e0 do_output+0x4ce/0x5e0 do_execute_actions+0x55d2/0x7b30 ovs_execute_actions+0xea/0x450 Same root-cause shape as commit 975b5b067f52 (\"ipv6: sr: restore network header before routing and forwarding\"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path. Clear inner_protocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/act_mpls.c is the only other skb_mpls_pop() caller and gets the same fix; sch_frag.c saves and restores inner_protocol around fragmentation in the same way OVS does.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97899", "url": "https://ubuntu.com/security/CVE-2026-97899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix memory leak in query_perf_config_list() When krealloc() fails, free the original oa_config_ids before returning to avoid a memory leak. (cherry picked from commit 9977e9d84f46d4f12ad35fbbc0ec4638554bce87)", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97904", "url": "https://ubuntu.com/security/CVE-2026-97904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: initialize policy rwsem before sysfs publication cpufreq_policy_alloc() initializes policy->rwsem after kobject_init_and_add() has created the policy sysfs directory and its default attributes. A sysfs access can therefore reach a policy callback before the semaphore has been initialized. Initialize policy->rwsem before publishing the policy kobject so sysfs callbacks always see an initialized semaphore.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97905", "url": "https://ubuntu.com/security/CVE-2026-97905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: zero-initialize policy cpumask before sysfs publication cpufreq_policy_alloc() allocates policy->cpus with alloc_cpumask_var(), i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate kmalloc_node() allocation, so its bitmap holds whatever the slab allocator left behind: cpufreq_online() cpufreq_policy_alloc() alloc_cpumask_var(&policy->cpus) /* bitmap is uninitialized */ kobject_init_and_add() /* policy%u/ appears in sysfs */ cpufreq_policy_online() cpumask_copy(policy->cpus, cpumask_of(cpu)) /* first valid value */ This leaves a window in which the sysfs attributes are already reachable while policy->cpus is still garbage. show()/store() gate on policy_is_inactive(), i.e. cpumask_empty(policy->cpus), so a non-zero bitmap makes them run the attribute callbacks on a policy that is not initialized yet. Fix this by using zalloc_cpumask_var() for policy->cpus.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97909", "url": "https://ubuntu.com/security/CVE-2026-97909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: initialize IRQ lock before requesting IRQ uni_reader_init() registers the shared IRQ before initializing reader->irq_lock. A pending interrupt can invoke the handler while the lock is still uninitialized. Initialize the lock before registering the IRQ so the interrupt path always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97910", "url": "https://ubuntu.com/security/CVE-2026-97910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sprd: validate compress buffer sizes against fixed allocations sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the fixed allocations. A fragment_size larger than the 32K IRAM data area makes the stage 0 copy_from_user() overflow past the IRAM allocation, and a buffer_size larger than the 2M DDR buffer makes the wrapping copy at the end of sprd_platform_compr_copy() write fully user controlled data past the buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP state reaches the copy callback directly. Reject parameters that do not fit into the fixed buffers in set_params(), and fix the advertised max fragment size: 128K never fitted into the 32K IRAM buffer. The caps values may have been carried over from the qdsp6 driver, which allocates its buffers according to the advertised maxima, unlike this driver. With 32K as max fragment size the advertised limits are self-consistent: 32K * 64 = 2M equals the DDR buffer size. Discovered by Atuin - Automated Vulnerability Discovery Engine.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97923", "url": "https://ubuntu.com/security/CVE-2026-97923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the var ref when its initialization fails create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 (\"tracing: Use hist trigger's var_ref array to destroy var_refs\") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it. The call was correct when it was written, before var refs were taken out of destroy_hist_field(). init_var_ref() cannot free it either. The caller owns the field, so init_var_ref() undoes only its own string allocations and leaves the field alone. Freeing it there would leave create_var_ref() passing freed memory to destroy_hist_field(), which reads its flags. Call __destroy_hist_field(), which frees the field without consulting the flag.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97926", "url": "https://ubuntu.com/security/CVE-2026-97926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: validate cylinder group metadata before caching it ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: \tucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); \tucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); \tucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); \tucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: - c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32 bit count outside the s_csp allocation. - c_frotor becomes a bitmap scan start, start = c_frotor >> 3, and then length = ((s_fpg + 7) >> 3) - start. A start beyond the block bitmap wraps the unsigned length to a huge value, so ubh_scanc() walks far past the cylinder group buffers. c_irotor drives the inode bitmap the same way. A crafted image can set any of these freely, turning an ordinary allocation into an out of bounds access. Reject a cylinder group whose recorded index does not match the group being read, or whose rotors fall outside the group, before the metadata is cached. Valid filesystems keep cg_cgx equal to the group number and the rotors within the group, so only malformed images are rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97927", "url": "https://ubuntu.com/security/CVE-2026-97927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: create the root dentry after loading cylinder metadata ufs_fill_super() installed sb->s_root before it loaded the cylinder group structures for a writable mount: \tsb->s_root = d_make_root(inode); \t... \tif (!sb_rdonly(sb)) \t\tif (!ufs_read_cylinder_structures(sb)) \t\t\tgoto failed; When ufs_read_cylinder_structures() failed, the error path freed the in-core superblock information and set sb->s_fs_info to NULL while sb->s_root stayed installed. get_tree_bdev() then reached deactivate_locked_super(), and because s_root was present, generic_shutdown_super() called sync_filesystem() and the put_super operation. Both dereference UFS_SB(sb), which is now NULL, so a mount that fails only while reading the cylinder groups oopses during teardown. A crafted image whose first cylinder group cannot be read reaches this path. Load the cylinder group metadata first and create the root dentry last, so the superblock is published to the VFS only once it is fully set up. ufs_setup_cstotal() and ufs_read_cylinder_structures() take only the super_block and do not use the root inode, so the reordering is safe.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97930", "url": "https://ubuntu.com/security/CVE-2026-97930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf The in04_last array in struct usx2ydev is declared as char[24], but in04_buf is allocated as sizeof(struct us428_ctls) which is 21 bytes. In i_usx2y_in04_int(), when ctl_snapshot_last == -2 (initialization path): memcpy(usx2y->in04_last, usx2y->in04_buf, sizeof(usx2y->in04_last)); This copies 24 bytes from a 21-byte slab allocation, reading 3 bytes past the end of the source object. Introduce a USX2Y_IN04_SIZE constant defined as sizeof(struct us428_ctls) and use it consistently for the in04_last array, the in04_buf allocation, the URB transfer length, and the comparison loop, replacing the bare 24 and 21 literals throughout.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97940", "url": "https://ubuntu.com/security/CVE-2026-97940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix fib6 walker UAF on seq stop ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a never-started iterator with a zeroed private object is not treated as linked. The same stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only widens the race.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97948", "url": "https://ubuntu.com/security/CVE-2026-97948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver The commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") refactored the EEH code such that the pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken. [<0>] 0xc00000011c78f870 [<0>] __switch_to+0xfc/0x1a0 [<0>] pci_lock_rescan_remove+0x30/0x44 [<0>] eeh_rmv_device+0x290/0x2e0 [<0>] eeh_pe_dev_traverse+0x80/0x130 [<0>] eeh_reset_device+0xcc/0x23c [<0>] eeh_handle_normal_event+0x830/0xa80 [<0>] eeh_event_handler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] start_kernel_thread+0x14/0x18 The issue is seen for cases where the errors are detected on the PHB directly AND|OR for devices where the driver error_detected() returns PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no error handlers like slot_reset(), resume() etc defined).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-74743", "url": "https://ubuntu.com/security/CVE-2026-74743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: inherit needed_headroom and needed_tailroom from lowerdev macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-89792", "url": "https://ubuntu.com/security/CVE-2026-89792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds reads in share config responses Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-97951", "url": "https://ubuntu.com/security/CVE-2026-97951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands When a LUN_RESET aborts a WRITE command that is in the TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and waits for the frontend to finish processing. If the initiator subsequently sends the remaining dataout PDUs, __iscsit_check_dataout_hdr() catches the payload, stops the dataout timer if the sequence is final and finally dumps the data. However, the iSCSI target doesn't trigger the completion process for these aborted commands. Because of this, the abort path hangs indefinitely in target_put_cmd_and_wait(), leading to a deadlocked target worker thread. Fix this by explicitly calling target_complete_cmd() when the final dataout PDU is received for an aborted WRITE command. target_complete_cmd() detects the CMD_T_ABORTED flag and cleanly routes the command into target_abort_work, allowing the abort completion to successfully unblock.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-97952", "url": "https://ubuntu.com/security/CVE-2026-97952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunvdc: unmap LDC cookies when the descriptor send fails __send_request() maps the request's pages into the LDC channel's map table (ldc_map_sg()), fills in the descriptor and marks it VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger(). When the trigger fails, the error path only prints a message: the descriptor stays READY and the cookies are never unmapped. The mapping is normally released in vdc_end_one() when the peer completes the descriptor - but a descriptor whose doorbell was never sent will never complete, and since dr->prod is not advanced on failure, the reset path (vdc_requeue_inflight(), which walks [cons, prod)) never visits it either. The map table entries are leaked permanently. Since commit a11f6ca9aef9 (\"sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN\") trigger failures occur in practice under load, so every resulting I/O error also leaks one request's worth of entries from the fixed-size (8192 entries per channel) map table. Because the allocator hands out contiguous ranges, fragmentation makes large multi-segment requests fail first as the table drains, until ldc_map_sg() fails permanently and the disk is dead until reboot. It also makes any retry-based recovery unusable: requeuing the request on -EAGAIN remaps the pages on every attempt, overwriting desc->cookies and orphaning the previous mapping, so the table drains at the retry rate. This is the memory exhaustion observed when the requeue approach was first tested in October 2025. Roll back on failure: unmap the cookies, mark the descriptor FREE again and clear the request entry. If the trigger failed with -ENOTCONN, __vdc_tx_trigger() has already reset the port, which tears down and reallocates both the dring and the LDC channel including its map table - nothing to roll back, and the stale descriptor must not be touched.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97954", "url": "https://ubuntu.com/security/CVE-2026-97954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix tcp stream corruption with large pages rds_message_map_pages() assigns PAGE_SIZE bytes to every scatterlist entry, even when total_len ends in a partial page. The RDS congestion map is defined as 8192 bytes, so on systems with PAGE_SIZE greater than 8192 the scatterlist maps bytes beyond the end of the congestion map. RDS-TCP transmits the SG contents according to those lengths, so the extra bytes become part of the TCP RDS stream and are interpreted as subsequent RDS message headers, corrupting the stream. Limit the final scatterlist mapping to the number of bytes remaining. This has no effect on systems with a 4K page size and allows RDS-TCP to be used on systems with 16K and larger page sizes. The RDS selftest, which previously hung on 16K pages, now passes.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97957", "url": "https://ubuntu.com/security/CVE-2026-97957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix mailbox segment buffer overflow check_mbox_seq_id_and_seg_len() validates that seq_id does not exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed MBOX_SEG_LEN (48). However, this allows the last segment (seq_id=42) to carry a full 48-byte payload, writing to offset 42*48=2016 for 48 bytes (ending at byte 2064). The receive buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a 16-byte heap buffer overflow. The hinic3 driver already handles this correctly by defining MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it exceeds the remaining buffer space. Apply the same fix to the hinic driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97958", "url": "https://ubuntu.com/security/CVE-2026-97958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain(). If a netlink socket sends RTM_GETCHAIN requests repeatedly without recv()ing the responses, tc_ctl_chain() hogs CPU and triggers Hung Task splat. [0] As caught in the stack trace, netlink_attachskb() could confuse tc_ctl_chain() by returning -EAGAIN when the userspace netlink socket's receive buffer is full. The replay: label exists since commit 32a4f5ecd738 (\"net: sched: introduce chain object to uapi\") but was not used initially. Since commit 9f407f1768d3 (\"net: sched: introduce chain templates\"), the label is needed for RTM_NEWCHAIN because tcf_proto_lookup_ops() may release RTNL to call request_module(). However, the replay logic is unnecessary for RTM_GETCHAIN. Let's apply the replay logic only for RTM_NEWCHAIN. [0]: INFO: task repro:1018 is blocked on a mutex likely owned by task repro:1022. task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 task_flags:0x400040 flags:0x00080000 Call Trace: ? clockevents_program_event (kernel/time/clockevents.c:372) ? pskb_expand_head (net/core/skbuff.c:615) ? skb_release_data (net/core/skbuff.c:1122) ? netlink_attachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/af_netlink.c:1232) ? __netlink_lookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/af_netlink.c:499) ? tc_chain_notify (net/sched/cls_api.c:3045) ? tc_chain_notify (./include/linux/skbuff.h:1384 net/sched/cls_api.c:3041) ? netlink_unicast (net/netlink/af_netlink.c:1335) ? rtnl_unicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985) ? tc_ctl_chain (net/sched/cls_api.c:3242) ? rtnetlink_rcv_msg (net/core/rtnetlink.c:7146) ? netlink_unicast (net/netlink/af_netlink.c:1354) ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:7177) ? netlink_rcv_skb (net/netlink/af_netlink.c:2556) ? netlink_unicast (net/netlink/af_netlink.c:1319) ? netlink_sendmsg (net/netlink/af_netlink.c:1900) ? __sock_sendmsg (net/socket.c:800) ? __sys_sendto (net/socket.c:2281) ? __x64_sys_sendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284) ? do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97959", "url": "https://ubuntu.com/security/CVE-2026-97959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_route: free emptied bucket on filter move route4_change can move an existing filter to a different top-level bucket: route4_set_parms recomputes the handle from TCA_ROUTE4_TO/ FROM/IIF, and the handle-mismatch check is gated on the 'new' flag, so for an existing filter the new handle may differ from the old one and land in a different bucket. When this happens, the filter is unlinked from the old bucket, but the bucket itself is never freed once it goes empty. The stale empty bucket remains in head->table[], causing route4_delete to report *last=false even after the last live filter is gone. That pins the empty tcf_proto and causes a leak. Fix this by refcounting the filters linked to a bucket and freeing the bucket when the count drops to zero. The existing scan in route4_delete goes away with it. The count is updated at all sites that link or unlink a filter during add, change and delete, and the bucket is dropped from head->table[] as soon as it reaches zero. Conditions to recreate the bug: CONFIG_NET_CLS_ROUTE4=y, CONFIG_NET_SCH_INGRESS=y, CONFIG_NET_CLS_ACT=y. tc qdisc replace dev lo clsact tc filter add dev lo ingress protocol ip pref 100 route from 1 to 1 tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \\ route from 1 to 2 tc filter del dev lo ingress protocol ip pref 100 handle 0x10002 \\ route from 1 to 2 tc filter show dev lo ingress | grep -c 'pref 100 route chain 0 '", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97963", "url": "https://ubuntu.com/security/CVE-2026-97963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: initialize ptp_lock at probe time priv->ptp_lock is only initialized in stmmac_ptp_register(), which runs during __stmmac_open(). However, the lock is also used while the interface is down and has never been opened: tc_taprio_configure() invokes the PTP gettime64() callback to compute the EST base time when offloading a TAPRIO schedule, and stmmac_get_time() takes priv->ptp_lock. Using an uninitialized rwlock is undefined behaviour. Move the rwlock_init() to __stmmac_dvr_probe(), together with the other private locks, so that ptp_lock is always valid regardless of the interface state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97964", "url": "https://ubuntu.com/security/CVE-2026-97964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_synctty: ensure a writeable skb header ppp_sync_txmunge() checks headroom before prepending the address and control bytes, but does not ensure that the skb header is writable. A received skb can reach this function through PPP channel bridging without passing through ppp_start_xmit(), which calls skb_cow_head(). For example, a PPPoE frame may share its buffer with a clone queued to an AF_PACKET socket. If it is bridged to a synchronous tty channel, the address/control bytes can overwrite data still visible to that socket. Use skb_cow_head() to ensure both sufficient headroom and a writable header.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97969", "url": "https://ubuntu.com/security/CVE-2026-97969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix clock leak and spurious timer in settimeout() msc313e_wdt_settimeout() unconditionally calls msc313e_wdt_start() which introduces two severe bugs: 1. If the watchdog is already active, calling start() again will increase the reference count of the clock again. However stop() is only called once, the reference count is unbalance. 2. If the watchdog is stopped, calling settimeout() will start the hardware timer accidentally. Factor out the register-writing logic into a helper function. Only call it in settimeout() if the watchdog is running. Otherwise, simply update `wdev->timeout`.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97970", "url": "https://ubuntu.com/security/CVE-2026-97970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Avoid division by zero clk_get_rate() could return 0. Avoid a division by zero panic.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97981", "url": "https://ubuntu.com/security/CVE-2026-97981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Count dropped frames as NAPI work The RX loop only consumes budget when it successfully delivers a frame. Error paths keep consuming descriptors without reducing the budget, so a stream of bad frames can process the entire receive ring in one poll. Move the budget accounting to a common end-of-frame path. This counts each completed frame as NAPI work whether it was delivered or dropped, matching the behavior of the vendor driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97982", "url": "https://ubuntu.com/security/CVE-2026-97982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Fix budget accounting The gmac_rx() function returns the remaining NAPI budget, but its caller treats the return value as the number of packets received. An idle poll therefore reports a full budget and remains scheduled. Return the number of received packets instead. Preserve the existing free queue refill accounting by adding that count directly; continuing to subtract it from the budget would invert the refill behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97991", "url": "https://ubuntu.com/security/CVE-2026-97991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim_blk: reject out-of-range sector starts vdpasim_blk_check_range() logs an invalid start sector but continues validating the request. The subsequent unsigned capacity subtraction can underflow and let an out-of-range buffer offset reach the data path. The invalid offset is used by three request paths. VIRTIO_BLK_T_OUT copies guest data to blk->buffer + offset through vringh_iov_pull_iotlb(), causing an out-of-bounds write in _copy_from_iter() or memcpy(). VIRTIO_BLK_T_IN copies from blk->buffer + offset to the guest through vringh_iov_push_iotlb(), causing an out-of-bounds read in _copy_to_iter(). VIRTIO_BLK_T_WRITE_ZEROES passes blk->buffer + offset to memset(), causing an out-of-bounds write. Reject starts at or beyond the capacity before the subtraction. Treat the capacity boundary as invalid because the IN and OUT paths round byte counts down to sectors for validation but later copy the original byte counts. A sub-sector request at the capacity boundary would otherwise still access past the end of the buffer. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97993", "url": "https://ubuntu.com/security/CVE-2026-97993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx vhost_vdpa_set_config_call() swaps the eventfd_ctx_fdget() return value into v->config_ctx before checking it, so on failure the field briefly holds an ERR_PTR: \tctx = fd == VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd); \tswap(ctx, v->config_ctx); \tif (!IS_ERR_OR_NULL(ctx)) \t\teventfd_ctx_put(ctx); \tif (IS_ERR(v->config_ctx)) { \t\tlong ret = PTR_ERR(v->config_ctx); \t\tv->config_ctx = NULL; \t\treturn ret; \t} Commit 0bde59c1723a (\"vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails\") added that clearing, and spelled out the invariant the rest of the file relies on: \"we consider 'v->config_ctx' valid if it is not NULL\". The window between the swap and the clearing still breaks it. vhost_vdpa_config_cb() only tests for NULL, so a config interrupt delivered inside the window hands the ERR_PTR to eventfd_signal(). Check the fd before installing it instead. That closes the window and matches how vhost_vring_ioctl() handles the same failure for the vq call fd. It also stops a rejected fd from tearing down a config interrupt that was working: until now the swap replaced the live context and put it, so after an EBADF the device silently stopped delivering config interrupts until userspace installed a new fd.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97995", "url": "https://ubuntu.com/security/CVE-2026-97995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_console: do not free control-out buffers on remove __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): \tfree_buf \tremove_vqs \tvirtcons_remove \tunbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97998", "url": "https://ubuntu.com/security/CVE-2026-97998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: cope with concurrent instance destruction Instances are refcounted. However, only memory release happens on the 1 -> 0 transition; the unlink from hashes can occur with any refcount. Uncooperative userspace can force a situation where a queue is pending for destruction from netlink event while a different socket with same portid processes an UNBIND request. With right timing, this will unhash the instance again: Oops: general protection fault, [..] Call Trace: nfulnl_recv_config+0x31a/0xd50 nfnetlink_rcv_msg+0x7c2/0xeb0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98006", "url": "https://ubuntu.com/security/CVE-2026-98006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev The epq_in_urb object belonging to the caiaq device is coupled within the struct snd_usb_caiaqdev. After usb_submit_urb(epq_in_urb, GFP_KERNEL) executes successfully, epq_in_urb is successfully added to the urbp_list queue of the dummy HCD driver (userspace specifies dummy_hcd as the HCD layer driver for the caiaq USB device). When init_card() calls snd_usb_caiaq_send_command() which subsequently fails due to a timeout, and proceeds to call snd_card_free() to release the card, the embedded ep1_in_urb object is also freed. When the dummy HCD driver detects that the URB has been unlinked, it returns the URB (by usb_hcd_giveback_urb()), which triggers [1]. Decouple the ep1_in_urb object from the struct snd_usb_caiaqdev and switch to using a pointer instead. Separately allocate and manage the memory for ep1_in_urb to prevent the release of the snd_card memory object from interfering with it. midi_out_urb has the same issue as ep1_in_urb and is handled in the same way. [1] BUG: KASAN: slab-use-after-free in usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 Write of size 4 at addr ffff88803cee1050 by task ktimers/1/29 Call Trace: usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 dummy_timer+0xaac/0x4d50 drivers/usb/gadget/udc/dummy_hcd.c:2019 __run_hrtimer kernel/time/hrtimer.c:2067 [inline] __hrtimer_run_queues+0x3eb/0xaf0 kernel/time/hrtimer.c:2124 hrtimer_run_softirq+0x1e1/0x2e0 kernel/time/hrtimer.c:2141 Allocated by task 36: snd_card_new+0x7b/0x110 sound/core/init.c:184 create_card sound/usb/caiaq/device.c:429 [inline] snd_probe+0x236/0x1af0 sound/usb/caiaq/device.c:544 Freed by task 36: snd_card_free_when_closed sound/core/init.c:630 [inline] snd_card_free+0x138/0x1d0 sound/core/init.c:662 snd_probe+0x162b/0x1af0 sound/usb/caiaq/device.c:553", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98009", "url": "https://ubuntu.com/security/CVE-2026-98009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: clamp quantum in parse and fallback paths ets_qdisc_change() falls back to psched_mtu() with no floor for bands without an explicit quantum. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so a zero psched_mtu on a headerless device makes the deficit-refill loop spin under the qdisc lock. Move the floor into ets_quantum_parse() so explicitly configured quanta are also clamped to [256, 1<<20], not just the fallback path. Conditions to recreate the bug: CONFIG_NET_SCH_ETS=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root ets bands 3 strict 2 quanta 1 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98010", "url": "https://ubuntu.com/security/CVE-2026-98010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: drr: clamp quantum in change class drr_change_class() rejects explicit quantum==0 but falls back to psched_mtu() with no floor. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 (or a zero psched_mtu on a headerless device) makes the deficit-refill loop spin under the qdisc lock. Add clamp_t(u32, quantum, 256, 1<<20) after the zero reject and on the fallback path. The explicit-zero reject is preserved. Conditions to recreate the bug: CONFIG_NET_SCH_DRR=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root drr tc class add dev dummy0 parent 1: classid 1:1 drr quantum 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98011", "url": "https://ubuntu.com/security/CVE-2026-98011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum in change and init paths hhf_change() accepts any quantum from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) in hhf_change() matching fq_codel_change(). Clamp hhf_init() to [256, 1<<20] matching the siblings, and remove the old fallback that only set quantum=256 on overflow. Conditions to recreate the bug: CONFIG_NET_SCH_HHF=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root hhf tc qdisc change dev dummy0 root hhf quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98012", "url": "https://ubuntu.com/security/CVE-2026-98012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum in change path sfq_change() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and the init clamp. Conditions to recreate the bug: CONFIG_NET_SCH_SFQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root sfq tc qdisc change dev dummy0 root sfq quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98013", "url": "https://ubuntu.com/security/CVE-2026-98013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp quantum in change path fq_pie_change() accepts any quantum value from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Conditions to recreate the bug: CONFIG_NET_SCH_FQ_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq_pie tc qdisc change dev dummy0 root fq_pie quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98014", "url": "https://ubuntu.com/security/CVE-2026-98014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch, prevent mc_list repopulation during vport disable In mlx5_esw_vport_disable(), move esw_apply_vport_rx_mode() ahead of esw_vport_change_handle_locked() so vport->allmulti_rule is NULL before the change handler observes it. During FW-fatal recovery the disable runs while dev->state == INTERNAL_ERROR. The promisc query inside esw_update_vport_rx_mode() fails and returns early, leaving vport->allmulti_rule intact, so esw_update_vport_mc_promisc() runs and adds MLX5_ACTION_ADD entries to vport->mc_list whose flow rules are then installed in the FDB by esw_add_mc_addr(). esw_destroy_legacy_table() tears down the FDB with those refs still held, corrupting the sub-tree and leaving dangling flow_rule pointers in vport->mc_list. Two-stage failure on `echo 1 > /sys/bus/pci/devices//reset`: refcount_t: underflow; use-after-free. tree_put_node+0xef/0x110 [mlx5_core] clean_tree+0x44/0xd0 [mlx5_core] (x5) mlx5_fs_core_cleanup+0x57/0x1c0 [mlx5_core] mlx5_unload+0x65/0xd0 [mlx5_core] ... mlx5_health_try_recover BUG: unable to handle page fault for address: 0000000003000055 down_write+0x1c/0x60 mlx5_del_flow_rules+0x33/0x1f0 [mlx5_core] esw_del_mc_addr+0x7b/0x170 [mlx5_core] esw_apply_vport_addr_list+0x56/0xf0 [mlx5_core] esw_vport_change_handle_locked+0x28b/0x310 [mlx5_core] mlx5_esw_vport_enable+0x270/0x4a0 [mlx5_core] ... mlx5_load ... mlx5_health_try_recover esw_apply_vport_rx_mode(false, false) clears vport->allmulti_rule via its local state machine even when the FW del fails. With the rule NULL the !IS_ERR_OR_NULL(allmulti_rule) gate in the change handler closes, no rules are installed during disable, and the reload starts with a clean mc_list.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98015", "url": "https://ubuntu.com/security/CVE-2026-98015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put In mlx5_eswitch_termtbl_put(), the zero-ref cleanup check reads tt->ref_count after termtbl_mutex has been released. Two concurrent callers on the same mlx5_termtbl_handle race: one decrements ref_count to zero, removes the hash entry, and calls kfree(tt) while the other has already dropped the mutex and is about to evaluate if (!tt->ref_count), producing a use-after-free. Fix this by capturing the result of the decrement into a stack-local last variable before dropping the mutex. The cleanup decision is now made entirely under termtbl_mutex, and tt is not touched after kfree.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98016", "url": "https://ubuntu.com/security/CVE-2026-98016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free race in sample_restore_put() Concurrent teardown of TC sample rules sharing the same restore context may re-read restore->count after dropping restore_lock. At that point another thread may already have completed cleanup and freed the restore object. Use the result of the refcount decrement while holding restore_lock to determine whether cleanup is needed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98022", "url": "https://ubuntu.com/security/CVE-2026-98022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations Several subsystems allocate ring buffers sized by dev->tx_queue_len with no upper bound. An unprivileged user (via unshare -Urn) can set a huge tx_queue_len and exhaust global memory with ring allocations: - pfifo_fast: pfifo_fast_init() and pfifo_fast_change_tx_queue_len() allocate 3 skb_array rings of tx_queue_len entries each. - tun: tun_queue_resize() and the queue-attach path resize ptr_rings to tx_queue_len on the NETDEV_CHANGE_TX_QUEUE_LEN notifier. - tap (macvtap/ipvtap): tap_queue_resize() and tap_init() resize/init ptr_rings to tx_queue_len on the same notifier. netif_change_tx_queue_len() is the single entry point for IFLA_TXQLEN, sysfs, and the SIOCSIFTXQLEN ioctl. Cap new_len at S16_MAX (32767) there so the oversized value is rejected at set time. This takes effect whether the device is up or down, before dev->tx_queue_len is written, before any notifier fires, and before any ring is allocated. The \"> S16_MAX\" check also subsumes the previous unsigned-long truncation test, and a negative ifr_qlen from the ioctl lands far above the cap after conversion, so both old failure modes are covered by the one comparison. tx_queue_len is ambigious: both a per-ring sizing multiplier and a default queue-length/limit knob for consumers that allocate nothing at set time (pfifo/bfifo/gred/plug/sfb limits, htb direct_qlen, qfq max_classes, teql). 32767 is chosen as the largest value NLA_POLICY_FULL_RANGE can express for the u32 IFLA_TXQLEN policy in patch 2/3 while staying a legitimate queue length on high-BDP paths; the ring-memory trade-off of a shared knob is disclosed below. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn). - pfifo_fast: create veth pairs, set tx_queue_len to 500000, attach mq+pfifo_fast. ~28 iterations OOMs a 2GB guest. - tun: create 50 tun devices with IFF_MULTI_QUEUE, set tx_queue_len to 500000, open 8 queues each. ~1.6GB of ptr_ring allocations OOMs a 512MB guest. - tap: same as tun with IFF_TAP. ~960MB OOMs a 512MB guest. - On the fixed kernel the oversized tx_queue_len is rejected with -ERANGE at set time (all four paths: RTM_SETLINK, RTM_NEWLINK create, sysfs, ioctl - the latter two via this check, the former two via this check and the 2/3 parse policy respectively).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98023", "url": "https://ubuntu.com/security/CVE-2026-98023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: reject dynamic fdb entries that reference a nexthop id The commit cited in the Fixes tag allowed VXLAN FDB entries to point to FDB nexthops so that overlay traffic could be load balanced across multiple VTEPs. Such entries can only be configured from user space, cannot be learned and cannot roam. They only make sense with a user space control plane such as E-VPN where data plane learning is disabled. Despite that, the VXLAN driver does not currently prevent such entries from being configured with the \"dynamic\" flag. The per-nexthop FDB list is only protected by the per-device hash lock, which is not sufficient when two VXLAN devices point to the same FDB nexthop and therefore share the list. Aging runs in softirq context without RTNL, so an entry deleted by one device can race with an addition or deletion from the other, leading to list corruption: list_del corruption. next->prev should be ffff8881069d9548, but was dead000000000122. (next=ffff8881069d9448) WARNING: CPU: 0 PID: 90 at lib/list_debug.c:65 __list_del_entry_valid_or_report+0x1aa/0x210 ... vxlan_fdb_destroy+0x5b8/0xad0 vxlan_cleanup+0x328/0x450 call_timer_fn+0x2a/0x1c0 run_timer_softirq+0x18c/0x210 BUG: KASAN: slab-use-after-free in vxlan_fdb_destroy Fix this by rejecting the bogus configuration of dynamic FDB entries that point to FDB nexthops, both when created and when an existing entry is updated. As such, the per-nexthop FDB list is only ever mutated under the RTNL lock. Add test cases to make sure that this does not regress in the future.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98025", "url": "https://ubuntu.com/security/CVE-2026-98025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is \t} else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB \"frame\" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98027", "url": "https://ubuntu.com/security/CVE-2026-98027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer size mv88e6xxx_get_rxnfc() uses rxnfc->rule_cnt as the write index while dumping the policy IDR, clobbering the input value before it has been looked at. That input is the number of entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed policy rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Count into a local so the caller's limit survives the walk, and stop with -EMSGSIZE once it is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98030", "url": "https://ubuntu.com/security/CVE-2026-98030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size bcm_sf2_cfp_rule_get_all() walks the whole cfp.unique bitmap into rule_locs[] without consulting nfc->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed CFP rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98031", "url": "https://ubuntu.com/security/CVE-2026-98031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: Initialize extack in remove_nh_grp_entry() remove_nh_grp_entry() prints the extack message when a listener fails to replace the reduced nexthop group. However, extack is not initialized and listeners are not required to set a message when returning an error. Neither netdevsim nor mlxsw do so when an allocation fails, resulting in the dereference of an uninitialized stack pointer. Fix by zero-initializing extack, as was done in commit 6347c5314cee (\"nexthop: initialize extack in nh_res_bucket_migrate()\").", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98063", "url": "https://ubuntu.com/security/CVE-2026-98063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref in btf_var_show() btf_var_show() calls btf_type_id_resolve() unconditionally, which dereferences btf->resolved_ids. That is NULL for a base BTF - e.g. the vmlinux BTF that bpf_snprintf_btf() renders against - since base BTF is not resolved during parsing. btf_modifier_show() guards this with 'if (btf->resolved_ids)', but btf_var_show() does not. A BPF program that passes the type_id of a BTF_KIND_VAR from the vmlinux BTF to bpf_snprintf_btf() thus NULL-derefs: KASAN: probably user-memory-access in range [0x46638-0x4663f] RIP: 0010:btf_var_show (kernel/bpf/btf.c:2929) Call Trace: btf_type_show (kernel/bpf/btf.c:8259) btf_type_snprintf_show (kernel/bpf/btf.c:8329) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Resolve the var's type directly with btf_type_skip_modifiers() when resolved_ids is NULL, mirroring btf_modifier_show().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98064", "url": "https://ubuntu.com/security/CVE-2026-98064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref when showing a void BTF type btf_modifier_show() resolves the modifier and then calls btf_type_ops(t)->show() unconditionally. For the void type (type_id 0, BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL. A \"const void\" (a modifier resolving to void) cannot be a map key or value - map_check_btf() rejects it because void has no size - so the map dump path does not reach it. But bpf_snprintf_btf() takes a type_id straight from the BPF program, and passing such a \"const void\" from the vmlinux BTF NULL-derefs: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:btf_modifier_show (kernel/bpf/btf.c:2914) Call Trace: btf_type_show (kernel/bpf/btf.c:8251) btf_type_snprintf_show (kernel/bpf/btf.c:8321) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fall back to btf_df_show() when the resolved type has no show op; it emits the \"\" placeholder already used for kinds like FWD and FUNC. bpf_snprintf_btf() then returns the length as usual.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98066", "url": "https://ubuntu.com/security/CVE-2026-98066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Fix potential double-free at error path The fix for caiaq driver's resource management to handle the errors tries to release the resources in a common destructor call, but as a sashiko review for another patch suggested, some of the audio resources such as URBs have been already freed, and this may lead to a double-free. For addressing the double-free, call the common destructor function from each place, and assure that the resource pointers get cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98068", "url": "https://ubuntu.com/security/CVE-2026-98068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: don't let rds_conn_shutdown() consume a concurrent drop rds_conn_shutdown() finishes by moving the path from RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts RDS_CONN_ERROR as the starting state of that final transition, so that a FIN processed in softirq context during the teardown does not derail the shutdown into a noisy error path. But consuming that RDS_CONN_ERROR also consumes the shutdown pass that came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN is a no-op. For the FIN case that is harmless - the socket the FIN arrived on is the very socket the teardown just released. It is not harmless for a dropper that attached something to the path first. rds_tcp_accept_one() is such a dropper. Its path claim in rds_tcp_accept_one_path() transitions RDS_CONN_DOWN -> RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous socket in softirq context, an administrative reset - can put the path into RDS_CONN_ERROR between that claim and the state check that follows, which accepts RDS_CONN_ERROR. The accept then installs the freshly accepted socket with rds_tcp_set_callbacks() while the queued teardown - which sampled tc->t_sock before this socket existed - is still running. rds_connect_path_complete() fails its transition to RDS_CONN_UP and drops the path again, queueing the pass that should reap the socket it just installed. If the in-flight shutdown's final transition consumes that drop's RDS_CONN_ERROR, the queued pass finds the path in RDS_CONN_DOWN and does nothing. The installed socket is never torn down: it sits established with its callbacks armed and its rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some later event drops it again. Reproduced with widened race windows as an ever-growing receive queue on a socket owned by a path stuck in RDS_CONN_DOWN, with the peer's send path wedged behind it. Make the final transition only DISCONNECTING -> DOWN. If it fails because the path is in RDS_CONN_ERROR, a drop raced the teardown: cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one piece of the skipped tail that must not be left behind - and return, letting the pass the drop queued finish the job: it tears down whatever attached to the path in the meantime, completes the transition to RDS_CONN_DOWN, and re-arms the reconnect from its own tail. The timer quiesce in that branch matters because the racing drop does not always queue that pass: rds_conn_path_drop() returns without queueing when a destroy is pending - exactly the situation during a netns teardown or module unload, when a FIN on the dying socket is processed while rds_conn_path_destroy() flushes cp_down_w. If the flushed pass is the one that takes this return, no later pass exists, and rds_conn_path_destroy() would find cp_conn_w still armed (WARN_ON) and then free a path whose reconnect timer can still fire. With the cancel in the branch, every exit of a shutdown pass leaves the timer quiesced no matter which pass completes the transition. The FIN case keeps making progress, one pass later and still without noisy logging. Any other state keeps today's rds_conn_path_error() handling; no current cp_state writer can leave a DISCONNECTING path in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from a non-DISCONNECTING state), so that branch is defensive. On kernels without the preceding patches the same hazard exists with the sample-based quiesce; the fix applies there equally.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98069", "url": "https://ubuntu.com/security/CVE-2026-98069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire the fastpath locks in rds_conn_shutdown() rds_conn_shutdown() quiesces the transmit and receive-refill paths by waiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and then runs the transport shutdown and rds_conn_path_reset(). Sampling the bits clear is not the same as owning them: the moment after the wait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or rds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run concurrently with the teardown. The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the transmit state under it. Oracle UEK fixed the same class of crashes - a 14-year tail of BUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL dereferences in rds_ib_send_cqe_handler() during failover testing - by making the teardown path *acquire* the fastpath bit locks instead of testing them (\"rds: Make sure transmit path and connection tear-down does not run concurrently\"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed. Do the same here: take both locks before calling the transport shutdown, hold them across rds_conn_path_reset(), and release them explicitly with a wake-up afterwards. Both are released with clear_bit_unlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rds_send_path_reset() are ordered before either bit is seen clear by the next acquire_in_xmit() or acquire_refill(). The fastpath users of these bits - rds_send_xmit() and rds_ib_recv_refill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rds_tcp_reset_callbacks() is different: since the previous patch it acquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rds_tcp_accept_one() on the single-threaded krdsd workqueue and holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown(). An IB path's drain in rds_ib_conn_path_shutdown() has no round cap, but no blocking waiter either: rds_tcp_reset_callbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDS_CONN_DISCONNECTING. Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on the path's ordered cp_wq, whose only execution slot is occupied by the blocked cp_down_w itself, so they are pending at most and cancel without flushing - a reliance on cp_wq being ordered that is now noted next to those cancels (on ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98070", "url": "https://ubuntu.com/security/CVE-2026-98070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks() rds_tcp_reset_callbacks() quiesces the transmit path by setting the path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to be sampled clear before swapping the underlying socket and calling rds_send_path_reset(). Sampling the bit clear is not the same as owning it: rds_send_xmit() can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its state recheck after taking the lock is a store-buffering pattern (the resetter writes the state and reads the bit, the sender writes the bit and reads the state) and acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write and the transmit path then runs concurrently with rds_send_path_reset() rewriting cp_xmit_* state - which is exactly what the comment above rds_send_path_reset() tells its callers to prevent. Take the lock instead, hold it across the socket swap and rds_send_path_reset(), and release it with a wake-up at the end. The lock-ordering constraint documented above the wait still holds: the lock is acquired before lock_sock(), so a sender inside tcp_sendmsg() can never be waited on while we hold the socket lock. Two details of the old code go away with the same change: - t_sock is now read only after the lock is acquired. The old code cached it before waiting; the teardown in rds_conn_shutdown() releases that socket and clears t_sock, so a pointer cached before the wait can be stale by the time the accept path resumes. Reading it under RDS_IN_XMIT is what makes the exclusion complete once the teardown owns the same lock, which the next patch arranges; until then the teardown still only samples the bit, and the two paths remain as exposed to each other as they are today. - The old !osock early path called rds_send_path_reset() with no serialization at all. It now runs under the lock like the normal path. The conditional RDS_CONN_RESETTING transition of the previous patch happens before the socket check either way: a path found without a socket is either still connecting (its reconnect worker blocked on t_conn_path_lock) and legitimately goes RESETTING -> UP on the new socket, or it has been torn down meanwhile and is dropped. The in-function comment describing the old wait-based quiesce is rewritten to describe the lock-based one, and the stale block comment above the function (which still described a return value and an incomplete list of t_sock writers) is refreshed to name all four writers - the connect, accept, teardown and swap paths - and what serializes each of them.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98071", "url": "https://ubuntu.com/security/CVE-2026-98071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: clear cp_flags bits individually in rds_conn_path_reset() rds_conn_path_reset() wipes the whole flag word with a plain cp->cp_flags = 0 store. Every other accessor of that word uses atomic bitops, and some of them can run concurrently with the reset: RDS_LL_SEND_FULL is set from rds_send_xmit() and cleared from the transport completion paths, neither of which holds anything that excludes the shutdown worker. A plain store racing an atomic read-modify-write on the same word is a data race, and whichever side loses has its update silently discarded. Clear the two bits the reset is actually responsible for instead. RDS_IN_XMIT and RDS_RECV_REFILL need no store at all here: they belong to the caller, rds_conn_shutdown(), which waits for both to be clear before calling the transport shutdown and this reset. This also gives every bit in cp_flags a single well-defined writer discipline, which the following patches rely on when they turn RDS_IN_XMIT and RDS_RECV_REFILL into bit locks held across the teardown: a blanket store mid-teardown would destroy lock ownership that an atomic clear preserves. Oracle UEK carries the same conversion (\"net/rds: Preserve essential connection state flags\"), motivated by its asynchronous shutdown state machine, whose progress and destroy flags must survive the reset. UEK's variant also clears RDS_IN_XMIT and RDS_RECV_REFILL because there the reset runs as the final step of a teardown that owns both bits, making those clears its unlock. Upstream that release belongs in rds_conn_shutdown(): once a later patch in this series turns the two bits into locks held across the teardown, ending ownership needs release semantics and a wake-up that a plain clear inside the reset would not provide. Based on Oracle UEK commit \"net/rds: Preserve essential connection state flags\" by Gerd Rausch.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98072", "url": "https://ubuntu.com/security/CVE-2026-98072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in release_in_xmit() release_in_xmit() clears RDS_IN_XMIT with clear_bit_unlock() and then checks waitqueue_active() to decide whether anyone needs waking. clear_bit_unlock() is only a release operation: it orders the critical section before the bit clear, but does not order the subsequent plain load of the wait queue head after it. The waiter side does the mirror image - it adds itself to the wait queue and then tests the bit. That is the classic store-buffering pattern: the releasing CPU can read the wait queue as empty while the waiting CPU still reads the bit as set, so the sleeper is never woken. The waiters are rds_conn_shutdown() and rds_tcp_reset_callbacks(), both in uninterruptible wait_event() with no timeout. A lost wake-up strands the shutdown worker on its single-threaded workqueue until some other sender releases the bit again - and on a connection that is being torn down precisely because it failed, there may never be another sender. The barrier used to be there: release_in_xmit() did clear_bit() followed by smp_mb__after_atomic() until commit 1422f28826d2 (\"rds: introduce acquire/release ordering in acquire/release_in_xmit()\") folded both into clear_bit_unlock(), which strengthened the lock hand-off but silently dropped the full barrier the wake-up check depends on. The refill counterpart, release_refill() in net/rds/ib_recv.c, still carries its smp_mb__after_atomic() for exactly this reason. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98074", "url": "https://ubuntu.com/security/CVE-2026-98074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: do not clear curr_active_slave prematurely when releasing all slaves When releasing all slaves during bond destruction (all == true), __bond_release_one() unconditionally clears bond->curr_active_slave to NULL in every iteration. If a backup slave is released before the active slave, bond_alb_deinit_slave() triggers rlb_teach_disabled_mac_on_primary(), which increments the active slave dev promiscuity counter and sets bond_info->primary_is_promisc = 1. Because bond->curr_active_slave was prematurely cleared to NULL when releasing the backup slave, the subsequent iteration releasing the active slave evaluates oldcurrent as NULL, so bond_change_active_slave(bond, NULL) is skipped. Consequently, bond_alb_handle_active_change() is never called to decrement the promiscuity counter, permanently leaking promiscuous mode on the physical device after bond teardown. When oldcurrent == slave, bond_change_active_slave(bond, NULL) already sets bond->curr_active_slave to NULL. We only need to avoid selecting a new active slave when all == true. Replace the if (all) branch with if (!all && oldcurrent == slave).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98075", "url": "https://ubuntu.com/security/CVE-2026-98075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject BPF_PSEUDO_FUNC reference to the main program fixups.c:jit_subprogs() rewrites BPF_PSEUDO_FUNC loads to contain real function addresses. This function is invoked from bpf_jit_subprogs() only when env->subprog_cnt > 1. Meaning that for any program like below: int main(void *ctx) { void *ptr = main; ... bpf_timer_set_callback(..., ptr); ... } The 'ptr' won't be ever converted to contain an address. In combination with e.g. bpf_timer_set_callback() this would lead to a function call at a bogus address. Instead of complicating the implementation, just assume that no useful program needs main to be a sync or async callback and reject BPF_PSEUDO_FUNC loads for the main subprogram.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98076", "url": "https://ubuntu.com/security/CVE-2026-98076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/probes: Fix use-after-free on field name/type of events with multiple probes The fields of a probe-based dynamic event (kprobe, uprobe, eprobe and fprobe events) are created in traceprobe_define_arg_fields() by handing the probe_arg name/type strings to trace_define_field(), which only stores the pointers without copying. Those strings are owned by the trace_probe and are freed when that probe is removed. An event can have several probes attached. The field list is defined only once, by the first probe that registers the event, but it is kept alive by any surviving sibling probe. Deleting just that first probe by symbol - # primary A: fields are defined from A's args echo 'p:kprobes/ev vfs_read a1=$arg1' > kprobe_events # append B: shares A's event call echo 'p:kprobes/ev vfs_write a1=$arg1' >> kprobe_events # delete only A (matched by symbol), B survives echo '-:kprobes/ev vfs_read' >> kprobe_events frees A's args (trace_probe_cleanup() -> traceprobe_free_probe_arg()), but trace_probe_unlink() keeps the trace_probe_event because the probe list is not empty. The event call stays registered via B while its fields now reference freed memory. Any field lookup then reads it, e.g. echo 'a1 == 1' > events/kprobes/ev/filter BUG: KASAN: slab-use-after-free in strcmp+0xa7/0xb0 Call Trace: strcmp trace_find_event_field parse_pred process_preds create_filter apply_event_filter event_filter_write field->name references parg->name (kstrdup'd, freed with the probe) and, for array arguments, field->type references parg->fmt (kmalloc'd, freed with the probe) - the scalar type otherwise points at the static fmttype rodata, which is safe. Have traceprobe_define_arg_fields() duplicate the name and type strings and anchor the copies on the trace_probe_event, which embeds the event call and outlives every individual probe; trace_probe_event_free() releases them. The reproducer above triggers reliably; the field lookup and the delete both run under event_mutex, so this is a dangling reference after removal rather than a race. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98077", "url": "https://ubuntu.com/security/CVE-2026-98077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace() sip_skip_whitespace() returns dptr unchanged when its own loop exhausts the buffer (dptr == limit), instead of NULL like its sibling sip_follow_continuation() returns on its own \"no more data\" path. ct_sip_get_header() only checks for NULL after calling it: dptr = sip_skip_whitespace(dptr, limit); if (dptr == NULL) break; if (*dptr != ':' || ++dptr >= limit) break; so a recognized header name followed only by spaces/tabs running to the exact end of the SIP payload, with no colon, makes the very next statement read one byte past the buffer. Make both \"no more data\" outcomes return NULL, matching the convention sip_follow_continuation() already uses and that both existing callers already check for.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98078", "url": "https://ubuntu.com/security/CVE-2026-98078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix reversed sequence option serialization hton_seq() expects the host-order source first and the unaligned network-order destination second. The version 1 sync sender passes these arguments in reverse for both sequence blocks. This leaves 24 bytes of the kmalloc-backed message unwritten. It may disclose stale heap data and replace the live connection sequence state with values read from the buffer. Pass the connection sequence state as the source and the message payload as the destination for both blocks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98080", "url": "https://ubuntu.com/security/CVE-2026-98080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not force reloc root creation during qgroup_account_snapshot() [BUG] When running btrfs/252 with quota enabled through MKFS_OPTIONS=\"-O quota\", it has a high chance to trigger the following kernel warning and flips the fs RO: BTRFS info (device dm-2): relocating block group 30408704 flags metadata|dup ------------[ cut here ]------------ WARNING: fs/btrfs/extent-tree.c:879 at lookup_inline_extent_backref+0x74b/0x960 [btrfs], CPU#4: btrfs/2173 CPU: 4 UID: 0 PID: 2173 Comm: btrfs Not tainted 7.2.0-rc6-custom+ #457 PREEMPT(full) 3adc6528fb66f7a55fe1095385818e742f200aab Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:lookup_inline_extent_backref+0x74b/0x960 [btrfs] Call Trace: insert_inline_extent_backref+0x7c/0x160 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_inc_extent_ref+0xa9/0x270 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_run_delayed_refs+0x4af/0x11c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_run_delayed_refs+0x9d/0xf0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshot+0x39d/0xf00 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshots+0x9b/0xc0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_commit_transaction+0x280/0xeb0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] prepare_to_relocate+0x147/0x200 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] relocate_block_group+0x6b/0x5e0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_block_group+0x92c/0x2380 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_balance+0xa2c/0x19c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_ioctl+0x2839/0x2d30 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS info (device dm-2): leaf 4593991680 gen 233 total ptrs 175 free space 5953 owner 2 BTRFS info (device dm-2): refs 3 lock_owner 2173 current 2173 \titem 0 key (166772736 METADATA_ITEM 1) itemoff 16250 itemsize 33 \t\textent refs 1 gen 222 flags 2 \t\tref#0: tree block backref root 266 [ Skip the tree dump ] \titem 174 key (263225344 METADATA_ITEM 0) itemoff 10328 itemsize 33 \t\textent refs 1 gen 162 flags 258 \t\tref#0: tree block backref root 267 BTRFS error (device dm-2): extent item not found for insert, bytenr 179847168 num_bytes 16384 parent 4594335744 root_objectid 273 owner 0 offset 0 BTRFS error (device dm-2): failed to run delayed ref for logical 179847168 num_bytes 16384 type 182 action 1 ref_mod 1: -117 [CAUSE] The above error is showing that there is a tree reference to a metadata extent that is no longer there. With \"ref_verify\" mount option (requires CONFIG_BTRFS_DEBUG), there is some extra debug output: BTRFS error (device dm-2): dumping block entry [180961280 16384], num_refs 0, metadata 1, from disk 0 BTRFS error (device dm-2): root entry 256, num_refs 18446744073709551615 BTRFS error (device dm-2): root entry 273, num_refs 18446744073709551615 BTRFS error (device dm-2): Ref action 3, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 1 btrfs_force_cow_block+0x129/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_insert_empty_items+0x3a/0x70 [btrfs] insert_with_overflow+0x53/0x130 [btrfs] btrfs_insert_dir_item+0x125/0x290 [btrfs] btrfs_add_link+0xaa/0x410 [btrfs] btrfs_rename+0x5ea/0xcd0 [btrfs] btrfs_rename2+0x28/0x60 [btrfs] vfs_rename+0x5b2/0xe10 filename_renameat2+0x244/0x430 __x64_sys_rename+0x48/0x70 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98088", "url": "https://ubuntu.com/security/CVE-2026-98088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() dev_to_node() can return NUMA_NO_NODE (-1) on systems without NUMA topology information for the PCI device, such as single-socket boards that don't expose device-to-node affinity. Passing -1 directly into cpumask_of_node() indexes node_to_cpumask_map[-1], an out-of-bounds array read caught by UBSAN: UBSAN: array-index-out-of-bounds in arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' Fall back to cpu_online_mask when no NUMA node is available, rather than assuming dev_to_node() always returns a valid node index.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98090", "url": "https://ubuntu.com/security/CVE-2026-98090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: restore active device pointers after failed sprout btrfs_init_new_device() switches latest_dev and possibly s_bdev from the seed device to the new sprout device before creating the first writable chunks. If chunk creation or the subsequent sprout setup fails, the error path releases the new device without switching those pointers back. btrfs_show_devname() can then dereference the freed latest_dev and crash. Restore the active device pointers to the latest seed device before removing and releasing the failed sprout device.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98091", "url": "https://ubuntu.com/security/CVE-2026-98091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: detach failed sprout device from transaction update list When creating the first metadata chunk for a sprout filesystem, create_chunk() adds the new device to the transaction dev_update_list through device->post_commit_list. If the subsequent system chunk creation fails, btrfs_init_new_device() aborts the transaction and releases the device while post_commit_list is still linked. This triggers a warning in btrfs_free_device() and leaves the transaction list referencing freed memory. Detach the device while holding chunk_mutex before releasing it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98094", "url": "https://ubuntu.com/security/CVE-2026-98094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: fbtft: make dirty_lock IRQ-safe fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled. Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again. The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled: WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2} CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); lock(console_owner); *** DEADLOCK *** Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98095", "url": "https://ubuntu.com/security/CVE-2026-98095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_packet: Don't cast tpacket_hdr.tp_len to int in tpacket_parse_header(). syzbot reported BUG() in sock_sendmsg_nosec(). [0] The problem is that tpacket_parse_header() casts user-provided tpacket_hdr.tp_len, which is u32, to int. If the length is larger than INT_MAX, the following condition in tpacket_parse_header() passes, if (unlikely(tp_len > size_max)) and any negative value can be returned to the caller, up to sock_sendmsg_nosec(). The repro set tpacket_hdr.tp_len to 0xfffffdef, which is cast to -EIOCBQUEUED (-529), triggering BUG() in sock_sendmsg_nosec(). *(uint64_t*)0x200000000008 = 0xfffffdef; ... syscall(__NR_write, /*fd=*/r[0], /*buf=*/0x200000000000ul, /*count=*/1ul); Let's define the local tp_len as u32 in tpacket_parse_header(). [0]: kernel BUG at net/socket.c:803! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 5628 Comm: syz-executor176 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 RIP: 0010:sock_sendmsg_nosec+0x145/0x180 net/socket.c:803 Code: 06 67 48 0f b9 3a eb 95 e8 e8 3a 22 f8 48 89 df 4c 89 f6 4c 89 e2 4d 89 fb 2e e8 32 a5 5c 16 e9 51 ff ff ff e8 cc 3a 22 f8 90 <0f> 0b e8 c4 3a 22 f8 48 83 c3 18 48 89 d8 48 c1 e8 03 42 80 3c 28 RSP: 0018:ffffc90003aefb48 EFLAGS: 00010293 RAX: ffffffff89a578d4 RBX: ffff8880764c67c0 RCX: ffff88807fb23e80 RDX: 0000000000000000 RSI: 00000000fffffdef RDI: 00000000fffffdef RBP: 00000000fffffdef R08: ffffc90003aef747 R09: 1ffff9200075dee8 R10: dffffc0000000000 R11: fffff5200075dee9 R12: 0000000000000001 R13: dffffc0000000000 R14: ffffc90003aefbc0 R15: ffffffff8aac4310 FS: 000055559101b400(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000210 CR3: 0000000073dca000 CR4: 00000000003526f0 Call Trace: __sock_sendmsg net/socket.c:815 [inline] sock_write_iter+0x2de/0x3e0 net/socket.c:1266 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x612/0xba0 fs/read_write.c:687 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f173130ecb9 Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 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 d8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd67e44248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f173130ecb9 RDX: 0000000000000001 RSI: 0000200000000000 RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd67e44388 R13: 0000000000000002 R14: 00002000000000c0 R15: 0000000000000002 ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98096", "url": "https://ubuntu.com/security/CVE-2026-98096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: restore network header before routing and forwarding ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative. This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows. Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98098", "url": "https://ubuntu.com/security/CVE-2026-98098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL deref in tipc_named_node_up() on empty publication list User-space applications can bind a large number of service addresses to one or more sockets. Each binding of a local-scope service address inserts one entry (publication) into the TIPC name table. If the number of these publications exceeds TIPC_MAX_PUBL (65535), protocol service types (such as node state and link state) are no longer inserted into the name table. This causes two issues: 1. User-space applications subscribing to node or link up/down events stop receiving notifications. 2. A NULL pointer dereference can occur: BUG: kernel NULL pointer dereference, address: 00000000000000d0 ... CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full) ... RIP: 0010:tipc_named_node_up (./include/linux/skbuff.h:2251 net/tipc/name_distr.c:195 net/tipc/name_distr.c:221) ... Call Trace: tipc_node_write_unlock (net/tipc/node.c:428) tipc_rcv (net/tipc/node.c:934 net/tipc/node.c:2189) tipc_udp_recv (net/tipc/udp_media.c:389) Thread 1 (tipc_net_finalize) | Thread 2 (named_distribute) -----------------------------|----------------------------- | ... | list_for_each_entry(publ, pls, binding_node) { | ... | __skb_queue_tail(list, skb); | ... | } | ... | hdr = buf_msg(skb_peek_tail(list)); ... | tipc_nametbl_publish(); | If 'tipc_nametbl_publish()' (Thread 1) fails because the number of local publications reaches TIPC_MAX_PUBL, list (Thread 2) will be empty. As a result, NULL is passed to 'buf_msg()', leading to a NULL pointer dereference. Fix these issues by allowing protocol service types (node state, link state, and topology server) to be inserted into the name table unconditionally. This ensures that users subscribing to these types always receive notifications. In addition, the maximum number of local user publications is reduced to (TIPC_MAX_PUBL - 1). This ensures that the maximum bulk size calculated in tipc_link_set_queue_limits() remains valid.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98108", "url": "https://ubuntu.com/security/CVE-2026-98108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan l2cap_new_connection() sets default value of channel mode to match the parent channel. l2cap_le_connect_req() left this at the default, and created L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that mode. This causes FLAG_DEFER_SETUP channels to reply to L2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect. It can also result to stack OOB write (of l2cap_alloc_cid determined values) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not limit maximum number of deferred channels or check for duplicate ident. Fix by setting chan->mode correctly in l2cap_le_connect_req(). Also check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE instead of OOB write to make it less brittle.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98113", "url": "https://ubuntu.com/security/CVE-2026-98113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: rate limit unmapped SID errors A client can include many structurally valid but unmapped SIDs in a DACL. Logging every mapping failure lets one request generate hundreds of kernel error messages. Rate limit the message to prevent an authenticated client from flooding the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98116", "url": "https://ubuntu.com/security/CVE-2026-98116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation with an mmap_count check performed under the PCM stream lock, but the lock is released long before the buffer is actually freed: snd_pcm_sync_stop(), constraint refinement and do_free_pages() all happen in between. snd_pcm_mmap_data(), on the other hand, takes no lock at all: it validates against the old buffer's state and dma_bytes, remaps its pages into the VMA, and only then increments mmap_count. A concurrent mmap() can therefore slip in between the check and the free. remap_pfn_range() installs writable PTEs for the old buffer's pages without taking page references, and the subsequent do_free_pages() returns those pages to the page allocator while the VMA still maps them. This leaves a stale, writable mapping of freed pages: a page-level use-after-free that can be leveraged for local privilege escalation. Make snd_pcm_mmap_data() participate in the buffer-access scheme introduced for hw_params/hw_free: acquire runtime->buffer_accessing before validating and remapping, and release it afterwards. Buffer reallocation already fails with -EBUSY while accessors are active, and the mmap side now fails with -EBUSY while a reallocation is in progress, so the validate/remap sequence and the check/free sequence can no longer interleave. A reproducer that turns this race into a stale writable mapping of the freed DMA buffer pages is available on request.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98121", "url": "https://ubuntu.com/security/CVE-2026-98121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix NULL pointer dereference in PM callbacks msc313e_wdt_probe() doesn't set the driver data for the platform device. As a result, dev_get_drvdata() in msc313e_wdt_suspend() and msc313e_wdt_resume() will return NULL, leading to a NULL pointer dereference afterward. Set the platform device driver data in msc313e_wdt_probe().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98123", "url": "https://ubuntu.com/security/CVE-2026-98123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration sctp_verify_asconf() walks ASCONF-ACK parameters with sctp_walk_params(), which advances by SCTP_PAD4(length), while the consumer sctp_get_asconf_response() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset. When those bytes yield a length of zero, the while loop over asconf_ack_len makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help). The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read. Reject SCTP_PARAM_ERR_CAUSE parameters shorter than sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERR_CAUSE parameter the consumer can see, so the consumer's asconf_ack_len check is dropped and it returns err_param->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTP_PARAM_ERR_CAUSE per RFC 5061. The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98130", "url": "https://ubuntu.com/security/CVE-2026-98130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START The SCTP_CMD_TIMER_START handler checks timer_pending() before calling timer_reduce(). The timer can expire and detach between these operations, causing timer_reduce() to rearm the timer without taking the association reference required for the newly armed timer. The timer callback later unconditionally drops its association reference, which can leave the association reference count unbalanced and result in use-after-free during association teardown. Use the return value of timer_reduce() to determine whether the timer was actually armed. Take the association reference only when timer_reduce() successfully starts a new timer, closing the race between checking the timer state and rearming it. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98154", "url": "https://ubuntu.com/security/CVE-2026-98154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix -EIO cleanup order in queue_rq On -EIO, the RDMA queue_rq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete. Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98157", "url": "https://ubuntu.com/security/CVE-2026-98157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation The poll_msec sysfs store file uses simple_strtoul() which accepts an unsigned long, but the target field (poll_msec) is unsigned int. On 64-bit systems, a value > UINT_MAX is silently truncated when stored. Fix the mismatch by using kstrtouint() instead. This rejects values larger than UINT_MAX at parse time, making truncation impossible. Also add a check for value < 1 to reject the 0-delay case, which would cause the poll work to spin without delay and consume 100% CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89796", "url": "https://ubuntu.com/security/CVE-2026-89796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid infinite kdamond_merge_regions() internal loop Patch series \"mm/damon: unurgent fixes for infinite loop, NULL de-ref and races\", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-98158", "url": "https://ubuntu.com/security/CVE-2026-98158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_async: drop the errored frame instead of resetting its headroom ppp_receive_nonmp_frame() prepends a two-byte direction tag before running the pass/active BPF filters: \t*(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG); Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in ppp_async's process_input_packet() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD: \terr: \t\tif (skb) { \t\t\t/* make skb appear as freshly allocated */ \t\t\tskb_trim(skb, 0); \t\t\tskb_reserve(skb, - skb_headroom(skb)); \t\t} ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head: skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev: kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled ppp_decompress_frame() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason. Rather than restore the headroom, drop the errored frame - as ppp_synctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read. The original V1 of this patch made room in ppp_receive_nonmp_frame() with skb_cow_head(); Eric pointed out that fixing the root cause in the transport is the right approach. Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-93288", "url": "https://ubuntu.com/security/CVE-2026-93288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state sashiko reports: \"nfnl_log_net_exit() calls nf_log_unset(), which clears the logger pointer without an RCU grace period. Immediately after, ops_free_list() frees the per-net state while concurrent packets might still be executing nf_log_packet() under rcu_read_lock().\" Clear the pointer via .pre_exit to make sure rcu readers have completed before pernet storage is free'd. The change in nf_log_syslog.c is only done for consistency: it doesn't use pernet data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93782", "url": "https://ubuntu.com/security/CVE-2026-93782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: flush backend after device ioctls vhost-scsi translates guest response descriptors into userspace iovecs when commands are submitted. Target-core completes those commands asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while an in-flight command still retains response iovecs translated through the old table. If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command completion can write the response to an unrelated userspace object. Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device ioctl. This waits for in-flight commands that can still use the old response iovecs before the ioctl returns.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93783", "url": "https://ubuntu.com/security/CVE-2026-93783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr and dereferences hdr->addr and hdr->ctrl without validating skb->len first. A truncated frame with skb->len less than the minimum header size causes an out-of-bounds read of uninitialized memory. Additionally, a zero-length frame causes skb->len-- to underflow to UINT_MAX, making skb_tail_pointer() read far past the buffer. Commit 23882b828c3c (\"Bluetooth: RFCOMM: validate skb length in MCC handlers\") fixed the same class of missing-length-check bugs in the MCC sub-handlers, but the top-level rfcomm_recv_frame() was left unfixed. KMSAN reports: BUG: KMSAN: uninit-value in rfcomm_run ... Uninit was created at: __alloc_skb+0x474/0xb60 vhci_write+0xe9/0x870 Fix this by rejecting frames smaller than sizeof(struct rfcomm_hdr) + 1 (the minimum frame must have a 3-byte header and a 1-byte FCS).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93784", "url": "https://ubuntu.com/security/CVE-2026-93784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie() The KASAN allocation trace shows that a malformed IE buffer is stored via SIOCSIWGENIE (cfg80211_wext_siwgenie()) without any validation. The crash trace shows that a subsequent SIOCSIWESSID triggers a connection attempt which calls cfg80211_sme_get_conn_ies() to process the stored IE buffer, causing: - An out-of-bounds read in skip_ie() which reads ies[pos+1] (the length byte) past the end of the 1-byte buffer. - An integer underflow in the memcpy size argument when offs returned by ieee80211_ie_split() exceeds ies_len, causing unsigned subtraction to wrap to SIZE_MAX and triggering a fortify panic. Fix this by validating the IE buffer in cfg80211_wext_siwgenie() before storing it. [drop unnecessary ie_len check, update commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93785", "url": "https://ubuntu.com/security/CVE-2026-93785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate idmap key payload length The cifs.idmap key type stores its payload length in key->datalen, which is limited to U16_MAX. Accepting a larger key payload truncates the recorded length and can make later users interpret the payload using inconsistent bounds. Reject oversized preparsed payloads before allocating or copying them. This keeps key->datalen consistent with the stored data for both inline and separately allocated idmap payloads.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93789", "url": "https://ubuntu.com/security/CVE-2026-93789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: bound aligned TLV advance in FW parser Validate ALIGN(tlv_len, 4) against remaining parser length before consuming bytes from the firmware image. This avoids length underflow on malformed TLVs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93795", "url": "https://ubuntu.com/security/CVE-2026-93795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix leaks and online flag on radix_tree_insert failure When radix_tree_insert() fails in blkg_create(), the error path has two issues: 1. blkg->online is set to true unconditionally, even when the blkg was never fully inserted. Move the assignment inside the success block. 2. The error path calls blkg_put() without first calling percpu_ref_kill(). Because the refcount is still in percpu mode, percpu_ref_put() only does this_cpu_sub() without checking for zero, so blkg_release() is never triggered. This permanently leaks the blkg memory, its percpu iostat, policy data, the parent blkg reference, and the cgroup css reference — the latter preventing the cgroup from ever being destroyed. Fix by replacing blkg_put() with percpu_ref_kill(), matching the pattern used in blkg_destroy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93797", "url": "https://ubuntu.com/security/CVE-2026-93797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix an off-by-1 boundary check Before looking at the 11th byte, check the length is big enough.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93798", "url": "https://ubuntu.com/security/CVE-2026-93798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix reloc root cleanup in merge_reloc_roots() If the root we got has zero root refs in its root item, we are resetting the root's ->reloc_root without using barriers like we do everywhere else. Sashiko complained about this while reviewing another patch, and it's correct (see the Link tag below). Also, we should not clear BTRFS_ROOT_DEAD_RELOC_TREE from the root unless the root points to the reloc root we have. Fix this by using clear_reloc_root(), which issues the memory barrier after setting the root's ->reloc_root to NULL and before clearing the bit BTRFS_ROOT_DEAD_RELOC_TREE from the root.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93800", "url": "https://ubuntu.com/security/CVE-2026-93800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol() If during relocation we fail in insert_dirty_subvol() because btrfs_update_reloc_root() returned an error, we will leave a root's reloc_root field pointing to a reloc root that was freed instead of NULL, resulting later in a use-after-free, or double free attempt during unmount. The sequence of steps is this: 1) During relocation the call to btrfs_update_reloc_root() in insert_dirty_subvol() fails, so insert_dirty_subvol() returns the error to merge_reloc_root() without adding the root to the list rc->dirty_subvol_roots; 2) Then merge_reloc_root() aborts the current transaction because insert_dirty_subvol() returned an error; 3) Up the call chain, merge_reloc_roots() gets the error, adds the reloc root for root X to the local reloc_roots list and jumps to the 'out' label, where it calls free_reloc_roots() to free all the reloc roots in the local reloc_roots list. This frees the reloc root for root X; 4) We go up the call chain to relocate_block_group() which calls clean_dirty_subvols() to go over dirty roots and set their ->reloc_root field to NULL, but root X is not in the dirty_subvol_roots list, so its ->reloc_root still points to a reloc root; 5) Relocation finishes, with an error and a transaction abort, but the ->reloc_root field for root X still points to the reloc root that was freed in step 3; 6) When unmounting the fs we end up calling: btrfs_free_fs_roots() btrfs_drop_and_free_fs_root() --> calls btrfs_put_root() against root X's ->reloc_root which is not NULL and points to the already freed reloc root in step 4 above Resulting in a use-after-free to a double free attempt. Syzbot reported this with the following dmesg/syslog: [ 106.004389][ T5339] BTRFS error (device loop0 state A): Transaction aborted (error -5) [ 106.014266][ T5339] BTRFS: error (device loop0 state A) in merge_reloc_root:1655: errno=-5 IO failure [ 106.021891][ T1061] BTRFS error (device loop0 state A): error while writing out transaction: -5 [ 106.026964][ T1061] BTRFS warning (device loop0 state A): Skipping commit of aborted transaction. [ 106.033807][ T5340] BTRFS error (device loop0 state A): bdev /dev/loop0 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 [ 106.039265][ T1061] BTRFS: error (device loop0 state A) in cleanup_transaction:2067: errno=-5 IO failure [ 106.044382][ T5339] BTRFS info (device loop0 state EA): forced readonly [ 106.074329][ T5339] BTRFS: error (device loop0 state EA) in merge_reloc_roots:1887: errno=-5 IO failure [ 106.081004][ T5356] BTRFS info (device loop0 state EA): scrub: started on devid 1 [ 106.085611][ T5339] BTRFS info (device loop0 state EA): balance: ended with status: -30 [ 106.089517][ T5356] BTRFS info (device loop0 state EA): scrub: not finished on devid 1 with status: -30 [ 106.662365][ T5338] BTRFS info (device loop0 state EA): last unmount of filesystem 3a375e4e-b156-4d76-a2ad-16e198ce1409 [ 106.682946][ T5338] ================================================================== [ 106.686574][ T5338] BUG: KASAN: slab-use-after-free in btrfs_put_root+0x2f/0x250 [ 106.690090][ T5338] Write of size 4 at addr ffff88803f978630 by task syz.0.0/5338 [ 106.693173][ T5338] [ 106.694279][ T5338] CPU: 0 UID: 0 PID: 5338 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) [ 106.694293][ T5338] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 106.694300][ T5338] Call Trace: [ 106.694308][ T5338] [ 106.694314][ T5338] dump_stack_lvl+0xe8/0x150 [ 106.694331][ T5338] print_address_description+0x55/0x1e0 [ 106.694343][ T5338] ? btrfs_put_root+0x2f/0x250 [ 106.694358][ T5338] print_report+0x58/0x70 [ 106. ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93802", "url": "https://ubuntu.com/security/CVE-2026-93802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: validate beacon length before fixed buffer copy rsi_prepare_beacon() copies the mac80211 beacon frame after FRAME_DESC_SZ into a management skb whose usable tailroom may be smaller than MAX_MGMT_PKT_SIZE after alignment. Validate the beacon length against the actual tailroom before the copy and skb_put(). Leave ownership of the management skb with the caller on error, matching the existing rsi_send_beacon() cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93803", "url": "https://ubuntu.com/security/CVE-2026-93803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libipw: fix key index receive bound checks libipw_rx() reads skb->data[hdrlen + 3] to extract the WEP key index in both the software-decrypt key selection path and the hardware-decrypted IV/ICV strip path. In both places the existing guard only checks skb->len >= hdrlen + 3, which proves bytes up to hdrlen + 2 but not the byte at hdrlen + 3. Require hdrlen + 4 bytes before reading that item in both paths. This is a local source-boundary check only; it does not change the key index semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93805", "url": "https://ubuntu.com/security/CVE-2026-93805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate rx/tx MLME callback frame lengths before access cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints before rejecting frames shorter than the frame-control field. After that, they only require len >= 2 before dispatching into subtype handlers that assume their fixed fields are present. The frames that trip this are not shorter than 2 bytes; they are short relative to their subtype. mwifiex is a concrete in-tree example on the length side: mwifiex_process_mgmt_packet() only requires a 4-address ieee80211_hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and removing addr4, pkt_len can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARN_ON(len < 2) does not fire on such a frame, and cfg80211_process_deauth() then reads u.deauth.reason_code as a two-byte access starting at offset 24, immediately past the 24-byte buffer. Add a frame-control length gate, then validate each subtype's minimum frame size in an if/else-if chain that mirrors the dispatch logic. Trace only after the frame is known to be well-formed. Side effects of this change: - The WARN_ON(len < 2) is dropped. It only guarded the frame_control read, never the subtype fixed fields, and it does not fire on the frames that actually trigger the out-of-bounds read (which are >= 2). The len >= 2 check is kept as the guard before dereferencing frame_control, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93807", "url": "https://ubuntu.com/security/CVE-2026-93807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers rsi_hal_load_key() copies tx_mic_key and rx_mic_key from data[16] and data[24] whenever key data is present. Those offsets are only part of the 32-byte TKIP key layout. Shorter keys used by other ciphers, such as CCMP, do not provide those bytes, so the unconditional copies can read past the supplied key buffer. Only copy the MIC keys for TKIP, and reject malformed TKIP keys that are shorter than the expected 32-byte layout. [drop useless length check]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93808", "url": "https://ubuntu.com/security/CVE-2026-93808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: caiaq: validate EP1 reply lengths usb_ep1_command_reply_dispatch() uses buf[0] as a command byte and then reads command-specific fixed items from the same URB buffer. Several paths use buf + 1, buf[1], buf[2], or buf + 3 without first proving that urb->actual_length contains those bytes. Add per-command length checks, use a payload length derived from the bytes after the command byte for the control-state copy, and reject short analog input payloads before the input helper reads fixed offsets from the EP1 reply.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93811", "url": "https://ubuntu.com/security/CVE-2026-93811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling 1. When ndr_decode_v4_ntacl() fails, the code jumped to free_n_data which only freed n.data, skipping kfree(acl.sd_buf) and leaking the buffer. Zero-initialize struct xattr_ntacl acl, reorder error labels to out_free to release acl.sd_buf on all error paths. 2. if (acl.sd_size < sizeof(struct smb_ntsd)) is true, original code returned success without freeing sd_buf and left stale *pntsd. Set rc = -EINVAL before jumping to out_free to return error code and free buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93812", "url": "https://ubuntu.com/security/CVE-2026-93812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr ndr_encode_v4_ntacl() allocates sd_ndr.data via kzalloc() at entry. If any subsequent ndr_write_*() call returns error during encoding, the allocated sd_ndr.data won't be freed and causes memory leak. Move kfree(sd_ndr.data) into out label to ensure the buffer gets released on all success and error return paths.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93813", "url": "https://ubuntu.com/security/CVE-2026-93813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tree-checker: validate INODE_REF's namelen [BUG] A crafted btrfs image can trigger the following crash: BUG: unable to handle page fault for address: ffffd1dc42884000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page CPU: 9 UID: 0 PID: 1034 Comm: poc Not tainted 7.1.0-rc4-custom+ #383 PREEMPT(full) 46af0a92938a63be7132e0dfd71e62327c51d5c2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:memcpy+0xc/0x10 Call Trace: read_extent_buffer+0xe4/0x100 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] btrfs_get_name+0x15e/0x1e0 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] reconnect_path+0x165/0x390 exportfs_decode_fh_raw+0x337/0x400 ? drop_caches_sysctl_handler+0xb0/0xb0 ---[ end trace 0000000000000000 ]--- RIP: 0010:memcpy+0xc/0x10 Kernel panic - not syncing: Fatal exception [CAUSE] TThe crafted image has the following corrupted INODE_REF item: item 9 key (258 INODE_REF 257) itemoff 11544 itemsize 4106 \tindex 2 namelen 4096 name: d\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000 The itemsize matches the namelen, but the namelen is 4096, way larger than normal name length limit (BTRFS_NAME_LEN, 255). Meanwhile the memory of the @name is only 255 byte sized, this will cause out-of-boundary access, and cause the above crash. [FIX] Add extra namelen verification for INODE_REF, just like what we have done in ROOT_REF checks. Now the crafted image can be rejected gracefully: BTRFS critical (device dm-2): corrupt leaf: root=5 block=30572544 slot=14 ino=259, invalid inode ref name length, has 4096 expect [1, 255] BTRFS error (device dm-2): read time tree block corruption detected on logical 30572544 mirror 2 [ Rebase, add a Link: tag, add an simple cause analyze ]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93815", "url": "https://ubuntu.com/security/CVE-2026-93815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: au1000: move free_irq out of the close-time spinlocked section au1000_close() calls free_irq() while aup->lock is still held with spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ descriptor request mutex, so it does not belong inside the close-time spinlocked section. This was found by our static analysis tool and then confirmed by manual review of the in-tree au1000_close() .ndo_stop path. The reviewed path keeps aup->lock held across the MAC reset, queue stop and free_irq(dev->irq, dev). A directed runtime validation kept that ndo_stop carrier and the same free_irq(dev->irq, dev) operation under the driver lock. Lockdep reported \"BUG: sleeping function called from invalid context\" and \"Invalid wait context\" while free_irq() was taking desc->request_mutex, with au1000_close() and free_irq() on the stack. Drop aup->lock before freeing the IRQ. The protected close-time work still stops the device and queue before IRQ teardown, but the sleepable IRQ core path now runs outside the spinlocked section.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93816", "url": "https://ubuntu.com/security/CVE-2026-93816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate inline dentry name lengths before conversion Inline dentry conversion copies names out of the inline dentry area before checking that each recorded name length fits in the available filename slots. A corrupted image can therefore make the conversion path read past the inline filename storage while building the regular dentry block. Validate each inline dentry name length against the inline filename area before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93819", "url": "https://ubuntu.com/security/CVE-2026-93819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93820", "url": "https://ubuntu.com/security/CVE-2026-93820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rockchip: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93821", "url": "https://ubuntu.com/security/CVE-2026-93821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93822", "url": "https://ubuntu.com/security/CVE-2026-93822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: iproc: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93825", "url": "https://ubuntu.com/security/CVE-2026-93825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: Add NULL check for spi_get_device_id() in spi_get_device_match_data() Prevent NULL pointer dereference when spi_get_device_id() returns NULL, which can happen when using driver_override without matching SPI ID entry.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93830", "url": "https://ubuntu.com/security/CVE-2026-93830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac2: disable RBUE in default RX interrupt mask Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97407", "url": "https://ubuntu.com/security/CVE-2026-97407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in set_fmt rockchip_pdm_set_fmt() calls pm_runtime_get_sync() before accessing hardware registers, but ignores its return value. If the runtime resume fails, the function continues to perform register accesses while the device state is undefined. Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() and return early on failure to avoid unpowered register accesses.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97408", "url": "https://ubuntu.com/security/CVE-2026-97408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate connectionless PSM length Connectionless L2CAP frames carry a two-byte PSM at the start of the payload. l2cap_recv_frame() currently reads that PSM unconditionally after validating only the outer L2CAP length. A malformed connectionless frame with a zero- or one-byte payload can therefore make the parser read beyond the advertised skb payload and use tailroom bytes as part of the PSM. A VHCI-backed QEMU reproducer injected a one-byte connectionless payload and reached the unchecked read. Reject connectionless frames that cannot contain the PSM before reading or pulling it. This preserves all valid connectionless frames while dropping only structurally incomplete packets.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97411", "url": "https://ubuntu.com/security/CVE-2026-97411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ibm: emac: mal: fix potential system hang in mal_remove() napi_disable() is not idempotent and calling it on an already-disabled or unenabled NAPI context will cause the kernel to spin indefinitely waiting for the NAPI_STATE_SCHED bit to clear. In mal_remove(), napi_disable() is called unconditionally. If no MACs were registered, NAPI was never enabled. Also, if they were registered but subsequently unregistered, NAPI was already disabled in mal_unregister_commac(). In either case, calling napi_disable() causes the kernel to hang upon module removal. Fix this by only calling napi_disable() in mal_remove() if the commac list is not empty (which implies NAPI is enabled).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97413", "url": "https://ubuntu.com/security/CVE-2026-97413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Fix integer underflow in process_read and process_write usr_len is read from a network-supplied message field (le16_to_cpu) and used to compute data_len = off - usr_len without validating that usr_len <= off. A malicious RDMA client can send usr_len > off causing an integer underflow, resulting in data_len wrapping to a huge size_t value which is then passed to the rdma_ev callback as a memory length, leading to out-of-bounds memory access. Fix by reading and validating usr_len <= off before rtrs_srv_get_ops_ids() in both process_read() and process_write(), ensuring the early return path acquires no reference and has no resource leak.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97416", "url": "https://ubuntu.com/security/CVE-2026-97416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: balance: fix potential bg lookup failure in btrfs_may_alloc_data_chunk() [BUG] Running btrfs balance can trigger a null-ptr-deref before relocating a data chunk when metadata corruption leaves a chunk in the chunk tree without a corresponding block group in the in-memory cache: KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] RIP: 0010:btrfs_may_alloc_data_chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601 Call Trace: __btrfs_balance fs/btrfs/volumes.c:4217 [inline] btrfs_balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604 btrfs_ioctl_balance fs/btrfs/ioctl.c:3577 [inline] btrfs_ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313 ... [CAUSE] __btrfs_balance() iterates the on-disk chunk tree and passes the chunk logical bytenr to btrfs_may_alloc_data_chunk() before relocating a data chunk. That helper then queries the in-memory block group cache: cache = btrfs_lookup_block_group(fs_info, chunk_offset); chunk_type = cache->flags; /* cache may be NULL */ A corrupt image can contain a chunk item whose matching block group item is missing, so no block group is ever inserted into the cache. In that case btrfs_lookup_block_group() returns NULL. The code only guards this with ASSERT(cache), which becomes a no-op when CONFIG_BTRFS_ASSERT is disabled. The subsequent dereference of cache->flags therefore crashes the kernel. [FIX] Add a NULL check after btrfs_lookup_block_group() in btrfs_may_alloc_data_chunk() and print and error message for clarity.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97417", "url": "https://ubuntu.com/security/CVE-2026-97417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack() The timestamp-only fast path dereferences the option stream as *(__be32 *)ptr, which assumes 4-byte alignment that the TCP option stream does not guarantee. Use get_unaligned_be32() instead, which reads the value safely and already returns host byte order, so the htonl() on the comparison constant can be dropped. This matches the existing get_unaligned_be32() use later in the same function.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97418", "url": "https://ubuntu.com/security/CVE-2026-97418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es18xx: check control allocation before private data setup snd_es18xx_mixer() creates controls with snd_ctl_new1() and then stores bookkeeping pointers or sets private_free before calling snd_ctl_add(). snd_ctl_new1() can return NULL on allocation failure, so those writes can dereference a NULL control pointer. Check the returned control pointers before using them and return -ENOMEM on allocation failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97419", "url": "https://ubuntu.com/security/CVE-2026-97419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: broadcast netlink notifications in the device's net namespace The HSR generic netlink family sets .netnsok = true. HSR devices can live in network namespaces other than init_net. Two async notifiers broadcast events with genlmsg_multicast(). They are hsr_nl_ringerror() and hsr_nl_nodedown(). That helper delivers only on the default genl socket in init_net. So the events always land in init_net. The network namespace of the device does not matter. This has two effects. A listener in the device's own namespace never sees its own ring error and node down events. A privileged listener in init_net receives events from HSR devices in other namespaces. The payload carries the peer node MAC (HSR_A_NODE_ADDR) and the slave port ifindex (HSR_A_IFINDEX). Switch both callers to genlmsg_multicast_netns(). Other families with .netnsok = true already do this. Examples are gtp, ovpn, team, batman-adv, netdev-genl, ethtool and handshake. hsr_nl_ringerror() already has the slave port. It uses dev_net(port->dev). hsr_nl_nodedown() takes the namespace from the master port via hsr_port_get_hsr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97420", "url": "https://ubuntu.com/security/CVE-2026-97420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: NUL-terminate replaced sysctl value When writing to sysctls, proc_sys_call_handler() guarantees that the buffer passed to proc handlers is NUL-terminated. If bpf_sysctl_set_new_value() replaces the pending sysctl value, it can hand a replacement buffer directly to proc handlers. However, the helper currently copies only buf_len bytes into that buffer without appending a NUL terminator, leaving downstream parsers vulnerable to out-of-bounds access. Fix this by appending a '\\0' after the replaced value to restore the expected sysctl semantics. Since the helper already rejects buf_len greater than PAGE_SIZE - 1, there is always room for the extra byte. Reproduced in a QEMU x86_64 guest booted with KASAN while exercising the sysctl replacement path with a cgroup/sysctl BPF program. The reproducer targets `/proc/sys/net/core/flow_limit_cpu_bitmap`, fills the original user write buffer with non-zero bytes, and overrides the sysctl value so the replacement buffer lacks a terminating NUL. Under that setup, the pre-fix kernel reported: BUG: KASAN: slab-out-of-bounds in strnchrnul+0x72/0x90 Read of size 1 at addr ffff88800de57000 by task repro_patch3/66 CPU: 0 UID: 0 PID: 66 Comm: repro_patch3 Not tainted 7.1.0-rc3-00269-g8370ca1f87cc #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? strnchrnul+0x72/0x90 ? strnchrnul+0x72/0x90 kasan_report+0xca/0x100 ? strnchrnul+0x72/0x90 strnchrnul+0x72/0x90 bitmap_parse+0x37/0x2e0 flow_limit_cpu_sysctl+0xc6/0x840 ? __pfx_flow_limit_cpu_sysctl+0x10/0x10 ? __kvmalloc_node_noprof+0x5ba/0x870 proc_sys_call_handler+0x31d/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? selinux_file_permission+0x39f/0x500 ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... The buggy address is located 0 bytes to the right of allocated 4096-byte region [ffff88800de56000, ffff88800de57000) With this fix applied, rerunning the same sysctl-targeted path yields no corresponding KASAN reports.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97421", "url": "https://ubuntu.com/security/CVE-2026-97421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz() Several corner cases, especially important on 32 bits: - umem->iova is u64, the function argument should pass in u64 or iova will be truncated - Check that the length is not too large for the iova - Check that lengths > 4G don't overflow the GENMASK", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97430", "url": "https://ubuntu.com/security/CVE-2026-97430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: Prevent queuing new commands if xhci is inaccessible Refuse to queue a new command on the command ring if xHC is marked inaccessible with the HCD_FLAG_HW_ACCESSIBLE. HCD_FLAG_HW_ACCESSIBLE is set and cleared in suspend and resume. Also print a warning if xhci is being suspended with commands still pending on the command ring.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97434", "url": "https://ubuntu.com/security/CVE-2026-97434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: fix handling of NAPI on the remove path All the NAPI instances for a DPSW device are attached to the first switch port's net_device but shared by all ports. The NAPI instances get disabled only once the last port goes down. This causes an issue on the .remove() path where each port is unregistered and freed one at a time, causing the NAPI instances to be deleted even though they are not disabled. In order to avoid this, split up the unregister_netdev() calls from the free_netdev() so that we make sure all ports go down before we attempt a deletion of NAPI instances. Also, make the netif_napi_del() explicit as it is on the .probe() path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97435", "url": "https://ubuntu.com/security/CVE-2026-97435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: flower: reject cross-chip redirect dsa_port_from_netdev() may return a valid port from a different switch chip. Programming another chip's port index into the local hardware causes redirection to the wrong port, or an out-of-bounds access if the index exceeds the local chip's port count. Apply a minimal fix that adds a check to catch this case and adjusts the extack message. When cls->common.skip_sw is not set, the operation could instead redirect to the upstream port and let the software or upstream switch(es) handle the forward, but that is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97436", "url": "https://ubuntu.com/security/CVE-2026-97436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: rework FDB management on the bridge leave path On bridge leave, the dpaa2_switch_port_set_fdb() function always allocates a new FDB for the port which is becoming standalone. In case no FDB is found, then the port leaving a bridge will continue to use the current one. The above logic does not cover the case in which there are multiple bridges which have ports from the same DPSW instance. In this case, when the last port leaves bridge #1, it finds an unused FDB to switch to, but the old FDB is not marked as unused. Since the number of FDBs is equal to the number of DPSW interfaces, this will eventually lead to multiple ports sharing the same FDB. Fix this by changing how we are managing the FDBs on the leave path. Instead of directly allocating a new FDB, first verify if the current port is the last one to leave a bridge. If this is the case, then continue to use the current FDB and only allocate another FDB if there are other ports remaining in the bridge.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97437", "url": "https://ubuntu.com/security/CVE-2026-97437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e() The bounds check in ntfs_dir_emit() compares fname->name_len (a character count) against e->size (a byte count) without accounting for the 2-byte-per-character UTF-16LE encoding or the ATTR_FILE_NAME header size: if (fname->name_len + sizeof(struct NTFS_DE) > le16_to_cpu(e->size)) This computes: name_len + 16 > e_size The correct check must account for the ATTR_FILE_NAME header (66 bytes before the name) and the UTF-16LE character size (2 bytes each): sizeof(NTFS_DE) + offsetof(ATTR_FILE_NAME, name) + name_len * sizeof(short) > e_size Which computes: 16 + 66 + name_len * 2 > e_size The correct calculation already exists as fname_full_size() in ntfs.h and is used in cmp_fnames(), namei.c, and fslog.c, but was not used in the readdir path. A crafted NTFS image with an index entry containing a small e->size but large fname->name_len bypasses the current check, causing ntfs_utf16_to_nls() to read past the entry boundary. Additionally, add a key_size validation in hdr_find_e() to ensure the declared key_size does not exceed the available entry data, preventing comparison functions from reading past entry boundaries on the lookup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97438", "url": "https://ubuntu.com/security/CVE-2026-97438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate index entry key bounds [BUG] A malformed NTFS directory index entry can advertise a key_size larger than the bytes actually present in its NTFS_DE payload. Directory lookup then passes that malformed key to cmp_fnames(), which can read past the end of the kmalloc'ed index buffer. BUG: KASAN: slab-out-of-bounds in fname_full_size fs/ntfs3/ntfs.h:590 [inline] BUG: KASAN: slab-out-of-bounds in cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 Read of size 1 at addr ffff88801c313018 by task syz.6.3365/9279 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 __asan_report_load1_noabort+0x14/0x30 mm/kasan/report_generic.c:378 fname_full_size fs/ntfs3/ntfs.h:590 [inline] cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 hdr_find_e.isra.0+0x3ed/0x670 fs/ntfs3/index.c:762 indx_find+0x4b5/0x900 fs/ntfs3/index.c:1186 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... Allocated by task 9279: kasan_save_stack+0x39/0x70 mm/kasan/common.c:56 kasan_save_track+0x14/0x40 mm/kasan/common.c:77 kasan_save_alloc_info+0x37/0x60 mm/kasan/generic.c:573 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0xc3/0xd0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __do_kmalloc_node mm/slub.c:5650 [inline] __kmalloc_noprof+0x2bd/0x900 mm/slub.c:5662 kmalloc_noprof include/linux/slab.h:961 [inline] indx_read+0x41d/0xad0 fs/ntfs3/index.c:1059 indx_find+0x447/0x900 fs/ntfs3/index.c:1179 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... [CAUSE] The index-header validators only validated INDEX_HDR-level geometry. They did not walk each NTFS_DE to verify entry alignment, subnode layout, or that key_size fit inside the entry payload. They also allowed a last sentinel entry to carry a non-zero key_size. [FIX] Walk every NTFS_DE in ntfs3's index-header validators and reject entries with invalid layout, mismatched subnode state, oversized key_size, or non-zero sentinel keys before lookup or log replay can consume them.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97439", "url": "https://ubuntu.com/security/CVE-2026-97439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib [BUG] A corrupted ntfs3 image can hit a NULL function pointer call in generic_perform_write() after toggling system.ntfs_attrib and then overwriting system.dos_attrib on the same file. BUG: kernel NULL pointer dereference, address: 0000000000000000 \\#PF: supervisor instruction fetch in kernel mode \\#PF: error_code(0x0010) - not-present page PGD bed5067 P4D bed5067 PUD 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffff88801025f988 EFLAGS: 00010246 Call Trace: generic_perform_write+0x409/0x8c0 mm/filemap.c:4255 __generic_file_write_iter+0x1bb/0x200 mm/filemap.c:4372 ntfs_file_write_iter+0xcd9/0x1c20 fs/ntfs3/file.c:1253 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x63b/0xf70 fs/read_write.c:686 ksys_write+0x133/0x250 fs/read_write.c:738 __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x77/0xc0 fs/read_write.c:746 ... [CAUSE] system.ntfs_attrib updates ATTR_DATA flags via ni_new_attr_flags() and switches i_mapping->a_ops to ntfs_aops_cmpr when FILE_ATTRIBUTE_COMPRESSED is set. system.dos_attrib then overwrites ni->std_fa from a one-byte DOS attribute value, clearing the compression bit without updating ATTR_DATA or the mapping operations. Old buffered writes use is_compressed(ni) to choose __generic_file_write_iter(). That leaves generic_perform_write() calling a NULL write_begin callback from ntfs_aops_cmpr. [FIX] Treat system.dos_attrib as a low-byte DOS attribute update and preserve the existing non-DOS attribute bits in ni->std_fa. This keeps compressed and sparse state consistent with ATTR_DATA and the mapping operations while keeping the existing DOS attribute semantics intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97440", "url": "https://ubuntu.com/security/CVE-2026-97440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix node refcount leak on ctrl packet alloc failure qrtr_send_resume_tx() calls qrtr_node_lookup() which takes a reference on the returned node. If the subsequent call to qrtr_alloc_ctrl_packet() fails due to memory allocation failure, the function returns -ENOMEM without calling qrtr_node_release() to release the node reference. Add qrtr_node_release(node) before returning on the allocation failure path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97441", "url": "https://ubuntu.com/security/CVE-2026-97441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: ahci: fail probe if BAR too small for claimed ports When an AHCI controller is disabled in BIOS, its HOST_CAP register may contain a bogus value, e.g. 0xFFFFFFFF. Since CAP.NP (Number of Ports) is a zeroes based 5-bit register field, a value of 0x1f means 32 ports. If CAP.NP claims more ports than can physically fit within the mapped BAR region, accessing port registers beyond the BAR boundary causes a kernel panic. Add validation in ahci_init_one() to check that the BAR size is sufficient for the number of ports claimed in CAP.NP. The check calculates the required MMIO size as: required_size = 0x100 (global registers) + max_ports * 0x80 If required_size exceeds the actual BAR size, the probe fails with -ENODEV, preventing the panic and providing a clear error message. [cassel: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97443", "url": "https://ubuntu.com/security/CVE-2026-97443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/ftrace: Fix WARNING in __unregister_ftrace_function perf_ftrace_function_unregister() unconditionally calls unregister_ftrace_function() without checking whether the ftrace_ops was ever successfully registered. This triggers a WARN_ON in __unregister_ftrace_function() when the ops doesn't have FTRACE_OPS_FL_ENABLED set. This can happen during perf_event_alloc() error cleanup when perf_trace_destroy() is called via __free_event() on an event whose ftrace_ops registration failed or was already torn down by perf_try_init_event()'s err_destroy path. The call path is: perf_event_alloc() error cleanup -> __free_event() -> event->destroy() [tp_perf_event_destroy] -> perf_trace_destroy() -> perf_trace_event_close() -> TRACE_REG_PERF_CLOSE -> perf_ftrace_function_unregister() -> unregister_ftrace_function() -> __unregister_ftrace_function() -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to unregister. If the ops is not enabled, just free the filter and return success.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97444", "url": "https://ubuntu.com/security/CVE-2026-97444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in two places Add boundary checks in acpi_ps_get_next_namestring() and acpi_ps_peek_opcode() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97445", "url": "https://ubuntu.com/security/CVE-2026-97445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources() Enhance buffer validation in acpi_ut_walk_aml_resources() to prevent buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97446", "url": "https://ubuntu.com/security/CVE-2026-97446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package() acpi_ns_custom_package() unconditionally dereferences the first element of the package to read the _BIX version number, without checking for NULL: if ((*Elements)->Common.Type != ACPI_TYPE_INTEGER) When firmware returns a _BIX package whose first element is an unresolvable reference, ACPICA evaluates that entry to NULL. acpi_ns_remove_null_elements() does not strip NULL entries for ACPI_PTYPE_CUSTOM packages (fixed-position format would break if elements were shifted), so acpi_ns_custom_package() sees the NULL and causes a crash. Add a NULL check for the first element (version field) before dereferencing it. The caller then receives AE_AML_OPERAND_TYPE instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97448", "url": "https://ubuntu.com/security/CVE-2026-97448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add validation for node in acpi_ns_build_normalized_path() Add validation for node in acpi_ns_build_normalized_path() to prevent use-after-free vulnerabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97449", "url": "https://ubuntu.com/security/CVE-2026-97449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add package limit checks in parser functions Add package limit checks in parser functions to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97450", "url": "https://ubuntu.com/security/CVE-2026-97450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate handler object type in two places ACPICA: validate handler object type in acpi_ev_has_default_handler() and acpi_ev_find_region_handler().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97451", "url": "https://ubuntu.com/security/CVE-2026-97451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op) Add overflow check for Index + Length to prevent integer overflow when calculating the truncation length. This prevents negative size parameter being passed to memcpy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97452", "url": "https://ubuntu.com/security/CVE-2026-97452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Prevent adding invalid references Prevent adding references for local, argument, and debug objects in acpi_ut_copy_simple_object().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97453", "url": "https://ubuntu.com/security/CVE-2026-97453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate byte_count in acpi_ps_get_next_package_length() Validate package length reading in acpi_ps_get_next_package_length().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97454", "url": "https://ubuntu.com/security/CVE-2026-97454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in acpi_ps_get_next_field() Add boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97455", "url": "https://ubuntu.com/security/CVE-2026-97455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix use-after-free in acpi_ds_terminate_control_method() Fix use-after-free issue in acpi_ds_terminate_control_method() by clearing references to method locals and arguments.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97456", "url": "https://ubuntu.com/security/CVE-2026-97456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix condition check in acpi_ps_parse_loop() Fix condition check for AML_ELSE_OP in acpi_ps_parse_loop() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97472", "url": "https://ubuntu.com/security/CVE-2026-97472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: fix temp address generation after prefix deprecation When a router temporarily deprecates an IPv6 prefix (either by sending a Router Advertisement with Preferred Lifetime = 0 or by letting the lifetime expire) and later restores it, the kernel permanently loses its ability to generate temporary privacy addresses (RFC 8981) for that prefix. This happens because the address worker attempts to generate a replacement temporary address when the current one nears expiration. As the base prefix is deprecated already, the generation fails after marking the temporary address as already having spawned a replacement (ifp->regen_count++). When the router eventually restores the prefix, the temporary address becomes active again. However, once it naturally expires, the address worker sees this temporary address already tried to generate one and skips the regeneration. Fix the issue by resetting the regen_count check of the latest temp address generated for the prefix updated by the incoming RA.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97475", "url": "https://ubuntu.com/security/CVE-2026-97475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tegra/soctherma: Switch to devm cooling device registration Use devm_thermal_of_cooling_device_register() to simplify resource management and avoid manual cleanup in error paths. As a side effect this change has the benefit of solving an existing issue. Before, the function tegra_soctherm_remove() only called debugfs_remove_recursive() and never called thermal_cooling_device_unregister() for any of the cooling devices registered here. After the driver removal, the thermal framework's cdev list would still hold references to thermal_cooling_device objects whose devdata pointer (ts) pointed to memory already freed by the platform device's devm cleanup. With this change, the cooling device is unregistered when the driver is removed, thus fixing the issue above.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97476", "url": "https://ubuntu.com/security/CVE-2026-97476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: filter RDS_INFO_* getsockopt by caller's netns The RDS_INFO_* family of getsockopt(2) options reads several file-scope global lists that are not per-netns: rds_sock_info / rds6_sock_info, rds_sock_inc_info / rds6_sock_inc_info -> rds_sock_list rds_tcp_tc_info / rds6_tcp_tc_info -> rds_tcp_tc_list rds_conn_info / rds6_conn_info, rds_conn_message_info_cmn (for the *_SEND_MESSAGES and *_RETRANS_MESSAGES variants), rds_for_each_conn_info (for RDS_INFO_IB_CONNECTIONS) -> rds_conn_hash[] The handlers do not filter by the caller's network namespace. rds_info_getsockopt() has no netns or capable() check, and rds_create() has no capable() check, so AF_RDS is reachable from an unprivileged user namespace. As a result, an unprivileged caller in a fresh user_ns plus netns can read the bound address and sock inode of every RDS socket on the host, the peer address of incoming messages on every RDS socket on the host, the peer address and TCP sequence numbers of every rds-tcp connection on the host, and the peer address and RDS sequence numbers of every RDS connection on the host. The rds-tcp transport is reachable from a non-initial netns (see rds_set_transport()), so a one-shot init_net gate at rds_info_getsockopt() would deny legitimate per-netns visibility to rds-tcp callers. Instead, filter at each handler by comparing the netns of the caller's socket to the netns of the list entry, or to rds_conn_net(conn) for connection paths. Only copy entries whose netns matches the caller. Counters (RDS_INFO_COUNTERS) are aggregate statistics and remain global. Reproducer (KASAN VM, rds and rds_tcp loaded): an AF_RDS socket binds 127.0.0.1:4242 in init_net as root. A child process enters a fresh user_ns plus netns and opens AF_RDS there, then calls getsockopt(SOL_RDS, RDS_INFO_SOCKETS). Before this change, the child sees the init_net socket. After this change, the child sees zero entries. Drop the rds_sock_count, rds_tcp_tc_count, and rds6_tcp_tc_count globals. v2 used them for the size precheck and lens->nr; v3 replaced the precheck with a per-ns count from a first pass over the list, so the globals have no remaining readers. The matching increments and decrements in rds_create()/rds_destroy_sock() and rds_tcp_set_callbacks()/rds_tcp_restore_callbacks() go away with them. Reported by the kernel test robot under clang W=1.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97481", "url": "https://ubuntu.com/security/CVE-2026-97481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix possible ISR soft lockup There are rare cases in which the host gets stuck in the ISR because it is flooded with messages during the startup phase. The reason for the soft lockup in the ISR is the missing FIFO error IRQ (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers the IRQ immediately again. Fix this by adding a check for the FIFOE status and clearing the FIFO if no data is ready (DR). This behavior was observed on an AM62L device which uses the OMAP 8250 driver. Fix it for all 8250 drivers, since the OMAP driver's special IRQ setup handling may trigger this behavior more frequently, but it is not ensured that other 8250 drivers aren't affected.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97482", "url": "https://ubuntu.com/security/CVE-2026-97482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET log goku_irq() handles a number of bus events under a single ep0 path. It already guards the gadget driver suspend/resume callbacks against a NULL ->driver: \tif (dev->gadget.speed != USB_SPEED_UNKNOWN \t\t\t&& dev->driver \t\t\t&& dev->driver->resume) { \t\tspin_unlock(&dev->lock); \t\tdev->driver->resume(&dev->gadget); \t\t... \t} but the very next branch unconditionally dereferences dev->driver when an INT_USBRESET arrives: \tif (stat & INT_USBRESET) { \t\tACK(INT_USBRESET); \t\tINFO(dev, \"USB reset done, gadget %s\\n\", \t\t\tdev->driver->driver.name); \t} If the controller raises INT_USBRESET before any gadget driver has been bound (or after one has been unbound), dev->driver is NULL and the printk dereferences NULL. smatch flags the inconsistency: drivers/usb/gadget/udc/goku_udc.c:1618 goku_irq() error: we previously assumed 'dev->driver' could be null (see line 1607) Fall back to a placeholder when the gadget driver is not bound. No functional change while a gadget driver is bound.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97483", "url": "https://ubuntu.com/security/CVE-2026-97483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: hcd: fix possible deadlock in rh control transfers >From within the SCSI error handler memory allocations must not trigger IO. Handling errors in UAS and the storage driver may involve resetting a device. The thread doing the reset itself relies on VM magic. However, that is insufficient, as resetting a device involves resuming it. Resumption as well as resetting involves conrol transfers to the parent of the device to be reset. That may be a root hub. Hence usbcore must heed the flags passed to usb_submit_urb() processing control transfers to root hubs. The problem exist since the storage driver has been merged.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97484", "url": "https://ubuntu.com/security/CVE-2026-97484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vhci_hcd: fix NULL deref in status_show_vhci platform_get_drvdata() can return NULL if a VHCI host controller's probe failed (e.g. due to USB bus number exhaustion). status_show_vhci() checked for a NULL pdev but not for a NULL hcd returned by platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not return NULL - it returns a pointer offset of 0x260, causing a NULL pointer dereference when that value is subsequently dereferenced. Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move status_show_not_ready() above status_show_vhci() to make it callable from the new error path without a forward declaration.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97485", "url": "https://ubuntu.com/security/CVE-2026-97485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: omfs: handle set_blocksize failures omfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97486", "url": "https://ubuntu.com/security/CVE-2026-97486", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hpfs: handle set_blocksize failures hpfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97487", "url": "https://ubuntu.com/security/CVE-2026-97487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: handle set_blocksize failures jfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97488", "url": "https://ubuntu.com/security/CVE-2026-97488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qnx4: handle set_blocksize failures qnx4 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97489", "url": "https://ubuntu.com/security/CVE-2026-97489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bfs: handle set_blocksize failures bfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the \tBUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97490", "url": "https://ubuntu.com/security/CVE-2026-97490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: affs: handle set_blocksize failures affs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97491", "url": "https://ubuntu.com/security/CVE-2026-97491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Don't sleep inside rds_ib_conn_path_shutdown New rds rdma self tests exposed a hang when tearing down the ib network configs. This is caused by the shutdown worker thread sleeping on the wait_event call, which blocks other work items in the queue. Fix this by changing wait_event to wait_event timeout, and looping until the wait check succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97492", "url": "https://ubuntu.com/security/CVE-2026-97492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed In case reconfiguration of NAN fails, we call ieee80211_handle_reconfig_failure, that marks all interfaces as not in the driver. Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces is called to destroy all the interfaces. If we have any other interface but the NAN one, for example a BSS station, then when its state (links, stations) will be removed, we won't tell the driver about this, because we will think that the interfaces are not in the driver, and then drivers might remain with dangling pointers to objects like stations and links (at least for iwlwifi this is the case). ieee80211_handle_reconfig_failure is meant to be called after we cleaned up the state in the driver, there is no reason to call it for NAN reconfiguration failure. Fix the code to just warn in such a case, as we do in other error paths in reconfig where it is too complicated to rewind.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97502", "url": "https://ubuntu.com/security/CVE-2026-97502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: avoid NULL deref of host->data in IRQ handler mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL: if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; } So we may legitimately reach the rest of the handler with host->data == NULL (and therefore data == NULL). The DATDNE branch already guards against this with an explicit \"if (data != NULL)\" check, but the subsequent TOUTRD (\"read data timeout\") and CRCWR/CRCRD (\"data CRC error\") branches dereference data unconditionally: if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); } if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... } If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this: drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914) Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch. No functional change for callers where data is non-NULL, which is the only case in which these branches did meaningful work before this change.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97506", "url": "https://ubuntu.com/security/CVE-2026-97506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ixp4xx - fix buffer chain unwind on allocation failure chainup_buffers() builds a linked list of buffer descriptors for a scatterlist. If dma_pool_alloc() fails while constructing the list, the current code sets buf to NULL and later dereferences it unconditionally at the end of the function: buf->next = NULL; buf->phys_next = 0; This can lead to a null-pointer dereference on allocation failure. If the failure happens after part of the descriptor chain has already been allocated and DMA-mapped, the partially constructed chain also needs to be released. Fix this by terminating the partially constructed chain on allocation failure and letting the callers unwind it via their existing cleanup paths. Also fix ablk_perform() to preserve the hook pointers before checking for failure, so partially built chains can be freed correctly.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97507", "url": "https://ubuntu.com/security/CVE-2026-97507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dm1105: fix missing error check for dma_alloc_coherent The return value of dm1105_dma_map(), which handles DMA memory allocation, is ignored in dm1105_hw_init(). If dma_alloc_coherent() fails, the driver will proceed using a NULL pointer for DMA transfers, leading to a kernel oops or invalid hardware access. Fix this by checking the return value and propagating -ENOMEM on failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97508", "url": "https://ubuntu.com/security/CVE-2026-97508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Set tb->root_switch to NULL when domain is stopped Similarly what we do with the firmware connection manager. This makes tb_xdp_handle_request() return error to the remote host. However, we need to make sure we keep the uuid alive so that we can reply until the whole domain is released.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97510", "url": "https://ubuntu.com/security/CVE-2026-97510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Release request if tb_cfg_request() fails in __tb_xdomain_response() If tb_cfg_request() fails setting up the request (for example the control channel is shut down already) it returns an error without calling the callback. To avoid leaking that memory, call tb_cfg_request_put() if tb_cfg_request() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-90053", "url": "https://ubuntu.com/security/CVE-2026-90053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_htb: limit htb_classify inner-class filter hops htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent. The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification. htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90054", "url": "https://ubuntu.com/security/CVE-2026-90054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix corruption of urgent data on multi-segment retransmit On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: \t/* tcp_write_xmit() */ \tlimit = mss_now; \tif (tso_segs > 1 && !tcp_urg_mode(tp)) \t\tlimit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: \t/* __tcp_retransmit_skb() */ \tlen = cur_mss * segs;\t\t/* segs > 1, no urg_mode check */ \t... \t/* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: \tseg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) \tseg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) \tseg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90055", "url": "https://ubuntu.com/security/CVE-2026-90055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90056", "url": "https://ubuntu.com/security/CVE-2026-90056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: only stop PTP if it was initialized fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90058", "url": "https://ubuntu.com/security/CVE-2026-90058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai. Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted. Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90062", "url": "https://ubuntu.com/security/CVE-2026-90062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: move hardware offload step after building the chain blob Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90063", "url": "https://ubuntu.com/security/CVE-2026-90063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90067", "url": "https://ubuntu.com/security/CVE-2026-90067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: validate banner payload length When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (`server_feat` and `server_req_feat`). Therefore, `payload_len` must be at least 16 bytes. Fix this by adding a check in `process_banner_prefix()` to reject a `payload_len` smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90068", "url": "https://ubuntu.com/security/CVE-2026-90068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix off-by-one check on the second enum channel The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80x_mux_values. The core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which defaults off.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-93245", "url": "https://ubuntu.com/security/CVE-2026-93245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: policy_int make sure list heads are initialized before fail path If profile create fails before policy_init is complete the list heads are not properly initialized causing profile_free() sanity checks to trigger the following splat. AppArmor WARN aa_policy_destroy: (((!list_empty(&policy->profiles) && (&policy->profiles)->prev != ((void *) 0x122 + (0xdead000000000000UL))))): WARNING: security/apparmor/lib.c:509 at aa_policy_destroy+0x164/0x1b0 security/apparmor/lib.c:509, CPU#0: syz.0.17/5541 Modules linked in: CPU: 0 UID: 0 PID: 5541 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:aa_policy_destroy+0x16b/0x1b0 security/apparmor/lib.c:509 Code: 85 ed 7e 4d e8 96 bc 37 fd 5b 41 5c 41 5e 41 5f 5d e9 19 27 4e 07 cc e8 83 bc 37 fd 48 8d 3d 0c f0 d3 0b 48 c7 c6 a4 eb 38 8e <67> 48 0f b9 3a e9 04 ff ff ff e8 66 bc 37 fd 48 8d 3d ff ef d3 0b RSP: 0018:ffffc9000345eaa0 EFLAGS: 00010293 RAX: ffffffff848f530d RBX: ffff88803f734800 RCX: ffff88801af2a580 RDX: 0000000000000000 RSI: ffffffff8e38eba4 RDI: ffffffff90634320 RBP: 0000000000000000 R08: 0000000000000cc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d95913 R12: dead000000000122 R13: ffff88803f734800 R14: ffff88803f734828 R15: dffffc0000000000 FS: 00007f5f6a1836c0(0000) GS:ffff88808c519000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d02407b048 CR3: 0000000012aa9000 CR4: 0000000000352ef0 Call Trace: aa_free_profile+0x9d/0x9f0 security/apparmor/policy.c:334 aa_alloc_profile+0x1e4/0x3e0 security/apparmor/policy.c:416 unpack_profile security/apparmor/policy_unpack.c:1153 [inline] aa_unpack+0x17db/0x7430 security/apparmor/policy_unpack.c:1748 aa_replace_profiles+0x226/0x2a20 security/apparmor/policy.c:1183 policy_update+0x234/0x4a0 security/apparmor/apparmorfs.c:505 profile_load+0x1cb/0x320 security/apparmor/apparmorfs.c:522 vfs_write+0x296/0xba0 fs/read_write.c:685 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f6939e0d9 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:00007f5f6a183028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f5f69625fa0 RCX: 00007f5f6939e0d9 RDX: 0000000000000041 RSI: 0000200000000400 RDI: 0000000000000003 RBP: 00007f5f6a183090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f5f69626038 R14: 00007f5f69625fa0 R15: 00007ffe23725c18", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90070", "url": "https://ubuntu.com/security/CVE-2026-90070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Return zero on status read failure st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or error path instead of acting on an invalid status value. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90071", "url": "https://ubuntu.com/security/CVE-2026-90071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: restore skb->dev on the slave failure path teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90072", "url": "https://ubuntu.com/security/CVE-2026-90072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90073", "url": "https://ubuntu.com/security/CVE-2026-90073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare \"tc qdisc add ... hhf\" succeeds with a clamped quantum but \"tc qdisc add ... hhf limit 1000\" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90074", "url": "https://ubuntu.com/security/CVE-2026-90074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp default quantum to avoid signed overflow fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90075", "url": "https://ubuntu.com/security/CVE-2026-90075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_codel: clamp default quantum and mtu fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests \"*backlog <= params->mtu\"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memory_limit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double psched_mtu() call. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90078", "url": "https://ubuntu.com/security/CVE-2026-90078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: fix length calculations and avoid invalid header warnings syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act(): !skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55 There are a few issues in tcf_skbmod_act(): 1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets). Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90081", "url": "https://ubuntu.com/security/CVE-2026-90081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in rds_cong_map_updated() rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-89780", "url": "https://ubuntu.com/security/CVE-2026-89780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: restore skb->dev on deaggregated frames rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89789", "url": "https://ubuntu.com/security/CVE-2026-89789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets().", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90088", "url": "https://ubuntu.com/security/CVE-2026-90088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90102", "url": "https://ubuntu.com/security/CVE-2026-90102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: key the data server cache on the NFS version nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4. Two deviceids on one address with different ds_versions[0].version therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL. Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90103", "url": "https://ubuntu.com/security/CVE-2026-90103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix LAYOUTSTATS send buffer exhaustion encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that. ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for. The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held. Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90107", "url": "https://ubuntu.com/security/CVE-2026-90107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free pending qentry in smc_llc_flow_stop() before memset smc_llc_flow_stop() resets a flow struct with a blind memset: \tspin_lock_bh(&lgr->llc_flow_lock); \tmemset(flow, 0, sizeof(*flow)); \tflow->type = SMC_LLC_FLOW_NONE; \tspin_unlock_bh(&lgr->llc_flow_lock); If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object. A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct. Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90114", "url": "https://ubuntu.com/security/CVE-2026-90114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: Reject descending VLAN tunnel ranges A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90126", "url": "https://ubuntu.com/security/CVE-2026-90126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf8563: fix clock provider leak on unbind pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference. The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90128", "url": "https://ubuntu.com/security/CVE-2026-90128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: fix wrong list iterated in add_direct_chain error path In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89779", "url": "https://ubuntu.com/security/CVE-2026-89779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate ef->size covers the record's name and value When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to cover it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89781", "url": "https://ubuntu.com/security/CVE-2026-89781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read in read_log_rec_buf() read_log_rec_buf() copies a log record into a caller buffer starting at \tu32 off = lsn_to_page_off(log, lsn) + log->record_header_len; log->record_header_len (and log->data_off, used for the following pages) comes verbatim from the on-disk restart area and is only checked for 8-byte alignment in is_rst_area_valid(), so off can exceed log->page_size. \"tail = log->page_size - off\" then underflows and memcpy() reads past the page_size-sized buffer returned by read_log_page(), spilling adjacent slab memory into the replay buffer. This is reachable by mounting a crafted NTFS image: BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580 Read of size 64 at addr ffff88800a877ff8 by task exploit/127 read_log_rec_buf fs/ntfs3/fslog.c:2299 log_replay fs/ntfs3/fslog.c:4216 ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324 ntfs_fill_super fs/ntfs3/super.c:1392 get_tree_bdev_flags fs/super.c:1694 __x64_sys_mount fs/namespace.c:4360 The buggy address is located 4088 bytes to the right of the 4096-byte region [ffff88800a876000, ffff88800a877000) Reject an in-page offset outside the current page before the copy. [almaz.alexandrovich@paragon-software.com: replaced the >= sign with >]", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90140", "url": "https://ubuntu.com/security/CVE-2026-90140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cuse: wait for pending RCU callbacks on module exit Since commit 053fc4f755ad (\"fuse: fix UAF in rcu pathwalks\"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory: userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text! The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour). Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90141", "url": "https://ubuntu.com/security/CVE-2026-90141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix integer overflow in ftp helper port/address parsing ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16 (hport) and into unsigned char (p[]) without checking for overflow. A crafted FTP PASV/EPSV response with an over-long port or address octet wraps the value, so the helper configures the data connection with a truncated port/address. The netfilter conntrack FTP helper had the same defect, fixed in commit 2b413fc689ba (\"netfilter: nf_conntrack_ftp: avoid u16 overflows\"). Apply the equivalent fix here: widen the port accumulator to u32 and reject values above 65535, and reject address octets above 255.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90143", "url": "https://ubuntu.com/security/CVE-2026-90143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: kcm: Hold RCU read lock while running BPF parser kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser program. Hold the RCU read lock while running the program.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90151", "url": "https://ubuntu.com/security/CVE-2026-90151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: remove callback IDR entry on client allocation failure nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown. A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it. Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client. This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90157", "url": "https://ubuntu.com/security/CVE-2026-90157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative optlen in cgroup getsockopt hook A cgroup getsockopt BPF program can shrink ctx->optlen after the kernel getsockopt handler has run. The kernel-buffer variant, used by TCP_ZEROCOPY_RECEIVE, only rejects values larger than the original length. If BPF writes a negative optlen, that value is accepted and propagated back to the TCP getsockopt code. It can then be passed to copy_to_sockptr() as a size_t and trigger the hardened usercopy bytes > INT_MAX warning. Reject negative ctx.optlen in __cgroup_bpf_run_filter_getsockopt_kern(), matching the lower-bound validation already present in the sockptr-based getsockopt hook.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90160", "url": "https://ubuntu.com/security/CVE-2026-90160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lwt_bpf: Restore reserved headroom after xmit program ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output. That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise. On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb. Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90198", "url": "https://ubuntu.com/security/CVE-2026-90198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix use-after-free in snd_card_do_free() A use-after-free was detected in snd_card_do_free() when a sound card managed by devres is unbound while a user-space application still holds an open file descriptor. For managed cards, the memory is allocated using devres_alloc(), and its release function is set to __snd_card_release(), which calls snd_card_free(). When the device is unbound, the unbind thread calls snd_card_free(), which drops a reference to the card's device. If the user thread still has an open file descriptor, the reference count does not reach zero, and the unbind thread blocks on wait_for_completion(&released). When the user thread closes the file descriptor, it drops the final reference, invoking the device release callback release_card_device(), which calls snd_card_do_free(). snd_card_do_free() performs cleanup and calls complete(card->release_completion). This wakes up the unbind thread, which returns from snd_card_free() and __snd_card_release(). The devres core then immediately frees the memory block containing the snd_card structure. Meanwhile, the user thread continues execution in snd_card_do_free() and evaluates `if (!card->managed)`. It reads the `managed` boolean from the snd_card structure that was just freed by the unbind thread, triggering a KASAN use-after-free. Fix this by caching the value of card->managed in a local variable before calling complete(). This ensures that the card pointer is not dereferenced after the unbind thread has been woken up and potentially freed the card. BUG: KASAN: use-after-free in snd_card_do_free sound/core/init.c:604 [inline] BUG: KASAN: use-after-free in release_card_device+0x1ab/0x1b0 sound/core/init.c:153 Read of size 1 at addr ffff8881912ec909 by task syz-executor130/5857 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description+0x55/0x1e0 mm/kasan/report.c:378 print_report+0x58/0x70 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 snd_card_do_free sound/core/init.c:604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c:153 device_release+0xc4/0x1f0 drivers/base/core.c:-1 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x222/0x550 lib/kobject.c:737 snd_card_file_remove+0x331/0x390 sound/core/init.c:1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c:2986 __fput+0x418/0xa50 fs/file_table.c:512 fput_close_sync+0x11f/0x240 fs/file_table.c:617 __do_sys_close fs/open.c:1511 [inline] __se_sys_close fs/open.c:1496 [inline] __x64_sys_close+0x7e/0x110 fs/open.c:1496 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90202", "url": "https://ubuntu.com/security/CVE-2026-90202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers _base_release_memory_pools() unconditionally frees every ioc->pcie_sg_lookup[] entry, including ones the setup loop never allocated after a partial failure, causing a \"bad dma\" warning on debug kernels or a NULL pointer dereference otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90203", "url": "https://ubuntu.com/security/CVE-2026-90203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check block offset is not negative If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93252", "url": "https://ubuntu.com/security/CVE-2026-93252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix circular locking dependency in ocfs2_init_acl() A lockdep warning indicates a circular locking dependency between `&oi->ip_xattr_sem` and `&journal->j_trans_barrier`: WARNING: possible circular locking dependency detected is trying to acquire lock: (&oi->ip_xattr_sem){++++}-{4:4}, at: ocfs2_init_acl+0x2fd/0x7e0 fs/ocfs2/acl.c:367 but task is already holding lock: (&journal->j_trans_barrier){.+.+}-{4:4}, at: ocfs2_start_trans+0x3ab/0x700 fs/ocfs2/journal.c:369 The deadlock involves two code paths: Path 1 (setxattr) where `ocfs2_xattr_set()` acquires `ip_xattr_sem` (write) and then starts a transaction, which acquires `j_trans_barrier` (read); and Path 2 (mkdir/mknod) where `ocfs2_mknod()` starts a transaction (`j_trans_barrier` read) and then calls `ocfs2_init_acl()`, which attempts to acquire `ip_xattr_sem` (read) on the parent directory to retrieve the default ACL. Because rw_semaphores are subject to writer priority, a pending writer on `j_trans_barrier` (e.g., the journal commit thread) can cause Path 1 to block, while Path 2 is blocked waiting for Path 1 to release `ip_xattr_sem`. The patch fixes the lock ordering by precomputing the ACL state before starting the OCFS2 transaction, while preserving POSIX ACL storage semantics and the existing inode/security initialization order. By reading the parent directory's default ACL and preparing the new inode's ACLs outside the transaction, `ip_xattr_sem` is always acquired before `j_trans_barrier`. `struct ocfs2_acl_state` encapsulates the prepared ACL state, while `ocfs2_acl_init_prepare()` and `ocfs2_acl_init_release()` avoid code duplication between `ocfs2_mknod()` and `ocfs2_init_security_and_acl()`. `ocfs2_calc_xattr_init()` and `ocfs2_init_acl()` use this precomputed state, removing internal `ip_xattr_sem` acquisition and redundant disk reads. Additionally, remove the `ip_xattr_sem` acquisition from `ocfs2_xattr_set_handle()`. This function is only used while initializing a new inode that has not yet been inserted into the inode hash or attached to a dentry, meaning there is no risk of concurrent access and the lock is unnecessary.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90209", "url": "https://ubuntu.com/security/CVE-2026-90209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/debug: Fix deadlock during unregister Unregistering an s390dbf debug area while one of the associated debugfs files is being written to can cause a deadlock: $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs write debugfs_file_get() debug_unregister() mutex_lock(debug_mutex) debugfs_remove() wait for debugfs_file_put() debug_file_ops.write() debug_input() mutex_lock(debug_mutex) ==> DEADLOCK Fix this by splitting debug_unregister() into an s390dbf and debugfs part, and running only the s390dbf part with debug_mutex locked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90214", "url": "https://ubuntu.com/security/CVE-2026-90214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: fix stream_data leak on open error In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream. Free stream_data and clear the stream pointer on the error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90216", "url": "https://ubuntu.com/security/CVE-2026-90216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubi: Fix rollback for explicit UBI device numbers ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90218", "url": "https://ubuntu.com/security/CVE-2026-90218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix WARNING in res_to_rt syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via addr_handler() during asynchronous address resolution: \" WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ib_addr process_one_req RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c:624 process_one_work kernel/workqueue.c:3375 [inline] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c:3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 \" In addr_handler(), cma_acquire_dev_by_src_ip() is called to populate id_priv->cma_dev and bind the associated ib_device to id_priv->id.device. If cma_acquire_dev_by_src_ip() returns an error (non-zero status), the ID remains unassociated with any RDMA device. Previously, rdma_restrack_add(&id_priv->res) was invoked unconditionally even when cma_acquire_dev_by_src_ip() failed, passing a resource with a NULL dev pointer and triggering the WARN_ON assertion in res_to_rt(). Fix this by only adding the resource to restrack when acquiring the device succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90219", "url": "https://ubuntu.com/security/CVE-2026-90219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Free debugfs on registration failure c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev. Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90221", "url": "https://ubuntu.com/security/CVE-2026-90221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing nci_core_init_rsp_packet_v1() and nci_core_init_rsp_packet_v2() parse the CORE_INIT_RSP packet without validating that the skb contains enough data. A malformed response (e.g. injected via virtual_ncidev) can declare a large num_supported_rf_interfaces while providing insufficient data, causing reads of uninitialized slab memory. This is later used in nci_init_complete_req(), triggering a KMSAN uninit-value warning. Add skb length checks before accessing packet fields: - Validate the skb has at least 1 byte for the status field. - Validate the skb can hold the fixed-size header before parsing. - In v2, bounds-check each variable-length rf_interface entry and its extension parameters within the parsing loop. - In v1, verify the skb is large enough for both the variable-length rf_interfaces array and the trailing rsp_2 structure.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90222", "url": "https://ubuntu.com/security/CVE-2026-90222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: hold a reference to the request skb during send_frame __pn533_send_async() publishes the command and then calls dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame can be matched to this command: the I2C threaded IRQ runs pn533_recv_frame(), which queues cmd_complete_work, and pn533_send_async_complete() frees cmd->req with consume_skb(). On the I2C transport, pn533_i2c_send_frame() still dereferences the same skb after i2c_master_send() returns, so a completion that races the send can free the skb while the transport is still using it. The request skb is owned by the command object and may be freed by command completion at any time after dev->cmd is published, so the transport send path must not assume it stays alive. Hold a temporary reference to the request skb across the send_frame() call so the transport always sees a live skb even if completion races the send. Add a pn533_send_cmd_frame() helper and use it from all three send paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90223", "url": "https://ubuntu.com/security/CVE-2026-90223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound SNL TLV parsing to the skb and add length checks nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed: - For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made \"service_name_len = length - 1\" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90224", "url": "https://ubuntu.com/security/CVE-2026-90224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix double completion race in nci_data_exchange_complete nci_close_device() and nci_rx_work can both call nci_data_exchange_complete() concurrently. After commit 4527025d440ce8 (\"nfc: nci: fix circular locking dependency in nci_close_device\") moved flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock), rx_work is no longer serialized with the explicit completion call in the close path. Both callers read the non-NULL callback pointer and invoke rawsock_data_exchange_complete(), which calls sock_put() -- but only one sock_hold() was taken, so the second sock_put() underflows the refcount and frees the socket while it is still in use. Replace the bare clear_bit(NCI_DATA_EXCHANGE) with test_and_clear_bit() so that only the first caller proceeds to invoke the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90225", "url": "https://ubuntu.com/security/CVE-2026-90225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: read llcp_sock->local under the socket lock in getsockopt nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and then dereferenced the cached pointer inside the locked region. llcp_sock_bind() assigns and clears llcp_sock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on lock_sock(), and then dereference a freed nfc_llcp_local once bind() has unwound. Move the llcp_sock->local read and the NULL check inside the lock_sock(sk) region so bind() cannot mutate or free the pointer between the load and the use.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90226", "url": "https://ubuntu.com/security/CVE-2026-90226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: avoid userspace overflow on invalid optlen nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90228", "url": "https://ubuntu.com/security/CVE-2026-90228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() When a host issues an Identify command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89784", "url": "https://ubuntu.com/security/CVE-2026-89784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6 rpcb_register_inet4() and rpcb_register_inet6() store the result of rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL. rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROC_SET encode path: rpcb_register_call() -> rpc_call_sync() -> rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel. The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890) rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910) rpcauth_wrap_req_encode (net/sunrpc/auth.c:745) call_encode (net/sunrpc/clnt.c:1966) __rpc_execute (net/sunrpc/sched.c:952) rpc_run_task (net/sunrpc/clnt.c:1243) rpc_call_sync (net/sunrpc/clnt.c:1272) rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500) svc_generic_rpcbind_set nfsd_rpcbind_set svc_register svc_setup_socket svc_addsock write_ports nfsctl_transaction_write vfs_write The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFP_KERNEL kstrdup() in rpc_sockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check. Mirror that handling: bail out with -ENOMEM when rpc_sockaddr2uaddr() returns NULL, before the address is fed into the encoder.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90245", "url": "https://ubuntu.com/security/CVE-2026-90245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: kyro: Validate overlay viewport coordinates The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90248", "url": "https://ubuntu.com/security/CVE-2026-90248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: fix teardown of an adopted proto on insert-race loss In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90249", "url": "https://ubuntu.com/security/CVE-2026-90249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes The IIO core does not filter duplicate writes to the event enable attribute, so writing the same value twice invokes write_event_config() twice. Enabling twice leaks a runtime PM reference, preventing the device from ever suspending again; disabling twice underflows the usage count and triggers a \"Runtime PM usage count underflow\" warning. Bail out early when the requested state matches the current state. While at it, switch to pm_runtime_resume_and_get() so a failed resume is propagated to userspace instead of silently marking the event enabled.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90251", "url": "https://ubuntu.com/security/CVE-2026-90251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: \tif (skb->len < sizeof(*rp)) { \t\tbt_dev_err(hdev, \"MSFT supported features length mismatch\"); \t\tgoto failed; \t} evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so \tmsft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, \t\t\t\t GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes (\"skb->len=11 evt_prefix_len=255\", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with \"MSFT event prefix length mismatch\" and msft->evt_prefix is left unset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90257", "url": "https://ubuntu.com/security/CVE-2026-90257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: avoid OOB read of build info string The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read Build Information) and hands the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length. A backend that answers with status only leaves that pointer past the end of the received data, so the walk reads adjacent slab memory until it meets a NUL. Those bytes reach the kernel log and the firmware-info debugfs file. To fix this, print the string with a bounded \"%.*s\" limited to skb->len - 1. A short or unterminated response then prints as much as arrived instead of failing setup. This mirrors commit dd068ef04412 (\"Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()\"), which fixed the identical pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90274", "url": "https://ubuntu.com/security/CVE-2026-90274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: etm4x: fix underflow for usage of (nrseqstate - 1) According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR is implemented only when TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000. IOW, the number of usage in the initialisation or setting TRCSEQEVR with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000. Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR relevant fields setup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90281", "url": "https://ubuntu.com/security/CVE-2026-90281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend Runtime PM must be enabled before creating the PHY, since phy_create() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference. Take a runtime PM usage reference with pm_runtime_get_noresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90283", "url": "https://ubuntu.com/security/CVE-2026-90283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: release subpool on fill_super failure hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size mount options are specified. hugepage_new_subpool() may also reserve huge pages for min_size. If root dentry creation fails after the subpool is created, the failure path frees the subpool with kfree(). This bypasses hugepage_put_subpool() and can leave min_size reservations charged. Use hugepage_put_subpool() on the failure path, matching the normal put_super path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90284", "url": "https://ubuntu.com/security/CVE-2026-90284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: do not queue completed sysfs fallback requests fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to pending_fw_head. device_add() publishes the fallback loading interface, so a userspace helper which discovers the device by scanning sysfs can write 0 to the loading attribute and complete the request before it is queued as pending. In that interleaving firmware_loading_store() calls fw_state_done() while pending_list still points to itself, so it cannot remove an entry from pending_fw_head. The subsequent unconditional list_add() then queues an already-completed fw_priv. Once the request is released, pending_fw_head can retain a pointer to freed memory and the next fallback request can fault while validating the list. Only in-flight fallback requests need suspend or reboot abort handling. If the request is already DONE after device_add(), return success from the fallback path without sending another uevent, waiting again, or queueing it as pending. This preserves the invariant that pending_fw_head contains only active fallback requests.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90285", "url": "https://ubuntu.com/security/CVE-2026-90285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path qla2x00_sysfs_read_vpd() called ha->isp_ops->read_optrom() a second time after releasing optrom_mutex. The repeated read is redundant and, unlike the first, runs without optrom_mutex held, exposing flash access to concurrent optrom operations. Drop the duplicate call.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90286", "url": "https://ubuntu.com/security/CVE-2026-90286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx6: Use PFP on the compute queues too On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90290", "url": "https://ubuntu.com/security/CVE-2026-90290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Restore DAIF state on error Sashiko AI has reported that if swsusp_mte_save_tags() for some reason fails we return from swsusp_arch_suspend() with DAIF being masked - that is not what we'd expect. Restore the saved DAIF state before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93256", "url": "https://ubuntu.com/security/CVE-2026-93256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: mask DAIF before restoring hibernated kernel The arm64 hibernate code manages the exception masking in an unsound way, leading to potential crashes and/or warnings during resume. When a hibernation image is saved in `swsusp_arch_suspend()`, all DAIF exceptions are masked (by virtue of `local_daif_save()`), and the suspended image is saved assuming that all DAIF exceptions will remain masked when the image is restored. When a hibernation image is resumed by `swsusp_arch_resume()`, only interrupts are masked (by virtue of `local_irq_disable()` in `resume_target_kernel()`). When pseudo-NMI is enabled the DAIF.IF bits will be clear, and regardless of pseudo-NMI the DAIF.DA bits will be clear. This means that there are two problems: (1) It is possible to take Debug, SError, or pseudo-NMI exceptions during the resume process. This is unsafe, as during the resume process both the old ane new kernels will tranisently be in an inconsistent state, and swsusp_arch_suspend_exit() won't retain an executable mapping of any exception vectors. Any exception taken here will be fatal and silent. (2) When re-entering the resumed kernel, some DAIF bits will be clear unexpectedly. This permits Debug, SError, or pseudo-NMI exceptions to be taken for a short period while the resumed kernel is not yet in a consistent state. This is detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING. Avoid these issues by masking all DAIF exceptions during resume.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90292", "url": "https://ubuntu.com/security/CVE-2026-90292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix use-after-free in siw_accept() siw_accept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it. The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association. Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90293", "url": "https://ubuntu.com/security/CVE-2026-90293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: post the full-feature receive buffers after session registration isert_put_login_tx() posts the full-feature receive buffers before __transport_register_session() runs, so an initiator that does not wait for the final Login Response can still have a SCSI command executed against an se_session whose se_tpg is NULL - the same oops as the previous patch, at target_submit+0xbe. Post them from isert_get_rx_pdu(), which the previous patch already uses to send that response, and post them before that send: the receive queue is filled at the moment the initiator is told it may use it. Allocating there keeps the existing property that a memory allocation failure cannot happen once the final Login Response is on the wire. The receive queue is already empty between the final Login Request and isert_post_recvm(); this moves the second point later, from a median of 92 us to 172 us over 1200 logins. Only an initiator that sends before it has been told to can reach that window, and on IB and RoCE its send is retried there until the buffers appear - isert_rdma_accept() asks for rnr_retry_count = 7. iWARP has no RNR flow control, so there the same send terminates the connection instead. Measured over rxe, 400 login cycles per run, with an initiator that does not wait: an instrumented build counted no entries to isert_recv_done() before the buffers are posted in 10 runs, where that initiator oopsed 8 of 10 unpatched runs and 5 of 10 with only the previous patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90294", "url": "https://ubuntu.com/security/CVE-2026-90294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: delay the final Login Response until the session is registered isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90295", "url": "https://ubuntu.com/security/CVE-2026-90295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: \timx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), \t\t\t\t GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90296", "url": "https://ubuntu.com/security/CVE-2026-90296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix devres accumulation across driver rebind imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system. Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver(). That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release. Tested by rebinding the driver on qemu's mcimx6ul-evk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90297", "url": "https://ubuntu.com/security/CVE-2026-90297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: crtc: Propagate layer initialization error sun4i_crtc_init() returns plain NULL when layer initialization fails, while all its other error paths return an error pointer. The only caller, sun4i_tcon_bind(), checks the result with IS_ERR() and happily continues with tcon->crtc set to NULL. sun4i_rgb_init() and sun4i_lvds_init() then dereference it in drm_crtc_mask(), which oopses. Return the error pointer instead.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90298", "url": "https://ubuntu.com/security/CVE-2026-90298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: tcon: Drop TCON TOP device reference of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90302", "url": "https://ubuntu.com/security/CVE-2026-90302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: synchronize heartbeat callbacks with o2net teardown Patch series \"ocfs2: harden heartbeat teardown races\". This series fixes two OCFS2 heartbeat/o2net teardown races found by KASAN. This patch (of 2): Heartbeat callbacks stay registered while configfs local-node teardown enters o2net_stop_listening(). A node-down event can still run through o2net_disconnect_node() and o2net_set_nn_state() while teardown is destroying o2net_wq, so the later queue/flush operations can hit a dead workqueue. KASAN has caught this as a slab-use-after-free in __queue_work() with the call chain: KASAN slab-use-after-free in __queue_work+0x56/0xa90 Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __queue_work+0x56/0xa90 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __queue_delayed_work+0x58/0x1e0 queue_delayed_work_on+0xb4/0xc0 o2net_set_nn_state+0x467/0x840 o2net_disconnect_node+0x7b/0xe0 o2net_hb_node_down_cb+0x54/0x60 o2hb_run_event_list+0x236/0x2d0 o2hb_check_slot+0xad4/0xbc0 lock_release+0xc8/0x290 o2hb_check_slot+0x9ea/0xbc0 trace_hardirqs_on+0x18/0x130 o2hb_do_disk_heartbeat+0x646/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) __lock_acquire+0x466/0x2260 lockdep_hardirqs_on_prepare+0xea/0x1a0 ktime_get_with_offset+0xe9/0x230 o2hb_thread+0x14e/0x770 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 __switch_to+0x2e9/0x730 ret_from_fork_asm+0x1a/0x30 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x292/0x760 __alloc_workqueue+0x736/0xc60 alloc_workqueue_noprof+0xb1/0x110 o2net_start_listening+0xe5/0x430 o2nm_node_local_store+0x184/0x310 configfs_write_iter+0x18a/0x210 vfs_write+0x469/0x810 ksys_write+0xd2/0x170 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 rcu_core+0x4f4/0x1320 handle_softirqs+0x156/0x660 queue_delayed_work_on o2net_set_nn_state o2net_disconnect_node o2net_hb_node_down_cb o2hb_run_event_list Keep heartbeat callbacks registered so quorum state still tracks node state, but stop them from driving o2net reconnect/disconnect work once local teardown starts. Mark the transport offline before destroying o2net_wq, wait for any in-flight heartbeat callback to finish, and delay bring-up replay until the new local node is published through o2nm_this_node(). The replay also has to stay serialized with heartbeat callback delivery. Otherwise a live-node snapshot can be copied, a real hb_down callback can install -ENOTCONN for a peer, and the stale replay can call o2net_hb_node_up() for that same peer and queue reconnect work even though heartbeat is already down. The buggy scenario involves two paths, with each column showing the order within that path: local-node teardown: heartbeat node-down callback: 1. configfs local-off enters 1. o2hb_run_event_list() invokes o2net_stop_listening(). o2net_hb_node_down_cb(). 2. teardown heads for 2. the callback reaches destroy_workqueue(o2net_wq). o2net_disconnect_node() and o2net_set_nn_state(). 3. teardown destroys and NULLs 3. the callback flushes or queues o2net_wq. work through o2net_wq.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90303", "url": "https://ubuntu.com/security/CVE-2026-90303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults When CONFIG_DEBUG_USER=y, and cmdline \"user_debug=31\" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the \"oops\" state, acquiring a lock may risk a deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90307", "url": "https://ubuntu.com/security/CVE-2026-90307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it: BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8) Without KASAN the returned bytes are whatever is next in the slab. One run returned \".strtab\". rsp->data[3] in srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90314", "url": "https://ubuntu.com/security/CVE-2026-90314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression \"table_sz - offset - sizeof(*hdr)\", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90316", "url": "https://ubuntu.com/security/CVE-2026-90316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/omap: dsi: Do not copy isr table To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90318", "url": "https://ubuntu.com/security/CVE-2026-90318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: release buffer head after rebuilding parent fat_scan_logstart() leaves the matching directory entry's buffer head in sinfo.bh for the caller to release, just like fat_scan(). fat_rebuild_parent() uses the directory entry to rebuild the parent inode for the nostale_ro NFS export path, but does not release sinfo.bh after a successful scan. Release it once fat_build_inode() has consumed the directory entry data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90319", "url": "https://ubuntu.com/security/CVE-2026-90319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: clear mport->net when rio_add_net() fails rio_alloc_net() stores the newly allocated rio_net in mport->net before rio_scan_alloc_net() registers the device. If rio_add_net() fails, rio_scan_alloc_net() drops the device reference with put_device(), which releases the rio_net through the device release callback. However, mport->net is left pointing at the freed object. A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rio_net again. Clear mport->net in the rio_add_net() failure path, matching the cleanup done for the destID table allocation failure path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90327", "url": "https://ubuntu.com/security/CVE-2026-90327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: do not write beyond optlen in getsockopt pep_getsockopt() clamps the reported length to the caller's buffer with min_t(), but then stores the value with put_user(val, (int __user *) optval), which always writes sizeof(int) bytes. A getsockopt() call with an optlen smaller than sizeof(int) thus reports the clamped length yet writes a full int, one to three bytes past the user buffer. Write the value with copy_to_user() bounded by len, so at most optlen bytes are copied, matching the length reported back to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90329", "url": "https://ubuntu.com/security/CVE-2026-90329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: synchronize input before cleaning up a failed probe hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90334", "url": "https://ubuntu.com/security/CVE-2026-90334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: clear cdev pointer after cdev_add() failure tty_cdev_add() drops the cdev reference when cdev_add() fails, but leaves driver->cdevs[index] pointing to freed memory. tty_unregister_device() later passes that stale pointer to cdev_del(), causing a use-after-free. Clear the slot after dropping the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90341", "url": "https://ubuntu.com/security/CVE-2026-90341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: coreboot: Validate table bounds The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90348", "url": "https://ubuntu.com/security/CVE-2026-90348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90360", "url": "https://ubuntu.com/security/CVE-2026-90360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: use system_freezable_wq for init complete work schedule_delayed_work() uses system_wq, which is non-freezable, allowing regulator_init_complete_work to run concurrently with system suspend. This work fires ~30s after boot to disable unused regulators via I2C. When it races with PM suspend, the I2C adapter may already be suspended, triggering a -ESHUTDOWN warning in __i2c_transfer(): WARNING: ... at __i2c_transfer+0x36c/0x3c8 Call trace: __i2c_transfer i2c_transfer regmap_i2c_write _regmap_update_bits regulator_disable_regmap _regulator_do_disable regulator_late_cleanup regulator_init_complete_work_function process_one_work Switch to system_freezable_wq so the work is frozen before any device is suspended, eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90361", "url": "https://ubuntu.com/security/CVE-2026-90361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix leak in ath11k_service_ready_ext_event() Currently, during ath11k_service_ready_ext_event() processing, svc_rdy_ext.mac_phy_caps can be allocated during TLV parsing. This is a temporary allocation that is freed on the success path, but not on the error path. If parsing succeeds far enough to allocate mac_phy_caps and then fails on a later TLV, the allocation leaks. So free the allocation on the error path. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90362", "url": "https://ubuntu.com/security/CVE-2026-90362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Drop dev_pm_opp_set_rate(0) dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Drop the explicit call to it. Every call site of ops->link_clk_disable() is followed by pm_runtime_put(), so the power vote will be rescinded if deemed safe. Patchwork: https://patchwork.freedesktop.org/patch/742783/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90372", "url": "https://ubuntu.com/security/CVE-2026-90372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss If a peer's VHT/HE MCS map has no supported spatial stream (all fields 0x3), the loop exits with nss == 0 and the function returned (u8)-1 (255), which was then written into the firmware sta_rec_bf beamforming fields. Clamp the result to 0.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90378", "url": "https://ubuntu.com/security/CVE-2026-90378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt792x: Fix memory leak in SDIO TX path When tx_prepare_skb() returns an error in the SDIO TX path, the skb is not freed, leading to a memory leak. This can occur when zero-length frames (such as WNM NULL frames) are dropped to prevent potential hardware TX hangs. Fix this by properly releasing the skb with ieee80211_tx_status_ext() when tx_prepare_skb() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90382", "url": "https://ubuntu.com/security/CVE-2026-90382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set. Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf (\"mt76x2: remove some harmless WARN_ONs in tx status and rx path\") did for the neighboring rx and tx status paths. Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93261", "url": "https://ubuntu.com/security/CVE-2026-93261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/lockdep: Fix NULL pointer dereference in __lock_set_class() register_lock_class() can return NULL when the lock class pool is exhausted, graph_lock() fails, or key validation fails. However, __lock_set_class() uses the return value directly in pointer arithmetic without a NULL check: class = register_lock_class(lock, subclass, 0); hlock->class_idx = class - lock_classes; If class is NULL, this computes a wild offset that corrupts hlock->class_idx. The subsequent reacquire_held_locks() call will invoke hlock_class() with this corrupted index, leading to a NULL or out-of-bounds pointer dereference. Add the missing NULL check, consistent with how __lock_acquire() already handles this case at the same call site.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93283", "url": "https://ubuntu.com/security/CVE-2026-93283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix device_register() error path When device_register() fails in i3c_master_register_new_i3c_devs(), put_device() is called to drop the reference taken by device_register(). That drops the last reference, so the device's release callback i3c_device_release() runs and frees the i3c_device. Two problems follow from that: i3c_device_release() does WARN_ON(i3cdev->desc), so it warns because desc->dev->desc still points back at the descriptor. Clear it before calling put_device(). After put_device() frees the i3c_device, desc->dev is left pointing at freed memory, so clear desc->dev as well. That prevents, for example, i3c_master_unregister_i3c_devs() seeing desc->dev as non-NULL and dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90386", "url": "https://ubuntu.com/security/CVE-2026-90386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90388", "url": "https://ubuntu.com/security/CVE-2026-90388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Check atomic pool allocation result directly The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90391", "url": "https://ubuntu.com/security/CVE-2026-90391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone dmirror_fault() is called from the dmirror_read() and dmirror_write() retry loops after dmirror_do_read() or dmirror_do_write() finds a missing device page table entry. If the mirrored mm has already exited, mmget_not_zero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress. Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90393", "url": "https://ubuntu.com/security/CVE-2026-90393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF in bpf_netns_link_update_prog In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90394", "url": "https://ubuntu.com/security/CVE-2026-90394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sc2731_charger: cancel work on remove The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released. Set the platform drvdata used by remove, then cancel the work after unregistering the notifier. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90395", "url": "https://ubuntu.com/security/CVE-2026-90395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: isp1704_charger: cancel work on remove The USB notifier and initial VBUS detection can schedule isp->work. The remove path unregisters the notifier and power supply, but does not wait for queued or running work before tearing down the power supply state. Cancel the work after unregistering the notifier. Do this before unregistering the power supply. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93262", "url": "https://ubuntu.com/security/CVE-2026-93262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5-ppl: fix use-after-free in ppl_do_flush() The loop in ppl_do_flush() continues iterating after calling ppl_io_unit_finished(), touching io->pending_flushes and leading to a use-after-free. Add a break statement to stop the loop once io is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90403", "url": "https://ubuntu.com/security/CVE-2026-90403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix error path in rtl_pci_probe() In the last error path in rtl_pci_probe(), the cleanup functions are skipped due to a wrong goto label. Moreover, the successful call to rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to be reverted. Fix this issue by updating the labels and adding the relevant cleanup functions to the last error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90411", "url": "https://ubuntu.com/security/CVE-2026-90411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request __nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the rsp_iu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmd_iu unmapped and still marked the op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call .exit_request() when .init_request() fails, the cmd_iu mapping is leaked for every op whose rsp_iu mapping fails. Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and returns the error without marking the op idle, so it stays in the FCPOP_STATE_UNINIT state set by the initial memset().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90413", "url": "https://ubuntu.com/security/CVE-2026-90413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject login PDUs declaring more data than was received isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), \tpayload_length = ntoh24(login_req->dlength); \ttmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90414", "url": "https://ubuntu.com/security/CVE-2026-90414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject PDUs declaring more data than was received isert_recv_done() hands each received PDU to the opcode handlers without ever looking at wc->byte_len, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) - out of the fixed-size descriptor: isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len); Because the declared length is never checked against wc->byte_len, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer. Nothing upstream of isert closes this door: - __iscsit_check_dataout_hdr() bounds the inbound payload against conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check. - iscsi_set_connection_parameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsi_check_acceptor_state(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling. - isert never clamps the negotiated value to its own fixed receive descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated. The imm_data_len == data_len path is more than an over-read: it aliases the receive descriptor via sg_set_buf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated. Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN: BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 isert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout() (ib_isert.c:1160), inlined through isert_rx_opcode(). Validate wc->byte_len against the framing in isert_recv_done() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISER_HEADERS_LEN (commit 29e7b925ae6d (\"IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN\")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all. isert reads the data segment from a fixed offset: isert_get_data() returns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum against wc->byte_len bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything furth ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90415", "url": "https://ubuntu.com/security/CVE-2026-90415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: free STAG index when TPT entry write fails write_tpt_entry() allocates a new STAG index with c4iw_get_resource() and bumps stats.stag.cur before programming the entry. When write_adapter_mem() fails, it returns the error without releasing the index or reversing the statistic. No MR is inserted into rhp->mrs, so deregistration never reclaims it, leaking the index until device teardown. Record whether this call allocated the index and, on a failed write, return it to tpt_table and decrement stats.stag.cur. Key the rollback on both the write error and that flag, not the error alone: a non-reset update carries a caller-owned STAG that this call did not allocate and must not free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90416", "url": "https://ubuntu.com/security/CVE-2026-90416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed \"%d\" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as \"-2147483648\\n\" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with \"%u\" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90419", "url": "https://ubuntu.com/security/CVE-2026-90419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent out-of-bounds read in super root block parsing super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90420", "url": "https://ubuntu.com/security/CVE-2026-90420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix infinite loop in nilfs_clean_segments() syzbot reported a hung task in nilfs_transaction_begin(). This occurs because the cleaner ioctl falls into an infinite loop if nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device is remounted as read-only after an I/O error). Currently in nilfs_clean_segments(), if err is non-zero, it logs the error and sleeps but doesn't abort when it encounters a terminal error like -EROFS. This causes the thread to loop forever. Fix this by breaking out of the loop if nilfs_segctor_construct() returns -EROFS. This matches the behaviour in nilfs_segctor_write_out(), which also handles -EROFS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93264", "url": "https://ubuntu.com/security/CVE-2026-93264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Fix PBL chunk length computation On register MR, when creating the PBL, if it's an indirect PBL we create a chunk list to hold the PBL pages pointers. Each chunk is 4KB in size and can hold 510 addresses (EFA_PTRS_PER_CHUNK) and has a 12-byte control buffer at the end of it holding the next chunk's pointer and its length. If the PBL number of pages is a multiple of EFA_PTRS_PER_CHUNK, the calculated last chunk length is wrongly computed as 0, even though that chunk is fully populated with 510 real page pointers. This wrong length is used both to DMA map the chunk and is propagated to the device, causing the device to see the chunk as empty and reject the memory registration. Fix the calculation so it will be performed only if the number of pages isn't a multiple of EFA_PTRS_PER_CHUNK, if it is, its already handled in the above loop correctly. Also prevent out-of-bounds reach in the chunks array in such scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89782", "url": "https://ubuntu.com/security/CVE-2026-89782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject restart table growth beyond U16_MAX entries During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): \trt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90431", "url": "https://ubuntu.com/security/CVE-2026-90431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: Prevent crash handling to race with rproc_del() There's no synchronization between rproc_crash_handler_work() and rproc_del(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues. To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds. In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a \"deleting\" flag is introduced. This is similar to the RPROC_DELETE state that was introduced to ensure that \"start\" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the \"state\" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90434", "url": "https://ubuntu.com/security/CVE-2026-90434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: release zisofs block pointer buffer head zisofs_fill_pages() reads the compressed block pointer table. The error paths release the current buffer_head, the loop also releases the old buffer_head when it advances. However, the success path leaves the last buffer_head referenced. Release it before returning success.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90435", "url": "https://ubuntu.com/security/CVE-2026-90435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix integer overflow of user QP buffer size set_user_buf_size() computes the QP buffer size by left-shifting the user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers. A sufficiently large rq.wqe_cnt causes signed integer overflow, which is undefined behavior, and yields a small or negative buf_size, causing ib_umem_get() to map a buffer smaller than the hardware will actually write into. Replace the shifts and addition with check_shl_overflow() and check_add_overflow(), rejecting invalid user inputs. Moreover, guard the identical shift computing qp->sq.offset in _create_user_qp() before set_user_buf_size() is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92476", "url": "https://ubuntu.com/security/CVE-2026-92476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Initialize completion before requesting IRQ kmb_ocs_aes_probe() requests the device IRQ before initializing irq_completion. Once the handler is registered it can run immediately, and ocs_aes_irq_handler() unconditionally calls complete(). An interrupt in this window would therefore use an uninitialized completion. Initialize the completion before requesting the IRQ, as the sibling OCS HCU and ECC drivers already do.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89785", "url": "https://ubuntu.com/security/CVE-2026-89785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89787", "url": "https://ubuntu.com/security/CVE-2026-89787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check dir entry fits before reading the hash trailer in ext4_search_dir() For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4_DIRENT_HASHES()), at an offset derived from de->name_len. On the sb_no_casefold_compat_fallback() path ext4_match() reads that trailer, but ext4_search_dir()'s by-hand pre-check only tests de->name + de->name_len <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4_DIRENT_HASHES(de) lands past the block end, so ext4_match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object: BUG: KASAN: use-after-free in ext4_match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4_match (fs/ext4/namei.c:1435) ext4_search_dir (fs/ext4/namei.c:1470) __ext4_find_entry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4_lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filename_lookup (fs/namei.c:2842) vfs_statx (fs/stat.c:353) __do_sys_newfstatat (fs/stat.c:538) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4_match(). This is the same bound ext4_check_dir_entry() already enforces via ext4_dir_rec_len(), so no well-formed entry is rejected. The other caller, ext4_find_dest_de(), runs ext4_check_dir_entry() first and is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92494", "url": "https://ubuntu.com/security/CVE-2026-92494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix buffer_head leak in ext4_init_orphan_info ext4_init_orphan_info() reads orphan file blocks with ext4_bread() and stores the returned buffer_head in oi->of_binfo[i].ob_bh. If ext4_bread() succeeds but the orphan block magic or checksum validation fails, the function jumps to out_free. However, the old out_free loop starts releasing buffers from i - 1, so the current buffer_head at index i is skipped. This leaks the buffer_head reference obtained by ext4_bread() on the bad magic and bad checksum error paths. Fix this by tracking the number of successfully read buffer_heads and releasing exactly those buffer_heads on the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92496", "url": "https://ubuntu.com/security/CVE-2026-92496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx() Currently, in ath11k_wmi_tlv_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Add an upfront length check before dereferencing skb->data as a wmi_cmd_hdr. The check is placed before the trace_ath11k_wmi_event() call to preserve the existing trace semantics (tracing the full raw WMI event including the header), unlike the analogous ath12k fix which could use skb_pull_data() directly. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92498", "url": "https://ubuntu.com/security/CVE-2026-92498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: avoid buffer overreads in WMI event handlers The following WMI event handlers currently read from the event buffer without first verifying that the message was large enough to hold the expected event: ath6kl_wmi_scan_complete_rx() ath6kl_wmi_addba_req_event_rx() ath6kl_wmi_delba_req_event_rx() Add length checks to prevent overread.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92501", "url": "https://ubuntu.com/security/CVE-2026-92501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drain in-flight DIO before buffered write fallback generic/746 started failing intermittently on ext3 (no-extent inodes). The test triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO. Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied, post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback) ----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared() iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async) dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0, 8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range() iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages() invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO) This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92504", "url": "https://ubuntu.com/security/CVE-2026-92504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int3400: clean up ODVP on probe failures evaluate_odvp() creates per-ODVP sysfs files before the thermal zone and later probe resources are registered. The current unwind path only calls cleanup_odvp() from the late sysfs failure path, so failures after evaluate_odvp() but before that label, including thermal_tripless_zone_device_register() failures, leave the ODVP files and storage behind. Move the ODVP cleanup to the common ART/TRT unwind path so every failure after evaluate_odvp() releases the ODVP state. Also clear the cached ODVP pointers in cleanup_odvp(), because evaluate_odvp() can already call it for partial setup failures while probe continues.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92508", "url": "https://ubuntu.com/security/CVE-2026-92508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_free_cq() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93268", "url": "https://ubuntu.com/security/CVE-2026-93268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: skip extra isize expansion during mount to prevent deadlock ext4_try_to_expand_extra_isize() is called from __ext4_mark_inode_dirty() while holding an active jbd2 handle. During mount (!SB_ACTIVE), the expand path may move xattrs to external blocks and release ea_inodes via iput(). When !SB_ACTIVE, iput() calls write_inode_now() which acquires s_writepages_rwsem, creating a circular lock dependency: s_writepages_rwsem --> jbd2_handle --> xattr_sem --> s_writepages_rwsem This can be triggered via: ext4_process_orphan() -> ext4_truncate() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() or: ext4_evict_inode() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() Skip expansion when !SB_ACTIVE. This is a minor loss of functionality (extra isize won't grow for these inodes during mount), which e2fsck can resolve later if needed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89786", "url": "https://ubuntu.com/security/CVE-2026-89786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bounds read in ext4_read_inline_dir() ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: \tdir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic \".\" and \"..\" land at their block-dir offsets. A dirent is formed at \"dir_buf + pos - extra_offset\", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92521", "url": "https://ubuntu.com/security/CVE-2026-92521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92522", "url": "https://ubuntu.com/security/CVE-2026-92522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: validate MADT IOAPIC entry bounds The IOAPIC hotplug lookup parses both MADT and _MAT records directly. The MADT walk previously used a subtable's declared length to advance the cursor after only locating a generic header. The _MAT path likewise passed a generic header to the IOAPIC helper. Validate that a current record has a complete generic header, that its declared length is contained in the available record range, and that a typed IOAPIC record contains the full fixed IOAPIC body before reading its fields. Use the same relation for both MADT and _MAT provider paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92524", "url": "https://ubuntu.com/security/CVE-2026-92524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc() When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93037", "url": "https://ubuntu.com/security/CVE-2026-93037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Propagate sdma_txinit_ahg() errors set_txreq_header_ahg() ignores the return value of sdma_txinit_ahg(). If sdma_txinit_ahg() fails, it returns before initializing tx->txreq. However, set_txreq_header_ahg() ignores the error and returns the AHG change count, causing the caller to continue processing the request as though initialization had succeeded. Propagate sdma_txinit_ahg() failures to the caller and abort request processing when initialization fails. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93039", "url": "https://ubuntu.com/security/CVE-2026-93039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: Keep link pointers valid on realloc failure meson_card_reallocate_links() grows the DAI link and private data arrays with two consecutive krealloc() calls and updates the owner pointers only after both calls have succeeded. A successful krealloc() may move the data: it frees the old block and returns a new one. When that happens for the link array and the second krealloc() then fails, card->dai_link still points to the block that krealloc() already freed, and the error path frees the new block too. The probe error path then calls meson_card_clean_references(), which dereferences card->dai_link and kfree()s it again, resulting in a use-after-free and a double free. Commit card->dai_link and card->num_links right after the first krealloc() succeeds, so the pointer always refers to a valid allocation that meson_card_clean_references() can walk and free. krealloc() with __GFP_ZERO zero-initializes the added entries, so walking them on the error path is safe. With both failure paths reduced to a plain return, drop the goto labels and the error message.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93040", "url": "https://ubuntu.com/security/CVE-2026-93040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize channel state checks pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent. For example, pause() can observe EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93041", "url": "https://ubuntu.com/security/CVE-2026-93041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize abort state updates dw_edma_abort_interrupt() drops vc.lock before changing request and status. issue_pending() can acquire the lock in that small window, observe the old busy state, and skip starting queued descriptors. Then the abort handler overwrites the channel status as idle, leaving the new descriptors stranded for good. Keep descriptor completion and the state transition in the same critical section.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93046", "url": "https://ubuntu.com/security/CVE-2026-93046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: software node: Fix software_node_get_reference_args() with index -1 The bounds check for the index passed to software_node_get_reference_args() was failing when passed UINT_MAX, this in turn would lead to an out of bound access in the property array. Fix the bound check to also cover the UINT_MAX case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93048", "url": "https://ubuntu.com/security/CVE-2026-93048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior. Commit 5daa7b21496a (\"mtd: prepare partition add and del functions for ioctl requests\") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e (\"mtd: add a flags for partitions which should just leave smth. after them\") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value. With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers: WARN_ON((!mtd->erasesize || !master->_erase) && \t\t!(mtd->flags & MTD_NO_ERASE)) in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the \"out of reach\" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error. Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93049", "url": "https://ubuntu.com/security/CVE-2026-93049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdswap: Avoid freeing registered blktrans device twice In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice. add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev. The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89777", "url": "https://ubuntu.com/security/CVE-2026-89777", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio_msi_cap_len() lazily allocates the per-device MSI permission table: \tvdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); \tif (!vdev->msi_perm) \t\treturn -ENOMEM; \tret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); \tif (ret) { \t\tkfree(vdev->msi_perm); \t\treturn ret;\t\t/* vdev->msi_perm left dangling */ \t} When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at \"if (vdev->msi_perm) return len;\" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93051", "url": "https://ubuntu.com/security/CVE-2026-93051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ad525x_dpot: use driver core groups for sysfs files ad_dpot_probe() creates per-RDAC sysfs files manually and then optionally creates the command sysfs group. This leaves probe responsible for rolling back partial sysfs state and makes remove responsible for matching every file that probe created. Move the device attributes into driver core dev_groups for the I2C and SPI drivers and use an is_visible() callback to expose only the attributes supported by the probed device. With this shape, the driver core creates the sysfs files only after probe succeeds and removes them before the remove callback frees the driver data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93052", "url": "https://ubuntu.com/security/CVE-2026-93052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: bcm-vk: Use acquire/release for msgq_inited bcm_vk_sync_msgq() fills the message queue information and then sets msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the message queues and their cached queue information. atomic_set()/atomic_read() do not order those accesses. A reader can see msgq_inited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate. Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the gate and does not publish queue state to readers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93053", "url": "https://ubuntu.com/security/CVE-2026-93053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: speakup: keyhelp: guard letter_offsets possible out-of-range indexing help_init() builds letter_offsets[] by using the first byte of each function name as an index via `(start & 31) - 1`. If function_names are overridden from sysfs (root) with a name starting outside [a–z], the index underflows or exceeds the array, leading to OOB write. Function names can be overridden with the following commands as root: modprobe speakup_soft echo \"0 _bad\" > /sys/accessibility/speakup/i18n/function_names # then press Insert+2 on /dev/tty This fix checks the first letter in help_init(), and if it is not in the [a–z] range the function returns an error to the caller. Eventually this error is propagated to drivers/accessibility/speakup/main.c:2217, which causes a bleep sound.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93054", "url": "https://ubuntu.com/security/CVE-2026-93054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same \"device gone\" state as normal uio_unregister_device().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93055", "url": "https://ubuntu.com/security/CVE-2026-93055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: UDF symlink pathComponent header OOB read udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93056", "url": "https://ubuntu.com/security/CVE-2026-93056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: remove broken string configfs attributes The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for the fn_play, fn_cap, and fn_cntl string options. The store function contains an inverted null check on the kstrndup() return value. This means every write attempt returns -ENOMEM on success and dereferences a NULL pointer on allocation failure. The attributes have been broken and unused for many years. Remove the UAC1_STR_ATTRIBUTE macro and the three attributes it generated. The internal defaults (FILE_PCM_PLAYBACK, FILE_PCM_CAPTURE, FILE_CONTROL) set in f_audio_alloc_inst() are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93061", "url": "https://ubuntu.com/security/CVE-2026-93061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Avoid stack over-read in debug output helpers host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93067", "url": "https://ubuntu.com/security/CVE-2026-93067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clamps an AUX read to the payload limit: \tsize_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: \tif (size) \t\tsize = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 (\"drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer\").", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93271", "url": "https://ubuntu.com/security/CVE-2026-93271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate ath11k can receive HT/VHT/HE frames whose reported MCS is above the maximum that can be expressed in the corresponding mac80211 rate space (e.g. an HE frame reported with MCS 12, while HE tops out at MCS 11). The frame itself is valid and decodes correctly, but for such a frame ath11k_dp_rx_h_rate() leaves rx_status->rate_idx set to the out-of-range value and never assigns rx_status->encoding, so it stays RX_ENC_LEGACY from the ath11k_dp_rx_h_ppdu() initialization. Once that frame reaches mac80211 it trips the rate sanity check and the frame is dropped with a splat: ath11k_pci 0000:03:00.0: Received with invalid mcs in HE mode 12 WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:5433 ieee80211_rx_list+0xb0a/0xe90 [mac80211] Dropping the frame would discard otherwise valid data, so instead cap the reported MCS to the maximum the rate space can express and deliver the frame. Set rx_status->encoding before the range check and assign rate_idx from the capped value, so a frame with an out-of-range MCS no longer leaves partial or bogus rate metadata behind. Also downgrade the logging level since they are not treated as invalid frames now. The only loss is that such a frame is reported as the capped MCS in the rx rate statistics. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93095", "url": "https://ubuntu.com/security/CVE-2026-93095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: validate thread record before delete key rebuild hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93098", "url": "https://ubuntu.com/security/CVE-2026-93098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: glink: fix deadlock in endpoint destroy during driver detach During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89778", "url": "https://ubuntu.com/security/CVE-2026-89778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: fix out-of-bounds page array access on empty zisofs block zisofs_uncompress_block()'s empty-block fast path returns pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the decompression path which returns bytes produced relative to poffset. zisofs_fill_pages() uses that return to advance its page cursor, so when the zisofs block size is below PAGE_SIZE and a sub-page block leaves poffset partway into a page, a following empty block over-counts and advances pages[] one element past its end, after which \"if (poffset && *pages)\" reads pages[1] out of bounds. rock.c only rejects a block-size shift > 17, so a crafted \"ZF\" Rock Ridge record can set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a compressed file on such a mounted ISO9660 image. Return the byte count relative to poffset and zero only [poffset, PAGE_SIZE) of the first page, matching the decompression path. The page-aligned case (poffset == 0) is unaffected. BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290) Read of size 8 at addr ffff88800f5eac48 by task exploit/142 zisofs_read_folio (fs/isofs/compress.c:290) read_pages (mm/readahead.c:184) ... filemap_read (mm/filemap.c:2814) vfs_read (fs/read_write.c:574) __x64_sys_pread64 (fs/read_write.c:769) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address is located 0 bytes to the right of the allocated 8-byte region in the kmalloc-8 cache", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93102", "url": "https://ubuntu.com/security/CVE-2026-93102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Free RX data on late probe failure hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning. If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears down the device data without calling hfi1_free_rx(). This leaks netdev_rx and its dummy netdev. Free the RX support after IB unregistration and before postinit_cleanup(), as done on normal device removal.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93103", "url": "https://ubuntu.com/security/CVE-2026-93103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89783", "url": "https://ubuntu.com/security/CVE-2026-89783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use \"sp->len >= XFRM_MAX_DEPTH\", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]'", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93108", "url": "https://ubuntu.com/security/CVE-2026-93108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ipoib: Drain RCU callbacks during module teardown IPoIB reclamation completions can be signaled from inside an RCU callback. Teardown can wake before the callback returns and unload ib_ipoib while its code is still executing. Client registration failure can also remove already-added devices and queue callbacks. Wait after client and workqueue teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93109", "url": "https://ubuntu.com/security/CVE-2026-93109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Drain RCU callbacks during module teardown devx_free_subscription() can remain queued after the last DevX event file drops its module reference or an auxiliary driver detaches its devices. mlx5_ib can then unload before the callback runs. Registration error unwind has the same risk because driver registration can attach existing devices before failing. Wait after all drivers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93110", "url": "https://ubuntu.com/security/CVE-2026-93110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Wait for RCU callbacks before unloading ib_core put_gid_ndev() is queued with call_rcu() and implemented in ib_core. Stopping the workqueues does not drain callbacks already queued, so RCU could invoke it after the module code has been unloaded. synchronize_rcu() does not wait for callbacks. Wait for them after all producers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93114", "url": "https://ubuntu.com/security/CVE-2026-93114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/surface: acpi-notify: Check ACPI companion before use Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 (\"ACPI: driver: Check ACPI_COMPANION() against NULL during probe\") does for the core ACPI platform drivers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93115", "url": "https://ubuntu.com/security/CVE-2026-93115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93120", "url": "https://ubuntu.com/security/CVE-2026-93120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93130", "url": "https://ubuntu.com/security/CVE-2026-93130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix resource leak on module load failure We need to properly clean up the SMBIOS request and the privacy driver when the module load fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93131", "url": "https://ubuntu.com/security/CVE-2026-93131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-privacy: Fix race condition Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93138", "url": "https://ubuntu.com/security/CVE-2026-93138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire(). Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93140", "url": "https://ubuntu.com/security/CVE-2026-93140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 (\"udf: Mark LVID buffer as uptodate before marking it dirty\"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline] vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline] __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93141", "url": "https://ubuntu.com/security/CVE-2026-93141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: r8a66597: avoid double free of ep0_req in probe error path If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL. Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once. Issue found using a prototype static analysis tool and confirmed by code review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93145", "url": "https://ubuntu.com/security/CVE-2026-93145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister() gdsc_unregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pm_genpd_remove() on the individual generic_pm_domain structures registered by gdsc_init(): \tvoid gdsc_unregister(struct gdsc_desc *desc) \t{ \t\tstruct device *dev = desc->dev; \t\tsize_t num = desc->num; \t\tgdsc_pm_subdomain_remove(desc, num); \t\tof_genpd_del_provider(dev->of_node); \t} That leaves dangling entries on the global gpd_list. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdsc_init() will end up trying to re-register a name that is still in the list and pm_genpd_init() returns -EEXIST. While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh of_genpd_get_from_provider() call racing with the teardown could attach to a domain that is mid-removal. Iterate the scs[] array and pm_genpd_remove() each registered domain after the subdomain links are torn down. The regulators stay devm- managed (devm_regulator_get_optional() in gdsc_register()), so the release happens automatically when the underlying device is unbound; just the genpd accounting needs to be undone explicitly.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93278", "url": "https://ubuntu.com/security/CVE-2026-93278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown cvm_oct_rx_shutdown calls free_irq and netif_napi_del without disabling the napi instance first. As the free_irq only waits for completion of hard interrupt handlers, the napi poll function could still be active. If cvm_oct_remove proceeds to free the plat structure (which holds the NAPI instances), the active poll function will access freed memory, resulting in a use-after-free crash.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93279", "url": "https://ubuntu.com/security/CVE-2026-93279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown The TX cleanup tasklet can be scheduled by the watchdog IRQ handler to execute cvm_oct_tx_do_cleanup. There can be a pending tasklet in the queue which might run after the cvm_oct_remove() frees net_device structures, causing a use-after-free in cvm_oct_tx_do_cleanup() as it iterates cvm_oct_device[] which is an array of netdevice pointers. Add tasklet_kill() after free_irq() to ensure the tasklet is no longer scheduled or running before teardown proceeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93280", "url": "https://ubuntu.com/security/CVE-2026-93280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: greybus: audio: bound the topology section sizes against the fetched size gb_audio_gb_get_topology() fetches a topology blob of a module-supplied size, and gbaudio_tplg_parse_data() then walks it by adding the module-supplied size_dais, size_controls and size_widgets fields to form the control, widget and route section offsets. Those le32 sizes are never checked against the fetched blob, so a module reporting a small topology size but large section sizes makes the offsets point past the allocation, and parsing reads out of bounds. Reject a topology whose section sizes do not fit within the fetched size before it is parsed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93151", "url": "https://ubuntu.com/security/CVE-2026-93151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: fix response resource leak on queue teardown When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm \"kworker/2:1H\", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 unreferenced object 0xffff88814bd05e80 (size 64): comm \"kworker/3:1H\", pid 148, jiffies 4295195428 backtrace (crc e35510cb): __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources() that frees up the RDMA read/write context and the request SGLs of such responses.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93158", "url": "https://ubuntu.com/security/CVE-2026-93158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul - stop probe if context pool creation fails sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool. Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93159", "url": "https://ubuntu.com/security/CVE-2026-93159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes. If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated work_data is not usable for producing RNG output and must not remain associated with the hwrng state. Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data. Fix this by freeing the pending work_data. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93160", "url": "https://ubuntu.com/security/CVE-2026-93160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-ecc - reject hardware ECDH without a public key The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm. atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93161", "url": "https://ubuntu.com/security/CVE-2026-93161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - clear AES key schedule from stack qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame. Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93165", "url": "https://ubuntu.com/security/CVE-2026-93165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Fix memory overread in ring handler `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93167", "url": "https://ubuntu.com/security/CVE-2026-93167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: csky: Fix a4/a5 restoration in syscall trace path The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93170", "url": "https://ubuntu.com/security/CVE-2026-93170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93177", "url": "https://ubuntu.com/security/CVE-2026-93177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup vddInd, vddciInd and mvddInd from VBIOS-parsed tables index into vddc, vddci and vddmem lookup tables without bounds checks across nine sites. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93178", "url": "https://ubuntu.com/security/CVE-2026-93178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93274", "url": "https://ubuntu.com/security/CVE-2026-93274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: bcm2835: Don't remove an unregistered GPIO chip If the devm_pinctrl_register() function fails, bcm2835_pinctrl_probe() calls gpiochip_remove() before gpiochip_add_data() has registered the GPIO chip. This means that upon failure the gpio_chip.gpiodev is NULL resulting in a null pointer dereference inside the gpiochip_remove() function. Remove the unnecessary function call to gpiochip_remove(). No GPIO cleanup is required because the GPIO chip has not yet been registered. Without this change there is potential for a kernel panic upon registration failure", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93183", "url": "https://ubuntu.com/security/CVE-2026-93183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/lima: call drm_mm_init() with a valid allocation range lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2: [ 1.736297] ------------[ cut here ]------------ [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931! [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.750697] Modules linked in: [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree) [ 1.769446] Workqueue: events_unbound deferred_probe_work_func [ 1.775261] PC is at drm_mm_init+0x9c/0xa4 [ 1.779339] LR is at lima_vm_create+0x144/0x17c [ ... ] Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93185", "url": "https://ubuntu.com/security/CVE-2026-93185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rt700-sdw: always drain jack work on remove rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93188", "url": "https://ubuntu.com/security/CVE-2026-93188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: bound device-supplied profile index kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93189", "url": "https://ubuntu.com/security/CVE-2026-93189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path (\"hwmon: prevent packets from going to driver for probe\", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93191", "url": "https://ubuntu.com/security/CVE-2026-93191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix incorrect task context in smack_msg_queue_msgrcv The smack_msg_queue_msgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task. In the msgsnd() syscall path, if a receiver is already waiting, the pipelined_send() optimization is used to push the message directly to the receiver task: ipc/msg.c`pipelined_send(): ` smp_store_release(&msr->r_msg, msg) In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->r_tsk, passed as the 'target' parameter): ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, target := msr->r_tsk,,) However, smack_msg_queue_msgrcv() ignores the 'target' and checks 'current': smack_msg_queue_msgrcv(…) ` smk_curacc_msq(isp, MAY_READWRITE); // current task 'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy. Test: 1) create a sysv message queue with label “foo” 2) echo \"bar foo r\" >/smack/load2 3) msgrcv(,,,0,MSG_NOERROR) in \"bar\"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a \"foo\"-labeled task: \"bar\"-labeled task gets the message. This patch fixes the issue by checking permission on the 'target' task instead of 'current'. (2008-02-04, Casey Schaufler)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2025-40123", "url": "https://ubuntu.com/security/CVE-2025-40123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce expected_attach_type for tailcall compatibility Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-89947", "url": "https://ubuntu.com/security/CVE-2026-89947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: meson: align gxbb_32k_clk_sel number of parents with actual count The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c (\"clk: amlogic: gxbb: drop non existing 32k clock parent\") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80671", "url": "https://ubuntu.com/security/CVE-2026-80671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf sched: Fix register_pid() overflow, strcpy, and BUG_ON register_pid() has several issues when processing untrusted perf.data: 1. Integer overflow: (pid + 1) * sizeof(struct task_desc *) can wrap to a small value on 32-bit systems when pid is large (e.g. 0x40000000), causing realloc to return a tiny buffer followed by out-of-bounds writes in the initialization loop. 2. Heap buffer overflow: strcpy(task->comm, comm) copies the untrusted comm string into a fixed 20-byte COMM_LEN buffer with no length check. 3. BUG_ON on allocation failure: perf.data is untrusted input, so allocation failures should be handled gracefully rather than killing the process. 4. Realloc of sched->tasks assigned directly back, leaking the old pointer on failure; nr_tasks incremented before the realloc, leaving corrupted state on failure. Cap pid at PID_MAX_LIMIT (4194304, matching the kernel's maximum on 64-bit), replace strcpy with strlcpy, guard against NULL comm, replace BUG_ON with NULL returns using safe realloc patterns, and add NULL checks in callers that dereference the result.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-93203", "url": "https://ubuntu.com/security/CVE-2026-93203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: avoid CRC corruption due to parallel claim add batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either * add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone But when the \"new\" claim code was running in parallel to the \"change backbone\" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the \"new\" claim code path: * CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point. * CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc. * CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc The CRC is then wrong for both: * claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs. To avoid this, split the functionality in clear separate parts: * new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back) * update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93204", "url": "https://ubuntu.com/security/CVE-2026-93204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: atomically update mac addresses When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2025-22039", "url": "https://ubuntu.com/security/CVE-2025-22039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix overflow in dacloffset bounds check The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl(). This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer. This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.", "cve_priority": "high", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-21651", "url": "https://ubuntu.com/security/CVE-2025-21651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: don't auto enable misc vector Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below: [ 16.324639] Call trace: [ 16.324641] __queue_delayed_work+0xb8/0xe0 [ 16.324643] mod_delayed_work_on+0x78/0xd0 [ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge] [ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge] [ 16.324666] __handle_irq_event_percpu+0x64/0x1e0 [ 16.324667] handle_irq_event+0x80/0x170 [ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc [ 16.324671] __handle_domain_irq+0x84/0xfc [ 16.324673] gic_handle_irq+0x88/0x2c0 [ 16.324674] el1_irq+0xb8/0x140 [ 16.324677] arch_cpu_idle+0x18/0x40 [ 16.324679] default_idle_call+0x5c/0x1bc [ 16.324682] cpuidle_idle_call+0x18c/0x1c4 [ 16.324684] do_idle+0x174/0x17c [ 16.324685] cpu_startup_entry+0x30/0x6c [ 16.324687] secondary_start_kernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]--- So don't auto enable misc vector when request irq..", "cve_priority": "low", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43088", "url": "https://ubuntu.com/security/CVE-2026-43088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: zero aligned sockaddr tail in PF_KEY exports PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE` Fix those paths by clearing only the aligned sockaddr tail after `pfkey_sockaddr_fill()`.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31420", "url": "https://ubuntu.com/security/CVE-2026-31420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: mrp: reject zero test interval to avoid OOM panic br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock. The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames. Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2025-22103", "url": "https://ubuntu.com/security/CVE-2025-22103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix NULL pointer dereference in l3mdev_l3_rcv When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-21649", "url": "https://ubuntu.com/security/CVE-2025-21649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is sent on HIP08 devices Currently, HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL. But the tx process would still try to set hardware time stamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash. [ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge] [ 128.292938] sp : ffff800059b93140 [ 128.297200] x29: ffff800059b93140 x28: 0000000000003280 [ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080 [ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001 [ 128.315969] x23: 0000000000000000 x22: 0000000000000194 [ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000 [ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000 [ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24 [ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000 [ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368 [ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02 [ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0 [ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000 [ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff [ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294 [ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080 [ 128.390626] Call trace: [ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3] [ 128.405468] xmit_one.constprop.0+0xc4/0x200 [ 128.410600] dev_hard_start_xmit+0x54/0xf0 [ 128.415556] sch_direct_xmit+0xe8/0x634 [ 128.420246] __dev_queue_xmit+0x224/0xc70 [ 128.425101] dev_queue_xmit+0x1c/0x40 [ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch] [ 128.435409] do_output+0x60/0x17c [openvswitch] [ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch] [ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch] [ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch] [ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch] [ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch] [ 128.471460] xmit_one.constprop.0+0xc4/0x200 [ 128.476561] dev_hard_start_xmit+0x54/0xf0 [ 128.481489] __dev_queue_xmit+0x968/0xc70 [ 128.486330] dev_queue_xmit+0x1c/0x40 [ 128.490856] ip_finish_output2+0x250/0x570 [ 128.495810] __ip_finish_output+0x170/0x1e0 [ 128.500832] ip_finish_output+0x3c/0xf0 [ 128.505504] ip_output+0xbc/0x160 [ 128.509654] ip_send_skb+0x58/0xd4 [ 128.513892] udp_send_skb+0x12c/0x354 [ 128.518387] udp_sendmsg+0x7a8/0x9c0 [ 128.522793] inet_sendmsg+0x4c/0x8c [ 128.527116] __sock_sendmsg+0x48/0x80 [ 128.531609] __sys_sendto+0x124/0x164 [ 128.536099] __arm64_sys_sendto+0x30/0x5c [ 128.540935] invoke_syscall+0x50/0x130 [ 128.545508] el0_svc_common.constprop.0+0x10c/0x124 [ 128.551205] do_el0_svc+0x34/0xdc [ 128.555347] el0_svc+0x20/0x30 [ 128.559227] el0_sync_handler+0xb8/0xc0 [ 128.563883] el0_sync+0x160/0x180", "cve_priority": "medium", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2023-52676", "url": "https://ubuntu.com/security/CVE-2023-52676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Guard stack limits against 32bit overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904", "cve_priority": "high", "cve_public_date": "2024-05-17 15:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "low", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-90015", "url": "https://ubuntu.com/security/CVE-2026-90015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89816", "url": "https://ubuntu.com/security/CVE-2026-89816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used Commit 1c6ceeee6ebb (\"drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits\") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93234", "url": "https://ubuntu.com/security/CVE-2026-93234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: validate TV mode names before creating enum property The GUD protocol returns TV mode names as fixed-size GUD_CONNECTOR_TV_MODE_NAME_LEN entries and requires each name to be NUL-terminated. gud_connector_add_tv_mode() currently passes each fixed-size entry directly to drm_mode_create_tv_properties_legacy(), which eventually reaches drm_property_add_enum() and strlen(). If a device returns an entry without a terminating NUL byte, strlen() reads past the end of the slot and can run beyond the allocated buffer, triggering an out-of-bounds read. Validate that each returned TV mode name contains a NUL terminator within its fixed-size slot before passing it to the DRM property code. If a malformed entry is found, reject the device response with -EIO. This fixes the out-of-bounds read without changing the handling of valid devices, and avoids silently truncating malformed protocol data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89817", "url": "https://ubuntu.com/security/CVE-2026-89817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: NUL-terminate TV mode names read from the device gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89821", "url": "https://ubuntu.com/security/CVE-2026-89821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid divide-by-zero in __is_lut_linear() __is_lut_linear() computes the expected value of each entry with \texpected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89823", "url": "https://ubuntu.com/security/CVE-2026-89823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: fix race between partial drm_dev_register() failure and ioctl If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89843", "url": "https://ubuntu.com/security/CVE-2026-89843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89845", "url": "https://ubuntu.com/security/CVE-2026-89845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89846", "url": "https://ubuntu.com/security/CVE-2026-89846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: \tif (IS_FWI2_CAPABLE(ha)) { \t\tsense_data += rsp_info_len; \t\tpar_sense_len -= rsp_info_len; \t} rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): \tif (sense_len > par_sense_len) \t\tsense_len = par_sense_len; \tmemcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89847", "url": "https://ubuntu.com/security/CVE-2026-89847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid double completion in async IOCB timeout qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates \"if (sp->comp) complete(sp->comp)\"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93242", "url": "https://ubuntu.com/security/CVE-2026-93242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb() qla24xx_process_response_queue() advances ring_ptr past the head IOCB before dispatching, so by the time __qla_consume_iocb() runs, ring_ptr already points at the first continuation IOCB. The function however looped purex->entry_count times starting at ring_ptr. As entry_count includes the head, this consumed one entry too many: it stamped RESPONSE_PROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked. Mark the head processed and account for it, then consume only the entry_count - 1 continuation IOCBs, matching __qla_copy_purex_to_buffer().", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89849", "url": "https://ubuntu.com/security/CVE-2026-89849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path qla2x00_status_entry() filters out non-TYPE_SRB entries and the SRB_NVME_CMD, SRB_BIDI_CMD and SRB_TM_CMD types, then falls through to a SCSI fast path that assumes the command is an SRB_SCSI_CMD. The first thing on that path, qla_chk_edif_rx_sa_delete_pending(), and the subsequent handling both evaluate GET_CMD_SP(sp), i.e. sp->u.scmd.cmd. The srb u union overlays the SCSI command pointer with other command layouts (bsg_job, iocb_cmd). If firmware delivers an unexpected STATUS_TYPE IOCB for a non-SCSI handle, sp->u.scmd.cmd can read as a non-NULL garbage pointer, bypassing the NULL checks in qla_chk_edif_rx_sa_delete_pending() and at the cp == NULL test, and leading to a wild pointer dereference. Reject any SRB whose type is not SRB_SCSI_CMD before entering the fast path. The outstanding_cmds slot is left untouched so a genuinely non-SCSI command still completes through its proper handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89850", "url": "https://ubuntu.com/security/CVE-2026-89850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Don't query firmware state while chip is down qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89851", "url": "https://ubuntu.com/security/CVE-2026-89851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace enable parsing in debugfs qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as \"disable\" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89852", "url": "https://ubuntu.com/security/CVE-2026-89852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89853", "url": "https://ubuntu.com/security/CVE-2026-89853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89854", "url": "https://ubuntu.com/security/CVE-2026-89854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix cs84xx use-after-free on host teardown qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89855", "url": "https://ubuntu.com/security/CVE-2026-89855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize flash version read in reset handler The \"update cache versions without reset\" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89856", "url": "https://ubuntu.com/security/CVE-2026-89856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as \"ha->max_req_queues = ha->msix_count - 1\" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent \"ha->max_req_queues--\" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following \"ha->req_q_map[0] = req\" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89858", "url": "https://ubuntu.com/security/CVE-2026-89858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89861", "url": "https://ubuntu.com/security/CVE-2026-89861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89863", "url": "https://ubuntu.com/security/CVE-2026-89863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check qla_chk_edif_rx_sa_delete_pending() obtains the SCSI command via GET_CMD_SP(sp) and immediately dereferences cmd->sc_data_direction. That command pointer can be NULL: the firmware may post a status completion for a command that has already been returned or aborted. The caller qla2x00_status_entry() acknowledges this on the very same status path, re-fetching GET_CMD_SP(sp) and bailing out with the \"Command already returned\" message when it is NULL -- but that check runs only after qla_chk_edif_rx_sa_delete_pending() has already dereferenced the pointer, so a NULL cmd crashes the kernel in interrupt context. Return early when cmd is NULL, before touching cmd->sc_data_direction.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89864", "url": "https://ubuntu.com/security/CVE-2026-89864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: \tstruct qla_i2c_access { \t\tuint16_t device, offset, option, length; \t\tuint8_t buffer[0x40]; \t} __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89865", "url": "https://ubuntu.com/security/CVE-2026-89865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: \tif (len == 1) \t\topt |= BIT_0; \tif (opt & BIT_0) \t\tlen = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89871", "url": "https://ubuntu.com/security/CVE-2026-89871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89872", "url": "https://ubuntu.com/security/CVE-2026-89872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. [Sakari Ailus: Fix subject prefix and coding style a little.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89876", "url": "https://ubuntu.com/security/CVE-2026-89876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tda18250: fix possible integer overflow Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89878", "url": "https://ubuntu.com/security/CVE-2026-89878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: check firmware size before reading trailing marker s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89879", "url": "https://ubuntu.com/security/CVE-2026-89879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: bound JPEG frame size before copying into the buffer s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: \tpayload = le32_to_cpu(pdword[3]); \tif (payload > vc->req_image_size)\t/* payload is checked ... */ \t\treturn -EINVAL; \tvc->pkt_size = payload; \tvc->jpg_size = le32_to_cpu(pdword[4]);\t/* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89880", "url": "https://ubuntu.com/security/CVE-2026-89880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89881", "url": "https://ubuntu.com/security/CVE-2026-89881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89883", "url": "https://ubuntu.com/security/CVE-2026-89883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: sunxi-cir: Unregister rc device on probe failure After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93236", "url": "https://ubuntu.com/security/CVE-2026-93236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common When VIDIOC_TRY_FMT is called with an unsupported pixel format on the OUTPUT queue, vdec_try_fmt_common() falls back to V4L2_PIX_FMT_MPEG2. However, if a distro has locally patched MPEG2 support out (as it has been broken for some time) the platform format table does not contain MPEG2 so find_format() returns NULL and the subsequent dereference of fmt_out->max_width triggers a NULL pointer dereference. Fix this by falling back to the first format in the platform's format array instead of hardcoding V4L2_PIX_FMT_MPEG2. This is always valid since every platform defines at least one format.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89887", "url": "https://ubuntu.com/security/CVE-2026-89887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov7740: fix use-after-destroy in remove The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89888", "url": "https://ubuntu.com/security/CVE-2026-89888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov02a10: fix endpoint parsing use-after-free The ov02a10_check_hwcfg() function calls fwnode_handle_put(ep) immediately after allocating and parsing the endpoint. However, it subsequently calls fwnode_property_read_u32() using the same 'ep' handle, leading to a potential use-after-free. Additionally, reading the optional 'ovti,mipi-clock-voltage' property used to overwrite the 'ret' variable. If the property was missing, 'ret' would become negative, and this failure code would be incorrectly returned at the end of the function, causing probe to fail entirely. Fix the use-after-free by moving fwnode_property_read_u32() before the endpoint is parsed and freed. Avoid the error leak by not assigning the result of fwnode_property_read_u32() to 'ret'.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89890", "url": "https://ubuntu.com/security/CVE-2026-89890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: go7007: defer the ALSA v4l2 put until card release go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89891", "url": "https://ubuntu.com/security/CVE-2026-89891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free of dev_next->devlist on disconnect When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 (\"USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89892", "url": "https://ubuntu.com/security/CVE-2026-89892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: defer audio-only extension registration The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89893", "url": "https://ubuntu.com/security/CVE-2026-89893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: cancel NetUP CI work before teardown netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89894", "url": "https://ubuntu.com/security/CVE-2026-89894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: reject geometry changes while the VBI queue is busy vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: \toffset = lines_completed * (dev->width << 1) + ...; \tif (dma_q->current_field == 2) \t\toffset += dev->width * 2 * dma_q->lines_per_field; \tmemcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89895", "url": "https://ubuntu.com/security/CVE-2026-89895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cobalt: Avoid freeing ALSA private data twice snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89896", "url": "https://ubuntu.com/security/CVE-2026-89896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: fix memory leak in cedrus_init_ctrls() In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89897", "url": "https://ubuntu.com/security/CVE-2026-89897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: Serialize exclusive follower delivery cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89901", "url": "https://ubuntu.com/security/CVE-2026-89901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89923", "url": "https://ubuntu.com/security/CVE-2026-89923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Free guest debug data on vcpu destroy kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89924", "url": "https://ubuntu.com/security/CVE-2026-89924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix old_data leak in guest debug error path __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89925", "url": "https://ubuntu.com/security/CVE-2026-89925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory leak in guest debug handling bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89926", "url": "https://ubuntu.com/security/CVE-2026-89926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix length check __import_wp_info() struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: \twp_info->len = bp_data->len; \t[...] \tif (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) \t\treturn -EINVAL; \twp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89927", "url": "https://ubuntu.com/security/CVE-2026-89927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89930", "url": "https://ubuntu.com/security/CVE-2026-89930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter KVM services local TLB flushes on \"full\" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89932", "url": "https://ubuntu.com/security/CVE-2026-89932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always flush vpid02 on first use Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89936", "url": "https://ubuntu.com/security/CVE-2026-89936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: dac: m62332: Fix regulator reference count imbalance m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89937", "url": "https://ubuntu.com/security/CVE-2026-89937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sgp30: Handle IAQ thread creation failure kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89939", "url": "https://ubuntu.com/security/CVE-2026-89939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89945", "url": "https://ubuntu.com/security/CVE-2026-89945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l34: drain threaded IRQ before runtime suspend cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89946", "url": "https://ubuntu.com/security/CVE-2026-89946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89948", "url": "https://ubuntu.com/security/CVE-2026-89948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89949", "url": "https://ubuntu.com/security/CVE-2026-89949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89951", "url": "https://ubuntu.com/security/CVE-2026-89951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix stale receive device on merged fragments Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89952", "url": "https://ubuntu.com/security/CVE-2026-89952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89953", "url": "https://ubuntu.com/security/CVE-2026-89953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89954", "url": "https://ubuntu.com/security/CVE-2026-89954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: afs: validate v2 image info bounds The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89964", "url": "https://ubuntu.com/security/CVE-2026-89964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: eisa: Fix infinite loop when parsing invalid IRQ value When an invalid value is passed via the \"eisa_irq_edge=\" kernel command line parameter (e.g. \"eisa_irq_edge=16,5\"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89965", "url": "https://ubuntu.com/security/CVE-2026-89965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: reject an arena whose nfree is below the lane count The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89968", "url": "https://ubuntu.com/security/CVE-2026-89968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: reject unsolicited H2CData PDUs nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the \"list_add double add\" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89969", "url": "https://ubuntu.com/security/CVE-2026-89969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as \tqueue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89973", "url": "https://ubuntu.com/security/CVE-2026-89973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: check the data direction of a C2HData PDU nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89979", "url": "https://ubuntu.com/security/CVE-2026-89979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race between non-atomic ops and trigger-start We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89980", "url": "https://ubuntu.com/security/CVE-2026-89980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: harmony: initialize locks before requesting IRQ snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89982", "url": "https://ubuntu.com/security/CVE-2026-89982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89983", "url": "https://ubuntu.com/security/CVE-2026-89983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89984", "url": "https://ubuntu.com/security/CVE-2026-89984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \\ \t./perf bench syscall basic --loop 1000 | \\ \t./perf script -i - --fields brstack|tr ' ' '\\n'| \\ \tgrep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89989", "url": "https://ubuntu.com/security/CVE-2026-89989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89993", "url": "https://ubuntu.com/security/CVE-2026-89993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Initialize IRQ data before requesting IRQs dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89997", "url": "https://ubuntu.com/security/CVE-2026-89997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix resume-vs-remove race If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89999", "url": "https://ubuntu.com/security/CVE-2026-89999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: validate report length in wacom_intuos_pro2_bt_irq wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: \twacom_intuos_pro2_bt_pen(wacom); \tif (type == INTUOSP2_BT || type == INTUOSP2S_BT) { \t\twacom_intuos_pro2_bt_touch(wacom); \t\twacom_intuos_pro2_bt_pad(wacom); \t\twacom_intuos_pro2_bt_battery(wacom); \t} else { \t\twacom_intuos_gen3_bt_pad(wacom); \t\twacom_intuos_gen3_bt_battery(wacom); \t} Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] \t(the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT (\"gen3\"): wacom_intuos_gen3_bt_battery() reads data[45], \tso the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 (\"HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq\") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90000", "url": "https://ubuntu.com/security/CVE-2026-90000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: rmi: fix OOB access with undersized RMI reports The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: \tdata->input_report_size = hid_report_len(input_report); \tdata->output_report_size = hid_report_len(output_report); \talloc_size = data->output_report_size + data->input_report_size; \tdata->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); \tdata->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly \"this probe validated the reports\"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90007", "url": "https://ubuntu.com/security/CVE-2026-90007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Use rollback index when freeing MSI-X vectors pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90011", "url": "https://ubuntu.com/security/CVE-2026-90011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where \tpadding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90017", "url": "https://ubuntu.com/security/CVE-2026-90017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: \tconst u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); \t... \tc = frame_body[0]; \t... \ta = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90018", "url": "https://ubuntu.com/security/CVE-2026-90018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: \tif (attr_ptr + 4 > wps_ie + wps_ielen) \t\tbreak; \tu16 attr_id = get_unaligned_be16(attr_ptr); \tu16 attr_data_len = get_unaligned_be16(attr_ptr + 2); \tu16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: \tmemcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack \"u8 sr\"/\"u8 selected_registrar\" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The \"attr_ptr + 4 > wps_ie + wps_ielen\" header check above was added by commit 1463ca3ec6601 (\"staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()\"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90019", "url": "https://ubuntu.com/security/CVE-2026-90019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: fix null pointer dereference in usb_put_function_instance() usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90020", "url": "https://ubuntu.com/security/CVE-2026-90020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90025", "url": "https://ubuntu.com/security/CVE-2026-90025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix OOB altmode array index The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90031", "url": "https://ubuntu.com/security/CVE-2026-90031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90032", "url": "https://ubuntu.com/security/CVE-2026-90032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: usbtv: keep device alive while ALSA card exists The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90033", "url": "https://ubuntu.com/security/CVE-2026-90033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90034", "url": "https://ubuntu.com/security/CVE-2026-90034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2025-38097", "url": "https://ubuntu.com/security/CVE-2025-38097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: remove encap socket caching to avoid reference leak The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used \"recently\", but it's a lot more complex than just not caching the socket.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2026-89515", "url": "https://ubuntu.com/security/CVE-2026-89515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables() During fuzz testing, the following issue was discovered: BUG: KMSAN: uninit-value in __dma_map_sg_attrs+0x217/0x310 __dma_map_sg_attrs+0x217/0x310 dma_map_sg_attrs+0x4a/0x70 ata_qc_issue+0x9f8/0x1420 __ata_scsi_queuecmd+0x1657/0x1740 ata_scsi_queuecmd+0x79a/0x920 scsi_queue_rq+0x4472/0x4f40 blk_mq_dispatch_rq_list+0x1cca/0x3ee0 __blk_mq_sched_dispatch_requests+0x458/0x630 blk_mq_sched_dispatch_requests+0x15b/0x340 __blk_mq_run_hw_queue+0xe5/0x250 __blk_mq_delay_run_hw_queue+0x138/0x780 blk_mq_run_hw_queue+0x4bb/0x7e0 blk_mq_sched_insert_request+0x2a7/0x4c0 blk_execute_rq+0x497/0x8a0 sg_io+0xbe0/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Uninit was created at: __alloc_pages+0x5c0/0xc80 alloc_pages+0xe0e/0x1050 blk_rq_map_user_iov+0x2b77/0x6100 blk_rq_map_user_io+0x2fa/0x4d0 sg_io+0xad6/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Bytes 14-15 of 16 are uninitialized Memory access of size 16 starts at ffff88800cbdb000 When processing the last unaligned element of the scatterlist, it is supplemented with missing bytes in the amount of pad_len. These bytes remain uninitialized, which leads to a problem. Extend last_sg->length by pad_len first, then use sg_zero_buffer() to zero those pad_len bytes. sg_zero_buffer() uses sg_miter internally, which correctly handles sg entries spanning multiple pages and padding that crosses a page boundary. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80689", "url": "https://ubuntu.com/security/CVE-2026-80689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions mmio_trace_rw() and mmio_trace_mapping() retrieve mmio_trace_array into tr and pass it to __trace_mmiotrace_rw() and __trace_mmiotrace_map(). If these functions are invoked while mmio_trace_array is NULL (e.g. before initialization or after disabled), accessing tr->array_buffer.buffer will result in a NULL pointer dereference crash. Fix this by adding an explicit NULL check for tr at the beginning of __trace_mmiotrace_rw() and __trace_mmiotrace_map().", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80888", "url": "https://ubuntu.com/security/CVE-2026-80888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: drop dma_buf reference on foreign-fd prime import ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-80912", "url": "https://ubuntu.com/security/CVE-2026-80912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: reject an unclaimed class value in security_get_classes() security_get_classes() sizes an array by p_classes.nprim and fills it at value - 1, so a class value the policy never defines leaves a NULL. sel_make_classes() passes every entry to sel_make_dir(), reaching the same d_alloc_name() dereference as the permission array. The class symbol table is allowed to be sparse (policydb_class_isvalid() exists to absorb that), but this getter builds its own array straight from the hash table and has no such predicate. Fail the lookup when a value went unclaimed instead of handing out the NULL. Conforming policies define every class they declare and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-89595", "url": "https://ubuntu.com/security/CVE-2026-89595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix stale object mask after concurrent mark updates When a mark gets a new event bit, fanotify and inotify may avoid recalculating the object mask if the cached aggregate already contains that bit. This is racy with a recalculation triggered by a concurrent update to another mark on the same connector. The concurrent scan can read the mark before the new bit is added, while the updater reads the old aggregate before that scan publishes its result. The updater then skips recalculation and the scan publishes a mask without the bit, leaving the object mask stale after both updates complete. This can be reproduced with two fanotify groups watching the same inode: one thread removes FAN_MODIFY from one existing mark while another thread adds FAN_MODIFY to the other mark. After both fanotify_mark() calls return, writes can fail to produce FAN_MODIFY for the group whose mark now contains the bit. This was reproduced on an unmodified v6.12.95 kernel. The equivalent inotify interleaving loses IN_MODIFY events. For normal fanotify additions, recalculate whenever the raw mark mask changes. The normal mask is not cleared asynchronously, so an unchanged addition cannot introduce missing interest. Always recalculate ignore-mask updates because FS_MODIFY handling may clear the ignore mask without taking mark->lock, making snapshot comparisons unreliable. Always recalculate after updating an existing inotify watch. Its replace path temporarily sets mark->mask to zero, so a concurrent scan can observe zero even when the old and final masks are equal. Assigning the replacement mask directly would avoid the transient zero, but existing-watch updates are infrequent, so unconditional recalculation is simpler.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89603", "url": "https://ubuntu.com/security/CVE-2026-89603", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-74378", "url": "https://ubuntu.com/security/CVE-2026-74378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe get_srq_wqe() reads wqe->dma.num_sge from the shared receive queue buffer, which is mapped into userspace. It validates num_sge against max_sge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify num_sge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe. Read num_sge into a local variable and use it for both the bounds check and the size calculation.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-89488", "url": "https://ubuntu.com/security/CVE-2026-89488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix CT limit teardown use-after-free Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state. An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down. Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists. Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization. The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90049", "url": "https://ubuntu.com/security/CVE-2026-90049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80977", "url": "https://ubuntu.com/security/CVE-2026-80977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't touch shared zerocopy state in skb_tx_error() skb_tx_error() completes the zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone shares, while the caller only owns the reference it is about to drop. Through a clone it tells the producer its pages are free and drops SKBFL_SHARED_FRAG for an skb that is still in flight. Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC: clone_execute() sends a skb_clone() into ovs_dp_process_packet() while do_execute_actions() keeps forwarding the original, and skb_clone() does not privatise the frags here -- skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN. A flow miss on the clone then strips the marker from the packet still being forwarded, and a later local ESP delivery decrypts in place over frags it does not own privately. Skip it for a cloned skb. Nothing is lost: skb_release_data() clears the zerocopy state once the last reference to the shared data goes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80928", "url": "https://ubuntu.com/security/CVE-2026-80928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix cred UAF in smack_file_send_sigiotask() When inspecting the credentials of another task, objective credentials (->real_cred, accessed with __task_cred()) must always be used. Accessing ->cred on a non-current task is forbidden unless that task is being created or destroyed; a task is allowed to change its own ->cred pointer with no synchronization, and changing ->cred should only affect the current syscall. smack_file_send_sigiotask() was accessing both sets of credentials: First tsk->cred, then __task_cred(tsk). Fix it, always access the objective credentials here. I have tested that this bug can lead to a KASAN-reported UAF of struct cred in smack_file_send_sigiotask(), and that this fix prevents the race.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-93222", "url": "https://ubuntu.com/security/CVE-2026-93222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: avoid shared siginfo namespace rewrites send_signal_locked() rewrites sender ids for the target namespace. Group sends reuse the same siginfo, so one recipient can affect the next. Copy the siginfo before changing it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-80930", "url": "https://ubuntu.com/security/CVE-2026-80930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80931", "url": "https://ubuntu.com/security/CVE-2026-80931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: ds28e17: reject an oversize length on an I2C block read w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the device. The downstream slave puts a length byte in buf[0]. The driver then reads that many bytes into buf[1] with w1_f19_i2c_read(). buf[0] is controlled by the device and can be 0 to 255. w1_f19_i2c_read() only rejects a zero count. The caller buffer is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read run past it, up to about 222 bytes out of bounds. The SMBus core does check buf[0] against I2C_SMBUS_BLOCK_MAX. That check runs after master_xfer returns. By then the write is already done. i2c-algo-bit rejects an oversize length before it copies, and returns -EPROTO. Reject a length above I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites, the same way i2c-algo-bit does.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80932", "url": "https://ubuntu.com/security/CVE-2026-80932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: flush works in dependency order virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work. In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it. KASAN reported: BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80938", "url": "https://ubuntu.com/security/CVE-2026-80938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex mt7615_suspend() acquired the mt76 mutex and then called cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the same mutex via mt7615_mutex_acquire() at the top of the worker, so if mac_work is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against. Flush scan_work and mac_work before taking the mutex, matching the suspend paths in mt7921 and mt7925. scan_work only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps mac_work from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80941", "url": "https://ubuntu.com/security/CVE-2026-80941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb() The skb passed to the rtw_hci_tx_write() is expected to be freed when the function fails, but the error path in rtw_txq_push_skb() does not free the skb before returning. This can lead to a memory leak in rtw_txq_push() where a dequeued skb is passed to rtw_txq_push_skb().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80944", "url": "https://ubuntu.com/security/CVE-2026-80944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Detach sync cmd buffer on interrupted wait mwifiex synchronous commands keep the caller-provided data buffer in cmd_node->data_buf. Several callers pass stack-allocated objects there. If wait_event_interruptible_timeout() is interrupted, the caller can return and release that stack object while the firmware command is still the current command. A late firmware response then reaches the normal response handler, which can copy data through cmd_node->data_buf into the stale stack address. This fixes a stack corruption observed during repeated association and disassociation cycles. The panic trace showed the command wait being interrupted immediately before a bad pointer dereference: cmd_wait_q terminated: -512 Unable to handle kernel paging request at virtual address 002c583837384662 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted ... Tainted: [M]=MACHINE_CHECK The fault address decodes as little-endian ASCII: 0x002c583837384662 -> \"bF878X,\\0\" which is a fragment of the VERSION_EXT firmware string exposed as debugfs \"verext\": w8997o-V4, RF878X, FP92, 16.92.21.p153.7 The same runs also showed corrupted control data containing: 0x2400372e333531 -> \"153.7\\0$\" which is the tail of the same VERSION_EXT string. This points at a late VERSION_EXT response writing through a stale stack-backed data_buf after the interrupted wait returned. After cancelling pending commands on an interrupted or timed-out wait, detach the caller-owned data buffer from the still-current command. This preserves the existing command cancellation behaviour while preventing a late response from writing through a pointer whose lifetime ended with the waiting caller. Tested on an i.MX8MP board using an 88W8997.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80949", "url": "https://ubuntu.com/security/CVE-2026-80949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() The memory allocated for buf is not freed in some of the error paths in brcmf_sdio_read_control(). Fix that by adding vfree() calls. [arend: rework as suggested by Johannes]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80951", "url": "https://ubuntu.com/security/CVE-2026-80951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: bound IBI payload to the requested max_payload_len svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into the IBI slot. The loop is bounded by the hardware FIFO size (SVC_I3C_FIFO_SIZE), not by the slot size. slot->data points into the IBI pool, which i3c_generic_ibi_alloc_pool() sizes at max_payload_len per slot. svc_i3c_master_request_ibi() only rejects a max_payload_len larger than SVC_I3C_FIFO_SIZE, so a driver can request a smaller one. mctp-i3c requests 1. Each readsb() then copies the controller RXCOUNT bytes (up to 31) with no check against the slot size. A device that sends more bytes than the slot holds writes past slot->data, an out-of-bounds write into the IBI pool. Bound the loop by dev->ibi->max_payload_len and clamp each read to the space left in the slot, the same way dw-i3c does. A device can still send more than the requested payload. Flush the leftover bytes from the RX FIFO so they do not leak into the next transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80952", "url": "https://ubuntu.com/security/CVE-2026-80952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix info leak and UAF in device unregister path i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During device_unregister(), device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct i3c_device_info, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind. Keep desc valid until device_unregister() has completed. Since device_unregister() drops the device reference and may free the device, take an extra reference with get_device() before unregistering. Clear desc afterwards and release the extra reference with put_device(). This preserves the release-time invariant that desc must be NULL while avoiding both the information leak and a potential use-after-free from writing desc after the device has been released.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80963", "url": "https://ubuntu.com/security/CVE-2026-80963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-stats: fix a crash if allocation of per-cpu data fails If \"dm_kvzalloc(percpu_alloc_size, cpu_to_node(cpu))\" fails, the code jumps to the \"out\" label and calls dm_stat_free. dm_stat_free does \"for_each_possible_cpu(cpu) { dm_kvfree(s->stat_percpu[cpu][0].histogram, s->histogram_alloc_size);\", which crashes with NULL pointer dereference if s->stat_percpu[cpu] is NULL. This commit fixes the bug by testing s->stat_percpu[cpu] for NULL before using it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80964", "url": "https://ubuntu.com/security/CVE-2026-80964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: virmidi: Check card index validity at probe virmidi driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80965", "url": "https://ubuntu.com/security/CVE-2026-80965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: serial-u16550: Check card index validity at probe serial-u16550 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80966", "url": "https://ubuntu.com/security/CVE-2026-80966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: portman2x4: Check card index validity at probe Although portman2x4 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80967", "url": "https://ubuntu.com/security/CVE-2026-80967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcxhr: initialize mutexes before requesting threaded IRQ pcxhr_probe() requests pcxhr_threaded_irq() before initializing mgr->lock, even though the threaded handler takes that mutex. Initialize the manager locks before request_threaded_irq() so an early interrupt cannot run against uninitialized mutex state during probe.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80968", "url": "https://ubuntu.com/security/CVE-2026-80968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mts64: Check card index validity at probe Although mts64 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80969", "url": "https://ubuntu.com/security/CVE-2026-80969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mpu401: Check card index validity at probe mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80971", "url": "https://ubuntu.com/security/CVE-2026-80971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: clear the URB pointers on disconnect bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind: \tusb_kill_urb(bcd2k->midi_out_urb); \tusb_kill_urb(bcd2k->midi_in_urb); \tusb_free_urb(bcd2k->midi_out_urb); \tusb_free_urb(bcd2k->midi_in_urb); The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core: \tbcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE; \t... \tret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC); usb_kill_urb() does not stop a later submission either, so a submit that races the disconnect can requeue the URB after it has been reaped. midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits it from the completion handler. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000] Write of size 4 at addr ffff00001827d388 by task bpoc/168 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 Freed by task 168: usb_free_urb bcd2000_disconnect [snd_bcd2000] BUG: KASAN: slab-use-after-free in usb_submit_urb Read of size 8 at addr ffff00001827d3b8 by task bpoc/168 Clear both pointers after freeing and test them on the paths that can still run. Poison the URBs before freeing them: usb_poison_urb() waits for a running completion handler and rejects any later submission, so after it returns the input path is quiesced and only the rawmidi trigger path can still reach bcd2000_midi_send(). No unpoison is needed; the URBs are freed on the next line. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80972", "url": "https://ubuntu.com/security/CVE-2026-80972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Check card index validity at probe aloop driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80973", "url": "https://ubuntu.com/security/CVE-2026-80973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: bound the MIDI event length from the device usb6fire_comm_receiver_handler() forwards a MIDI event using a length byte the device supplies, with no bound and no check that the transfer delivered that many bytes: \tif (!urb->status) { \t\tif (rt->receiver_buffer[0] == 0x10) /* midi in event */ \t\t\tif (midi_rt) \t\t\t\tmidi_rt->in_received(midi_rt, \t\t\t\t\t\trt->receiver_buffer + 2, \t\t\t\t\t\trt->receiver_buffer[1]); \t} receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the device chooses, so a device that answers with 0x10 and a length of 0xFF makes snd_rawmidi_receive() read 255 bytes starting two bytes into a 64-byte object. The bytes past the buffer are handed to userspace through the rawmidi read path. urb->actual_length is not consulted either, so a short transfer leaves both the type byte and the length byte at their previous values and the handler acts on stale data. The receiver URB is submitted from usb6fire_comm_init() at probe, so the read happens on plug with no user action; forwarding to userspace also needs a MIDI input substream open, since usb6fire_midi_in_received() only calls snd_rawmidi_receive() when rt->in is set. KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device: BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive Read of size 255 at addr ffff000009f64682 by task bash/183 __asan_memcpy snd_rawmidi_receive usb6fire_midi_in_received [snd_usb_6fire] usb6fire_comm_receiver_handler [snd_usb_6fire] Allocated by task 11: usb6fire_comm_init [snd_usb_6fire] usb6fire_chip_probe [snd_usb_6fire] The buggy address is located 2 bytes inside of allocated 64-byte region [ffff000009f64680, ffff000009f646c0) Reject the event when the length exceeds the bytes that follow the header, and require the transfer to have delivered the header plus that many bytes. The receiver URB is submitted with a 64-byte transfer_buffer_length, so a genuine device cannot deliver an event longer than those 62 bytes and nothing valid is dropped. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80976", "url": "https://ubuntu.com/security/CVE-2026-80976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: reset IP6CB after IPv6 decapsulation decap_and_validate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags. End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet. The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports: BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu ip6_protocol_deliver_rcu+0x1118/0x1450 ip6_input_finish+0x11b/0x240 seg6_local_input_core+0xed/0x2e0 lwtunnel_input+0x1e9/0x4e0 ipv6_rthdr_rcv+0x525f/0x6c50 ip6_protocol_deliver_rcu+0xcb7/0x1450 Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field. Use IP6CB(skb)->iif rather than skb->skb_iif because VRF processing can replace skb_iif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKB_L3SLAVE for the same reason.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80978", "url": "https://ubuntu.com/security/CVE-2026-80978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap advertised IP tunnel headroom IP tunnel devices derive their advertised needed_headroom from lower output devices. A stack of user-created devices can make the derived value larger than the 16-bit skb header offsets can represent. Once IP output reserves it, skb head expansion can wrap those offsets. The runtime transmit path already caps a growing needed_headroom at 512. Apply the same cap when tunnel configuration publishes needed_headroom derived from a lower output device. Capping the advertised value is safe: IP tunnel transmit still expands the skb when a packet needs more headroom. A nonsensical stacked configuration can therefore incur an extra reallocation, but it cannot publish an unbounded reservation to upper layers.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80983", "url": "https://ubuntu.com/security/CVE-2026-80983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket refcount leak in smc_switch_conns() smc_switch_conns() takes a reference on the SMC socket before dropping lgr->conns_lock, so the connection stays alive while the CDC slot is fetched: sock_hold(&smc->sk); read_unlock_bh(&lgr->conns_lock); /* pre-fetch buffer outside of send_lock, might sleep */ rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend); if (rc) goto err_out; The err_out label only drops the wr_tx link reference, so this early exit returns without the matching sock_put(). The second error exit is not affected, because sock_put() has already run by then. A leaked sk_refcnt means the smc_sock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down. smc_cdc_get_free_slot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smc_switch_conns() run in the first place. Restructure so there is a single sock_put() covering both outcomes, instead of adding a second one to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80987", "url": "https://ubuntu.com/security/CVE-2026-80987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Reject oversized TX buffers ntb_process_tx() handles an oversized buffer by calling tx_handler() with a NULL data pointer and returning success. ntb_netdev therefore neither frees the skb in its completion callback nor takes its enqueue error path, leaking it. Reject oversized buffers in ntb_transport_tx_enqueue() before acquiring a queue entry and return -EMSGSIZE. The caller retains ownership of the buffer, and the preceding netdev patch frees the skb when enqueue returns this permanent error.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80988", "url": "https://ubuntu.com/security/CVE-2026-80988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Fail TX enqueue when the QP link is down Commit f195a1a6fe41 (\"ntb: Drop packets when qp link is down\") meant to make ntb_transport_tx_enqueue() drop packets submitted while the QP link is down, but it only returns 0 without consuming the packet. Zero means success by this function's contract, so ntb_netdev reports NETDEV_TX_OK and forgets the skb: nothing queued it, nothing frees it, and it leaks, one skb for every transmit racing a link-down. Return -ENOLINK instead, restoring the contract that a non-zero return leaves the buffer owned by the caller. With the preceding patch, ntb_netdev frees the skb on non-retryable enqueue failures and returns NETDEV_TX_OK, so a packet racing with link-down is dropped without leaking or entering a busy retry loop.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80994", "url": "https://ubuntu.com/security/CVE-2026-80994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix flow mask use-after-free on flow deletion The commit in the Fixes tag below made so flow->mask free is scheduled via RCU right after it is removed from the flow table. The pointer stays in the flow structure and it can be accessible while in the same RCU critical section. This is done to avoid requiring ovs_mutex for the ovs_flow_free(). However, while removing the flow during processing of CMD_DEL, we do not take RCU read lock before the removal, and ovs_flow_cmd_fill_info() uses the flow->mask pointer afterwards. The RCU read lock is taken, but it's already late at that point. The comment on that line acknowledges that the lock is cosmetic and doesn't serve a real purpose. This leads to use-after-free if the RCU grace period passes between removal and the filling. It is a short race window, but it is there and can lead to a real crash in case memory allocation for the info takes a bit longer: BUG: KASAN: slab-use-after-free in __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 BUG: KASAN: slab-use-after-free in ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 Read of size 4 at addr ffff88801ee89970 by task ovs_flow_del_ec/9487 Call Trace: __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c:930 ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c:1467 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Allocated by task 9487: mask_alloc net/openvswitch/flow_table.c:967 flow_mask_insert net/openvswitch/flow_table.c:1012 ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c:1084 ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c:1086 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Freed by task 9485: rcu_free_sheaf+0x1e/0x100 mm/slub.c:5978 rcu_do_batch kernel/rcu/tree.c:2645 rcu_core+0x59c/0x10c0 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9a0 kernel/softirq.c:622 ... instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 ovs_flow_tbl_remove() must be called after the ovs_flow_cmd_fill_info() to avoid this race. This also helps with cleaning up the forced cast and the cosmetic RCU read lock. Before the commit in the Fixes tag the order did not matter as long as the flow object itself was not freed. A wider RCU critical section could be another option, but we have a GFP_KERNEL allocation in the way. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-32042.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81000", "url": "https://ubuntu.com/security/CVE-2026-81000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tun: bound receive headroom tun_get_user() uses tun->align both as skb headroom and when choosing how much packet data to keep linear. OVS can propagate an oversized headroom request from another port to TUN or TAP. When align is larger than the usable space in a one-page skb head, SKB_MAX_HEAD(align) underflows and the result becomes negative when stored in good_linear. That value later wraps when assigned to the size_t linear variable, and tun_alloc_skb() can place skb->data outside the allocated head. Bound the headroom stored by TUN to the one-page skb-head budget and the largest non-sentinel 16-bit skb header offset. Leave one linear byte for raw TUN and a complete Ethernet header for TAP, including NET_IP_ALIGN. Also pull the raw-TUN protocol byte and the TAP Ethernet header before accessing them, so these checks remain safe for nonlinear skbs supplied by other allocation paths.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81001", "url": "https://ubuntu.com/security/CVE-2026-81001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: fix use-after-free in sl_sync() slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor. priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop: \t/* Snapshot list, allow later requests */ \tlist_replace_init(&net_todo_list, &list); \t__rtnl_unlock(); \t... \t\tif (dev->priv_destructor) \t\t\tdev->priv_destructor(dev);\t/* slip_devs[i] = NULL */ \t\tif (dev->needs_free_netdev) \t\t\tfree_netdev(dev); \t\t... \t\t/* Free network device */ \t\tkobject_put(&dev->dev.kobj); So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed */ sl = netdev_priv(dev) if (sl->tty || sl->leased) /* use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860 Commit e58c19124189 (\"slip: Fix use-after-free Read in slip_open\") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it. Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: the ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81002", "url": "https://ubuntu.com/security/CVE-2026-81002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xdp: fix zero-copy frame layout xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page and advertises PAGE_SIZE as its frame size. It allows the copied frame to occupy the page tail needed by skb_shared_info and records zero headroom even when metadata separates the frame header from packet data. An AF_XDP zero-copy packet redirected through cpumap can therefore make the skb overlap skb_shared_info or place it beyond the allocated page. Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result. BUG: KASAN: slab-out-of-bounds in skb_gro_receive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skb_gro_receive (net/core/gro.c:174) udp_gro_receive (net/ipv4/udp_offload.c:812) inet_gro_receive (net/ipv4/af_inet.c:1539) dev_gro_receive (net/core/gro.c:515) gro_receive_skb (net/core/gro.c:633) cpu_map_kthread_run (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Kernel panic - not syncing: KASAN: panic_on_warn set ...", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81003", "url": "https://ubuntu.com/security/CVE-2026-81003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: filter frames in afiucv_hs_rcv() by ingress device afiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-byte name fields in the transport header alone. No check is made against the net_device the frame arrived on. This can cause a frame arriving on any netdev to be delivered to an AF_IUCV socket. Three problems follow. First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL. iucv_sock_bind() takes the classic path whenever the requested userid matches iucv_userid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucv_hs_callback_syn() for such a match inherits hs_dev = NULL and transport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable. Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections Third, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() calls sk_alloc(&init_net, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAP_NET_RAW capability valid within that namespace can send a raw ETH_P_AF_IUCV frame on its own lo device and have it matched against init_net sockets. Fix all three by skipping any socket whose hs_dev does not match the ingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hs_dev is always a device in init_net (iucv_sock_bind() scans for_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket. Note that AF_IUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81005", "url": "https://ubuntu.com/security/CVE-2026-81005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: si: Fix NULL pointer dereference after failed registration try_smi_init() allocates new_smi->si_sm and later calls ipmi_register_smi_mod(), which maps to ipmi_add_smi(). During ipmi_add_smi(), the upper IPMI message handler obtains the initial BMC device information through __bmc_get_device_id(). This can fail if the BMC does not return a successful response to the Get Device ID command. When the BMC returns a nonzero completion code, the device-id helper retries the command and eventually returns -EIO if the device ID still cannot be fetched. On this failure path, ipmi_add_smi() logs \"Unable to get the device id\" and goes to out_err_started, where it invokes the lower driver's shutdown callback. try_smi_init() then logs the returned registration failure: ipmi_si IPI0001:00: IPMI message handler: Unable to get the device id: -5 ipmi_si IPI0001:00: Unable to register device: error -5 For ipmi_si, the shutdown callback is shutdown_smi(), which cleans up the SI state machine data, frees smi_info->si_sm, and sets smi_info->si_sm and smi_info->intf to NULL. However, intf->in_shutdown is not set on this failed-registration rollback path. Therefore, the asynchronous redo_bmc_reg work item can still retry BMC device-id probing after the lower driver has already cleared its SI state machine data. In the observed case, that retry path reached start_next_msg(), which passed the NULL smi_info->si_sm pointer to the selected KCS state machine handler: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Workqueue: events redo_bmc_reg [ipmi_msghandler] RIP: start_kcs_transaction+0x2c/0x190 [ipmi_si] Call Trace: start_next_msg+0x50/0x80 [ipmi_si] check_start_timer_thread.part.9+0x3b/0x50 [ipmi_si] sender+0x69/0x80 [ipmi_si] i_ipmi_request+0x2ac/0x9d0 [ipmi_msghandler] __get_device_id.isra.29+0xaa/0x180 [ipmi_msghandler] __bmc_get_device_id+0xef/0x950 [ipmi_msghandler] redo_bmc_reg+0x52/0x60 [ipmi_msghandler] process_one_work+0x1a7/0x360 Set intf->in_shutdown on the out_err_started path before invoking the lower driver's shutdown callback. This prevents later redo_bmc_reg retries from using an interface whose lower driver state has been cleaned up, and applies the same shutdown state to other IPMI interfaces as well.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81007", "url": "https://ubuntu.com/security/CVE-2026-81007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: validate write message length ipmb_write() read message fields before validating the length byte. A zero or short write can read uninitialized stack bytes. A length smaller than the SMBus header underflows the block write length. Require a non-empty buffer and the minimum IPMB request length. Also require the length byte plus payload before parsing the message.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81008", "url": "https://ubuntu.com/security/CVE-2026-81008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: interconnect: Fix use after free in icc_get() and of_icc_get_by_index() In of_icc_get_by_index() and icc_get(), if the dynamic allocation for path->name fails via kasprintf(), the error handling path directly calls kfree(path) to free the path object and returns an error. However, prior to this point, path_find() calls path_init(), which already links the path's requests into the req_list of the respective interconnect nodes via hlist_add_head(). Directly invoking kfree(path) leaves dangling pointers in the hlist. A subsequent call to icc_get() or icc_set_bw() will traverse or modify these corrupted lists, triggering a slab use afterfree. KASAN report showing the vulnerability when reproducing via debugfs: BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0 Fix this by replacing kfree(path) with the proper teardown function, icc_put(path), which safely removes the requests from the req_list using hlist_del() and drops the provider usage references before freeing the memory. Additionally, in icc_get(), ensure that the icc_lock mutex is released prior to calling icc_put(path) to avoid a deadlock, as icc_put() internally acquires the same lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81017", "url": "https://ubuntu.com/security/CVE-2026-81017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Bound the EC-reported sensor number Each EC FIFO event carries an 8-bit sensor number (in->sensor_num). cros_ec_sensorhub_ring_handler() validates the FIFO event count, the per-read count and the ring bound, but not the sensor number, which cros_ec_sensor_ring_process_event() then uses unchecked to index sensorhub->batch_state[] - allocated with only sensorhub->sensor_num entries. A sensor number of sensor_num or larger is an out-of-bounds read and write of batch_state[]. Validate the sensor number in the ring handler, where each event is read from the EC, and drop a malformed event before it is used.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89440", "url": "https://ubuntu.com/security/CVE-2026-89440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: via-sdmmc: stop card-detect handling on probe failure request_irq() registers the SD card-detect interrupt and the probe enables it before mmc_add_host() runs. If mmc_add_host() fails, the error path only unmaps the registers and returns: the interrupt stays registered, so the handler keeps running against the host once it is freed. via_sdc_isr() dereferences sdhost and its MMIO base and schedules carddet_work, which via_sdc_card_detect() also runs against freed memory through its container_of() dereference. Add a probe-error path that disables and frees the interrupt and cancels carddet_work before unmapping. carddet_work can re-enable the device interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it again after cancelling the work. This issue was found by an in-house static analysis tool and confirmed by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89444", "url": "https://ubuntu.com/security/CVE-2026-89444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer set_attribute() populates the security area of the BIOS attribute request buffer with the current admin password via populate_security_buffer(), then dumps the whole request buffer with print_hex_dump_bytes(). This can expose the plaintext admin password in the kernel log. The same issue was fixed for the password attribute path by commit d1a196e0a6dc (\"platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data\"). Remove the remaining dump from the BIOS attribute path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93206", "url": "https://ubuntu.com/security/CVE-2026-93206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/proc: Use file_ns_capable() when checking config space read access proc_bus_pci_read() decides how much of the config space is readable based on capable(CAP_SYS_ADMIN), which checks the credentials of the task calling read(), not the credentials of the process that opened the file. The sysfs equivalent, pci_read_config(), has checked the credentials of the opening process since commit de139a339395 (\"pci: check caps from sysfs file open to read device dependent config space\"), so a privileged process can open the config space file and pass the file descriptor to an unprivileged process (for example, a process running a KVM guest with an assigned device), which can then read the entire config space. The check was subsequently routed through the LSM framework in commit 47970b1b2aa6 (\"pci: use security_capable() when checking capablities during config space read\") and converted to the dedicated helper in commit ab0fa82b2df9 (\"pci-sysfs: use proper file capability helper function\"). Thus, the two interfaces check the same capability against different credentials. Checking the credentials of the task calling read() makes the outcome depend on who reads rather than who opened, so the restriction is bypassed whenever a more privileged process reads through the descriptor. Checking the credentials recorded in file->f_cred settles the decision at open() time and ties it to the file, where it cannot change with the caller. Use file_ns_capable() to check CAP_SYS_ADMIN against the credentials in effect when the file was opened, bringing the procfs interface in line with the sysfs behaviour. As a result, a file descriptor opened by a privileged process and passed to an unprivileged one now allows the entire config space to be read through procfs, matching sysfs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89456", "url": "https://ubuntu.com/security/CVE-2026-89456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Propagate partial completion length across ERP recovery dasd_default_erp_postaction() copies the timing and device state from the finished ERP request back to the original request but drops proc_bytes. A request that was partially completed, an ESE read of a not-yet-allocated track returns fewer bytes than requested, and then recovered through the ERP chain loses its partial-completion length. __dasd_cleanup_cqr() then sees proc_bytes == 0 and completes the whole request instead of requeueing the remainder, silently returning zeroed data for the part that was never read. Carry proc_bytes over to the original request like the other per-request state.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89457", "url": "https://ubuntu.com/security/CVE-2026-89457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Guard sysfs discipline callbacks against unallocated private data Several sysfs show/store handlers call a discipline callback that dereferences device->private, either directly or through the DASD_DEFINE_ATTR() macro. During dasd_generic_set_online() the discipline is assigned before check_device() allocates device->private, so an unprivileged read of one of these world-readable attributes in that window dereferences a NULL pointer and panics. Guard the dereference inside each callback that actually touches device->private.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89458", "url": "https://ubuntu.com/security/CVE-2026-89458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Do not complete a failed ESE read as successful dasd_int_handler() completes an NRF read of an unallocated ESE track by calling ese_read() and unconditionally marking the request DASD_CQR_SUCCESS. dasd_eckd_ese_read() can return an error before it has zeroed the destination buffer: a failed sense-data parse or a current track outside the requested range both return early, leaving the destination pages untouched. The request is still completed successfully, so the block layer is handed stale / uninitialized memory instead of zeros. Check the ese_read() return value and fail the request through the normal error path instead of forcing DASD_CQR_SUCCESS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89461", "url": "https://ubuntu.com/security/CVE-2026-89461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: synchronize work cancellation on suspend max17040_work() requeues itself after every poll. cancel_delayed_work() only cancels a pending instance and does not wait for a callback that is already running. If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns. Use cancel_delayed_work_sync() to ensure polling is quiesced before suspend completes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89463", "url": "https://ubuntu.com/security/CVE-2026-89463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ucs1002: fix use-after-free on remove ucs1002 has no remove callback, so unbind runs entirely through devm. The alert IRQ handler queues the health_poll delayed work, and the work reschedules itself while the chip reports a bad-health condition. devm frees the alert IRQ, which only synchronizes the handler; it does not cancel the delayed work, which can then run after devm frees the driver data and dereference it. Register health_poll with devm_delayed_work_autocancel() before the alert IRQ is requested. devm then frees the IRQ before cancelling the work, so the handler can no longer queue it and the work is cancelled before the driver data is freed. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89464", "url": "https://ubuntu.com/security/CVE-2026-89464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: twl4030_charger: cancel workers via devm bci is devm-allocated. Two workers (bci->work and bci->current_worker) dereference it. twl4030_bci_remove() disables charging and masks interrupts. It cancels neither worker. A worker pending at remove() can run after devm frees bci. The USB transceiver comes from devm_usb_get_phy_by_node(). devm unregisters its notifier only after remove() returns. A cancel_work_sync() in remove() can then race a notifier reschedule. devm_work_autocancel() and devm_delayed_work_autocancel() avoid that. They cancel the workers during devm release, before bci is freed. The current_worker is registered first, since devm will cancel in reverse order and bci->work can reschedule current_worker. [Move comment about order into the commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89469", "url": "https://ubuntu.com/security/CVE-2026-89469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: lp8727: fix use-after-free in lp8727_release_irq() lp8727_isr_func(), the threaded IRQ handler, is the only caller that arms pchg->work via schedule_delayed_work(). lp8727_release_irq() currently cancels the work before freeing the IRQ, so an IRQ delivered in between can re-arm the work through the threaded handler. After .remove returns the devm layer frees pchg while lp8727_delayed_func() may still run and dereference it. Free the IRQ first so the threaded handler is quiesced and can no longer queue work, then cancel the delayed work to drain the final generation. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89470", "url": "https://ubuntu.com/security/CVE-2026-89470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS Currently the cros_usbpd-charger driver probe iterates based on raw charger port count returned by the embedded controller. The only check is against the number of USB PD ports which the embedded controller also defines. A malicious embedded controller could return an inaccurate port count (up to 255) resulting in an out of bounds write and subsequent memory corruption. Update helper functions in cros_usbpd-charger to limit port counts to EC_USB_PD_MAX_PORTS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89471", "url": "https://ubuntu.com/security/CVE-2026-89471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd-charger: bound the EC-reported port count cros_usbpd_charger_probe() reads two port counts from the EC and uses one of them, num_charger_ports, as the loop bound when populating a fixed-size array: \tstruct port_data *ports[EC_USB_PD_MAX_PORTS];\t/* 8 entries */ \t... \tfor (i = 0; i < charger->num_charger_ports; i++) \t\tcharger->ports[charger->num_registered_psy++] = port; Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports (from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The only validation is a sanity check that compares the two EC-reported values against each other: \tif (num_charger_ports < num_usbpd_ports || \t num_charger_ports > num_usbpd_ports + 1) \t\treturn -EPROTO; It never checks either count against EC_USB_PD_MAX_PORTS, the size of the ports[] array. A malfunctioning, malicious or compromised EC that reports num_usbpd_ports == num_charger_ports == N for any N > 8 (for example both 255) passes this check, and the loop then writes N pointers into the 8-entry ports[] array embedded in the devm_kzalloc()'d charger_data, overflowing it by up to 255 - 8 = 247 entries (~1976 bytes): a slab out-of-bounds write. Reject a port count larger than the ports[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89474", "url": "https://ubuntu.com/security/CVE-2026-89474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: drain usb_work before freeing the charger The USB-PHY notifier queues usb_work, whose handler calls power_supply_changed(bq->charger). The reset devm action only unregisters the notifier and was registered before the power supplies, so devm frees bq->charger on unwind before the action runs; a usb_work still queued can then dereference it. Register the reset action after the power supplies, so it unregisters the notifiers and drains usb_work before the supplies are released. Initialize usb_work and obtain the PHY references before registering the notifiers, so the worker cannot run before the supplies exist. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89475", "url": "https://ubuntu.com/security/CVE-2026-89475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq24257: fix use-after-free on remove The STAT-pin interrupt is devm-managed, so it stays armed until the devm cleanup that runs after remove() returns. remove() cancels bq->iilimit_setup_work while the threaded handler can still fire; that handler reschedules the work and dereferences bq, so the work runs against freed memory once devm frees bq. Make the delayed work device-managed with devm_delayed_work_autocancel(), registered before the interrupt request. The devm cleanup then releases the interrupt first, so the handler can no longer reschedule the work, and cancels the work before bq is freed. The explicit cancel_delayed_work_sync() in remove() is no longer needed and is dropped. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89476", "url": "https://ubuntu.com/security/CVE-2026-89476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix stream->outcnt underflow on duplicate RECONF responses A cached RECONF chunk may contain more than one request parameter. A duplicate response can therefore find and process the same ADD_OUT request again while another parameter is still outstanding, rolling back outcnt twice and possibly underflowing it. Track outstanding request types as bits and clear each bit after its first response. Later responses for the same request are then ignored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89477", "url": "https://ubuntu.com/security/CVE-2026-89477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix NULL deref on untransmitted RECONF completion sctp_process_strreset_outreq(), sctp_process_strreset_addstrm_out() and sctp_process_strreset_resp() complete a pending stream reconfiguration request by stopping the reconf timer on the transport it was sent on: \tt = asoc->strreset_chunk->transport; \tif (timer_delete(&t->reconf_timer)) \t\tsctp_transport_put(t); chunk->transport is assigned by __sctp_packet_append_chunk() when the chunk is appended to an outbound packet, and sctp_outq_flush_ctrl() arms the reconf timer at that same point. A request already published in asoc->strreset_chunk but not yet transmitted has neither, so completing it dereferences NULL. Two ways to get there. sctp_send_asconf_del_ip() sets asoc->src_out_of_asoc_ok without sending anything when the address being removed is the association's last one, and sctp_outq_flush_ctrl() then leaves every non-ASCONF control chunk queued; as only sctp_process_asconf_ack() clears that flag, it persists. An unprivileged process that removes such an address and then asks for a stream reset panics the kernel from softirq. A peer needs neither ASCONF nor local help: sctp_cmd_interpreter() uncorks the outqueue only once the whole packet has been processed, so a reply built while walking a RECONF chunk stays untransmitted for the rest of that walk, and one RECONF chunk carrying [Incoming SSN Reset Request, Outgoing SSN Reset Request, Response] -- or two RECONF chunks in one packet -- reaches the same dereference. KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef] RIP: 0010:timer_delete+0x67/0x110 Call Trace: sctp_process_strreset_addstrm_out (net/sctp/stream.c:832) sctp_sf_do_reconf (net/sctp/sm_statefuns.c:4212) sctp_do_sm (net/sctp/sm_sideeffect.c:1172) sctp_assoc_bh_rcv (net/sctp/associola.c:1044) sctp_rcv (net/sctp/input.c:243) ip_local_deliver (net/ipv4/ip_input.c:262) process_backlog (net/core/dev.c:6680) A response can only acknowledge a request that was actually sent, so do not match asoc->strreset_chunk while chunk->transport is NULL. Guarding the lookup covers all three completion sites.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89478", "url": "https://ubuntu.com/security/CVE-2026-89478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: drop a chunk if its transport was removed sctp_rcv() resolves the transport once per packet and leaves it in chunk->transport. The lookup reference, or the one sctp_add_backlog() takes if the socket is owned by userspace, keeps it around until the chunk has been processed. An authenticated ASCONF DEL-IP can remove it in the meantime. sctp_assoc_rm_peer() takes the transport out of the association and calls sctp_transport_free(), which tags it dead and drops the reference the association held. There is a window on both paths: the packet can sit on the socket backlog, and on the direct path the lookup completes before bh_lock_sock(). The DATA chunk in that packet puts the removed transport back into asoc->peer.last_data_from. Once the packet is done that reference goes away and the transport is freed by RCU, so the next delayed SACK carries the pointer into the SACK chunk and sctp_outq_select_transport() reads the freed transport's state. Drop the chunk in sctp_inq_push(), next to the existing rcvr->dead check. Both paths reach it with the association's socket lock held. The peer retransmits it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89479", "url": "https://ubuntu.com/security/CVE-2026-89479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stop processing a packet once its association is deleted sctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference. A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(), so the association and its transports are freed. The endpoint loop has no counterpart to the asoc->base.dead check in sctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed transport and is then passed to sctp_do_sm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context. The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctp_inq_free() releases the chunk on the association receive path. sctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89480", "url": "https://ubuntu.com/security/CVE-2026-89480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: reject a read that transferred too few bytes nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above. A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target. Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89482", "url": "https://ubuntu.com/security/CVE-2026-89482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone Commit 25e5cb780e62 (\"nvme-tcp: fix possible crash in write_zeroes processing\") established that blk_rq_payload_bytes() must not be read without first checking blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight, because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now tests the same two.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89483", "url": "https://ubuntu.com/security/CVE-2026-89483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: zero the discard fallback page nvme_setup_discard() always maps sizeof(struct nvme_dsm_range) * NVME_DSM_MAX_RANGES = 4096 bytes as the DSM payload however many ranges the command declares, because some devices ignore the 'Number of Ranges' field - the Fixes: commit records two that read past the declared ranges. A single-range discard fills only the first 16 bytes. Normally the buffer comes from kzalloc() and the other 4080 bytes are zero. When that allocation fails the code falls back to the per-controller ctrl->discard_page, which nvme_init_ctrl() obtains with alloc_page(GFP_KERNEL) and nothing ever zeroes, so those 4080 bytes are whatever the page last held and are handed to the controller. Reaching it requires the kzalloc(GFP_ATOMIC | __GFP_NOWARN) to fail, that is memory pressure; it is not remotely triggerable. Failing the allocation under KMSAN reproduces it, with the leaked tail full of vmemmap struct page pointers. The extent in the report is a partial transfer of the payload, not the whole 4096 bytes; the 16-byte boundary in it is the one declared range: [ 11.991601] BUG: KMSAN: uninit-value in dma_map_phys+0x14c8/0x1900 [ 11.991969] dma_map_phys+0x14c8/0x1900 [ 11.992220] dma_map_page_attrs+0xcf/0x130 [ 11.992485] e1000_xmit_frame+0x4099/0x6d10 [ 11.992768] dev_hard_start_xmit+0x22f/0xa80 [ 11.993068] sch_direct_xmit+0x35c/0xcb0 [ 11.993315] __dev_queue_xmit+0x1ee5/0x5eb0 [ 11.993608] ip_finish_output2+0x1903/0x1c30 [ 11.993881] ip_finish_output+0x288/0x870 [ 11.994125] ip_output+0x15e/0x400 [ 11.994365] __ip_queue_xmit+0x1e85/0x1fb0 [ 11.994639] ip_queue_xmit+0x60/0x80 [ 11.994899] __tcp_transmit_skb+0x4e71/0x5fa0 [ 11.995210] tcp_write_xmit+0x3a36/0x9160 [ 11.995533] __tcp_push_pending_frames+0xc5/0x3c0 [ 11.995854] tcp_push+0x7dc/0x840 [ 11.996076] tcp_sendmsg_locked+0x766c/0x8400 [ 11.996371] tcp_sendmsg+0x4b/0x90 [ 11.996572] inet_sendmsg+0x134/0x2a0 [ 11.996823] __sock_sendmsg+0x265/0x360 [ 11.997076] sock_sendmsg+0x100/0x1e0 [ 11.997293] nvme_tcp_try_send+0x196f/0x6370 [ 11.997605] nvme_tcp_queue_rq+0x1d54/0x20b0 [ 11.997882] blk_mq_dispatch_rq_list+0x5ee/0x2e50 [ 11.998175] __blk_mq_sched_dispatch_requests+0x16dc/0x24a0 [ 11.998539] blk_mq_sched_dispatch_requests+0x11b/0x2c0 [ 11.998865] blk_mq_run_work_fn+0x13b/0x280 [ 11.999146] process_scheduled_works+0x966/0x1ad0 [ 11.999465] worker_thread+0xe44/0x1480 [ 11.999709] kthread+0x53b/0x600 [ 11.999927] ret_from_fork+0x29f/0x7c0 [ 12.000191] ret_from_fork_asm+0x1a/0x30 [ 12.000460] [ 12.000558] Uninit was created at: [ 12.000788] __alloc_frozen_pages_noprof+0x8bf/0xd30 [ 12.001096] alloc_pages_mpol+0x1d0/0x5f0 [ 12.001326] alloc_pages_noprof+0x102/0x290 [ 12.001627] nvme_init_ctrl+0x5a3/0x9f0 [ 12.001891] nvme_tcp_create_ctrl+0xd75/0x19b0 [ 12.002170] nvmf_dev_write+0x4c68/0x4fd0 [ 12.002426] vfs_write+0x587/0x1a10 [ 12.002636] __x64_sys_write+0x207/0x4f0 [ 12.002874] x64_sys_call+0x2ff0/0x3ea0 [ 12.003123] do_syscall_64+0x147/0x3b0 [ 12.003400] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 12.003680] [ 12.003777] Bytes 16-2843 of 2844 are uninitialized [ 12.004068] Memory access of size 2844 starts at ffff888109f82000 [ 12.004412] [ 12.004530] CPU: 0 UID: 0 PID: 101 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMECTL-gf5098b6bae76 #1 PREEMPT(lazy) [ 12.005127] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 12.005762] Workqueue: kblockd blk_mq_run_work_fn [ 12.006073] ===================================================== Allocate the page with __GFP_ZERO. The single allocation site covers every use of it: bytes no discard has written stay zero, and bytes one did write hold that controller's own range list, which it has already been sent.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89485", "url": "https://ubuntu.com/security/CVE-2026-89485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: pin next file across nlm_inspect_file lock-drop nlm_traverse_files() pins the current file with f_count++ across a mutex_unlock for nlm_inspect_file(), but nothing pins the saved next pointer. A concurrent nlm_release_file() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step. Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock. Always call nlm_file_release() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlm_file_inuse(), which does a live walk of the inode lock list, rather than the cached f_locks field, so skipped files that never ran nlm_inspect_file() are evaluated correctly. Because every file in a hash bucket is now pinned and released, files skipped by the is_failover_file predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89487", "url": "https://ubuntu.com/security/CVE-2026-89487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: only skb_tx_error() a packet we are about to drop queue_userspace_packet() borrows the packet skb -- it only copies it into a private netlink message (user_skb) and does not own it; on return do_execute_actions() keeps forwarding it through the flow's remaining actions. Its error path nevertheless calls skb_tx_error(skb), which via skb_zcopy_clear() does skb_shinfo(skb)->flags &= ~SKBFL_ALL_ZEROCOPY, stripping SKBFL_SHARED_FRAG from that live skb (skb_tx_error()'s kerneldoc says \"skb must be freed afterwards\"). For a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG is what makes esp_input() skb_cow_data() before in-place AEAD; once it is stripped a later local ESP-in-UDP delivery decrypts in place over pages the sender does not own -- an unprivileged page-cache write (the \"Fragnesia\" primitive). do_execute_actions() ignores output_userspace()'s return value, so any action after a failed USERSPACE upcall inherits the stripped skb. Move the skb_tx_error() to the flow-miss drop path - the \"default\" branch of ovs_dp_process_packet()'s switch(error), before kfree_skb(). The call has been here since commit 36d5fe6a0007 (\"core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors\") but was harmless until esp_input() began relying on SKBFL_SHARED_FRAG to gate in-place decrypt; only then did stripping it on a still-forwarded skb become a page-cache write primitive.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89489", "url": "https://ubuntu.com/security/CVE-2026-89489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openrisc: fix arbitrary kernel memory access via or1k_atomic syscall sys_or1k_atomic() (syscall 244 in the \"or1k\" ABI) takes two user pointers, v1 and v2, and swaps the words they point to in hand-written assembly. l.lwz r29,0(r4) l.lwz r27,0(r5) l.sw 0(r4),r27 l.sw 0(r5),r29 The pointers are not checked with access_ok(). The four memory accesses also have no exception table entries. A caller passes a kernel address as either pointer, and the syscall reads from and writes to it directly. This gives an unprivileged process a kernel read/write primitive. It overwrites kernel data such as the sys_call_table, gaining code execution in kernel context. Check both pointers before entering the critical section. Add fixups for the four memory accesses so faults on valid but unmapped user addresses return -EFAULT. [shorne@gmail.com: fix comment style]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89490", "url": "https://ubuntu.com/security/CVE-2026-89490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix readdir position truncation on 32-bit kernels In ocfs2_dir_foreach_blk_el(), the directory cookie position is rebuilt with \tctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset; `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask \t~(sb->s_blocksize - 1) is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB block size). In the AND expression with the 64-bit `ctx->pos`, that unsigned operand is zero-extended to 64 bits per the usual arithmetic conversions, yielding 0x00000000fffff000. The high 32 bits of `ctx->pos` are silently cleared, even though directory size is allowed to exceed 4 GiB. When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position is reset back into the first 4 GiB block, making the re-validation path re-enumerate already-returned dirents indefinitely. This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken for all non-inline directories, so a directory large enough to cross 4 GiB reaches it. This is the same class of bug that commit 3dce5bb82c97 (\"exfat: Fix bitwise operation having different size\") fixed in exfat, and the fix mirrors the equivalent ext4 fix in this series. Cast the operand to loff_t so the mask is 64-bit before the AND: \tctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89491", "url": "https://ubuntu.com/security/CVE-2026-89491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cluster: don't sleep while holding o2hb_live_lock in o2hb_region_pin() Patch series \"ocfs2: cluster: o2hb_region_pin() fixes\", v2. This series fixes three related issues in o2hb_region_pin(), all are from the original implementation in commit: 58a3158a5d17 (\"ocfs2/cluster: Pin/unpin o2hb regions\"): 1) It is called with o2hb_live_lock (a spinlock) held, but the underlying configfs_depend_item() sleeps (takes inode rwsem and pins the filesystem). This triggers BUG under CONFIG_DEBUG_ATOMIC_SLEEP. 2) When called from the configfs drop_item callback, it creates a lock order inversion: parent inode_lock -> configfs root inode_lock, which can deadlock against subsystem unregistration paths taking root -> parent. 3) If pinning fails partway through o2hb_region_inc_user(), the o2hb_dependent_users counter is leaked and partially-pinned regions are never released, leaving heartbeat regions unprotected on subsequent mounts. Patch 1 reworks o2hb_region_pin() to drop o2hb_live_lock across each sleeping configfs_depend_item() call, using a config_item reference to keep the region alive while unlocked. Patch 2 adds a from_callback parameter to select configfs_depend_item_unlocked() when called from configfs context, avoiding the inode_lock nesting. Patch 3 fixes the error path in o2hb_region_inc_user() to unpin and decrement the counter on failure. This patch (of 3): o2hb_region_pin() is always called with the o2hb_live_lock spinlock held (from o2hb_region_inc_user() and o2hb_heartbeat_group_drop_item()), but it calls o2nm_depend_item() -> configfs_depend_item(), which sleeps: it pins the configfs filesystem and takes the configfs root inode rwsem. Under CONFIG_DEBUG_ATOMIC_SLEEP this triggers: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c in_atomic(): 1, ... name: mount.ocfs2 down_write configfs_depend_item o2hb_region_pin o2hb_region_inc_user o2hb_register_callback dlm_register_domain_handlers ... ocfs2_dlm_init ocfs2_mount_volume ocfs2_fill_super Rework o2hb_region_pin() to pin one region at a time with the lock dropped across the sleeping call: under o2hb_live_lock find the next eligible region and take a config_item reference to keep it alive, drop the lock, call o2nm_depend_item(), then retake the lock and record the pin. The config_item_put() is done with the lock released as well, since o2hb_region_release() also acquires o2hb_live_lock and can sleep. The region list may change while unlocked, so the scan restarts from the top after each pin. Local heartbeat still pins only the matching region; global heartbeat pins all eligible regions. The unpin path is unaffected: configfs_undepend_item() only takes a spinlock and does not sleep.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89493", "url": "https://ubuntu.com/security/CVE-2026-89493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate rl_used against rl_count in refcount block validator ocfs2_find_refcount_rec_in_rl() walks the on-disk refcount record array with: \tfor (; i < le16_to_cpu(rb->rf_records.rl_used); i++) { \t\trec = &rb->rf_records.rl_recs[i]; \t\t... rl_recs[] lives in a single metadata block (4096 bytes on the common configuration), so its real capacity is fixed by ocfs2_refcount_recs_per_rb(sb) (247 records for a 4K block with the 16-byte ocfs2_refcount_rec). rl_used and rl_count are both read directly off disk by ocfs2_validate_refcount_block() and are never checked against that capacity, nor against each other, before any refcount/reflink/CoW operation walks the array. A crafted (or corrupted) refcount block with rl_used == 0xffff makes the loop above walk far past the end of the block, dereferencing rl_recs[i] for i up to 65534. The resulting index is then handed to the sibling ocfs2_insert_refcount_rec(), whose insert-shift does: \tif (index < le16_to_cpu(rf_list->rl_used)) \t\tmemmove(&rf_list->rl_recs[index + 1], \t\t\t&rf_list->rl_recs[index], \t\t\t(le16_to_cpu(rf_list->rl_used) - index) * \t\t\t sizeof(struct ocfs2_refcount_rec)); i.e. a memmove() of up to (0xffff - index) * 16 bytes (~1 MiB) from an offset already past the block. This is reachable from an ordinary reflink (FICLONE) against a crafted/corrupted ocfs2 image: attaching an extent whose cpos sorts past every real record in the leaf forces the lookup to run off the end instead of returning early on a match. The attacker model is local: CAP_SYS_ADMIN mounting a crafted or corrupted ocfs2 image, or a raw write to the block device backing an already-mounted ocfs2 filesystem. ocfs2_validate_refcount_block() already validates the block's ECC, signature, rf_blkno and rf_fs_generation, but never rl_count/rl_used against the block's actual on-disk capacity. This is the same class of gap that ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) already closes for the sibling extent-list header, which checks both the record capacity and the \"used\" bound before any code walks h_list.l_recs[]: \tif (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) { \t\trc = ocfs2_error(...); \t\tgoto bail; \t} \tif (le16_to_cpu(eb->h_list.l_next_free_rec) > \t le16_to_cpu(eb->h_list.l_count)) { \t\trc = ocfs2_error(...); \t\tgoto bail; \t} Add the equivalent pair of checks to ocfs2_validate_refcount_block(): reject a refcount block whose rl_count does not match the fixed per-block capacity returned by ocfs2_refcount_recs_per_rb(), and reject rl_used > rl_count. Both checks are skipped when OCFS2_REFCOUNT_TREE_FL is set, because in that case the same union bytes hold an ocfs2_extent_list (rf_list), not the refcount record list (rf_records) -- that layout is already validated separately by ocfs2_validate_extent_block() when the referenced extent block is read. This mirrors the existing \"!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)\" guard used elsewhere in this file (e.g. ocfs2_get_refcount_rec()) to decide whether rf_records or rf_list is the live member of the union. With this in place, a forged rl_used/rl_count is caught at block validation time (ocfs2_error()), consistent with every other corruption check in this function, instead of driving an out-of-bounds read in ocfs2_find_refcount_rec_in_rl() and a subsequent out-of-bounds memmove() in ocfs2_insert_refcount_rec(). Verified against a crafted image on a v6.19 KASAN (KASAN_GENERIC) build: replaying the same reflink (FICLONE) reliably hit a KASAN report in __ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() before this patch, and triggers no report once ocfs2_validate_refcount_block() rejects the forged rl_used/rl_count.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89494", "url": "https://ubuntu.com/security/CVE-2026-89494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate lengths in dlm_mig_lockres_handler A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres->ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain. Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres->lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len <= DLM_LOCKID_NAME_MAX, num_locks <= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89495", "url": "https://ubuntu.com/security/CVE-2026-89495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: bound namelen in dlm_migrate_request_handler Patch series \"ocfs2/dlm: bound peer-controlled lengths in the o2dlm\". The o2dlm receive handlers trust u8 length and count fields from the wire without bounding them, so a node in a DLM domain can corrupt or panic any other node with a malformed message. Three defects: - dlm_migrate_request_handler() passes migrate->namelen unchecked to dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an o2dlm_mle slab object: a heap out-of-bounds write of up to ~215 attacker-controlled bytes. - dlm_mig_lockres_handler() passes mres->lockname_len unchecked to dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname slab object: a heap out-of-bounds write of up to ~223 bytes. - the same handler trusts mres->num_locks without checking that the message is large enough to hold that many entries, so dlm_process_recovery_data() walks mres->ml[] past the kmalloc(data_len) copy and trips a BUG_ON (an out-of-bounds read ending in a panic). The other o2dlm receive handlers already reject an oversized name; the migration and recovery handlers have omitted it since the DLM was added (see the Fixes tags). Patch 1 bounds namelen; patch 2 validates lockname_len, num_locks, and the payload size. Conforming recovery and migration traffic is unaffected. o2net authenticates peers only by the DLM domain key, so any node that has joined the domain -- including a compromised or malicious member -- can send these messages. There is no local trigger; the attacker must already be a member of the cluster. Each sink was confirmed under KASAN with an out-of-tree module mirroring it exactly -- a kmem_cache/kmalloc of the real destination size, then the same unclamped memcpy/loop: slab-out-of-bounds Write for the two writes, Read for the recovery walk, and a panic. A userspace AddressSanitizer build faults identically under -m32 and -m64. Scrubbed logs are available on request. I reported this privately to security@kernel.org and the ocfs2 maintainers on 2026-06-20; with no response after the standard embargo period I am posting the fix publicly. I have no embargo requirement. This patch (of 2): A node receiving a DLM_MIGRATE_REQUEST message trusts the peer-supplied name length (migrate->namelen) without bounding it. dlm_init_mle() then copies that many bytes into the fixed DLM_LOCKID_NAME_MAX-byte mname[] array of an o2dlm_mle slab object, so a malformed message from a cluster peer overflows the slab object by up to ~215 bytes: a heap out-of-bounds write of attacker-controlled data, reachable by any node in the domain. Reject an oversized name, the way dlm_master_request_handler() and the other o2dlm receive handlers already do; the migration handler omits the check entirely. Conforming messages are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89496", "url": "https://ubuntu.com/security/CVE-2026-89496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: always run deallocs on copy-on-write completion Local fuzzing of 6.12.94 has found the following memory leak caused by doing 'copy_file_range()' within the same filesystem: unreferenced object 0xffff88812192c980 (size 32): comm \"syz.0.49\", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................ c0 c5 92 21 81 88 ff ff 00 02 00 00 00 06 00 00 ...!............ backtrace (crc 7068d63f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] ocfs2_find_per_slot_free_list fs/ocfs2/alloc.c:6618 [inline] ocfs2_cache_block_dealloc+0x155/0x4b0 fs/ocfs2/alloc.c:6786 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:944 [inline] direct_splice_actor+0x232/0x480 fs/splice.c:1167 splice_direct_to_actor+0x4b4/0xb60 fs/splice.c:1111 do_splice_direct_actor fs/splice.c:1210 [inline] do_splice_direct+0x10f/0x1c0 fs/splice.c:1236 do_sendfile+0x430/0xbf0 fs/read_write.c:1388 unreferenced object 0xffff88812192c5c0 (size 32): comm \"syz.0.49\", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 29 70 00 00 00 00 00 00 19 00 00 00 00 00 00 00 )p.............. backtrace (crc afec850f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ocfs2_cache_block_dealloc+0x25c/0x4b0 fs/ocfs2/alloc.c:6793 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:9 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89497", "url": "https://ubuntu.com/security/CVE-2026-89497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: skip leading spaces before parsing client debug masks orangefs_prepare_cdm_array() sizes each client debug keyword buffer with strcspn(cds_head, \" \"), but then parses the keyword with %s. The %s conversion skips leading whitespace, while strcspn() does not. If a client debug entry starts with a space, the allocation can be sized for an empty keyword while sscanf() copies the following non-empty token. This can write past the end of the allocated keyword buffer. Skip leading spaces before computing the keyword length so the allocation matches the string parsed by sscanf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89498", "url": "https://ubuntu.com/security/CVE-2026-89498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix double-free of trailer_buf on readdir copy failure On a readdir downcall, orangefs_devreq_write_iter() frees op->downcall.trailer_buf with vfree() when copy_from_iter_full() fails, but does not clear the pointer before goto Efault. The waiter in do_readdir() is then woken with a negative status and frees the same pointer again on its r < 0 path, causing a deterministic double-free. A client holding /dev/pvfs2-req triggers it by sending a readdir downcall whose declared trailer_size exceeds the bytes it supplies. Clear the pointer after freeing so the readdir-side vfree() becomes a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89504", "url": "https://ubuntu.com/security/CVE-2026-89504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: as3722_get_regulator_dt_data: fix premature of_node_put leaving dangling of_node pointer In as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a reference on np, which is then assigned to pdev->dev.of_node. The function immediately calls of_node_put(np), releasing the reference and leaving pdev->dev.of_node as a dangling pointer. Remove the of_node_put(np) call to let the device hold the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89508", "url": "https://ubuntu.com/security/CVE-2026-89508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Lock the handler in ucma_set_ib_path() ucma_set_ib_path() calls ucma_event_handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference: \tmutex_lock(&ctx->file->mut);\t\t\t/* file A */ \tlist_add_tail(&uevent->list, &ctx->file->event_list);\t/* file B */ \tmutex_unlock(&ctx->file->mut);\t\t\t/* file B */ \twake_up_interruptible(&ctx->file->poll_wait);\t/* file B */ A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION caller sleeps in mutex_lock(), so the list_add_tail() lands on file B's event_list while only file A's mutex is held, racing every other user of that list: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0 Read of size 8 at addr ffff888153c6a418 by task poc_corr/486 Call Trace: __list_add_valid_or_report+0x1aa/0x1c0 ucma_event_handler+0x1be/0xc00 ucma_set_ib_path+0x45e/0x710 ucma_set_option+0x32e/0x590 ucma_write+0x1f9/0x330 Allocated by task 505: ucma_write_cm_event+0x1a1/0x660 Freed by task 505: kfree+0x1da/0x4c0 ucma_get_event+0x5d5/0x7e0 The freed object is a ucma_event that another thread dequeued from file B's list under file B's mutex. File A's mut is left held on top of that, wedging its next writer in uninterruptible sleep. This path needs a bound and address-resolved cm_id, so it requires an RDMA device to be present. Take the handler lock around the call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89510", "url": "https://ubuntu.com/security/CVE-2026-89510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Cancel reg_work before freeing device on remove c4iw_uld_state_change() queues reg_work to register the RDMA device. c4iw_remove() can free ctx->dev while this work is pending or running, leaving c4iw_register_device() accessing the freed device. Cancel reg_work before removing the device. The registration work can tear down ctx->dev when registration fails, so do not unregister or deallocate it again in that case. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89511", "url": "https://ubuntu.com/security/CVE-2026-89511", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: Fix NULL pointer dereference in TPA fragment processing Under memory pressure, the qede driver encounters NULL pointer dereferences when processing TPA continuation fragments. Commit 8a8633978b84 (\"qede: Add build_skb() support.\") accidentally dropped the assignment of tpa_info->buffer.data in qede_tpa_start(). When memory pressure causes an SKB allocation failure in qede_tpa_start(), the driver sets tpa_start_fail = true and attempts to recycle the physical page later in qede_tpa_end() via qede_reuse_page(). However, because buffer.data was left uninitialized (NULL), qede_reuse_page() pushes a \"ghost\" BD (valid DMA mapping but NULL data pointer) back into the active Rx ring. The next time the hardware uses this ring slot, it passes a NULL page to qede_fill_frag_skb(), causing a kernel panic. Example crash from production system: BUG: unable to handle kernel NULL pointer dereference at 0x8 RIP: qede_fill_frag_skb+0x96/0x430 [qede] Call Trace: qede_rx_int+0xb06/0x1de0 qede_poll+0x2f4/0x6c0 __napi_poll+0x2d/0x130 Fix the root cause by restoring the tpa_info->buffer.data assignment in qede_tpa_start(), ensuring valid pages are correctly tracked and recycled. Additionally, update the stale comment for struct qede_agg_info::buffer to reflect its current usage.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89512", "url": "https://ubuntu.com/security/CVE-2026-89512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: scp: Fix device reference leak on failed lookup Make sure to drop the reference taken to the SCP device when attempting to look up its driver data before the driver has been bound. Note that holding a reference to a device does not prevent its driver data from going away.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89524", "url": "https://ubuntu.com/security/CVE-2026-89524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: clamp assoc request/response lengths before subtracting IE offsets ath6kl_cfg80211_connect_event() subtracts fixed IE offsets from assoc_req_len (-= 4) and assoc_resp_len (-= 6), both u8, with no lower bound. The aggregate check recently added to ath6kl_wmi_connect_event_rx() bounds the declared lengths from above (their sum must fit the received event), but an assoc request/response shorter than its fixed offset still underflows here: the u8 wraps to ~250, and cfg80211_connect_result() / cfg80211_roamed() then treat that wrapped value as the IE length and copy that many bytes out of the small assoc_info buffer to user space via nl80211, disclosing adjacent slab memory. Clamp both lengths to their offsets before subtracting. Found by 0sec (https://0sec.ai) using automated source analysis; the missing lower bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89525", "url": "https://ubuntu.com/security/CVE-2026-89525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: reject VAT indexes equal to the entry count UDF 1.50 virtual partition mapping uses the VAT as an array of physical block mappings. s_num_entries stores the number of entries in that array, not the highest valid index. The valid VAT indexes are therefore below s_num_entries. udf_get_pblock_virt15() currently rejects only indexes greater than s_num_entries. A crafted image can request index s_num_entries, pass the bounds check, and make the kernel read one entry past the allocated VAT table. Change the check to reject block >= s_num_entries, so the count is handled as an exclusive upper bound. A crafted UDF image reproduced this on origin/master commit 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53 with a KASAN slab-out-of-bounds report in udf_get_pblock_virt15(). Trail of Bits has a reproducer that triggers kernel panic demonstrating the bug, and can share it if needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89532", "url": "https://ubuntu.com/security/CVE-2026-89532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix pcl_for_each_segment for empty chunks When a parsed chunk list contains a chunk whose ch_segcount is zero, pcl_for_each_segment computes its inclusive upper bound as &chunk->ch_segments[ch_segcount - 1]. ch_segcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the ch_segments flex array. The loop body then walks unrelated memory at sizeof(struct svc_rdma_segment) stride until it faults. A zero-segcount chunk is reachable from the wire: xdr_check_write_chunk() only rejects segcount values greater than rc_maxpages, and pcl_alloc_write() links a freshly allocated chunk onto rc_write_pcl/rc_reply_pcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves ch_segcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svc_rdma_get_inv_rkey() iterates all four PCLs with pcl_for_each_segment and dereferences segment->rs_handle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault. xdr_check_write_list / xdr_check_reply_chunk pcl_alloc_write() chunk = pcl_alloc_chunk(...) /* ch_segcount = 0 */ list_add_tail(&chunk->ch_list, &pcl->cl_chunks) /* fill loop iterates zero times for wire segcount 0 */ svc_rdma_get_inv_rkey() pcl_for_each_chunk(rc_write_pcl) pcl_for_each_segment(segment, chunk) pos <= &ch_segments[0u - 1u] /* 0xFFFFFFFF */ segment->rs_handle /* OOB read -> GPF */ Fix by switching the macro to a half-open upper bound that uses ch_segcount directly. For ch_segcount == 0 the loop start equals the loop end and the body is skipped; for ch_segcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and net/sunrpc/xprtrdma/svc_rdma_rw.c remain correct under the new bound, so no caller changes are needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89533", "url": "https://ubuntu.com/security/CVE-2026-89533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix offset arithmetic in read_chunk_range svc_rdma_read_chunk_range() walks a Read chunk's segment list to build a sub-range starting at byte offset and spanning length bytes for a Position-Zero or Call chunk. Two arithmetic defects in the per-segment loop produce wrong DMA lengths and a u32 underflow: pcl_for_each_segment(segment, chunk) { if (offset > segment->rs_length) { offset -= segment->rs_length; continue; } dummy.rs_handle = segment->rs_handle; dummy.rs_length = min_t(u32, length, segment->rs_length) - offset; dummy.rs_offset = segment->rs_offset + offset; First, the skip predicate uses '>' instead of '>='. When offset equals the segment's full rs_length, the segment is fully consumed and should be skipped, but the loop falls through into the body. The resulting dummy.rs_length is min_t(u32, length, rs_length) - rs_length, which underflows to a near-UINT_MAX u32 when length is smaller than rs_length, or is zero otherwise. Second, the length formula subtracts offset from the min_t() result rather than from segment->rs_length before the cap. For offset > 0 the segment's residual is rs_length - offset, not rs_length, so the cap must be applied to the residual. With the current bracketing, whenever length is smaller than rs_length - offset the per-segment length becomes length - offset instead of length, silently dropping offset bytes from the rebuilt chunk. Combined with the boundary case above it also enables the u32 underflow path, which propagates a huge nr_bvec into svc_rdma_build_read_segment() and a multi-MiB kmalloc_array_node() in svc_rdma_get_rw_ctxt(). Additionally, svc_rdma_read_call_chunk() can invoke this function with length == 0 when the last Read chunk ends exactly at the end of the Call chunk. With the corrected >= predicate, every segment is skipped and the function returns the initial -EINVAL, rejecting a valid request. Return success immediately when length is zero. Also break out of the loop once length is fully consumed to avoid passing zero-length segments to svc_rdma_build_read_segment(). Fix by using '>=' so a fully-consumed segment is skipped, by moving '- offset' inside min_t() so the cap is applied to the segment's residual length, by returning success for zero-length requests, and by stopping iteration when the requested range has been consumed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89538", "url": "https://ubuntu.com/security/CVE-2026-89538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field gss_krb5_unwrap_v2() sets buf->len to a logical length, which can be much smaller than head[0].iov_len (the allocated receive-page capacity). It then calls xdr_buf_trim() with a trim length derived from the 16-bit \"extra count\" (ec) field in the Kerberos v2 token header. The ec field is authenticated by the post-decrypt memcmp() against the encrypted header copy, so a randomly-mutated value is rejected. However, any peer holding a valid GSS context can legitimately encrypt a token whose ec exceeds the plaintext length. Per RFC 4121, such a token is structurally malformed. Although xdr_buf_trim() now clamps the buf->len subtraction to avoid unsigned underflow, the buffer is still left in a semantically invalid state (zero length, inconsistent iov lengths) when ec is oversized. Reject these tokens before calling xdr_buf_trim(), giving callers a well-defined GSS_S_DEFECTIVE_TOKEN error and keeping the xdr_buf internally consistent. The wrapped blob begins at a nonzero offset -- both callers pass len as offset + opaque_len -- so buf->len still counts the offset bytes that precede the blob. Compare the trim length against the remaining wrapped segment, buf->len - offset, rather than the whole buffer; comparing against buf->len alone leaves an offset-wide window in which an oversized ec passes the test and xdr_buf_trim() cuts into the bytes ahead of the blob.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89540", "url": "https://ubuntu.com/security/CVE-2026-89540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: init gssp_lock before publishing proc entry create_use_gss_proxy_proc_entry() publishes /proc/net/rpc/use-gss-proxy via proc_create_data() before init_gssp_clnt() runs mutex_init() on sn->gssp_lock. Once the dentry is linked under proc_subdir_lock it is immediately reachable from userspace, so a write that lands in the window drives set_gssp_clnt() into mutex_lock() on a zero-initialized struct mutex. create_use_gss_proxy_proc_entry(net) proc_create_data(\"use-gss-proxy\", ...) /* dentry live */ init_gssp_clnt(sn) mutex_init(&sn->gssp_lock) /* too late */ write_gssp() set_gssp_clnt(net) mutex_lock(&sn->gssp_lock) /* uninitialized */ gssp_rpc_create(...) sn->gssp_clnt = clnt mutex_unlock(&sn->gssp_lock) The window spans only the two statements between proc_create_data() returning and init_gssp_clnt(), so a writer reaches it only if the registering thread is preempted there while another task is already opening the freshly published file. register_pernet_subsys() runs in preemptible context under pernet_ops_rwsem, so that preemption is possible, and the window widens on auth_rpcgss module load, when the proc entry is created for every live net namespace whose tasks are already running. A writer that wins the race locks a zero-filled struct mutex. On CONFIG_DEBUG_MUTEXES the missing magic value trips a \"lock used without init\" splat; on a production kernel the fast path acquires the lock via CMPXCHG(owner, 0, current). In the latter case a second writer that arrives before init_gssp_clnt() re-zeroes owner can enter set_gssp_clnt() concurrently, shut down the first writer's clnt while it is still in use, and leak the loser's clnt. Fix by initializing sn->gssp_lock in sunrpc_init_net() so its lifetime matches the sunrpc_net it lives in. sn->gssp_clnt is already NULL from the kzalloc that backs net_generic storage, so the lazy helper is no longer needed; drop init_gssp_clnt(), its prototype, and the call from create_use_gss_proxy_proc_entry(). sunrpc.ko is a build-time dependency of auth_rpcgss.ko, so sunrpc_init_net() has always run on every netns before any auth_gss pernet init can publish the proc entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89541", "url": "https://ubuntu.com/security/CVE-2026-89541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_unwrap_resp_priv length checks gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 (\"SUNRPC: svcauth_gss: enforce krb5 token minimum length\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89542", "url": "https://ubuntu.com/security/CVE-2026-89542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_krb5_unwrap_v2 against short tokens gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and ptr+6 before validating that the token is at least GSS_KRB5_TOK_HDR_LEN (16) bytes long, and its rotate_left() helper passes buf->len - base to xdr_buf_subsegment() without verifying that base <= buf->len. When a caller hands in a sub-16-byte token, or a token whose declared len leaves base past the end of the buffer, three distinct failures follow: gss_krb5_unwrap_v2(offset, len, buf) ptr = buf->head[0].iov_base + offset ec = *(ptr + 4) /* OOB read on short head */ rrc = *(ptr + 6) /* OOB read on short head */ rotate_left(offset + 16, buf, rrc) xdr_buf_subsegment(buf, &subbuf, base, buf->len - base) /* u32 wrap when base > len */ _rotate_left(&subbuf, shift) shift %= buf->len /* divide-by-zero when base == len */ After decryption, the cleanup arithmetic has the same shape: movelen = min_t(unsigned int, buf->head[0].iov_len, len); movelen -= offset + GSS_KRB5_TOK_HDR_LEN + headskip; BUG_ON(offset + GSS_KRB5_TOK_HDR_LEN + headskip + movelen > buf->head[0].iov_len); The BUG_ON re-adds the value just subtracted, so it reduces to min(A, B) > A and is permanently false; it cannot catch the unsigned underflow of movelen, which then drives a ~UINT_MAX-byte memmove(). Add four defense-in-depth guards inside the unwrap core so it is safe regardless of what its callers validate: - reject tokens with len - offset < GSS_KRB5_TOK_HDR_LEN before touching ptr+4/ptr+6; - bail from rotate_left() when buf->len <= base, covering both the underflow and zero-length cases; - return early from _rotate_left() when buf->len is zero, so the shift %= buf->len modulo cannot fault; - replace the dead BUG_ON with a live check that returns GSS_S_DEFECTIVE_TOKEN before the movelen subtraction.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89548", "url": "https://ubuntu.com/security/CVE-2026-89548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: always drain cache_cleaner before destroying a cache_detail sunrpc_destroy_cache_detail() only cancels the global cache_cleaner delayed_work when cache_list is empty. During per-netns teardown cache_list is never empty because init_net's caches remain registered, so the cancel never fires. After unlink, the caller proceeds to cache_destroy_net() which kfrees the cache_detail while cache_clean() may still hold a dangling pointer to it. The result is a use-after-free: cache_dequeue() takes cd->queue_lock on freed memory, and cache_put() dereferences cd->cache_put as a function pointer from freed slab. Drop the list_empty guard so that cancel_delayed_work_sync() always runs, ensuring any in-flight cache_clean() completes before the cache_detail is freed. Re-arm the cleaner afterwards if other caches are still registered.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89549", "url": "https://ubuntu.com/security/CVE-2026-89549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: route to a populated pool in svc_pool_for_cpu() svc_set_num_threads() spreads the requested threads evenly across the service's pools (base = nrservs / sv_nrpools). When a service runs fewer threads than it has pools -- e.g. an nfsd configured with fewer threads than the host has NUMA nodes while running in \"pernode\" or \"percpu\" mode -- the trailing pools are left with no threads at all. svc_xprt_enqueue() selects a pool from the CPU servicing the transport, queues the transport on that pool's sp_xprts, and only wakes a thread from the same pool. Each thread services exclusively its own pool, so a transport that lands on a threadless pool is enqueued on sp_xprts and never picked up: the connection hangs indefinitely. Have svc_pool_for_cpu() skip pools that currently have no threads, falling back to the next populated pool. This trades NUMA locality for a guarantee that the work is actually serviced. sp_nrthreads is only updated under the service mutex; the lockless read here is a best-effort routing hint, so annotate it with data_race().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89551", "url": "https://ubuntu.com/security/CVE-2026-89551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow xdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by walking the tail, pages, and head iovecs. Each per-section step uses min_t() so it never removes more bytes than that section holds, but the final accounting at the fix_len label subtracts the total bytes actually consumed from buf->len without any clamp: fix_len: buf->len -= (len - trim); When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches xdr_buf_trim() in exactly that state: buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip; buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip); xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip); buf->len is a small wire-derived value while the iov_lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder. Fix by clamping the decrement so buf->len bottoms out at zero: buf->len -= min_t(unsigned int, buf->len, len - trim); On the normal path where the iov_lens sum to buf->len, (len - trim) is always <= buf->len and the result is identical to before. No callers change behavior outside the underflow case.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89554", "url": "https://ubuntu.com/security/CVE-2026-89554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection. Restore subflow_req->local_id from the cookie entry, as done for the other fields.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89555", "url": "https://ubuntu.com/security/CVE-2026-89555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: reload header after pskb_may_pull() mpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop when an MPLS route has multiple nexthops. While walking the MPLS label stack, the hash routine caches hdr for the current label. After finding the bottom-of-stack label, it calls pskb_may_pull() before reading the inner IP header. If an skb is constructed with the inner IP header in nonlinear data and insufficient tailroom in the linear head, pskb_may_pull() calls pskb_expand_head() to replace the skb head and free the old one. This leaves hdr pointing to freed memory. The IPv6 path can invalidate hdr again when it performs a second pull for the larger header. The issue was found through static analysis. A reproducer sending a legal Geneve packet through a bareudp/MPLS multipath setup triggered the same KASAN report in 2 of 2 unpatched runs: BUG: KASAN: slab-use-after-free in mpls_select_multipath Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23 Call Trace: mpls_select_multipath mpls_forward __netif_receive_skb_list_core netif_receive_skb_list_internal napi_complete_done gro_cell_poll __napi_poll net_rx_action Freed by task 23: kfree pskb_expand_head __pskb_pull_tail mpls_select_multipath Reload hdr from the current skb head after each successful pull before deriving the inner IPv4 or IPv6 header pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89557", "url": "https://ubuntu.com/security/CVE-2026-89557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: do overflow check for sb->bblog_shift in super_1_load() In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 } bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c. Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller. This may avoid unnecessary check, make the badblocks API code more simple and elegant.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89559", "url": "https://ubuntu.com/security/CVE-2026-89559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Prevent integer overflow in __nd_label_validate() The on-media namespace index field nslot is a u32 read from the DIMM label storage area. __nd_label_validate() bounds it against the config area size, but sizeof_namespace_label() returns unsigned, so the product nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before the comparison. A crafted nslot passes the bound and is then used as the loop trip count in nd_label_data_init(), whose memset() walks off the end of the config_size buffer: an out-of-bounds write. The field is not trusted -- it comes from the medium, or from userspace via ND_CMD_SET_CONFIG_DATA. Evaluate the product in 64-bit so the bound check is exact; conforming labels are unaffected. The check was safe when introduced by commit 4a826c83db4e (\"libnvdimm: namespace indices: read and validate\"): it multiplied by sizeof(struct nd_namespace_label), a size_t, so on a 64-bit build the product did not wrap. Commit 564e871aa66f (\"libnvdimm, label: add v1.2 nvdimm label definitions\") narrowed it to 32 bits when the label size became a runtime value read via sizeof_namespace_label().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93226", "url": "https://ubuntu.com/security/CVE-2026-93226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU iterator to dump route exceptions rt6_nh_dump_exceptions() uses hlist_for_each_entry() to iterate over RCU-protected exception lists. The caller holds rcu_read_lock(), but does not hold rt6_exception_lock, so rt6_insert_exception() can concurrently add an entry with hlist_add_head_rcu(). KCSAN reports this race (irrelevant details omitted): ================================================================== BUG: KCSAN: data-race in rt6_insert_exception / rt6_nh_dump_exceptions write (marked) to 0xffff8a7c44c59620 of 8 bytes by interrupt on cpu 5: rt6_insert_exception+0x3bb/0x760 __ip6_rt_update_pmtu+0x4fe/0x750 ip6_sk_update_pmtu+0x19a/0x3b0 udpv6_err+0x3ff/0x800 icmpv6_notify+0x1e1/0x440 icmpv6_rcv+0x8c0/0xab0 ip6_protocol_deliver_rcu+0x616/0x840 ip6_input_finish+0xb9/0x160 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff8a7c44c59620 of 8 bytes by task 549 on cpu 14: rt6_nh_dump_exceptions+0xb3/0x260 rt6_dump_route+0x53e/0x5f0 fib6_dump_node+0x6d/0xf0 fib6_walk_continue+0x290/0x2d0 fib6_dump_table+0x28d/0x360 inet6_dump_fib+0x37d/0x620 rtnl_dumpit+0x7b/0xd0 netlink_dump+0x3ae/0x7e0 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f 4 locks held by dumper/549: ... #1: (rcu_read_lock){....}-{1:3}, at: inet6_dump_fib+0x88/0x620 #2: (&tb->tb6_lock){+.-.}-{3:3}, at: fib6_dump_table+0x1e9/0x360 #3: (rcu_read_lock){....}-{1:3}, at: rt6_dump_route+0x483/0x5f0 value changed: 0xffff8a7c44e05700 -> 0xffff8a7c45d60100 Reported by Kernel Concurrency Sanitizer on: CPU: 14 UID: 0 PID: 549 Comm: dumper Not tainted 7.2.0-rc7-virtme #38 PREEMPT(lazy) ... Use hlist_for_each_entry_rcu() to safely iterate over the exception list.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89562", "url": "https://ubuntu.com/security/CVE-2026-89562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: fix hardware header length for NBMA tunnels ip6gre_tnl_link_config_route() accumulates the lower device's hardware header length into dev->hard_header_len whenever header_ops is set. This is incorrect for both users of header_ops. ip6gretap and ip6erspan have a fixed Ethernet hardware header length. For an NBMA ip6gre tunnel, ip6gre_header() creates only the GRE header, the optional FOU or GUE header, and the outer IPv6 header. The lower device header is headroom needed later, not part of the tunnel device's hardware header. Keep the lower device header in needed_headroom. Set hard_header_len to the tunnel header length only for ARPHRD_IP6GRE devices with header_ops, and leave the fixed Ethernet header length unchanged for tap and erspan devices.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89563", "url": "https://ubuntu.com/security/CVE-2026-89563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit() ip6_tnl_xmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skb_realloc_headroom(), copies skb->sk ownership, consumes the original skb, and then continues processing with the replacement skb kept only in its local variable. That is safe only if the helper cannot fail afterwards. But this helper still has post-reallocation error exits. collect_md tunnels reject non-NONE encap after the replacement, and ip6_tnl_encap() can also fail later. In those cases the helper returns an error to its callers while the caller still only has the original skb pointer. Both ip6_tnl_start_xmit() and the IPv6 GRE paths free the caller skb on error, so they can end up freeing an skb that ip6_tnl_xmit() already consumed. Use skb_cow_head() instead. It provides the required headroom and writability without privately replacing the caller-owned skb, so later error returns cannot leave callers with a stale pointer. The Ethernet users, ip6gretap and ip6erspan, clear IFF_TX_SKB_SHARING and already call skb_cow_head() before entering ip6_tnl_xmit(). They do not rely on the removed skb_shared() reallocation. This also makes the IPv6 tunnel path consistent with ip_tunnel_xmit().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89569", "url": "https://ubuntu.com/security/CVE-2026-89569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: serialize security confirmation handling rfcomm_security_cfm() looks up a session on session_list and then walks its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown uses rfcomm_mutex, krfcommd can close and free the same session and DLCs concurrently: hci_rx_work krfcommd ----------- --------- rfcomm_session_get() rfcomm_lock() rfcomm_session_close() rfcomm_dlc_unlink() rfcomm_session_del() kfree(s) rfcomm_unlock() walk s->dlcs The callback can then read a freed session list head and touch freed DLCs while updating their flags or timers. Serialize the session lookup and DLC traversal in rfcomm_security_cfm() with rfcomm_mutex. This matches the existing RFCOMM session lifetime rules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink() from tearing the objects down while the callback is using them. KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440 Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89 Workqueue: hci0 hci_rx_work Call Trace: rfcomm_security_cfm+0x41c/0x440 hci_encrypt_cfm+0x139/0x590 hci_encrypt_change_evt+0x37b/0xc40 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 69: rfcomm_session_add+0x9e/0x2f0 rfcomm_run+0x44b/0x41e0 Freed by task 69: kfree+0x131/0x3c0 rfcomm_session_del+0x188/0x220 rfcomm_run+0x1985/0x41e0", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89573", "url": "https://ubuntu.com/security/CVE-2026-89573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm array: reject an array block whose value size is not the caller's array_block_check() can only compare the header against itself, so a block with value_size 4 and max_entries 1018 is internally consistent and passes. dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and the roots for both live in the superblock. Point the mappings root at a hint block and __load_mappings() walks it through an info whose value size is 8, so element_at() strides 8 bytes over 4-byte entries and reaches offset 8160 of a 4096-byte block. get_ablock() and __shadow_ablock() are the two places that hold the block and the caller at once. Reject there when the two value sizes disagree. Arrays only ever read their own blocks, so this fires on crafted metadata only.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89575", "url": "https://ubuntu.com/security/CVE-2026-89575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm raid1: reserve space for NUL-terminator in build_constructor_string() Reserve space for the termination NUL after the maximum 20 decimal digits of a long long value to avoid buffer overflow in sprintf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89576", "url": "https://ubuntu.com/security/CVE-2026-89576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-era: fix shadowed superblock leak on take-snap failure metadata_take_snap() bumps the live superblock refcount and then dm_tm_shadow_block() allocates a new block for the metadata snapshot. If the subsequent dm_sm_inc_block() of writeset_tree_root or era_array_root fails, the function only unlocks the clone and returns. The newly allocated shadow block is never returned to the metadata space map, so each failed take-snap permanently leaks one metadata block. Free the clone with dm_sm_dec_block() on those error paths, matching the final step of metadata_drop_snap().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89582", "url": "https://ubuntu.com/security/CVE-2026-89582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix double free in bnx2x_init_firmware() error path bnx2x_init_firmware() frees bp->init_ops, bp->init_data and bp->init_ops_offsets in its error path without setting them to NULL. The cleanup function bnx2x_release_firmware() frees the same three pointers unconditionally, so if init_firmware fails and release_firmware is later called (e.g. from __bnx2x_remove or through the function state machine), all three are freed a second time. Set each pointer to NULL after kfree() in the error path so that the subsequent kfree(NULL) in bnx2x_release_firmware() is a safe no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89585", "url": "https://ubuntu.com/security/CVE-2026-89585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: auxdisplay: charlcd: cancel backlight work on registration failure With CONFIG_CHARLCD_BL_FLASH, charlcd_init() schedules bl_work before charlcd_register() calls misc_register(). If registration fails, the caller frees the charlcd object while delayed work still contains its address. Add charlcd_deinit() to cancel the delayed work and turn the backlight off. Use it for both registration rollback and normal unregistration.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89586", "url": "https://ubuntu.com/security/CVE-2026-89586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes ata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the UNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command. The TRIM descriptor is built by ata_format_dsm_trim_descr() into the 2048-byte ata_scsi_rbuf staging buffer, and the number of bytes copied is compared against the logical sector size by the caller: \tsize = ata_format_dsm_trim_descr(scmd, trmax, block, n_block); \tif (size != len)\t\t/* len == sdp->sector_size */ \t\tgoto invalid_param_len; ata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE (2048). On a device whose logical sector size exceeds that (e.g. a 4Kn device, where sector_size == 4096) the function can never return more than 2048, while the caller expects it to return sector_size. The comparison therefore always fails, so every TRIM is rejected with \"Parameter list length error\" and WARN_ON() splats on each attempt. TRIM / discard is thus completely broken on such devices. The descriptor was incorrectly sized from the logical sector size. A DSM TRIM payload is a list of 512-byte pages, each holding up to ATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical sector size. The Block Limits VPD page already advertises a single such page as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical blocks), so the block layer never sends a request that needs more than one page. Emit exactly one 512-byte page, independent of the logical sector size, and transfer only that page (COUNT == 1). For a 512-byte-sector device this is unchanged; devices with larger logical sectors now work instead of failing every TRIM.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89594", "url": "https://ubuntu.com/security/CVE-2026-89594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device The OMAP SSI driver uses a synthetic HSI controller device allocated via hsi_alloc_controller(), which does not go through the normal OF/platform device initialization path. As a result, the embedded struct device does not have a DMA mask initialized by default. After recent DMA API hardening changes, dma_map_sg() and related helpers now require a valid dma_mask to be present, otherwise the driver may crash or trigger warnings when attempting DMA mapping operations. Fix this by explicitly initializing the DMA mask for the SSI controller device and setting a 32-bit DMA mask, which matches the hardware capabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89596", "url": "https://ubuntu.com/security/CVE-2026-89596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix off-by-one when saving/restoring non-PCI config space nv_suspend() and nv_resume() walk the non-PCI configuration space with \tfor (i = 0; i <= np->register_size/sizeof(u32); i++) which runs one iteration too many. saved_config_space is declared as \tu32 saved_config_space[NV_PCI_REGSZ_MAX/4]; and NV_PCI_REGSZ_VER3 is equal to NV_PCI_REGSZ_MAX (0x604), so on a VER3 device register_size/sizeof(u32) is exactly the array length and the last iteration addresses one element past the end. The element it lands on is np->name_rx[0..3]: saved_config_space[] is followed immediately by char name_rx[IFNAMSIZ + 3], and char needs no padding. Nothing observable is corrupted by that, because nv_request_irq() rewrites name_rx with sprintf() before it is ever passed to request_irq(). The bug is the out-of-bounds access itself, which UBSAN reports and which CONFIG_UBSAN_TRAP=y turns into a trap that aborts the running kernel code, plus an MMIO read and, on resume, an MMIO writel() to base + 0x604, one dword past the range the driver mapped: \tnp->base = ioremap(addr, np->register_size); VER1 and VER2 devices stay inside the array, but they too get the stray read and the stray write one dword past their own window. Caught by UBSAN on an Apple Macmini3,1 (MCP79) during a deep S3 cycle. The splat below is trimmed: the build path in the file name, the CPU and taint lines, the Workqueue line, the \"?\" hint frames, and the frames below device_suspend are all cut. The kernel was tainted, with an out-of-tree nouveau and CPU_OUT_OF_SPEC; forcedeth itself was the stock module. UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c:6225:25 index 385 is out of range for type 'u32 [385]' Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... Both loops are hit. UBSAN reports each source location only once per module load (__ubsan_handle_out_of_bounds() calls suppress_report(), which does test_and_set_bit(REPORTED_BIT, ...) on the struct source_location), so the two splats land in the first S3 cycle after the module is loaded and later cycles are silent even though the access still runs off the end every time. In that first cycle line 6225 is reported from pci_pm_suspend and line 6240 from pci_pm_resume. The same off-by-one was fixed in nv_get_regs() by commit ba9aa134287f (\"forcedeth: fix buffer overflow\") in 2012; these two loops were missed. The suspend and resume side was reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix, but the patch was attached rather than sent inline and the thread ended there. Use < instead of <=, which saves and restores exactly register_size bytes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89597", "url": "https://ubuntu.com/security/CVE-2026-89597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: unregister connector callback on init failure uvesafb_init() registers the v86d connector callback before registering the platform driver. If platform_driver_register() fails, the function returns the error directly and leaves the connector callback registered. The later platform-device failure path already unregisters the callback. Add the same cleanup before the final return when platform-driver registration fails. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89599", "url": "https://ubuntu.com/security/CVE-2026-89599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: panel-dsi-cm: initialize lock before registering display dsicm_probe() registers the display before initializing ddata->lock. Once omapdss_register_display() publishes the display, another consumer can reach a dsicm callback that takes this mutex while it is still uninitialized. Initialize the mutex before registering the display so the published callbacks always see a valid lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89605", "url": "https://ubuntu.com/security/CVE-2026-89605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: release message context on send failure ecryptfs_send_message_locked() moves a message context from the free list to the allocated list before sending the request to the userspace daemon. If ecryptfs_send_miscdev() fails, the context is left on the allocated list and cannot be reused. Move it back to the free list on failure and clear the caller's pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89606", "url": "https://ubuntu.com/security/CVE-2026-89606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject too-small tag 70 packets ecryptfs_parse_tag_70_packet() subtracts fixed metadata fields from the parsed packet body size to derive the encrypted filename size. A malformed packet with a body smaller than those fixed fields can underflow that size calculation. Reject tag 70 packets before the subtraction unless the body contains the signature, cipher code, and at least one byte of encrypted filename data.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89607", "url": "https://ubuntu.com/security/CVE-2026-89607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key() sets decrypted_key_size = encrypted_key_size and performs two out-of-bounds writes: 1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into decrypted_key[64] via scatterlist, overflowing into the parent ecryptfs_auth_tok struct. 2. memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes into crypt_stat->key[64], corrupting root_iv, keysig_list, and mutexes in ecryptfs_crypt_stat. Only AES-192 (cipher code 0x08) enables this because it sets crypt_stat->key_size = 24 independently of encrypted_key_size, allowing crypto_skcipher_setkey() to succeed while encrypted_key_size exceeds ECRYPTFS_MAX_KEY_BYTES. The PKI decryption path (parse_tag_65_packet) already validates decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path omits this check. Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also protects the 512-byte encrypted_key[] buffer, so the former 512-byte check is removed as redundant. [tyhicks: Adjust the code comment to refer to macros representing the buffer sizes rather than mentioning the buffer size values since they may change in the future]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89608", "url": "https://ubuntu.com/security/CVE-2026-89608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: pass packet set buffer size to parser ecryptfs_parse_packet_set() receives a pointer into the file header, but it calculates the remaining packet buffer size from PAGE_SIZE - 8. For version 1 headers the packet set starts later in the header, so this can overstate the available buffer. Pass the actual packet set buffer length from the caller and calculate per-packet limits from the remaining bytes in that buffer. Recompute the remaining length after consuming a tag 3 packet before parsing the following tag 11 packet.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89609", "url": "https://ubuntu.com/security/CVE-2026-89609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: hold msg ctx list lock when cleaning daemon queue ecryptfs_exorcise_daemon() drops queued messages from a dying daemon without holding ecryptfs_msg_ctx_lists_mux, but ecryptfs_msg_ctx_alloc_to_free() requires that lock. Take the list lock while moving the queued contexts back to the free list to avoid racing with other global msg ctx list users.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89615", "url": "https://ubuntu.com/security/CVE-2026-89615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound page_lcns[] index by the log record The copy_lcns loop and the redo shorten loop index page_lcns[] at j + i, where i runs up to the log record's lcns_follow. That count is checked only against the record's own length, not the target entry, so check_dp_table() (which validates the entry's lcns_follow) does not cover it: the copy_lcns entry may even be freshly allocated after that check, and find_dp() bounds j but not i. A crafted record thus overflows page_lcns[] of an otherwise valid entry. Add dp_range_ok() and reject, before each loop, any record whose run does not fit the entry. These are the only two page_lcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded. [almaz.alexandrovich@paragon-software.com: original patch contained changes to the problem already handled, applied partly]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89616", "url": "https://ubuntu.com/security/CVE-2026-89616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame() ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target pages and then trusts decompress_lznt()'s return value: unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem, frame_size); if ((ssize_t)unc_size < 0) err = unc_size; else if (!unc_size || unc_size > frame_size) err = -EINVAL; decompress_lznt() stops as soon as the compressed stream is exhausted (e.g. a zero chunk header) and returns the number of bytes it actually wrote, which may be far less than frame_size. The bytes between unc_size and frame_size are never written. The only memset() that follows zeroes the region beyond i_valid; when the frame lies entirely within the file's valid size that memset() does not run, so the gap retains whatever was in the just-vmapped pages. All pages are then marked uptodate and returned to userspace, disclosing uninitialized (recently-freed) kernel page memory. A crafted compressed file whose stream decompresses to only a few bytes leaks the remainder of every frame on a plain read(2), which is enough to recover kernel pointers and defeat KASLR. Zero the [unc_size, frame_size) tail immediately after a successful LZNT decompress so the remainder reads back as zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89617", "url": "https://ubuntu.com/security/CVE-2026-89617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate dirty page table on log replay Each DIR_PAGE_ENTRY ends in a page_lcns[] array whose length is the on-disk lcns_follow field. check_rstbl() validates the table bookkeeping but never checks that this array fits in the entry, so a crafted lcns_follow lets the v0->v1 conversion memmove and later replay passes run off the entry. Add check_dp_table() to reject, right after check_rstbl(), any entry larger than its size claims via struct_size() (the same expression used to allocate these entries, so the check is overflow-safe by construction). All consumers can then trust lcns_follow as the real capacity. This covers every page_lcns[] access whose index is bounded by the entry itself (the conversion memmove, the HotFix store via find_dp(), and the self-bounded scan loops). Accesses whose index comes from the log record need a separate bound and are handled in a follow-up patch.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89621", "url": "https://ubuntu.com/security/CVE-2026-89621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: mcp2221: validate report size in mcp2221_raw_event() mcp2221_raw_event() never validates the size of incoming HID reports. In the MCP2221_I2C_GET_DATA path it trusts the device-supplied data[3] as the copy length without checking that 4 + data[3] bytes actually exist in the received report. A malicious or misbehaving USB device can send a short report with a large data[3], causing the memcpy to read past the valid report data in the HID transfer buffer and leak uninitialized kernel memory back to userspace through the I2C/SMBus read path. Add a minimum size check at entry and validate that the source range fits within the received report before the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89626", "url": "https://ubuntu.com/security/CVE-2026-89626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix field sysfs group cleanup on failure hid_sensor_custom_add_attributes() creates one sysfs group for each custom sensor field. If sysfs_create_group() fails after some groups have already been created, the function returns the error without removing the previously created groups. Add a local unwind path to remove the groups that were already created. With enable_sensor exposed only after the field attributes are ready, this path can free sensor_inst->fields without leaving enable_sensor able to access pointers into that array.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89627", "url": "https://ubuntu.com/security/CVE-2026-89627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: free buffered reports when destroying device roccat_report_event() duplicates each report with kmemdup() and stores the allocation in a circular-buffer slot. The allocation is released only when that slot is reused. The device destruction paths free struct roccat_device without releasing reports still stored in cbuf[]. This makes those allocations unreachable and leaks up to ROCCAT_CBUF_SIZE report buffers per device. Add a small destructor that frees every buffered report before freeing the device, and use it in both paths that can destroy a registered device.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89628", "url": "https://ubuntu.com/security/CVE-2026-89628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: picolcd: clamp eeprom debugfs read to bytes actually received picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte supplied by the device in its REPORT_EE_DATA reply -- clamped only to the caller's read() count: \tret = resp->raw_data[2]; \tif (ret > s) \t\tret = s; \tif (copy_to_user(u, resp->raw_data+3, ret)) It never checks resp->raw_size, the number of bytes picolcd_raw_event() actually copied into the 64-byte raw_data[] of the kmalloc'd struct picolcd_pending. A device (or a spoofed picoLCD) returning a length byte of 0xff, read with a count >= 255, makes copy_to_user() read past raw_data[] into adjacent slab memory and return it to userspace through the debugfs \"eeprom\" file: \tBUG: KASAN: slab-out-of-bounds in _copy_to_user \tRead of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd] The debug-dump path in the same file already validates the device length byte against the received size before trusting it; this read does not. The file is created S_IRUSR (root-only) and a crafted device is needed, so it is neither unprivileged- nor remotely-triggerable. Clamp the copy length to resp->raw_size - 3 (the payload actually received, minus the 3-byte header), floored at 0 for short replies.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89643", "url": "https://ubuntu.com/security/CVE-2026-89643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: avoid dropping live tree ref on fsnotify rule autoremove audit_del_rule() is used for both netlink deletion templates and internal fsnotify autoremove. The former passes a parsed template which owns a temporary tree reference; the latter passes the installed entry itself. The unconditional audit_put_tree() at the end of audit_del_rule() assumes the template case. For mixed AUDIT_DIR plus AUDIT_EXE rules, an fsnotify autoremove event therefore drops the installed rule's live tree reference. Repeating this across rules sharing the same tree can free the tree while another rule still references it, and a later autoremove dereferences the freed pathname while comparing rules. Move the temporary-tree put to audit_rule_change(), the caller that owns deletion templates. Keep it in the AUDIT_DEL_RULE cleanup so both successful deletion and -ENOENT still release the parser-owned tree. [PM: dropped unnecessary comment for line length reasons]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89649", "url": "https://ubuntu.com/security/CVE-2026-89649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound xattr value length in __build_xattrs() __build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare \"p += len\" and no ceph_decode_need() check that \"len\" bytes remain in the blob. For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob. The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space. Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89650", "url": "https://ubuntu.com/security/CVE-2026-89650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound num_export_targets array for mds info v2/v3 ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from each per-mds info record and advances the decode cursor by num_export_targets * sizeof(u32) without first checking that many bytes remain. The only upper-bound check that catches a runaway cursor (*p > info_end) is gated on info_v >= 4, because info_end is left NULL for info_v 2 and 3. When the monitor sends an MDS map whose per-mds info version is 2 or 3 with an oversized num_export_targets, the cursor moves past the message front buffer and the later export-targets loop calls the unchecked ceph_decode_32() on out-of-bounds memory. A kernel client processes CEPH_MSG_MDS_MAP from its monitor session (net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an on-path attacker on an unsigned/unencrypted messenger session, can therefore drive an out-of-bounds read in the client kernel; on x86_64 with KASAN it is reported as a slab-out-of-bounds read in ceph_mdsmap_decode(). The decoded values land in the internal info->export_targets[] array, so the consequence is a kernel out-of-bounds read, not an information leak to the attacker. Impact: a malicious or compromised Ceph monitor sending an MDS map with a per-mds info version of 2 or 3 and an oversized num_export_targets field triggers an out-of-bounds read in the CephFS client kernel. Add a ceph_decode_need() for the export-targets array before advancing the cursor, so the bound is enforced for every info_v >= 2, not only info_v >= 4. This mirrors the count-then-need idiom already used for m_data_pg_pools later in the same function. Compute the export-targets byte count with size_mul() and reuse that checked length when advancing the cursor, so the attacker-controlled num_export_targets multiplication fails closed on overflow rather than relying on the later kcalloc() guard.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89653", "url": "https://ubuntu.com/security/CVE-2026-89653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode MDSMap export_targets entries are monitor controlled. check_new_map() uses each entry as a bit number in a fixed stack bitmap, so a rank outside the protocol namespace can make set_bit() write past the end of the array. Reject ranks outside CEPH_MAX_MDS while decoding the map. Do not validate against possible_max_rank here because maps may legitimately reference ranks beyond a temporarily reduced max_mds.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89655", "url": "https://ubuntu.com/security/CVE-2026-89655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock list_for_each_entry() iterates ci->i_cap_flush_list but drops i_ceph_lock to send cap messages. During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid <= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock. When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next on freed memory. The race timeline: __kick_flushing_caps() handle_cap_flush_ack() ----------------------- ----------------------- holds i_ceph_lock <--- iterates to cf (tid=10) prepares FLUSH message drops i_ceph_lock <--- __send_cap() ── FLUSH(tid=10) \t MDS sends FLUSH_ACK(tid=10) ---> acquires i_ceph_lock cf->tid(10) <= flush_tid(10), detaches cf from i_cap_flush_list drops i_ceph_lock ceph_free_cap_flush(cf) <- frees it! acquires i_ceph_lock <--- for-loop advances: cf = list_next_entry(cf, i_list) -- UAF on freed cf->i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS may respond with FLUSH_ACK quickly enough that handle_cap_flush_ack() frees cf before __kick_flushing_caps can finish the iteration. Fix by converting to a manual while loop: save the next pointer under i_ceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89656", "url": "https://ubuntu.com/security/CVE-2026-89656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject buckets with mismatched CRUSH ids crush_decode() stores bucket data by array slot, and the mapper later derives the per-bucket workspace index from the decoded bucket id. A malformed map can therefore make one bucket reuse another bucket's workspace by encoding an id different from -1 - slot. For uniform buckets, the second replica selection expands the source bucket's permutation into that aliased workspace buffer. If the source bucket is larger than the aliased bucket, the write runs past the smaller permutation array and can escape the kvmalloc'd CRUSH workspace. KASAN reports a slab OOB write of 4 bytes in bucket_perm_choose(). Reject buckets whose encoded id does not match their array slot. Valid CRUSH maps already use the canonical negative id corresponding to the bucket slot, so this restores the invariant expected by work->work[-1 - in->id] without changing valid map behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89662", "url": "https://ubuntu.com/security/CVE-2026-89662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent lock owner use-after-free during client teardown __destroy_client() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on cl_ownerstr_hashtbl. client_has_state() does not count a bare owner, so DESTROY_CLIENTID can reach __destroy_client() with such owners present. __destroy_client() then walks the table, calling remove_blocked_locks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flc_owner. The per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently of client state. The two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks(). nfsd4_release_lockowner() holds a reference across the same call; __destroy_client() does not. Hold cl_lock across the walk, taking a reference and unhashing each owner, then drop it before remove_blocked_locks() and nfs4_put_stateowner(), which take blocked_locks_lock and cl_lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89663", "url": "https://ubuntu.com/security/CVE-2026-89663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: revoke copy-notify stateids before dropping their reference Copy-notify stateids live in the s2s_cp_stateids IDR and on their parent stid's sc_cp_list, pinned by a single membership reference. _free_cpntf_state_locked() only unlinks an entry once its refcount reaches zero, so any revoke path that runs while a concurrent find_cpntf_state()/manage_cpntf_state() holder has elevated cs_count drops the reference without unlinking, leaving the entry discoverable with its membership reference already consumed. A second revoke or a laundromat tick then frees it while the reader still holds the pointer -- a KASAN-detectable use-after-free at the reader's nfs4_put_cpntf_state(). This affected all three revoke paths: - The parent-stid drain (nfs4_free_cpntf_statelist()) repeatedly called _free_cpntf_state_locked() on the first list entry; a holder that had bumped cs_count made it return early, so the next iteration re-decremented and burned the holder's reference. - OFFLOAD_CANCEL (manage_cpntf_state()) and laundromat expiry likewise used _free_cpntf_state_locked() and could drop 2->1 without unlinking. Add revoke_cpntf_state_locked(), which unhashes the entry from the IDR and sc_cp_list first (deferring the final free to any holder), and use it from all three revoke paths. The drain now walks with list_for_each_entry_safe() and revokes each entry unconditionally, so it terminates in one pass per entry regardless of cs_count. The unhash is gated on !list_empty(&cps->cp_list); the idr_remove() gate matters because idr_alloc_cyclic() may have recycled the so_id by then. Keep _free_cpntf_state_locked() for the reference-holder put path only, where a concurrent revoke may already have unlinked the entry (its list_del_init() then a no-op).", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89665", "url": "https://ubuntu.com/security/CVE-2026-89665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE The NFSv2 sattr decoder converts the wire useconds to nanoseconds in svcxdr_decode_sattr(): \tiap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC; tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds value such as 4294968 wraps to tv_nsec == 704. The corruption therefore happens during decode, before any proc function can inspect the value, and a later range check on tv_nsec would see an in-range result and accept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply. NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return for a malformed time argument, and the check cannot move to the proc function the way the v3/v4 nsec range checks do. Guard the raw useconds before the multiplication and reject values greater than 1000000. useconds == 1000000 is kept: it is the Sun convention for \"set to the current server time\", and the in-tree Linux NFSv2 client emits it in both the atime and the mtime field for a plain touch / utimes(file, NULL) (see encode_sattr() and xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000 would turn that common operation into a hard decode failure for both SETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap on ILP32, so the Sun convention value passes through safely. Only genuinely out-of-range values (> 1000000) are rejected. The atime and mtime guards are therefore symmetric. The decoder only applied the Sun convention in the mtime block, which clears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a client puts 1000000 in the atime field but not in the mtime field, the atime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET set, so the bogus value reached the filesystem. Apply the convention in the atime block as well, clearing ATTR_ATIME_SET so the server uses its current time and ignores the value. Only ATTR_ATIME_SET is cleared there. The mtime block keeps its existing behavior, where 1000000 means \"set both atime and mtime to now\". [ cel: various tweaks, addenda, and clean-ups ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89669", "url": "https://ubuntu.com/security/CVE-2026-89669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: initialize copy-notify stateid before publishing it nfsd4_copy_notify() finished initializing the cpntf state after nfs4_alloc_init_cpntf_state() had already linked it into the s2s_cp_stateids IDR and the parent's sc_cp_list, with cs_count == 1 (the membership reference) and none held for the caller. A racing OFFLOAD_CANCEL (crafted cl_id == nn->s2s_cp_cl_id plus the guessable so_id) could reach manage_cpntf_state() and free the entry, turning the caller's subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid writes into use-after-free. The owning clientid was also only recorded after publication, so it could not gate an ownership check in that window. Record cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state() before nfs4_init_cp_state() publishes the entry, and return it with an extra reference. The caller reads the stateid under that reference and drops it with nfs4_put_cpntf_state(); on a late error the laundromat reaps the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89673", "url": "https://ubuntu.com/security/CVE-2026-89673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo nfsd4_ff_encode_getdeviceinfo() computes the da_addr_body reservation as 16 + netid_len + addr_len, but the subsequent xdr_encode_opaque() calls emit 8 + round_up(netid_len, 4) + round_up(addr_len, 4) bytes. The mismatch means the declared da_addr_body length exceeds the actual encoded data by 2-8 bytes on every flexfile GETDEVICEINFO reply, leaking stale reply-page content to the client and mis-aligning the subsequent version list decode. Use xdr_align_size() for each string length to match what xdr_encode_opaque() actually writes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89674", "url": "https://ubuntu.com/security/CVE-2026-89674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client: - fh_len doesn't account for XDR padding on the file handle data - uid and gid lengths use \"8 + len\" but xdr_encode_opaque() actually writes \"4 + xdr_align_size(len)\" bytes - ds_len omits the flags and stats_collect_hint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client. Fix this by breaking out every encoded field explicitly in the ds_len calculation, using xdr_align_size() for all variable-length opaque fields, and correcting the header constants.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89684", "url": "https://ubuntu.com/security/CVE-2026-89684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix cpntf publish race in nfs4_init_cp_state nfs4_alloc_init_cpntf_state() published the new cpntf entry into the s2s_cp_stateids IDR (with cs_type set) in one s2s_cp_lock section, then took the lock again to list_add() it onto p_stid->sc_cp_list. In the gap the entry is reachable by so_id but cp_list is still {NULL,NULL} from kzalloc. A racing OFFLOAD_CANCEL (so_id is echoed to the client as cnr_stateid, so any NFSv4.2 client can drive it) reaches manage_cpntf_state() -> _free_cpntf_state_locked() and does list_del() on the zeroed list_head, oopsing the server. Fold the cs_type assignment and the list_add() into the same critical section as idr_alloc_cyclic(), so a concurrent lookup either misses the entry or sees a fully linked cp_list. INIT_LIST_HEAD() the entry after allocation and switch _free_cpntf_state_locked() to list_del_init() so a stale unlink is a no-op. nfs4_init_copy_state() passes NULL p_stid and skips the list_add, preserving NFS4_COPY_STID semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89694", "url": "https://ubuntu.com/security/CVE-2026-89694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: check client ownership when cancelling a copy-notify stateid On the OFFLOAD_CANCEL path (clp != NULL), manage_cpntf_state() freed the target cpntf state without checking ownership. The lookup key st->si_opaque.so_id is allocated cyclically (guessable) and the embedded clientid is the fixed per-net nn->s2s_cp_cl_id, so any authenticated NFSv4.2 client could cancel and free another client's copy-notify stateid. Compare the creating clientid recorded in state->cp_p_clid against the requesting client's cl_clientid and return nfserr_bad_stateid on a mismatch instead of freeing the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89696", "url": "https://ubuntu.com/security/CVE-2026-89696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref When CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return success with fh_dentry and fh_export both NULL if fh_verify() returns nfserr_stale and putfh->no_verify is true. The NFSD4_FH_FOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserr_nofilehandle check -- it does not prevent subsequent ops from running with a NULL fh_dentry. A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes check_if_stalefh_allowed() to set no_verify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fh_want_write() which dereferences fh_export->ex_path.mnt without calling fh_verify() first, causing a NULL pointer dereference in the nfsd kthread. Fix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set and fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow) and ops with ALLOWED_WITHOUT_FH (which don't need a resolved filehandle) may proceed. All other ops receive nfserr_stale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERR_STALE returned at that point.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89697", "url": "https://ubuntu.com/security/CVE-2026-89697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: add fh_want_write() for early-verified SETATTR in nfsd_proc_setattr() The BOTH_TIME_SET branch calls fh_verify() early so setattr_prepare() can inspect the dentry. This causes nfsd_setattr() to skip fh_want_write(), so notify_change() runs without a mount write reference. Add the missing fh_want_write() call after the early fh_verify().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89699", "url": "https://ubuntu.com/security/CVE-2026-89699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: validate symlink target length in NFSv4 CREATE nfsd4_decode_create() accepts an unbounded cr_datalen from the wire for NF4LNK symlink targets, allowing a client to force a kmalloc of up to the maximum RPC payload size (several MiB) per COMPOUND op that persists until compound teardown. The VFS rejects oversized targets with ENAMETOOLONG, but the allocation has already occurred. Reject cr_datalen == 0 early with nfserr_inval and cr_datalen greater than NFS4_MAXPATHLEN (PATH_MAX) with nfserr_nametoolong to bound the allocation.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89704", "url": "https://ubuntu.com/security/CVE-2026-89704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: sample writeback error cursor before async COPY loop _nfsd_copy_file_range() samples dst->f_wb_err into \"since\" after the copy loop, then uses it to detect writeback errors via filemap_check_wb_err() once vfs_fsync_range() returns. Because the nfsd_file cache reuses a single struct file across requests targeting the same inode, a concurrent COMMIT or stable WRITE on dst advances dst->f_wb_err to the current mapping->wb_err via file_check_and_advance_wb_err() during its own vfs_fsync_range(). If that advancement lands between the writeback error appearing in mapping->wb_err and the COPY worker sampling \"since\", the worker captures the already-advanced cursor, errseq_check() sees cur == since and returns zero, and NFSD4_COPY_F_COMMITTED is set even though writeback failed. CB_OFFLOAD then encodes wr_stable_how = FILE_SYNC4, the client treats the copied data as durable, and the failure becomes silent data loss. Sample since once at the start of the function. The cursor then reflects state in effect before this COPY issues any writes, and filemap_check_wb_err() detects any error that occurs during the copy regardless of which thread first observes it. This matches the pattern used by nfsd_vfs_write() and nfsd4_clone_file_range().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89706", "url": "https://ubuntu.com/security/CVE-2026-89706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: Reset write verifier when async COPY writeback fails Async COPY captures nn->writeverf at request time and reports it to the client via CB_OFFLOAD after the worker kthread completes. When the post-copy vfs_fsync_range() or filemap_check_wb_err() in _nfsd_copy_file_range() reports an error, the worker correctly leaves NFSD4_COPY_F_COMMITTED clear so that CB_OFFLOAD encodes wr_stable_how as NFS_UNSTABLE, but the server's write verifier is not rotated. A client that receives NFS_UNSTABLE in CB_OFFLOAD follows up with COMMIT to make the copied data durable. With the verifier unchanged, COMMIT returns the same value the client just received via CB_OFFLOAD, and the client concludes the copy is durable -- silently dropping the data whose writeback in fact failed. This violates the UNSTABLE+COMMIT durability contract (RFC 7862 section 15.1, RFC 8881 section 18.32) and matches the bug just fixed in nfsd_vfs_write() and nfsd_commit(). Rotate nn->writeverf at the writeback-failure site. The async COPY worker has no svc_rqst, so commit_reset_write_verifier() is not available here; calling nfsd_reset_write_verifier() directly mirrors the trace-less reset already used by nfsd_file_check_write_error() for the same purpose. Filter out -EAGAIN and -ESTALE, matching commit_reset_write_verifier(), since neither indicates a durable-storage failure.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89710", "url": "https://ubuntu.com/security/CVE-2026-89710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget path When the server returns a new layout stateid while a valid one is still held, pnfs_layout_process() calls pnfs_mark_matching_lsegs_return() on the on-stack free_me list and jumps to out_forget. Segments whose reference count drops to zero are unlinked from lo->plh_segs and moved to free_me by mark_lseg_invalid(); for an idle cached segment the layout header holds the only reference, so this happens on the first decrement. out_forget never drains free_me -- only the success path calls pnfs_free_lseg_list(). Commit 814b84971388 (\"pNFS/NFSv4: Fix a layout segment leak in pnfs_layout_process()\") added the drain; commit 08bd8dbe8882 (\"pNFS/NFSv4: Try to return invalid layout in pnfs_layout_process()\") removed it while switching the destination to lo->plh_return_segs, which is drained elsewhere. Commit fb700ef02676 (\"NFSv4.1: Simplify layout return in pnfs_layout_process()\") switched the destination back to free_me without restoring the drain. Restore the pnfs_free_lseg_list() call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89711", "url": "https://ubuntu.com/security/CVE-2026-89711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check The header for commit e75b23f9e323 (\"nfsd: check d_can_lookup in fh_verify of directories\") details the assumption that justified adding the WARN_ON_ONCE to nfsd_mode_check(), that assumption is invalid (in the case of NFS reexport). When NFSD exports an NFS filesystem it is very possible for nfsd_mode_check() to encounter a @dentry that doesn't have i_op->lookup (see nfs_fhget()'s NFS_ATTR_FATTR_MOUNTPOINT and NFS_ATTR_FATTR_V4_REFERRAL handling, and d_flags_for_inode()). So remove nfsd_mode_check()'s WARN_ON_ONCE(). The nfserr_notdir return on that branch must stay. It guards the subsequent lookup_one_unlocked() -> __lookup_slow() path, which calls inode->i_op->lookup() with no NULL check, so returning nfserr_notdir is what keeps a client LOOKUP into such a @dentry from dereferencing a NULL method pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89712", "url": "https://ubuntu.com/security/CVE-2026-89712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock nfsd4_ssc_expire_umount() walks nn->nfsd_ssc_mount_list with list_for_each_entry_safe(ni, tmp, ...). For each expired entry it sets nsui_busy = true, drops nfsd_ssc_lock to run mntput() on the source vfsmount, then reacquires the lock to list_del + kfree the entry and continue iterating via the macro's saved tmp pointer. The nsui_busy flag protects the current ni from concurrent nfsd4_ssc_setup_dul() finders during the lock-drop window, but it does not pin tmp. Another nfsd RPC thread that fails its source- server mount and reaches nfsd4_ssc_cancel_dul() will, during that same window, take nfsd_ssc_lock, list_del + kfree its own ssc_umount item, and release the lock. If that item is the saved tmp of the expire walk, the next iteration dereferences a freed nfsd4_ssc_umount_item. Restart the walk from the head after the mntput() unlock window so no saved next pointer survives the lock-drop. The list is bounded by the number of active inter-server source mounts (typically small) and the expire delayed-work runs periodically rather than per-IO, so the restart is cheap.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89720", "url": "https://ubuntu.com/security/CVE-2026-89720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: fix out-of-bounds read in signature length check ubifs_sb_verify_signature() bounds the on-disk ubifs_sig_node->len field before handing the signature payload to verify_pkcs7_signature(), but the check has the wrong sign: \tif (le32_to_cpu(signode->len) > snod->len + sizeof(struct ubifs_sig_node)) The signature bytes start sizeof(struct ubifs_sig_node) (UBIFS_SIG_NODE_SZ, 64 bytes) into the node, so the payload is at most \tsnod->len - sizeof(struct ubifs_sig_node) bytes long. Adding the header size instead of subtracting it accepts a declared length up to 2 * UBIFS_SIG_NODE_SZ larger than the node actually holds -- past the end of c->sbuf, which is vmalloc(c->leb_size). verify_pkcs7_signature() -> pkcs7_parse_message() -> asn1_ber_decoder() is then handed that inflated length and reads beyond the allocation while walking the DER headers. The node length comes straight from the mounted image, so a crafted signed UBIFS image reaches this via ubifs_read_superblock() before the signature is cryptographically checked. snod->len is guaranteed to be >= UBIFS_SIG_NODE_SZ by the node scanner (c->ranges[UBIFS_SIG_NODE].min_len == UBIFS_SIG_NODE_SZ), so the corrected subtraction cannot underflow. Legitimately signed images are unaffected: a correct superblock never declares a signature longer than the node it is embedded in.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93213", "url": "https://ubuntu.com/security/CVE-2026-93213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: of: fix out-of-bounds read in of_alias_scan() stem parser The stem parser tests isdigit(*(end - 1)) before checking end > start and so reads one byte before the property name when the name is empty or all digits. Check the bound first.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89723", "url": "https://ubuntu.com/security/CVE-2026-89723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after truncation Shuangpeng Bai reported that KASAN detected a slab-out-of-bounds error in nilfs_direct_propagate() during testing. Analysis revealed that after truncating a file, a node block immediately below the B-tree root was not deleted. Instead, it remained in the B-tree node cache in a dirty state. The log writer subsequently detected this block and incorrectly invoked nilfs_direct_propagate() on it, which is designed to handle only data blocks in direct mapping. B-tree nodes in the cache are managed by virtual block numbers, and their logical keys typically exceed the range expected by direct mapping. Consequently, processing such a node as a direct mapping entry triggers a slab-out-of-bounds access. The root cause is that when a B-tree mapping collapses into a direct mapping during truncation, an intermediate node block pointed to by the root node is left behind as garbage instead of being explicitly deleted. This resolves the issue by adding a nilfs_btree_discard() operation to delete the remaining intermediate node block during the conversion. A 'deform' flag is added to the bop_delete interface to explicitly signal that the deletion is part of a mapping transformation. This allows the B-tree mapping implementation to perform the necessary cleanup and discarding of the residual node structure that would be otherwise be left orphaned after the transition.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89724", "url": "https://ubuntu.com/security/CVE-2026-89724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vicodec: fix out-of-bounds write in FWHT encoder vidioc_s_fmt_vid_out() sizes the encoder CAPTURE buffer from the compressed descriptor pixfmt_fwht, whose sizeimage_mult is 3: coded_w * coded_h * 3 + sizeof(struct fwht_cframe_hdr). fwht_encode_frame() encodes one plane per component, and an incompressible plane takes the FWHT_FRAME_UNENCODED path in encode_plane(), copying the plane verbatim. For a 4-component pixel format all four planes are full resolution (width_div == height_div == 1), so a frame that forces every plane through the unencoded fallback writes sizeof(struct fwht_cframe_hdr) + 4 * coded_w * coded_h bytes, overrunning the plane by coded_w * coded_h, which can result in corruption of adjacent kernel heap memory. Bump pixfmt_fwht.sizeimage_mult from 3 to 4, matching the largest components_num among the supported raw formats, so the capture buffer is always large enough for the unencoded fallback.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89725", "url": "https://ubuntu.com/security/CVE-2026-89725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: stm32: prevent out-of-bounds write on RX overflow stm32_rx_done() appends each received CEC byte to rx_msg.msg[] using rx_msg.len as the write index, incrementing it on every RXBR (receive-byte-ready) interrupt without checking it against the buffer size: \tcec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF; rx_msg.msg[] is a fixed CEC_MAX_MSG_SIZE (16) byte array in struct cec_msg, and rx_msg.len is only reset on RXACKE/RXOVR or after a completed message (RXEND). The number of bytes received before RXEND is decided by the remote CEC device (it sets EOM), not by the driver. A peer that keeps sending bytes without ending the message drives RXBR repeatedly, pushing rx_msg.len past 16 and writing peer-controlled bytes out of bounds into the surrounding memory. This is reachable in normal operation once the driver has probed and receiving is enabled, from the IRQ thread, without any local privilege. The length check in the CEC core runs on the consumer side, after the byte has been stored, so it does not prevent the overflow. Bound the index in the driver before the store, as the other platform CEC drivers already do (e.g. tegra_cec), dropping the excess bytes of an overlong frame. Found by static analysis tool CodeQL.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89726", "url": "https://ubuntu.com/security/CVE-2026-89726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen() Patch series \"lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()\", v2. This series fixes an off-by-one out-of-bounds read in ucs2_strnlen(). The first patch is the real fix, the second patch comes as a bonus and fixes the code indentation. This patch (of 2): ucs2_strnlen() checks the current character before checking whether the caller-provided maximum length has been reached. If the input is not NUL-terminated within that bound, the loop can read one ucs2_char_t past the limit. Test the length before dereferencing to prevent an off-by-one out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89729", "url": "https://ubuntu.com/security/CVE-2026-89729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature sensor_hub_get_feature() clamps its return value to the caller's buffer size, but the copy loop still copies field->report_size / 8 bytes for each report value. A malicious HID descriptor can advertise a large feature field size while an IIO caller supplies a small stack buffer, such as a single s32, causing an out-of-bounds write. HID core stores parsed report values in __s32 slots and clamps extracted values to 32 bits. Reject feature fields that require more than one slot per value, guard the total byte count calculation, and clamp each per-value copy to the remaining caller buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89730", "url": "https://ubuntu.com/security/CVE-2026-89730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write The trailing byte path in altera_cvp_send_block() dereferences a u32 pointer even when only 1-3 bytes remain in the input buffer. If the buffer ends at a page or scatterlist boundary, this can read past the valid image data and fault. Copy the remaining bytes into a zero-initialized u32 before writing the final word so only valid bytes are read from the input buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89732", "url": "https://ubuntu.com/security/CVE-2026-89732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Prevent deadlock during ep0 read loop Currently, ffs_ep0_read() holds ffs->mutex when it prepares to go to sleep waiting for an event. When no setup events are pending, it calls wait_event_interruptible_exclusive_locked_irq() with the mutex still held. The wait macro deliberately drops the waitqueue spinlock before sleeping but does not drop the mutex. If a userspace daemon is polling ep0 via read() and the gadget is asynchronously torn down via configfs (e.g., echo \"\" > UDC), a deadlock can occur: 1. The configfs teardown calls functionfs_unbind(), which queues a FUNCTIONFS_UNBIND event. 2. The daemon wakes up, consumes the event, and drops the mutex. 3. However, if the daemon loops and immediately issues another read() before exiting, it reacquires ffs->mutex and again goes into an interruptible sleep. 4. Meanwhile, functionfs_unbind() continues execution and attempts to acquire ffs->mutex to tear down ep0req. 5. The kernel deadlocks because the configfs thread is stuck in an uninterruptible sleep waiting for the mutex, while the userspace daemon is in an interruptible sleep holding the mutex forever because no more events will arrive. To fix this, we drop both the waitqueue spinlock and ffs->mutex before going to sleep, and use wait_event_interruptible_exclusive() instead. Upon waking up, we jump back to the `retry` label to safely reacquire the mutex and re-evaluate the state machine. By not sleeping with ffs->mutex held, we natively decouple gadget teardowns (which require the mutex) from userspace polling.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89733", "url": "https://ubuntu.com/security/CVE-2026-89733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and uvc_function_unbind() In uvc_function_bind() error path, we use usb_ep_free_request which uses uvc->control_req but does not set it to NULL afterwards. Thus, uvc->control_req is a dangling pointer causing a UAF. Also we do not set the uvc->control_buf pointer to NULL after freeing it, which is another dangling pointer. Fix it by setting uvc->control_req to NULL after we run usb_ep_free_request() and uvc->control_buf to NULL after kfree. Do the same for uvc_function_unbind().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93214", "url": "https://ubuntu.com/security/CVE-2026-93214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: fix deadlock in usbg_make_tpg() usbg_make_tpg() held dep_lock while calling configfs_depend_item_unlocked(), which acquires the configfs root inode lock when operating across subsystems. This creates a circular lock dependency with configfs_rmdir(): dep_lock -> configfs root inode lock -> su_mutex -> dep_lock In usbg_make_tpg(), dep_lock only serialized the read of opts->ready, which is a monotonic flag that transitions from false to true exactly once (in tcm_set_name()) and never reverts. Remove dep_lock from usbg_make_tpg() entirely and use READ_ONCE/WRITE_ONCE to access opts->ready locklessly instead.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89736", "url": "https://ubuntu.com/security/CVE-2026-89736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: Fix use-after-free on sound card disconnect g_audio_cleanup() invokes snd_card_free_when_closed() to initiate sound card teardown and immediately frees the underlying struct snd_uac_chip context. However, snd_card_free_when_closed() returns asynchronously while ALSA control elements (kctls) remain open in userspace. When userspace control applications access or close these open file descriptors, kctl callbacks attempt to dereference kctl->private_data pointing to &uac->c_prm or &uac->p_prm within the freed uac structure, resulting in a use-after-free (UAF) memory corruption. Fix this issue by deferring the destruction of struct snd_uac_chip until all references to the ALSA sound card are released. Register a custom card->private_free callback (u_audio_card_free) during g_audio_setup() that frees uac and its associated playback/capture request and ring buffers only when the sound card reference count drops to zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89741", "url": "https://ubuntu.com/security/CVE-2026-89741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"media: v4l2-dev: fix error handling in __video_register_device()\" This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a. The intentions of that patch were good, but it doesn't work. The idea is that if device_register fails, you have to do a put_device to let the ref counter release resources. However, the V4L2 API says that if video_register_device() fails, then you have to call video_device_release(), which kfree()s the video_device struct. But the put_device() will already have freed the struct, so you end up in a double-free scenario. There is not really a good way of fixing this without breaking video_register_device() into two parts, one that initializes everything, and one that does the actual device_register, and then converting all V4L2 drivers to this new model. That is a massive job, and it is very unlikely that device_register will fail. So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89742", "url": "https://ubuntu.com/security/CVE-2026-89742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: mport_cdev: fix use-after-free in dma_req_free() dma_req_free() acquires buf_mutex through req->map, drops the mapping reference with kref_put(), and then dereferences req->map again to unlock the mutex. If kref_put() drops the last reference, mport_release_mapping() frees the mapping, and the subsequent mutex_unlock() dereferences a freed object. This is a use-after-free. Fix this by caching map and md before kref_put(), clearing req->map while holding buf_mutex, and using the cached md for mutex unlocking. The bug is reachable from userspace via the RapidIO mport character device interface.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89749", "url": "https://ubuntu.com/security/CVE-2026-89749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix crash passing ERR_PTR to kthread_stop() event_test_stuff() calls kthread_run() and unconditionally passes the returned task_struct pointer to kthread_stop(). kthread_run() returns an error pointer such as ERR_PTR(-ENOMEM) when kthread creation fails, for example under memory pressure during the boot-time event self-test. kthread_stop() then dereferences the invalid pointer, crashing the kernel. Check the result of kthread_run() before passing it to kthread_stop(). Use WARN_ON() so that a failure to create the self-test thread does not go unnoticed, matching the ring-buffer self-test fix in commit 91542863abad (\"ring-buffer: Fix crash passing ERR_PTR to kthread_stop()\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89752", "url": "https://ubuntu.com/security/CVE-2026-89752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: memcg: stop reclaim when a limit update is superseded kernfs serializes file operations only per open file, so separate open files can update the same memory.high or memory.max file concurrently. Both handlers store the new limit before synchronous reclaim, but continue to use the writer's local target in the reclaim loop. If another writer raises or removes the limit, the first writer can continue reclaiming toward a stale target. For memory.max, this can leave the writer looping indefinitely once reclaim retries are exhausted. The OOM path sees sufficient margin under the current limit and returns true without killing, while the writer still compares usage against its stale target and records another OOM event. Check the current limit at the start of each reclaim iteration and stop if it no longer matches the writer's target. Reproducer: Populate a cgroup with anonymous memory and disable swapping. Lower memory.max from one open file, then restore it to \"max\" through another open file after the new limit becomes visible. Without the patch, the first writer remains blocked and repeatedly increments the OOM event counter. With the patch, it returns normally. This was not motivated by a reported production workload. We found it through automated randomized testing for our cgroup observability work and reduced it to the reproducer above.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89753", "url": "https://ubuntu.com/security/CVE-2026-89753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: \t0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 \ttask:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89765", "url": "https://ubuntu.com/security/CVE-2026-89765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers/itimer: Zero-init old itimerval before copy to userspace On native sparc64, struct __kernel_old_timeval contains a four-byte hole after tv_usec because tv_sec is 64-bit while __kernel_suseconds_t is 32-bit. put_itimerval() fills only the named fields in a stack-allocated __kernel_old_itimerval and copies the entire object to userspace, so getitimer() can expose the two padding holes. Zero-initialize the aggregate before assigning the fields so implicit padding is deterministic before it crosses the user/kernel boundary.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93219", "url": "https://ubuntu.com/security/CVE-2026-93219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/timer-sun4i: Advertise a real minimum delta sun4i_clkevt_next_event() compensates for the timer stop/start synchronization delay by programming evt - TIMER_SYNC_TICKS into the hardware interval register. The clockevent device currently advertises TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed to call set_next_event() with evt == TIMER_SYNC_TICKS. That programs a zero-tick interval. With oneshot/highres/nohz timer operation this can leave the next event stuck, which was observed as a boot hang on Allwinner D1 after the clockevents core started reusing forced minimum-delta events. Advertise one extra tick instead, so the smallest event accepted by the core still programs at least one hardware tick after the synchronization compensation.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-23191", "url": "https://ubuntu.com/security/CVE-2026-23191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix racy access at PCM trigger The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers. For addressing the UAF, this patch changes two things: - It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.", "cve_priority": "high", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-80824", "url": "https://ubuntu.com/security/CVE-2026-80824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbfs: fix use-after-free of usb_device in usbdev_release() usbdev_release() drops its reference to the struct usb_device before draining the list of completed async URBs, but that drain path reads back through the same object: free_async() calls dec_usb_memory_use_count() for any URB whose buffer came from the usbfs mmap() region, and its first statement is bus_to_hcd(ps->dev->bus). After a disconnect the usbfs reference can be the last one, in which case usb_put_dev() frees the device and the subsequent loop reads offset 80 of freed memory and uses the result as a struct usb_hcd *, which hcd_buffer_free_pages() then dereferences. This is reachable by an unprivileged process that has read/write access to a /dev/bus/usb node: mmap() the fd, submit one URB with a buffer inside the mapping, wait for the device to be unplugged, then munmap() and close(). It reproduces on every attempt rather than being a race, because a live MAP_SHARED vma holds a reference on the struct file, so usbdev_release() cannot run until the last vma is gone and the freeing branch of dec_usb_memory_use_count() is always taken. BUG: KASAN: slab-use-after-free in dec_usb_memory_use_count+0x3ae/0x410 Read of size 8 at addr ffff8880122ee050 by task poc/769 CPU: 1 UID: 1000 PID: 769 Comm: poc Tainted: G B 6.12.94 #3 Call Trace: dec_usb_memory_use_count+0x3ae/0x410 free_async+0x2aa/0x4f0 usbdev_release+0x375/0x460 __fput+0x3ea/0xb50 __x64_sys_close+0x86/0x100 Allocated by task 11: usb_alloc_dev+0x55/0xd90 hub_event+0x2524/0x43d0 Freed by task 769: kfree+0x121/0x360 device_release+0xd2/0x280 usb_put_dev+0x23/0x30 usbdev_release+0x2d8/0x460 Release the device reference after the drain loop instead. Nothing between the two points requires it to have been dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80826", "url": "https://ubuntu.com/security/CVE-2026-80826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: c67x00: fix use-after-free in c67x00_add_iso_urb() When TD creation fails for the last packet of an isochronous URB, c67x00_add_iso_urb() gives the URB back before updating the endpoint scheduling state. c67x00_giveback_urb() frees the URB private data, and the completion callback may release the final URB reference. The following accesses to urbp->ep_data, urb->interval, and urbp->cnt can therefore use freed memory. Update next_frame and cnt before giving back the failed final packet, making the giveback the last operation that uses the URB and its private data.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80827", "url": "https://ubuntu.com/security/CVE-2026-80827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: option: fix slab OOB read in interrupt URB callback The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. [ johan: use dev_err(); split signals declaration and initialisation ]", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80828", "url": "https://ubuntu.com/security/CVE-2026-80828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Complete cleanup after system-resume errors A failed system resume can leave the card unusable until reboot. usb_audio_resume() jumps to err_out when snd_usb_pcm_resume() or snd_usb_mixer_resume() fails. The error path skips the out: block, which restores D0 and decrements chip->num_suspended_intf. The card stays in SNDRV_CTL_POWER_D3hot, so later control access blocks in snd_power_ref_and_wait(). USB core logs an interface resume callback error. It does not retry that callback, so a later callback cannot complete the skipped cleanup. usb_audio_suspend() increments num_suspended_intf before returning success. A system-resume callback must consume the system-suspend count even if a component resume fails. Otherwise, the stranded count skews later suspend and resume cycles. Do not apply this cleanup to runtime-resume errors. Runtime PM can retry -EAGAIN or -EBUSY without another suspend callback. The count must continue to describe that suspended interface. Other runtime-resume errors latch runtime_error in the PM core and do not cause an immediate callback retry. Both parts of the system-resume error path are longstanding. Commit 88a8516a2128a (\"ALSA: usbaudio: implement USB autosuspend\") introduced err_out past the D0 restore. Commit 862b2509d157c (\"ALSA: usb-audio: Fix inconsistent card PM state after resume\") later moved num_suspended_intf-- into the out: block. The error path now skips both operations. No third-party code is needed to reach the error path. snd_usb_mixer_resume() ends in snd_usb_mixer_activate(), which returns the result of usb_submit_urb() for devices that have a mixer status URB. Its mixer->private_resume hook can also fail through scarlett2_init_notify(). snd_usb_pcm_resume() issues a SET_CUR request to a UAC3 power domain. It can return -EPIPE or -EIO when the device stalls the request. Route a component error through out: only when system_suspend is nonzero. Continue to return runtime-resume errors through err_out. Later component resume stages remain skipped. The original error still reaches USB core. A later transfer can fail if the device did not recover. I reproduced the system-resume failure on an Audient iD14 MkI with an out-of-tree diagnostic mixer resume hook. An injected -EIO on the unpatched core left control readers in uninterruptible sleep in snd_power_ref_and_wait() until a reboot. With this patch, the same failure restored control access. A second system suspend and resume also succeeded after I disabled fault injection.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80829", "url": "https://ubuntu.com/security/CVE-2026-80829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output() snd_usbmidi_novation_output() lays out a two-byte header at transfer_buffer[0..1] and passes &transfer_buffer[2] together with a length of ep->max_transfer - 2 to snd_rawmidi_transmit(): \tcount = snd_rawmidi_transmit(ep->ports[0].substream, \t\t\t\t &transfer_buffer[2], \t\t\t\t ep->max_transfer - 2); ep->max_transfer comes from the output endpoint's wMaxPacketSize via usb_maxpacket(). A malformed or malicious device can advertise a bulk OUT endpoint with a wMaxPacketSize of 1 - the USB core only clamps this value downwards - so ep->max_transfer becomes 1 and the count argument becomes -1. snd_rawmidi_transmit() passes the negative count on to __snd_rawmidi_transmit_peek(), where \"if (count1 > count) count1 = count\" leaves count1 negative; get_aligned_size() keeps it negative for a byte-stream substream, so the following memcpy(buffer, ..., count1) runs with a (size_t)-1 length and writes far past the transfer buffer, which was allocated with usb_alloc_coherent(ep->max_transfer). This is the same class of bug that was fixed for snd_usbmidi_akai_output() in commit 0970274613fb (\"ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()\"); the novation output routine was left unguarded. Bail out when the endpoint cannot hold the two-byte header plus at least one payload byte.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80830", "url": "https://ubuntu.com/security/CVE-2026-80830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: Add lock to usb_wakeup_notification() Add a spin lock to usb_wakeup notification to prevent a race condition with dereferencing freed memory. This could be hit by the xHCI driver as it calls this function from an IRQ and could race with the hub_disconnect() function, which properly grabs this lock to protect the state of the device.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80921", "url": "https://ubuntu.com/security/CVE-2026-80921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: zero stale crypto bits When shadowing crypto access bits from a format0 apcb (crycb 0 or 1), the bits 64..255 are unchanged from whatever is in the vsie page in the crycb and thus in the apcb. This gives a nested guest potential access to a device no longer available. Zero out the remaining bits.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80831", "url": "https://ubuntu.com/security/CVE-2026-80831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: mxs-dcp - fix source scatterlist length access mxs_dcp_aes_block_crypt() uses sg_dma_len() without mapping the source scatterlist with dma_map_sg() first. Therefore, sg_dma_len() is invalid and could return zero or a stale DMA length, causing encryption and decryption to process the wrong number of bytes when CONFIG_NEED_SG_DMA_LENGTH=y. Use the original scatterlist length instead.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80832", "url": "https://ubuntu.com/security/CVE-2026-80832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qce - fix CCM AAD buffer underallocation The AAD buffer allocated in qce_aead_ccm_prepare_buf_assoclen() can be smaller than the length later programmed into the DMA scatterlist. The allocation size is currently calculated as: ALIGN(assoclen, 16) + MAX_CCM_ADATA_HEADER_LEN while the DMA length is set to: ALIGN(assoclen + adata_header_len, 16) Since ALIGN() does not distribute over addition, the allocation can be smaller than the DMA length. For example, when assoclen = 32 and adata_header_len = 2: allocation = ALIGN(32, 16) + 6 = 38 DMA length = ALIGN(32 + 2, 16) = 48 As a result, the QCE hardware can read beyond the allocated buffer while computing the CBC-MAC over the associated data. The extra bytes are folded into the authentication tag, resulting in an incorrect tag and causing CCM self-test failures such as: alg: aead: ccm-aes-qce encryption test failed (wrong result) on test vector 8 Fix the allocation by adding the maximum possible AAD header length before alignment: ALIGN(assoclen + MAX_CCM_ADATA_HEADER_LEN, 16) This guarantees that the allocated buffer is large enough for the fully padded AAD data for all supported header sizes.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80840", "url": "https://ubuntu.com/security/CVE-2026-80840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: seg6: clear IPv4 control block on IPIP decapsulation End.DX4 and End.DT4 decapsulate an IPv4 packet through decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), which normally clears IPCB before IPv4 interprets skb->cb. The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts. The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40. Both tcp_v4_save_options() and __ip_options_echo() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls __ip_options_echo(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte option-data area. Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced: BUG: KASAN: slab-out-of-bounds in __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm. Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80842", "url": "https://ubuntu.com/security/CVE-2026-80842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: fix use-after-free of a master VLAN's multicast context br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so once it is cleared under the lock no reader can arm the context again. For a master VLAN the handshake never runs. __vlan_del() clears BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so br_multicast_toggle_one_vlan(masterv, false) returns early on !br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is never taken. br_vlan_put_master() then drains the context in br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a reader still inside rcu_read_lock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no br_vlan_is_brentry() test and flips the flag under br->multicast_lock, so it is not affected. The reader is the bridge transmit path. For a master VLAN br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after br_multicast_ctx_deinit() has already stopped them. BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 Allocated by task 610: br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 Only test br_vlan_is_brentry() when enabling, like the br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before br_multicast_ctx_deinit() drains the context.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80843", "url": "https://ubuntu.com/security/CVE-2026-80843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix xfrm_state_construct() auth-trunc leak attach_auth_trunc() can allocate x->aalg while leaving x->props.aalgo at zero when the selected auth algorithm has no sadb_alg_id. One real case is cmac(aes). xfrm_state_construct() then treats !x->props.aalgo as \"no auth algorithm attached yet\" and calls attach_auth(). That overwrites x->aalg and loses the first allocation. Any later failure or teardown only frees the replacement pointer. Check whether x->aalg is already attached instead of inferring that state from x->props.aalgo.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80844", "url": "https://ubuntu.com/security/CVE-2026-80844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah6: validate routing header segments_left AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6_rearrange_rthdr() assumes that segments_left is not larger than the number of addresses described by the routing header's hdrlen field. That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segments_left value. With segments_left equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access. Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80846", "url": "https://ubuntu.com/security/CVE-2026-80846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: drop ESP-in-TCP packets with no ingress device ESP-in-TCP receives records through the TCP strparser. handle_esp() restores skb->dev from the saved skb_iif before passing the packet into the XFRM input path. Queued TCP data can be processed after the original ingress device has been removed, for example during veth or net namespace teardown. In that case dev_get_by_index_rcu() returns NULL. The XFRM IPv4 and IPv6 input paths both expect skb->dev to be valid while building the route lookup, so queued ESP-in-TCP data can dereference a NULL device. Drop the packet if the saved ingress device can no longer be resolved. Such a packet can no longer be routed through the normal XFRM receive path, and this preserves the existing behaviour for packets whose ingress device still exists.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80848", "url": "https://ubuntu.com/security/CVE-2026-80848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: fix UAF during close ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80854", "url": "https://ubuntu.com/security/CVE-2026-80854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: keep port count until LUN teardown completes tcm_usbg_drop_nexus() permits session removal once tpg_port_count reaches zero. However, usbg_port_unlink() currently decrements that count from the fabric_pre_unlink() callback, before core_dev_del_lun() waits for active se_lun references to drain. If removal of the last LUN races a nexus removal, the latter can observe a zero port count and call target_remove_session(). This frees sess_cmd_map while an in-flight struct usbg_cmd, including its work item, can still be accessed. Overlapping the last-LUN unlink with nexus removal reproduces this lifetime violation as a DEBUG_OBJECTS \"free active\" warning for usbg_cmd_work, followed by a target-core BUG/Oops. The generic target-core unlink path has no callback after core_dev_del_lun() completes. Add an optional fabric_post_unlink() callback and use it for the f_tcm port count. The count now remains nonzero until core_dev_del_lun() has finished draining active LUN references, preventing nexus removal from freeing the session during command completion.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80855", "url": "https://ubuntu.com/security/CVE-2026-80855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on open O_TRUNC DAX failure fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open(\"file\", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80856", "url": "https://ubuntu.com/security/CVE-2026-80856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on setattr writeback failure fuse_do_setattr() takes filemap_invalidate_lock() for a DAX truncate (fault_blocked = true) and releases it at the out:/error: labels. But when a writeback flush is also needed, a write_inode_now() failure returns directly and leaks the lock, so any later fault or truncate on the file stalls on the stale rwsem. For example, truncate(2) on a setuid file reaches fuse_do_setattr() with both ATTR_SIZE and ATTR_MODE set: truncate(2) └─ do_truncate() ├─ dentry_needs_remove_privs() # S_ISUID └─ notify_change() # KILL_SUID -> ATTR_MODE └─ fuse_setattr() # no killpriv: │ # ia_valid |= ATTR_MODE └─ fuse_do_setattr() ├─ filemap_invalidate_lock() # IS_DAX && is_truncate └─ write_inode_now() # is_wb && ATTR_MODE └─ if (err) # e.g. daemon -> -EIO return err # <- lock leaked Fix this by adding an unlock label that releases the lock before returning the error, and use it for the fuse_dax_break_layouts() failure path as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80923", "url": "https://ubuntu.com/security/CVE-2026-80923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: dbgtty: Fix unregister on tty_register_driver() failure If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80768", "url": "https://ubuntu.com/security/CVE-2026-80768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: ft260: fix stack-use-after-return write in I2C read race ft260_i2c_read() points dev->read_buf at a caller-supplied buffer (often an on-stack variable), arms a completion and waits up to five seconds for the device to return the data. The HID input callback ft260_raw_event() runs in the input/IRQ path, independent of the dev->lock mutex held by the read path, and copies the device-supplied payload into dev->read_buf after a plain NULL check. These two paths share read_buf, read_idx and read_len with no serialization. If the device delays its response until the read times out, ft260_i2c_read() resets the controller, clears read_buf and returns, unwinding the stack frame the buffer lived in. A response that arrives at that moment lets ft260_raw_event() pass the NULL check and then memcpy() the device-controlled payload into the now-freed stack location, a bounded but attacker-influenced stack-use-after-return write triggerable by malicious or malfunctioning hardware. Add a dedicated spinlock that serializes every access to read_buf, read_idx and read_len. ft260_raw_event() now holds it across the NULL check, the memcpy and the index update, while the read path takes it when arming and when clearing the buffer, so the teardown can no longer slip between the check and the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80766", "url": "https://ubuntu.com/security/CVE-2026-80766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: fix use-after-free of inrange_timer on remove uclogic_remove() cancels the pen in-range timer and then stops the device: \ttimer_delete_sync(&drvdata->inrange_timer); \thid_hw_stop(hdev); timer_delete_sync() only guarantees the timer is idle at that instant. uclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop() stops the transport several lines later, and every report with pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer: \tmod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); A report landing between the timer_delete_sync() call and the transport teardown in hid_hw_stop() re-arms inrange_timer after it was cancelled. uclogic_remove() then returns and the devm drvdata is freed, while hid_hw_stop() has already freed the input device drvdata->pen_input points at, so when the timer fires ~100 ms later uclogic_inrange_timeout() dereferences freed memory -- a use-after-free in timer-softirq context. Swapping the two calls is not a fix: stopping the device first frees drvdata->pen_input via hidinput_disconnect() while the timer may still be pending, so a timer already armed before removal fires on the freed input device in the window before timer_delete_sync() runs. Use timer_shutdown_sync() before hid_hw_stop() instead. It cancels the timer, waits for a running callback while pen_input is still valid, and prevents any further re-arming -- a later mod_timer() from an in-flight report is silently ignored -- so the timer is provably dead before hid_hw_stop() frees the inputs. This is the ordering the timer core documents for this \"timer re-armed from another path\" teardown case.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80789", "url": "https://ubuntu.com/security/CVE-2026-80789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: bound SGL data length before allocating command buffers nvmet_tcp_map_data() reads the host-controlled 32-bit sgl->length and, for the in-capsule offset descriptor (type 0x01), checks it against port->inline_data_size before use. Any other SGL descriptor type -- including the non-inline transport SGL data-block descriptor (type (NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, the type a real host uses for out-of-capsule writes) skips that check entirely and falls straight through to: \tcmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt); with len taken directly from the wire, unbounded up to 4 GiB. nvmet_req_init() only parses the command and never inspects sgl->length, and nvmet_check_transfer_len() -- the only other place transfer_len is validated -- runs later, from req->execute(), after the allocation has already happened. For a write command the target responds with an R2T and parks the command waiting for the host to send the data; if the host (or an unauthenticated peer that simply never follows up) never does, the sgl_alloc() buffer stays resident for the life of the command. NVMe/TCP has no mandatory authentication in the default configuration, so any peer able to reach the target portal and complete a Fabrics connect can drive this with a single crafted command, repeatable across queues and connections for amplification. This is unbounded kernel memory allocation triggered by a remote, effectively unauthenticated peer. Validate len against the same NVMET_TCP_MAXH2CDATA ceiling this file already uses to bound per-PDU H2C data, for every SGL descriptor type, before doing any allocation. This closes the gap for the non-inline descriptor while leaving the existing, tighter inline_data_size check in place for the in-capsule case. Runtime-verified on a v6.19 KASAN stand: with this bound in place, a crafted write command carrying an oversized non-inline SGL length is rejected before sgl_alloc() runs, where the same request previously drove an unbounded ~256 MiB kernel allocation (up to 4 GiB) that stayed resident pending an R2T the host never satisfies.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80783", "url": "https://ubuntu.com/security/CVE-2026-80783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event() magicmouse_raw_event() handles DOUBLE_REPORT_ID (0xf7) packets, which pack two touch reports into one, by splitting the packet and calling itself on each half. The only guard against runaway recursion is a \"size < 1\" check, which stops zero-sized calls but does not bound the recursion depth. A malicious HID device that matches this driver can send a report starting with DOUBLE_REPORT_ID and filled with the sequence [0xf7, 0x00]. Each level consumes two bytes and recurses on the remainder, so an incoming report of up to HID_MAX_BUFFER_SIZE (16 KiB) drives roughly 8000 nested calls. That easily exhausts the 16 KiB kernel stack, leading to a stack overflow: a panic with CONFIG_VMAP_STACK, or memory corruption without it. A double report only ever wraps two normal reports; it is never legitimately nested. Refuse to re-enter the DOUBLE_REPORT_ID case from a recursive call so the recursion depth is bounded to two, while all valid packets keep being parsed exactly as before.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80796", "url": "https://ubuntu.com/security/CVE-2026-80796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: add data_len bound checks to activation parameter extractors nci_extract_activation_params_iso_dep() and nci_extract_activation_params_nfc_dep() read an inner length byte from the NCI RF_INTF_ACTIVATED_NTF payload and use it to memcpy() into fixed kernel buffers, but neither function receives the caller-validated activation_params_len. A crafted NCI notification with activation_params_len=1 and an inner length byte of up to 20 (NFC-A) or 50 (NFC-B) causes memcpy() to read that many bytes past the one valid byte in the activation params region -- a slab out-of-bounds read of kernel memory adjacent to the NCI skb. The sibling nci_extract_rf_params_*() family was given equivalent protection by commit 571dcbeb8e63 (\"net: nfc: nci: Fix parameter validation for packet data\"), but the two activation parameter extractors were not updated at that time. Add a data_len parameter to both functions, guard against an empty region before consuming the inner length byte, decrement the remaining count after consuming it, and clamp the copy length to what is actually available. Update both call sites to pass ntf.activation_params_len, which is already validated against the skb at ntf.c:801.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80807", "url": "https://ubuntu.com/security/CVE-2026-80807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid block index in GC ioctl Syzbot reported list corruption caused by a double list_add_tail() call on bh->b_assoc_buffers within nilfs_lookup_dirty_data_buffers(). Analysis revealed that the root cause was the insertion of a page/folio with a page index of ULONG_MAX into the page cache via the GC ioctl. filemap_get_folios_tag(), called by nilfs_lookup_dirty_data_buffers(), repeatedly detects a dirty folio with a page index of ULONG_MAX due to index wrap-around, leading to duplicate processing of dirty buffers. As a preparatory step, the GC ioctl loads the page/folio of the block to be moved during GC and inserts it into the page cache based on information in the nilfs_vdesc structure passed as an argument. Normally, this does not cause issues because the user-space GC library configures the nilfs_vdesc structure properly. However, since there is no range check on the parameters determining the page index, a request with artificially crafted parameters -- such as those generated by Syzbot -- can result in a page/folio being inserted with a page index of ULONG_MAX, triggering the above problem. This resolves the issue by checking the ranges of 'vd_offset' and 'vd_vblocknr' in the nilfs_vdesc structure that determine the page index, thereby preventing the invalid page/folio insertions.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80916", "url": "https://ubuntu.com/security/CVE-2026-80916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcov: fix data corruption and race conditions on PREEMPT_RT syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area. On PREEMPT_RT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state. Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites. Note that while the temporary storage is now on a per-thread basis, the per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that kcov_remote_start() and kcov_remote_stop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state. It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when __init function of built-in module runs. But this patch also fixes crashing the kernel when vmalloc_node() in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in (1) doing vmalloc() in kcov_remote_start() despite !in_task() context (2) out-of-array-bounds access if (1) succeeded but kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE (3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes problems.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-43437", "url": "https://ubuntu.com/security/CVE-2026-43437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain() In the drain loop, the local variable 'runtime' is reassigned to a linked stream's runtime (runtime = s->runtime at line 2157). After releasing the stream lock at line 2169, the code accesses runtime->no_period_wakeup, runtime->rate, and runtime->buffer_size (lines 2170-2178) — all referencing the linked stream's runtime without any lock or refcount protecting its lifetime. A concurrent close() on the linked stream's fd triggers snd_pcm_release_substream() → snd_pcm_drop() → pcm_release_private() → snd_pcm_unlink() → snd_pcm_detach_substream() → kfree(runtime). No synchronization prevents kfree(runtime) from completing while the drain path dereferences the stale pointer. Fix by caching the needed runtime fields (no_period_wakeup, rate, buffer_size) into local variables while still holding the stream lock, and using the cached values after the lock is released.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-53089", "url": "https://ubuntu.com/security/CVE-2026-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in offloaded map/prog info fill When querying info for an offloaded BPF map or program, bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns() obtain the network namespace with get_net(dev_net(offmap->netdev)). However, the associated netdev's netns may be racing with teardown during netns destruction. If the netns refcount has already reached 0, get_net() performs a refcount_t increment on 0, triggering: refcount_t: addition on 0; use-after-free. Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains valid, they cannot prevent the netns refcount from reaching zero. Fix this by using maybe_get_net() instead of get_net(). maybe_get_net() uses refcount_inc_not_zero() and returns NULL if the refcount is already zero, which causes ns_get_path_cb() to fail and the caller to return -ENOENT -- the correct behavior when the netns is being destroyed.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2025-40102", "url": "https://ubuntu.com/security/CVE-2025-40102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000) Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-39925", "url": "https://ubuntu.com/security/CVE-2025-39925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: j1939: implement NETDEV_UNREGISTER notification handler syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 (\"can: j1939: move j1939_priv_put() into sk_destruct callback\") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on \"struct j1939_priv\" held by j1939_sk_bind() call prevents \"struct net_device\" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. [mkl: remove space in front of label]", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2024-58095", "url": "https://ubuntu.com/security/CVE-2024-58095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before txBeginAnon() call Added a read-only check before calling `txBeginAnon` in `extAlloc` and `extRecord`. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes. Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-58094", "url": "https://ubuntu.com/security/CVE-2024-58094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before truncation in jfs_truncate_nolock() Added a check for \"read-only\" mode in the `jfs_truncate_nolock` function to avoid errors related to writing to a read-only filesystem. Call stack: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) If the `isReadOnly(ip)` condition is triggered in `jfs_truncate_nolock`, the function execution will stop, and no further data modification will occur. Instead, the `xtTruncate` function will be called with the \"COMMIT_WMAP\" flag, preventing modifications in \"read-only\" mode.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-46754", "url": "https://ubuntu.com/security/CVE-2024-46754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Remove tst_run from lwt_seg6local_prog_ops. The syzbot reported that the lwt_seg6 related BPF ops can be invoked via bpf_test_run() without without entering input_action_end_bpf() first. Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a (\"ipv6: sr: Add seg6local action End.BPF\"). The reason is that the per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self test case but each BPF function expects it. Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.", "cve_priority": "low", "cve_public_date": "2024-09-18 08:15:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-80806", "url": "https://ubuntu.com/security/CVE-2026-80806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't enable DAX on new encrypted files Currently, when a new encrypted regular file is created, the call to ext4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made before EXT4_INODE_ENCRYPT is set. As a result, it can set S_DAX if the filesystem is mounted with \"-o dax=always\". EXT4_INODE_ENCRYPT then actually gets set a bit later in __ext4_new_inode(), when it calls fscrypt_set_context() which calls ext4_set_context(). ext4_set_context() sets EXT4_INODE_ENCRYPT and calls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too. This was intended to clear S_DAX as well. However, this was broken by commit 043546e46dc7 (\"fs/ext4: Only change S_DAX on inode load\"). This causes data written to the file to bypass encryption, also causing xfstests failures such as generic/548 (when \"-o dax=always\" is used). Fix this by simplifying the flow by making __ext4_new_inode() set EXT4_INODE_ENCRYPT earlier. This makes it take effect in ext4_set_inode_flags(inode, init=true), making S_DAX never be set. Similarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first place on new encrypted inodes. Then it doesn't need to be cleared. As a result of these simplifications, ext4_set_context() no longer needs to change inode flags or state when 'handle != NULL'. Remove that too.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80863", "url": "https://ubuntu.com/security/CVE-2026-80863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix OOB in free_rd_atomic_resources() free_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic. Updating max_dest_rd_atomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] BUG: KASAN: slab-out-of-bounds in rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 Write of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063 CPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xf7/0x600 mm/kasan/report.c:482 kasan_report+0xe4/0x120 mm/kasan/report.c:595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fefc75a70cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fefc8495018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd RDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007 RBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0 Allocated by task 11063: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5296 [inline] __kmalloc_noprof+0x32a/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:155 [inline] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_ma ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80590", "url": "https://ubuntu.com/security/CVE-2026-80590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 (\"net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list\") and by commit 9e4b7a99a03a (\"net: gso: fix panic on frag_list with mixed head alloc types\") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 (\"tun: Allow GSO using virtio_net_hdr\"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80765", "url": "https://ubuntu.com/security/CVE-2026-80765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: validate initial device info bounds The Hyper-V synthetic HID host supplies SYNTH_HID_INITIAL_DEVICE_INFO messages that contain a HID descriptor followed by the report descriptor bytes. mousevsc_on_receive_device_info() trusts bLength and wDescriptorLength without checking that the received packet contains both byte ranges. A malformed host or backend message can therefore make the guest read past the received VMBus packet while copying the report descriptor. Pass the received initial-device-info size into the parser and reject descriptor lengths that exceed the packet. Impact: A malicious Hyper-V host or backend can crash a guest by sending a short initial device-info message with an oversized HID report descriptor length.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80767", "url": "https://ubuntu.com/security/CVE-2026-80767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix use-after-free in enable_sensor enable_sensor_store() can call set_power_report_state(), which dereferences sensor_inst->power_state and sensor_inst->report_state. These pointers refer to entries in sensor_inst->fields. Create the field attributes before exposing the enable_sensor sysfs attribute, so enable_sensor cannot be accessed before the state it depends on has been initialized. On remove, delete enable_sensor before freeing the field attributes, so a concurrent sysfs write cannot dereference freed memory through power_state or report_state.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80918", "url": "https://ubuntu.com/security/CVE-2026-80918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix number/pointer type confusion on long items When fetch_item() is called by hid_scan_report() on an item with HID_ITEM_TAG_LONG, it stores a pointer to the item data in item->data.longdata instead of storing a value directly in item->data.{u8/u16/u32}. When item_udata() or item_sdata() encounters such an item, it incorrectly assumes that the item is in short format, and therefore returns the lower part of a kernel pointer reinterpreted as a number. When a HID device is connected whose descriptor contains a HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this causes the lower half of a kernel pointer to be printed into dmesg as a number, like this: hid (null): invalid report_size 107953555 To fix it, let item_udata() and item_sdata() verify that the item is in short format. Note that this bug only affects hid_scan_report(), while the main parsing pass hid_parse_collections() will always bail out when encountering a long item. Sidenote: There are currently no users of data.longdata; maybe we should just remove any parsing of long-format descriptors as a follow-up.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80889", "url": "https://ubuntu.com/security/CVE-2026-80889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix timer drain order, wakeup handling and tx_gen ordering This patch is a follow-up to commit cf070fe33bfb (\"can: isotp: serialize TX state transitions under so->rx_lock\") which addresses following sashiko-bot findings: - isotp_sendmsg(): drain so->txfrtimer first so a stale callback can't re-arm echotimer after the claim - isotp_release(): wake so->wait after forcing ISOTP_SHUTDOWN so a sleeping sendmsg() claim isn't stranded - isotp_sendmsg(): have both wait_event_interruptible() calls in isotp_sendmsg() also wake on ISOTP_SHUTDOWN and do not return claim to IDLE to avoid corrupting a concurrent isotp_release() process. - isotp_sendmsg(): handle potential claim of a new transfer when the wait_event_interruptible() call returns in CAN_ISOTP_WAIT_TX_DONE mode. Don't touch timers and states of the new transfer if a new thread incremented so->tx_gen before getting the lock at err_event_drop. - isotp_sendmsg(): handle a stuck can_send() and omit timer and state changes if a new transfer was claimed. wait_tx_done() returns the error recorded in so->tx_result[], tagged with the caller's own generation. - isotp_tx_timeout(): on a claimed timeout, record the ECOMM error for the timed-out transfer's own generation in so->tx_result[]; sk->sk_err is raised unconditionally, same as every other error path here. - isotp_tx_gen_done()/isotp_tx_timeout(): always read tx.state (acquire) before tx_gen - the reverse order let a weakly ordered CPU pair a fresh tx.state with a stale tx_gen/tx_result slot. - isotp_sendmsg(): wait_tx_done: drain sk_err via sock_error() once we have read the result from so->tx_result[], so an already-reported error doesn't stay latched for a later poll()/SO_ERROR. Also align the remaining lock-free so->tx.state/rx.state/cfecho accesses and use skb->hash as unique loopback echo frame indicator.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-46170", "url": "https://ubuntu.com/security/CVE-2026-46170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: free sk if last When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on \"itself\".", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46158", "url": "https://ubuntu.com/security/CVE-2026-46158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: always decrease sk refcount When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as \"unlikely\".", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-80555", "url": "https://ubuntu.com/security/CVE-2026-80555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Free all memory if cp_init() fails The routine cp_free() is called to unpin/free any memory once an I/O is completed successfully, or if cp_prefetch() fails. But if cp_init() fails, and cp->initialized is not enabled, the same routine cannot be used to free all the memory. An attempt to address this exists in ccwchain_handle_ccw(), where a single call to ccwchain_free() is made for the currently-processed CCW segment. But this will leak other segments (created as a result of a Transfer in Channel) that had been allocated as part of the same channel program. Address this by performing the cleanup outside of the recursive ccwchain_handle_ccw()/ccwchain_loop_tic() logic.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2025-68794", "url": "https://ubuntu.com/security/CVE-2025-68794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: adjust read range correctly for non-block-aligned positions iomap_adjust_read_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio. Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-80781", "url": "https://ubuntu.com/security/CVE-2026-80781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix OOB read of field->usage in hid_set_field() hid_set_field() hands field->usage + offset to hid_dump_input() before the guard that bounds offset: \thid_dump_input(field->report->device, field->usage + offset, value); \tif (offset >= field->report_count) { \t\thid_err(...); \t\treturn -1; \t} Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is allocated inline with the hid_field in hid_register_field() and holds field->maxusage entries, so an offset past it reads off the end of the kvzalloc()ed allocation and into a neighbouring object. Had the guard run first, offset < report_count <= maxusage would already have confined the pointer to the array. A caller supplies such an offset today. picolcd_fb_send_tile() validates only report->maxfield before issuing hid_set_field(report->field[0], 11 + i, ...) for i = 0..31, so its offsets are fixed at 11..42 and are never checked against the bound field. When the device registers that field with fewer usages, the framebuffer deferred-io work drives the read on every tile. KASAN reports a 4-byte slab-out-of-bounds read in hid_dump_input() below hid_set_field(), and the same boot logs \"offset (1) exceeds report_count (1)\" from the guard that runs only afterwards. Move the hid_dump_input() call below the guard. Because field->maxusage >= field->report_count, the guard then establishes that field->usage + offset lies inside the array before it is dereferenced, for every caller and without changing behaviour on the valid path. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80782", "url": "https://ubuntu.com/security/CVE-2026-80782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: do not keep a stale msc->input if no input is claimed magicmouse_input_mapping() caches the first hid_input's input_dev in msc->input while the report descriptor is parsed, and the rest of the driver treats a non-NULL msc->input as proof that an input device was registered. That does not hold on the hid-input error path. If hidinput_connect() fails -- for instance because input_register_device() returns an error -- it unwinds through hidinput_disconnect(), which frees every input_dev it created, including the one cached in msc->input. The failure does not abort the probe. hid_connect() only skips the claim: \tif ((connect_mask & HID_CONNECT_HIDINPUT) && !hidinput_connect(hdev, \t\t\t\tconnect_mask & HID_CONNECT_HIDINPUT_FORCE)) \t\thdev->claimed |= HID_CLAIMED_INPUT; and the \"device has no listeners\" bailout below it does not fire for this driver, which sets ->raw_event; on the USB Magic Mouse 2 / Magic Trackpad 2 paths hidraw and hiddev are claimed as well. hid_hw_start() therefore returns 0 and magicmouse_probe() continues with msc->input pointing at freed memory. Being non-NULL, it passes the \"input not registered\" check in probe and the NULL checks in ->raw_event and ->event, so the next input report dereferences freed memory. Clear msc->input when the HID core did not claim an input device, so the existing NULL checks cover this case as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-80583", "url": "https://ubuntu.com/security/CVE-2026-80583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses The \"DEC0 MODE\" to \"DEC7 MODE\" controls are enumerated, but tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 (\"ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type\") and commit 0ea5eff7c606 (\"ASoC: codecs: va-macro: fix accessing array out of bounds for enum type\"), but tx-macro was missed. On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value sanity check catches the 4 bytes written past the enumerated item and every read of these controls fails with -EINVAL: snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80587", "url": "https://ubuntu.com/security/CVE-2026-80587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid combining some incoming suboptions Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80547", "url": "https://ubuntu.com/security/CVE-2026-80547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Implement a crw lock Unlike the channel_program struct, which covers synchronous I/O submissions and asynchronous interrupts, the CRW region relies exclusively on asynchronous events coming from hardware. Implement a lock to manage the list of those payloads, to ensure they are read cohesively.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80548", "url": "https://ubuntu.com/security/CVE-2026-80548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Selectively expand io_mutex The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80552", "url": "https://ubuntu.com/security/CVE-2026-80552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure index for read/write regions are within range The introduction of the capability chain rightly clamped the region indexes to the range of the capabilities itself, but neglected to do so for the existing read/write regions which should also be enforced.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80788", "url": "https://ubuntu.com/security/CVE-2026-80788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations When fuzzing the nvme target code, I tripped a kernel warning in nvmet_tcp_map_data() because the length passed into the allocator is controlled by the remote initiator. A remote initiator that sends a command with an SGL claiming a huge number, can create a scatterlist and iovec allocation of over 1 million entries, which causes the backing kmalloc call to exceed MAX_PAGE_ORDER and then the page allocator will trip on a WARN_ON_ONCE_GFP() message: WARNING: mm/page_alloc.c:5280 __alloc_frozen_pages_noprof Workqueue: nvmet_tcp_wq nvmet_tcp_io_work ... sgl_alloc_order nvmet_tcp_map_data nvmet_tcp_try_recv_pdu As it's never good to trip a kernel warning remotely due to many systems having panic-on-warn enabled, let's silence it by just add GFP_NOWARN to the allocation flags.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80790", "url": "https://ubuntu.com/security/CVE-2026-80790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: fix invalid free in LS IOD error path nvmet_fc_alloc_ls_iodlist() advances iod while initializing the LS IOD array. If an rqstbuf allocation or response buffer DMA mapping fails, the unwind loop decrements iod past the start of the array. The final kfree(iod) therefore frees an address before the allocated object. This can be reproduced with nvme-fcloop and failslab by setting fail-nth to 6 before creating a target port. KASAN reports: BUG: KASAN: invalid-free in nvmet_fc_register_targetport Free of addr ffff88816cf8ff48 by task nvmet_fail_nth/9552 Free the original allocation base stored in tgtport->iod instead. With this fix applied, the same sysfs write with fail-nth=6 returns -ENOMEM without any KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80792", "url": "https://ubuntu.com/security/CVE-2026-80792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix use-after-free in ip6_finish_output2() ip6_finish_output2() caches a pointer to the IPv6 destination address (daddr) before invoking lwtunnel_xmit(). The LWT-BPF transmit path or other encapsulation operations within lwtunnel_xmit() can reallocate the skb head, freeing the memory that daddr points to. When lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, the function continues to use the stale daddr pointer to compute the nexthop and to look up or create the neighbour entry. This results in a use-after-free read, which can leak sensitive kernel data, pollute the neighbour table with arbitrary values, misdirect traffic, or crash the system. Fix this by re-fetching the IPv6 header and the destination address pointer after lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, ensuring that the subsequent nexthop computation and neighbour lookup operate on valid memory.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80793", "url": "https://ubuntu.com/security/CVE-2026-80793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: reject undersized MTUs in ip_do_fragment() ip_do_fragment() subtracts the IPv4 header length from the effective MTU and passes the resulting payload MTU to ip_frag_next(). If the effective MTU is smaller than hlen + 8, ip_frag_next() rounds the fragment payload length down to zero. The fragmentation state then never makes forward progress: state->left, state->ptr and state->offset stay unchanged while ip_do_fragment() keeps allocating and transmitting header-only fragments until the softlockup detector fires. This is reproducible with a route installed using \"mtu lock 20\", but it is also reproducible without route MTU lock, for example by forwarding a packet to a device whose MTU is 20. Fix it in ip_do_fragment() by rejecting mtu < hlen + 8 with -EMSGSIZE, matching the existing IPv6 fragmentation check.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80557", "url": "https://ubuntu.com/security/CVE-2026-80557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix OOB read in decode_watchers() via missing bounds check ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80794", "url": "https://ubuntu.com/security/CVE-2026-80794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix uninit-value in the RF discover/activated NTF handlers nci_rf_discover_ntf_packet() and nci_rf_intf_activated_ntf_packet() each parse a notification into an on-stack struct (nci_rf_discover_ntf / nci_rf_intf_activated_ntf) that is not initialised. The RF technology-specific parameters are only extracted when rf_tech_specific_params_len is non-zero, so a notification that reports a zero length leaves the rf_tech_specific_params union uninitialised - and both handlers then pass it to nci_add_new_protocol(), which reads it: - discover: nci_add_new_target() -> nci_add_new_protocol(); - activated: nci_target_auto_activated() -> nci_add_new_protocol(). nci_add_new_protocol() uses nfca_poll->nfcid1_len as both a branch condition and a memcpy() length and copies nfcid1/sens_res/sel_res into ndev->targets, which is later exposed to user space via NFC_CMD_GET_TARGET. BUG: KMSAN: uninit-value in nci_add_new_protocol+0x624/0x6c0 nci_add_new_protocol+0x624/0x6c0 nci_ntf_packet+0x25b2/0x3c30 nci_rx_work+0x318/0x5d0 process_scheduled_works+0x84b/0x17a0 worker_thread+0xc10/0x11b0 kthread+0x376/0x500 Local variable ntf.i created at: nci_ntf_packet+0xbc2/0x3c30 Zero-initialise both on-stack notifications so the union reads back as zero when no technology-specific parameters are present.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80795", "url": "https://ubuntu.com/security/CVE-2026-80795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix out-of-bounds write in nci_target_auto_activated() nci_target_auto_activated() appends a target to the fixed-size array ndev->targets[NCI_MAX_DISCOVERED_TARGETS] and increments ndev->n_targets without first checking the array is full; unlike its sibling nci_add_new_target(), which bails out when n_targets already equals NCI_MAX_DISCOVERED_TARGETS. ndev->n_targets is only cleared by nci_clear_target_list(), so an NFCC that repeatedly re-runs discovery (RF_DISCOVER_RSP, which re-enters NCI_DISCOVERY without clearing the target list) and reports an auto-activated target (RF_INTF_ACTIVATED_NTF) drives n_targets past the limit. The append then writes a struct nfc_target past the end of the array (a slab out-of-bounds write), and nfc_targets_found() goes on to walk the array with the inflated count: BUG: KASAN: slab-out-of-bounds in nci_add_new_protocol+0x94/0x2ac [nci] Write of size 2 at addr ffff0000c7299a18 by task kworker/u8:0/12 Workqueue: nfc0_nci_rx_wq nci_rx_work [nci] Call trace: nci_add_new_protocol+0x94/0x2ac [nci] nci_ntf_packet+0xddc/0x11a0 [nci] nci_rx_work+0x15c/0x1e0 [nci] process_one_work+0x2dc/0x500 worker_thread+0x240/0x460 kthread+0x1c0/0x1d0 ret_from_fork+0x10/0x20 The buggy address belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1024 bytes to the right of allocated 1560-byte region [ffff0000c7299000, ffff0000c7299618) Guard nci_target_auto_activated() with the same check used by nci_add_new_target().", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80823", "url": "https://ubuntu.com/security/CVE-2026-80823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: validate ATR_REQ length against the received frame st21nfca_tm_recv_atr_req() checks that the received ATR_REQ frame is at least ST21NFCA_ATR_REQ_MIN_SIZE and that the self-declared atr_req->length is at least sizeof(struct st21nfca_atr_req), but never checks that atr_req->length does not exceed the actual received length (skb->len). st21nfca_tm_send_atr_res() then trusts the declared length: \tgb_len = atr_req->length - sizeof(struct st21nfca_atr_req); \t... \tmemcpy(atr_res->gbi, atr_req->gbi, gb_len); so an RF peer that sends a short frame but sets atr_req->length larger than the frame makes gb_len exceed the general bytes actually present, and the memcpy reads out of bounds past the received skb. Those bytes are placed in the ATR_RES and sent back to the peer (kernel-memory disclosure to a proximity attacker); a larger declared length is an out-of-bounds read (DoS). Reject frames whose declared length exceeds the received length. The adjacent nfc_tm_activated() path in the same function already derives its general-bytes length from skb->len rather than the declared field. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80797", "url": "https://ubuntu.com/security/CVE-2026-80797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: purge fragmented skbs during cleanup pn53x_common_clean() purges resp_q before freeing the common PN533 state, but it leaves fragment_skb untouched. The fragmentation helpers queue transmit fragments there while sending large initiator or target-mode frames, and those skbs remain owned by the driver until they are sent or discarded. If the device is removed while fragments are still queued, the common cleanup path frees the PN533 state without releasing the queued fragment skbs, leaking them. Purge fragment_skb during cleanup alongside resp_q.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80798", "url": "https://ubuntu.com/security/CVE-2026-80798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: reject PDUs shorter than the LLCP header Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes before parsing it. nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/ nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a CONNECT or CC PDU then computes \ttlv_array_len = skb->len - LLCP_HEADER_SIZE; as a size_t and hands it to the TLV walk. When the frame is shorter than the header the subtraction wraps to a huge value and the walk runs far past the buffer, an out-of-bounds read. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Guard the common receive choke point __nfc_llcp_recv(), shared by both the target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so a short skb is dropped before the rx_work worker parses it. Use pskb_may_pull() rather than a skb->len test so the two header bytes are guaranteed to sit in the skb linear area even for a non-linear skb, matching how the sibling NCI and HCI receive paths validate their headers. Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on linux-next. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80799", "url": "https://ubuntu.com/security/CVE-2026-80799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain three related bugs in their TLV parsing loops: 1. 'offset' is declared u8 but tlv_array_len is u16. When TLV data advances offset past 255 it silently wraps to zero, causing infinite loops or double-processing of buffer data. 2. Before reading tlv[0] (type) and tlv[1] (length) there is no check that offset+2 <= tlv_array_len. A truncated TLV causes an OOB read of one byte past the buffer end. 3. After reading the length field, the value bytes are accessed without checking offset+2+length <= tlv_array_len. A crafted length=0xFF on a short buffer causes up to 255 bytes of OOB read past the buffer end. Both functions are reachable without authentication via nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes directly into nfc_llcp_parse_gb_tlv() with no additional validation. Fix all three issues by widening offset from u8 to u16 and adding bounds checks for both the TLV header and value field before each access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80800", "url": "https://ubuntu.com/security/CVE-2026-80800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound the connect_sn TLV walk to the skb Commit 27256cdb290e (\"nfc: llcp: bound SNL TLV parsing to the skb and add length checks\") fixed the unbounded TLV walk in nfc_llcp_recv_snl(), and commit d8bd2dedbde5 (\"nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers\") subsequently bounded nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv(). One sibling parser sharing the same pattern remains unbounded: nfc_llcp_connect_sn(). nfc_llcp_connect_sn() walks a TLV list, reading a two-byte header (type, length) followed by length bytes of value, without checking that the two header bytes or the declared length stay within the buffer. It returns a pointer to a service name of up to 255 bytes that may point past the end of the skb; it is subsequently consumed by memcmp() in nfc_llcp_sock_from_sn(). In addition tlv_array_len was computed as \"skb->len - LLCP_HEADER_SIZE\" in size_t, so a CONNECT/CC frame shorter than the LLCP header underflows to a huge length and the walk runs far past the buffer. nfc_llcp_connect_sn() is reachable from nfc_llcp_recv_connect() and nfc_llcp_recv_cc(), i.e. from received CONNECT and CC PDUs. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP, and the nfc_llcp_rx_skb() dispatcher applies no minimum-length guard. Walk the TLV list by pointer, bounded by skb_tail_pointer(skb), and validate each declared length before use, matching the approach already used for nfc_llcp_recv_snl(). Starting the walk at &skb->data[LLCP_HEADER_SIZE] against the tail pointer also removes the size_t underflow for short frames. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80801", "url": "https://ubuntu.com/security/CVE-2026-80801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: microread: validate target discovery payload lengths microread_target_discovered() parses target discovery payloads from skb->data according to the HCI gate. The fixed field offsets and UID copies were checked only against the destination nfc_target buffers, not against the actual skb length. Validate that each gate-specific payload contains the fixed fields and UID bytes before reading or copying them.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80802", "url": "https://ubuntu.com/security/CVE-2026-80802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: bound the device-reported read length and fix an skb leak fdp_nci_i2c_read() takes the next packet length from two device-supplied bytes and never validates it. The value is a u16 used as the i2c_master_recv() count into a 261-byte on-stack buffer: a malicious, counterfeit or malfunctioning controller (or an i2c bus interposer) can drive it far past the buffer for a stack out-of-bounds write that clobbers the canary and return address, or below the minimum frame size (directly, or by truncating the computed sum) so the header/LRC strip and the next length read run past a short receive. Reject a length outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD], as a corrupted packet already is, and force resynchronization. The same loop allocates one data skb per iteration and assumes a length packet followed by a data packet; a device that sends two data packets in one call leaks the first skb when the second allocation overwrites it. Free a previously allocated skb before allocating the next.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80803", "url": "https://ubuntu.com/security/CVE-2026-80803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: digital: clamp SENSF_RES length to the destination buffer digital_in_recv_sensf_res() memcpy()s resp->len bytes from a remote NFC-F device response into the NFC_SENSF_RES_MAXSIZE-byte target.sensf_res field without an upper-bound check. A nearby malicious NFC-F device can send an oversized SENSF_RES response to overflow the stack-local struct nfc_target. Clamp resp->len to NFC_SENSF_RES_MAXSIZE before the copy. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80536", "url": "https://ubuntu.com/security/CVE-2026-80536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: bounds-check buffer log item's dirty bitmap xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: \tmemcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), \t\titem->ri_buf[i].iov_base, \t\tnbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80553", "url": "https://ubuntu.com/security/CVE-2026-80553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Cancel existing workqueues The initialization of the io_work and crw_work workqueues begs the question of whether they should be un-initialized. Add the corresponding cleanup tags in _release_dev to ensure work isn't dispatched after the private struct is free'd.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74662", "url": "https://ubuntu.com/security/CVE-2026-74662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: publish queues before arming timer inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74666", "url": "https://ubuntu.com/security/CVE-2026-74666", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: synchronize pressure clearing with ring reconfiguration packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74663", "url": "https://ubuntu.com/security/CVE-2026-74663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: reject overly deep qdisc hierarchies Deep qdisc hierarchies can lead to excessive recursion in qdisc tree walkers and exhaust the kernel stack. The existing loop check does not cover the create-and-graft path, so a hierarchy can still be extended by creating a new child qdisc below an already deep parent. Store the hierarchy depth in struct Qdisc and update it when qdiscs are grafted. Reject new child qdiscs once the parent is already at the maximum allowed depth.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74668", "url": "https://ubuntu.com/security/CVE-2026-74668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in TX_RING send path tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative. Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb(). The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74582", "url": "https://ubuntu.com/security/CVE-2026-74582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in non-ring send paths packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-80737", "url": "https://ubuntu.com/security/CVE-2026-80737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: synchronize DMA teardown dmaengine_terminate_all() does not wait for a running callback, so the TX callback can still touch the TX buffer after it is freed. The RX poll timer reads the RX buffers without the port lock. Switch to dmaengine_terminate_sync() and delete the RX timer before freeing the buffers.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74626", "url": "https://ubuntu.com/security/CVE-2026-74626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_netdev: Preserve RX queue depth on allocation failure ntb_netdev_rx_handler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception. A retry path could refill the queue later, but ntb_netdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74637", "url": "https://ubuntu.com/security/CVE-2026-74637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix group leader use-after-free after sibling detach perf_group_detach() handles leader and sibling detach differently. When the group leader is detached, all siblings are promoted to singleton events and their group_leader pointer is reset to themselves. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. That is harmless when the sibling is being closed and freed immediately, as in the DETACH_DEAD path. It is not safe when the sibling is detached but kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the sibling is removed from the context, while its file descriptor can still keep it alive. A typical failing sequence is: - A group contains leader L and sibling S. - CPU hot-unplug detaches S with DETACH_GROUP, removing it from L->sibling_list but leaving S->group_leader == L. - L is later closed and freed. - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and dereferences the freed leader. This was reproduced by running the perf event fuzzer, CPU hotplug, and a stress workload concurrently: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT pc : perf_ioctl+0x34c/0xc68 x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908) Call trace: perf_ioctl+0x34c/0xc68 (P) __arm64_sys_ioctl+0xa0/0xf4 invoke_syscall+0x58/0xe4 el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x40/0xc0 el0t_64_sync_handler+0x68/0xdc el0t_64_sync+0x1c4/0x1c8 The fault happened in perf_ioctl(), where perf_event_for_each() follows the stale group_leader pointer and perf_event_for_each_child() then dereferences the freed leader's context. Fix the use-after-free by promoting the detached sibling to a singleton. Also fix __event_disable() cgroup accounting and event state change.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74647", "url": "https://ubuntu.com/security/CVE-2026-74647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Remove buffer from list prior to unmap operation fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74632", "url": "https://ubuntu.com/security/CVE-2026-74632", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix huge_zero_pfn race Patch series \"mm/huge_memory: fix huge_zero_pfn race\", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80562", "url": "https://ubuntu.com/security/CVE-2026-80562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: ml-ioh: use raw_spinlock_t for the register lock ioh_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irq_set_type callback additionally emits a dev_warn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same fix as commit a02b8950d619 (\"gpio: pch: use raw_spinlock_t for the register lock\"); this driver shares the same structure as gpio-pch.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80805", "url": "https://ubuntu.com/security/CVE-2026-80805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: validate attr entry pointer before field access xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen, valuelen) before checking if the entry pointer itself is within bounds. If nameidx is crafted to point near the end of the buffer, these field accesses can read out-of-bounds before the bounds check at name_end > buf_end is performed. Add explicit bounds checks for entry pointers before accessing their fields. Use offsetof() to check that the start of the flexible array member (nameval/name) is within bounds, which ensures all preceding fields are safe to access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80808", "url": "https://ubuntu.com/security/CVE-2026-80808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: stop retrying saturated xattr cache entries ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked. Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop. Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition. Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80809", "url": "https://ubuntu.com/security/CVE-2026-80809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix missing metadata reservation for large xattrs [BUG] lsetxattr() panics the kernel when setting a large xattr value on a fragmented filesystem where the file already has an external xattr block. [CAUSE] ocfs2_calc_xattr_set_need() never reserves metadata blocks for a new xattr value's extent tree when the file already has an external xattr block. The not_found path leaves meta_add at zero, so meta_ac is NULL when ocfs2_xattr_extend_allocation() runs. A new value root has room for a single extent record. On a fragmented filesystem, the allocator cannot satisfy the xattr value in one contiguous run, so each non-contiguous run requires its own extent record. When the value root's extent list is full and meta_ac is NULL, ocfs2_add_clusters_in_btree() returns RESTART_META, and ocfs2_xattr_extend_allocation() hits BUG_ON(why == RESTART_META). [FIX] The case where no xattr block exists yet already calls ocfs2_extend_meta_needed(&def_xv.xv.xr_list) to reserve value tree metadata. Add the same reservation to the case where an xattr block already exists, making the two cases consistent. Replace the BUG_ON with a -ENOSPC return so that if RESTART_META is returned despite the reservation, the error propagates to userspace instead of panicking the kernel.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80812", "url": "https://ubuntu.com/security/CVE-2026-80812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dummy: Check card index validity at probe snd_dummy_probe() blindly trusts that the given devptr->id value is within the proper card index range. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80814", "url": "https://ubuntu.com/security/CVE-2026-80814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rndis_host: add overflow check in rndis_rx_fixup() Add an overflow check to ensure that data_offset + data_len + 8 does not wrap, which would enable an OOB read of the USB data buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80819", "url": "https://ubuntu.com/security/CVE-2026-80819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept rfcomm_sock_recvmsg() completes a deferred setup by calling rfcomm_dlc_accept() without holding any RFCOMM lock: \tif (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { \t\trfcomm_dlc_accept(d); \t\treturn 0; \t} and rfcomm_dlc_accept() dereferences the session on its first line: \tstruct sock *sk = d->session->sock->sk; Every other path that touches d->session runs under rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). rfcomm_connect_ind() is even documented as \"called under rfcomm_lock()\". This call site is the only one that skips it. The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against teardown, since __rfcomm_dlc_close() returns early when it wins the test_and_clear. But rfcomm_recv_disc() forces the state first: \td->state = BT_CLOSED; \t__rfcomm_dlc_close(d, err); and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2. With the state already BT_CLOSED that switch does not match, the bit is never consulted, and __rfcomm_dlc_close() falls through to rfcomm_dlc_unlink(), which sets d->session = NULL. So a remote DISC on a deferred dlc clears the session while leaving RFCOMM_DEFER_SETUP set. The next recvmsg() then passes the test_and_clear and dereferences a NULL session. No timing window is needed: once the DISC has been processed, the dereference is unconditional. Give rfcomm_dlc_accept() the same shape as rfcomm_dlc_open() and rfcomm_dlc_close(): an exported wrapper that takes rfcomm_mutex and re-checks the session, around a __rfcomm_dlc_accept() that the two in-core callers, which already hold the mutex, keep using. Reproduced on a KASAN + PROVE_LOCKING kernel with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session, opens a dlc on a channel bound with BT_DEFER_SETUP, and sends DISC after the socket is accepted. recv() on the accepted socket then hits: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10 is the offset of sock in struct rfcomm_session. With this patch the same run completes with recv() returning 0 and no report, and lockdep stays quiet, confirming rfcomm_mutex is still taken before lock_sock on this path as it is on the thread side.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80917", "url": "https://ubuntu.com/security/CVE-2026-80917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems On 32-bit systems the config space is too large to ioremap in one go, so pci_ecam_create() maps each bus segment separately and relies on the ->add_bus callback (pci_ecam_add_bus) to populate the per-bus mapping in cfg->winp[]. pci_ecam_map_bus() then uses that mapping as the base for every config access. The generic ECAM ops (pci_generic_ecam_ops) already provide the ->add_bus and ->remove_bus callbacks, but the CAM (legacy) ops in pci-host-generic.c do not. As a result, on a 32-bit host using \"pci-host-cam-generic\" the per-bus mapping is never set up and the first config read dereferences a NULL base, crashing during bus enumeration: Unable to handle kernel NULL pointer dereference at virtual address 00000800 Oops [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 6.9.7+ #43 Hardware name: Digilent Nexys-Video-A7 RV32 (DT) epc : pci_generic_config_read+0x40/0xb0 ra : pci_generic_config_read+0x2c/0xb0 [] pci_generic_config_read+0x40/0xb0 [] pci_bus_read_config_dword+0x50/0xb0 [] pci_bus_generic_read_dev_vendor_id+0x3c/0x1ec [] pci_scan_single_device+0xa4/0x11c [] pci_scan_slot+0x9c/0x23c [] pci_scan_child_bus_extend+0x58/0x2f4 [] pci_scan_root_bus_bridge+0x64/0xe8 [] pci_host_probe+0x20/0xc8 [] pci_host_common_probe+0x144/0x1e4 Fix this by giving the CAM ops the same ->add_bus/->remove_bus callbacks. Since pci_ecam_add_bus() and pci_ecam_remove_bus() are static to ecam.c, move the CAM ops definition there as pci_generic_cam_ops (mirroring pci_generic_ecam_ops) and export it for pci-host-generic.c to reference. [mani: removed timestamp from log]", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2022-1205", "url": "https://ubuntu.com/security/CVE-2022-1205", "cve_description": "A NULL pointer dereference flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system.", "cve_priority": "high", "cve_public_date": "2022-08-31 16:15:00 UTC" }, { "cve": "CVE-2022-50303", "url": "https://ubuntu.com/security/CVE-2022-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix double release compute pasid If kfd_process_device_init_vm returns failure after vm is converted to compute vm and vm->pasid set to compute pasid, KFD will not take pdd->drm_file reference. As a result, drm close file handler maybe called to release the compute pasid before KFD process destroy worker to release the same pasid and set vm->pasid to zero, this generates below WARNING backtrace and NULL pointer access. Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step of kfd_process_device_init_vm, to ensure vm pasid is the original pasid if acquiring vm failed or is the compute pasid with pdd->drm_file reference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10", "cve_priority": "medium", "cve_public_date": "2025-09-15 15:15:00 UTC" }, { "cve": "CVE-2023-53320", "url": "https://ubuntu.com/security/CVE-2023-53320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info() The function mpi3mr_get_all_tgt_info() has four issues: 1) It calculates valid entry length in alltgt_info assuming the header part of the struct mpi3mr_device_map_info would equal to sizeof(u32). The correct size is sizeof(u64). 2) When it calculates the valid entry length kern_entrylen, it excludes one entry by subtracting 1 from num_devices. 3) It copies num_device by calling memcpy(). Substitution is enough. 4) It does not specify the calculated length to sg_copy_from_buffer(). Instead, it specifies the payload length which is larger than the alltgt_info size. It causes \"BUG: KASAN: slab-out-of-bounds\". Fix the issues by using the correct header size, removing the subtraction from num_devices, replacing the memcpy() with substitution and specifying the correct length to sg_copy_from_buffer().", "cve_priority": "low", "cve_public_date": "2025-09-16 17:15:00 UTC" }, { "cve": "CVE-2025-39726", "url": "https://ubuntu.com/security/CVE-2025-39726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ism: fix concurrency management in ism_cmd() The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that. This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well. A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it. On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.", "cve_priority": "high", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39779", "url": "https://ubuntu.com/security/CVE-2025-39779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: subpage: keep TOWRITE tag until folio is cleaned btrfs_subpage_set_writeback() calls folio_start_writeback() the first time a folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tag even if there are still dirty blocks in the folio. This can break ordering guarantees, such as those required by btrfs_wait_ordered_extents(). That ordering breakage leads to a real failure. For example, running generic/464 on a zoned setup will hit the following ASSERT. This happens because the broken ordering fails to flush existing dirty pages before the file size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode or for compressed writes, it locks several folios for delalloc and starts writing them out. Let's call the last locked folio folio X. Suppose the write range only partially covers folio X, leaving some pages dirty. Process A calls btrfs_subpage_set_writeback() when building a bio. This function call clears the TOWRITE tag of folio X, whose size = 8K and the block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range. Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. It calls tag_pages_for_writeback() to tag dirty folios with PAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then, B collects tagged folios using filemap_get_folios_tag() and must wait for folio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE) However, between tagging and collecting, process A may call btrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY) As a result, process B won't see folio X in its batch, and returns without waiting for it. This breaks the WB_SYNC_ALL ordering requirement. Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retains the TOWRITE tag. We now manually clear the tag only after the folio becomes clean, via the xas operation.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39810", "url": "https://ubuntu.com/security/CVE-2025-39810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix memory corruption when FW resources change during ifdown bnxt_set_dflt_rings() assumes that it is always called before any TC has been created. So it doesn't take bp->num_tc into account and assumes that it is always 0 or 1. In the FW resource or capability change scenario, the FW will return flags in bnxt_hwrm_if_change() that will cause the driver to reinitialize and call bnxt_cancel_reservations(). This will lead to bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc may be greater than 1. This will cause bp->tx_ring[] to be sized too small and cause memory corruption in bnxt_alloc_cp_rings(). Fix it by properly scaling the TX rings by bp->num_tc in the code paths mentioned above. Add 2 helper functions to determine bp->tx_nr_rings and bp->tx_nr_rings_per_tc.", "cve_priority": "low", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-37861", "url": "https://ubuntu.com/security/CVE-2025-37861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.", "cve_priority": "low", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-38643", "url": "https://ubuntu.com/security/CVE-2025-38643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() Callers of wdev_chandef() must hold the wiphy mutex. But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes: WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985", "cve_priority": "low", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38615", "url": "https://ubuntu.com/security/CVE-2025-38615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: cancle set bad inode after removing name fails The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted. The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's \"icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier\". In some it's outright \"we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles\".", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38361", "url": "https://ubuntu.com/security/CVE-2025-38361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check dce_hwseq before dereferencing it [WHAT] hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used. (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)", "cve_priority": "low", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38259", "url": "https://ubuntu.com/security/CVE-2025-38259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd9335: Fix missing free of regulator supplies Driver gets and enables all regulator supplies in probe path (wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup in final error paths and in unbind (missing remove() callback). This leads to leaked memory and unbalanced regulator enable count during probe errors or unbind. Fix this by converting entire code into devm_regulator_bulk_get_enable() which also greatly simplifies the code.", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38239", "url": "https://ubuntu.com/security/CVE-2025-38239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix invalid node index On a system with DRAM interleave enabled, out-of-bound access is detected: megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it accordingly.", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2022-50071", "url": "https://ubuntu.com/security/CVE-2022-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: move subflow cleanup in mptcp_destroy_common() If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE eBPF program, the MPTCP protocol ends-up leaking all the subflows: the related cleanup happens in __mptcp_destroy_sock() that is not invoked in such code path. Address the issue moving the subflow sockets cleanup in the mptcp_destroy_common() helper, which is invoked in every msk cleanup path. Additionally get rid of the intermediate list_splice_init step, which is an unneeded relic from the past. The issue is present since before the reported root cause commit, but any attempt to backport the fix before that hash will require a complete rewrite.", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2025-37920", "url": "https://ubuntu.com/security/CVE-2025-37920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: Fix race condition in AF_XDP generic RX path Move rx_lock from xsk_socket to xsk_buff_pool. Fix synchronization for shared umem mode in generic RX path where multiple sockets share single xsk_buff_pool. RX queue is exclusive to xsk_socket, while FILL queue can be shared between multiple sockets. This could result in race condition where two CPU cores access RX path of two different sockets sharing the same umem. Protect both queues by acquiring spinlock in shared xsk_buff_pool. Lock contention may be minimized in the future by some per-thread FQ buffering. It's safe and necessary to move spin_lock_bh(rx_lock) after xsk_rcv_check(): * xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers. * xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-43456", "url": "https://ubuntu.com/security/CVE-2026-43456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix type confusion in bond_setup_by_slave() kernel BUG at net/core/skbuff.c:2306! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306 RSP: 0018:ffffc90004aff760 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900 RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780 R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0 Call Trace: ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900 dev_hard_header include/linux/netdevice.h:3439 [inline] packet_snd net/packet/af_packet.c:3028 [inline] packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592 ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646 __sys_sendmsg+0x170/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe1a0e6c1a9 When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond, bond_setup_by_slave() directly copies the slave's header_ops to the bond device: bond_dev->header_ops = slave_dev->header_ops; This causes a type confusion when dev_hard_header() is later called on the bond device. Functions like ipgre_header(), ip6gre_header(),all use netdev_priv(dev) to access their device-specific private data. When called with the bond device, netdev_priv() returns the bond's private data (struct bonding) instead of the expected type (e.g. struct ip_tunnel), leading to garbage values being read and kernel crashes. Fix this by introducing bond_header_ops with wrapper functions that delegate to the active slave's header_ops using the slave's own device. This ensures netdev_priv() in the slave's header functions always receives the correct device. The fix is placed in the bonding driver rather than individual device drivers, as the root cause is bond blindly inheriting header_ops from the slave without considering that these callbacks expect a specific netdev_priv() layout. The type confusion can be observed by adding a printk in ipgre_header() and running the following commands: ip link add dummy0 type dummy ip addr add 10.0.0.1/24 dev dummy0 ip link set dummy0 up ip link add gre1 type gre local 10.0.0.1 ip link add bond1 type bond mode active-backup ip link set gre1 master bond1 ip link set gre1 up ip link set bond1 up ip addr add fe80::1/64 dev bond1", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2022-49858", "url": "https://ubuntu.com/security/CVE-2022-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix SQE threshold checking Current way of checking available SQE count which is based on HW updated SQB count could result in driver submitting an SQE even before CQE for the previously transmitted SQE at the same index is processed in NAPI resulting losing SKB pointers, hence a leak. Fix this by checking a consumer index which is updated once CQE is processed.", "cve_priority": "medium", "cve_public_date": "2025-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-22057", "url": "https://ubuntu.com/security/CVE-2025-22057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: decrease cached dst counters in dst_release Upstream fix ac888d58869b (\"net: do not delay dst_entries_add() in dst_release()\") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30 Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-22083", "url": "https://ubuntu.com/security/CVE-2025-22083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang: 1. Use-after-free when no tpgs are found: This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If a scsi request is then sent we do: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend which sees the vs_tpg we just did a kfree on. 2. Tpg dir removal hang: This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1. The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg. Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir. 3. Tpg leak: This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names. The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs. Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2024-58096", "url": "https://ubuntu.com/security/CVE-2024-58096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode ath11k_hal_srng_* should be used with srng->lock to protect srng data. For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock. So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319 So add srng->lock for them to avoid such warnings. Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct hal_srng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_process_rx(). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-21947", "url": "https://ubuntu.com/security/CVE-2025-21947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix type confusion via race condition when using ipc_msg_send_request req->handle is allocated using ksmbd_acquire_id(&ipc_ida), based on ida_alloc. req->handle from ksmbd_ipc_login_request and FSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion between messages, resulting in access to unexpected parts of memory after an incorrect delivery. ksmbd check type of ipc response but missing add continue to check next ipc reponse.", "cve_priority": "high", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2022-49562", "url": "https://ubuntu.com/security/CVE-2022-49562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing \"random\" pfns for pretty much any other VM_PFNMAP case.", "cve_priority": "low", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2025-21812", "url": "https://ubuntu.com/security/CVE-2025-21812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: rcu protect dev->ax25_ptr syzbot found a lockdep issue [1]. We should remove ax25 RTNL dependency in ax25_setsockopt() This should also fix a variety of possible UAF in ax25. [1] WARNING: possible circular locking dependency detected 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted ------------------------------------------------------ syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated---", "cve_priority": "high", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21801", "url": "https://ubuntu.com/security/CVE-2025-21801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ravb: Fix missing rtnl lock in suspend/resume path Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations. Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down", "cve_priority": "low", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-54683", "url": "https://ubuntu.com/security/CVE-2024-54683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: IDLETIMER: Fix for possible ABBA deadlock Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs: | ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20 | | but task is already holding lock: | ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v] | | which lock already depends on the new lock. A simple reproducer is: | #!/bin/bash | | while true; do | iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\" | iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\" | done & | while true; do | cat /sys/class/xt_idletimer/timers/testme >/dev/null | done Avoid this by freeing list_mutex right after deleting the element from the list, then continuing with the teardown.", "cve_priority": "medium", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2024-53220", "url": "https://ubuntu.com/security/CVE-2024-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to account dirty data in __get_secs_required() It will trigger system panic w/ testcase in [1]: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2752! RIP: 0010:new_curseg+0xc81/0x2110 Call Trace: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is if checkpoint_disabling and lfs_mode are both on, it will trigger OPU for all overwritten data, it may cost more free segment than expected, so f2fs must account those data correctly to calculate cosumed free segments later, and return ENOSPC earlier to avoid run out of free segment during block allocation. [1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2025-21759", "url": "https://ubuntu.com/security/CVE-2025-21759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: extend RCU protection in igmp6_send() igmp6_send() can be called without RTNL or RCU being held. Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection.", "cve_priority": "high", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57999", "url": "https://ubuntu.com/security/CVE-2024-57999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing. These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range. The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries Workqueue: events work_for_cpu_fn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100 LR [c00000000005e830] iommu_init_table+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620 [c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 There are 2 issues in the code 1. The index is \"int\" while the address is \"unsigned long\". This results in negative value when setting the bitmap. 2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well.", "cve_priority": "low", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57982", "url": "https://ubuntu.com/security/CVE-2024-57982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: state: fix out-of-bounds read during lookup lookup and resize can run in parallel. The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array. rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask; While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) { This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again). Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent. The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side. xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2022-49651", "url": "https://ubuntu.com/security/CVE-2022-49651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: srcu: Tighten cleanup_srcu_struct() GP checks Currently, cleanup_srcu_struct() checks for a grace period in progress, but it does not check for a grace period that has not yet started but which might start at any time. Such a situation could result in a use-after-free bug, so this commit adds a check for a grace period that is needed but not yet started to cleanup_srcu_struct().", "cve_priority": "low", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2022-49359", "url": "https://ubuntu.com/security/CVE-2022-49359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Job should reference MMU not file_priv For a while now it's been allowed for a MMU context to outlive it's corresponding panfrost_priv, however the job structure still references panfrost_priv to get hold of the MMU context. If panfrost_priv has been freed this is a use-after-free which I've been able to trigger resulting in a splat. To fix this, drop the reference to panfrost_priv in the job structure and add a direct reference to the MMU structure which is what's actually needed.", "cve_priority": "high", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2022-49234", "url": "https://ubuntu.com/security/CVE-2022-49234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: Avoid cross-chip syncing of VLAN filtering Changes to VLAN filtering are not applicable to cross-chip notifications. On a system like this: .-----. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-' '-1-2-' '-1-2-' Before this change, upon sw1p1 leaving a bridge, a call to dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1. In this scenario: .---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-' When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be called for sw2 and sw3 with a non-existing port - leading to array out-of-bounds accesses and crashes on mv88e6xxx.", "cve_priority": "medium", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2024-57945", "url": "https://ubuntu.com/security/CVE-2024-57945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Fix the out of bound issue of vmemmap address In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)). However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page. For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END. This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base.", "cve_priority": "low", "cve_public_date": "2025-01-21 13:15:00 UTC" }, { "cve": "CVE-2024-53210", "url": "https://ubuntu.com/security/CVE-2024-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct() Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skb_queue_purge() and WARN_ON in iucv_sock_destruct() during socket close. To fix this decrease skb refcount by one if MSG_PEEK is set in order to prevent memory leak and WARN_ON. WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53187", "url": "https://ubuntu.com/security/CVE-2024-53187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check for overflows in io_pin_pages WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2170108, 2170970, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168549, 2168549, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168510, 2168199, 2168214, 2107442, 2129861 ], "changes": [ { "cves": [ { "cve": "CVE-2025-68190", "url": "https://ubuntu.com/security/CVE-2025-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked() kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-46242", "url": "https://ubuntu.com/security/CVE-2026-46242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s \"*pprev = next\" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays.", "cve_priority": "high", "cve_public_date": "2026-05-30 13:16:00 UTC" }, { "cve": "CVE-2025-38349", "url": "https://ubuntu.com/security/CVE-2025-38349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: don't decrement ep refcount while still holding the ep mutex Jann Horn points out that epoll is decrementing the ep refcount and then doing a mutex_unlock(&ep->mtx); afterwards. That's very wrong, because it can lead to a use-after-free. That pattern is actually fine for the very last reference, because the code in question will delay the actual call to \"ep_free(ep)\" until after it has unlocked the mutex. But it's wrong for the much subtler \"next to last\" case when somebody *else* may also be dropping their reference and free the ep while we're still using the mutex. Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion. A mutex \"unlock\" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up. See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics: \t\"mutex_unlock() may access the mutex structure even after it has \t internally released the lock already - so it's not safe for \t another context to acquire the mutex and assume that the \t mutex_unlock() context is not using the structure anymore\" So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops _their_ reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it. Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole _point_ of refcounts: unlike mutexes, they are inherently about object lifetimes).", "cve_priority": "high", "cve_public_date": "2025-07-18 08:15:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-80726", "url": "https://ubuntu.com/security/CVE-2026-80726", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-46113", "url": "https://ubuntu.com/security/CVE-2026-46113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, \"KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE\", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the \"correct\" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the \"wrong\" shadow page. However, that was only an imprecision until 2032a93d66fa (\"KVM: MMU: Don't allocate gfns page for direct mmu pages\") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-52988", "url": "https://ubuntu.com/security/CVE-2026-52988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase Publish new hooks in the list into the basechain/flowtable using splice_list_rcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on.", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2023-53231", "url": "https://ubuntu.com/security/CVE-2023-53231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: Fix detection of atomic context Current check for atomic context is not sufficient as z_erofs_decompressqueue_endio can be called under rcu lock from blk_mq_flush_plug_list(). See the stacktrace [1] In such case we should hand off the decompression work for async processing rather than trying to do sync decompression in current context. Patch fixes the detection by checking for rcu_read_lock_any_held() and while at it use more appropriate !in_task() check than in_atomic(). Background: Historically erofs would always schedule a kworker for decompression which would incur the scheduling cost regardless of the context. But z_erofs_decompressqueue_endio() may not always be in atomic context and we could actually benefit from doing the decompression in z_erofs_decompressqueue_endio() if we are in thread context, for example when running with dm-verity. This optimization was later added in patch [2] which has shown improvement in performance benchmarks. ============================================== [1] Problem stacktrace [name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291 [name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi [name:core&]preempt_count: 0, expected: 0 [name:core&]RCU nest depth: 1, expected: 0 CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1 Hardware name: MT6897 (DT) Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4 [2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/", "cve_priority": "medium", "cve_public_date": "2025-09-15 15:15:00 UTC" }, { "cve": "CVE-2023-53707", "url": "https://ubuntu.com/security/CVE-2023-53707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1 The type of size is unsigned int, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later.", "cve_priority": "medium", "cve_public_date": "2025-10-22 14:15:00 UTC" }, { "cve": "CVE-2024-49568", "url": "https://ubuntu.com/security/CVE-2024-49568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg When receiving proposal msg in server, the fields v2_ext_offset/ eid_cnt/ism_gid_cnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2_ext_offset, once exceed the max value, there has the chance to access wrong address, and crash may happen. This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt before using them.", "cve_priority": "high", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2026-89560", "url": "https://ubuntu.com/security/CVE-2026-89560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation Whiteout objects are used in the upper layer of an OverlayFS to indicate that the file with this name does not exist in the unified view, even if it is present in one of the lower layer file systems. For the userspace implementations of OverlayFS (fuse-overlayfs), whiteout objects can be created from userspace as well: * mknod(2) with S_IFCHR and makedev(0, 0) * renameat2(2) with RENAME_WHITEOUT, creating the whiteout in the old place of the moved file. This commit guards whiteout creation in both of these cases with LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered character devices and are not bound to a driver. LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a whiteout object: creating one is the only S_IFCHR creation that the VFS exempts from CAP_MKNOD, so it is as unprivileged as creating a regular file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that expose a kernel interface [1]. For the mknod(2) case, introduce a Landlock erratum. The creation of whiteout objects through mknod(2) was previously guarded using LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using LANDLOCK_ACCESS_FS_MAKE_REG. For the renameat2(2) case, fix a bug: Before this commit, renameat2(2) with RENAME_WHITEOUT would create a directory entry even when all LANDLOCK_ACCESS_FS_MAKE_* rights were denied. This does not affect normal renames within layered OverlayFS mounts: When doing a regular rename() on a mounted fuse-overlayfs, it is the fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT, and only the Landlock domain of that daemon is checked there. Depends-on: 49c9e09d9610 (\"landlock: Fix handling of disconnected directories\") Depends-on: fe72ce6710cb (\"landlock: Add errata documentation section\") [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and add link(2) to the user doc]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2024-41062", "url": "https://ubuntu.com/security/CVE-2024-41062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bluetooth/l2cap: sync sock recv cb and release The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work \t l2cap_sock_release hci_acldata_packet \t l2cap_sock_kill l2cap_recv_frame \t sk_free l2cap_conless_channel \t l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.", "cve_priority": "high", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2022-50406", "url": "https://ubuntu.com/security/CVE-2022-50406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: iomap: fix memory corruption when recording errors during writeback Every now and then I see this crash on arm64: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dm_thin_pool dm_persistent_data XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296). dm_bio_prison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0 dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECT potentially unexpected fatal signal 6. nf_reject_ipv6 potentially unexpected fatal signal 6. ipt_REJECT nf_reject_ipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) ip_tables pc : 000003fd6d7df200 x_tables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wb_workfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseq_set+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : __filemap_set_wb_err+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseq_set+0x1c/0x100 __filemap_set_wb_err+0x24/0xe0 iomap_do_writepage+0x5e4/0xd5c write_cache_pages+0x208/0x674 iomap_writepages+0x34/0x60 xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: ---truncated---", "cve_priority": "low", "cve_public_date": "2025-09-18 16:15:00 UTC" }, { "cve": "CVE-2026-97523", "url": "https://ubuntu.com/security/CVE-2026-97523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close race between scheduler and state change The mptcp scheduler may race with subflow sockets state change: data transmission on the selected socket may fail and a later release could try to use mss_now reset to 0 for a divide operation. Address the issue by explicitly checking for the critical scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97524", "url": "https://ubuntu.com/security/CVE-2026-97524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid unneeded actions on subflow reset Once in a blue moon, the mptcp receive path can recursively call mptcp_data_ready() via state change under unlucky error conditions, and then try to hold the data lock again. Break the recursion loop explicitly checking for the exceptional condition. Add a new flag instead of using an existing one like 'closing', to exit early in subflow_state_change(), and explicitly flush the RX queue at reset time. This avoids unneeded processing to check for available data -- calling get_mapping_status() and more on a dying subflow -- but also in error reporting and worker scheduling. Note that we must consume the currently peeked skb before invoking mptcp_dss_corruption to avoid consuming it again after the eventual reset has freed it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-80833", "url": "https://ubuntu.com/security/CVE-2026-80833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ss support which is one of the only remaining ones. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. Also, it had a buffer overread bug in the line 'memcpy(ctx->seed, d + dlen, ctx->slen);'. There's no point in fixing these bugs separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80834", "url": "https://ubuntu.com/security/CVE-2026-80834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ce support which is one of the only remaining ones. Note that the sun8i-ce support for hwrng remains in place. That is the interface that actually matters. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. There's no point in fixing this separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-74496", "url": "https://ubuntu.com/security/CVE-2026-74496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Fix use-after-free in fou_create() fou_create() publishes struct fou through sk_user_data before adding the new FOU port to the per-netns list. If fou_add_to_port_list() fails, the error path frees fou while it is still reachable through sk_user_data. A concurrent receive can then dereference the freed object in fou_from_sock(). This ordering issue was previously noted in the linked discussion. The failure is reachable when local port 0 is requested. Each socket binds to a different ephemeral port, but fou_cfg_cmp() compares the requested port 0 and reports -EALREADY once an entry already exists. Release the tunnel socket before freeing fou so sk_user_data is cleared first, and defer reclamation with kfree_rcu() to protect concurrent RCU readers. This matches the lifetime handling in fou_release().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-93286", "url": "https://ubuntu.com/security/CVE-2026-93286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: appletalk: fix NULL pointer dereference in aarp_send_ddp() aarp_send_ddp() calls atalk_find_dev_addr(dev) in the LocalTalk fast path without checking for NULL. When the device has no AppleTalk interface configured (dev->atalk_ptr == NULL), this leads to a NULL pointer dereference at the at->s_net access. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:aarp_send_ddp (net/appletalk/aarp.c:552 (discriminator 2)) Call Trace: atalk_sendmsg (net/appletalk/ddp.c:1715) __sys_sendto (net/socket.c:2265 (discriminator 1)) __x64_sys_sendto (net/socket.c:2272) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Add a NULL check consistent with the other callers of atalk_find_dev_addr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93287", "url": "https://ubuntu.com/security/CVE-2026-93287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: reject oversized block transfers in the common path The SMBus block transfer length data->block[0] is validated in i2c_smbus_xfer_emulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbus_xfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked. Add an early validation in __i2c_smbus_xfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback runs. data->block[0] is filled in by the device on SMBus block reads, so the check is scoped to operations where the length is actually supplied by the caller. This is consistent with the existing -EINVAL convention in the emulated path and protects all downstream consumers at once: the smbus_write tracepoint, all native smbus_xfer driver implementations, and the emulated path. Two distinct bugs are fixed by this change: Bug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h) trace_smbus_write() fires before any validation and copies data->block[0]+1 bytes into a 34-byte event buffer. With block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221. BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91 Call Trace: __asan_memcpy+0x23/0x80 trace_event_raw_event_smbus_write+0x27c/0x530 __i2c_smbus_xfer+0x43a/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c) stub_xfer() implements .smbus_xfer directly and only clamps block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With block[0]=0xff and command=0 the loop accesses block[1+i] for i up to 254, far past the 34-byte union. UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44 index 34 is out of range for type '__u8 [34]' Call Trace: __ubsan_handle_out_of_bounds+0xd7/0x120 stub_xfer+0x1971/0x198f [i2c_stub] __i2c_smbus_xfer+0x306/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97931", "url": "https://ubuntu.com/security/CVE-2026-97931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: us122l: Prevent write upgrades for read mappings The hwdep mmap callback rejects read-buffer mappings that are initially writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ. A process that can open the hwdep node O_RDWR can later use mprotect() to make the mapping writable. The read allocation begins with struct usb_stream. Its read_size member is used by the fault handler to decide which pages belong to the read buffer. The read VMA intentionally remains expandable because pcm_usb_stream uses mremap() after reading that size. Changing read_size first can therefore map and access pages beyond the allocation. The same member is also consumed by usb_stream_free(), where changing it can make free_pages_exact() release pages outside the allocation. Clear VM_MAYWRITE for read-buffer mappings after rejecting an initially writable VMA. This keeps the separate output-buffer mapping writable while preventing later permission upgrades.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97568", "url": "https://ubuntu.com/security/CVE-2026-97568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: syncookies: remember the request backup flag Instead of using an uninitialised bit when copying the info in subflow_ulp_clone(). To fix this, no need to extend the join_entry structure: backup is coming from struct mptcp_subflow_request_sock, only one bit. Do the same here by using one bit for both.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97572", "url": "https://ubuntu.com/security/CVE-2026-97572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Propagate RX ring init failures in bnxt_init_nic() bnxt_init_rx_rings() returns an error when bnxt_alloc_one_rx_ring() fails, but bnxt_init_nic() discards that return value and calls bnxt_init_chip(), which enables TPA. If an allocation fails, this could leave rxr->rx_tpa[] partially zeroed and TPA would be enabled over an array with zeroed entries. This would lead to a zeroed DMA address being handed out if the agg_idx is translated to a SW index at a zeroed entry. Fix this by propagating the error out of bnxt_init_nic(). Both callers already check its return value and unwind with bnxt_free_skbs() and bnxt_free_mem(), which tolerate a partially initialized RX ring.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97573", "url": "https://ubuntu.com/security/CVE-2026-97573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset() bnxt_rx_ring_reset() frees the ring buffers and then reallocates them, ignoring the result. bnxt_alloc_one_rx_ring() can fail in bnxt_alloc_one_tpa_info_data(), which returns -ENOMEM on the first failed allocation and leaves the remaining rxr->rx_tpa[] entries zeroed. The error isn't propagated up, so the loop in bnxt_rx_ring_reset continues and at the end the code re-enables TPA with partially unallocated rx_tpa array. This means that when the agg_id from hardware is mapped to a SW index in rxr->rx_tpa[], an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by falling back to a global reset, which is what the existing code already does when other functions fail, but unlike the other failure cases this particular failure has to return because TPA can't be re-enabled since the allocation failed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97576", "url": "https://ubuntu.com/security/CVE-2026-97576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC tile counts The stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from column_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[] and use them as tile-loop bounds, but std_validate_compound() does not bound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling enabled whose tile counts exceed the uAPI array capacity, mirroring the existing compound-control range checks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97582", "url": "https://ubuntu.com/security/CVE-2026-97582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gpio-fan) Fix use-after-free in alarm work fan_alarm_irq_handler() queues fan_data->alarm_work, but nothing cancels it. fan_alarm_notify() dereferences fan_data and its hwmon device. On unbind, devres frees the interrupt, which only waits for the handler itself, and then releases the hwmon device and fan_data, so a pending fan_alarm_notify() can run after those frees. Replace INIT_WORK() with devm_work_autocancel(), registered before devm_request_irq(). The devres cleanup then frees the interrupt first, so no new work can be queued, and cancels the work while fan_data and the hwmon device are still alive. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97592", "url": "https://ubuntu.com/security/CVE-2026-97592", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done. Similar with the buffers which are part of the gcm_sg_walk structs from the variables gw_in and gw_out.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97596", "url": "https://ubuntu.com/security/CVE-2026-97596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reject invalid states in connection template sync records IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6 records.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97598", "url": "https://ubuntu.com/security/CVE-2026-97598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: bound automatic table ID allocation fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment (\"ip rule ... table 0\") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TABLE_MAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable. The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97601", "url": "https://ubuntu.com/security/CVE-2026-97601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97604", "url": "https://ubuntu.com/security/CVE-2026-97604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vfb: defer cleanup until the last reference FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114) Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489) unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97608", "url": "https://ubuntu.com/security/CVE-2026-97608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: unregister loggers before per-net teardown nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL lock nf_log_mutex find logger in loggers[][] net->nf.nf_loggers[pf] = logger unlock nf_log_mutex nf_log_unregister(logger) lock nf_log_mutex loggers[pf][type] = NULL unlock nf_log_mutex synchronize_rcu() module exit returns module core frees backend memory Later, a sysctl read or packet logging operation can dereference the stale per-net logger pointer. Fix this by unregistering the global logger backends before tearing down per-net state. Once the global registrations are gone, later writers can no longer rebind the logger. unregister_pernet_subsys() already waits for an RCU grace period after the pre-exit callback clears the per-net selection, while nf_log_unregister() continues to cover readers of the global logger table. Apply this ordering fix to both nf_log backends that combine per-net teardown with global logger registration.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97611", "url": "https://ubuntu.com/security/CVE-2026-97611", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix use-after-free of the flow table mask array tbl_mask_array_realloc() retires the old mask_array before it stops being reachable: \told = ovsl_dereference(tbl->mask_array); \tif (old) { \t\t... \t\tcall_rcu(&old->rcu, mask_array_rcu_cb); \t} \trcu_assign_pointer(tbl->mask_array, new); call_rcu() only waits for read-side critical sections already in flight. tbl->mask_array still points at old between the call_rcu() and the rcu_assign_pointer(), so a reader entering ovs_flow_tbl_lookup_stats() in that window picks up old in a fresh critical section that the pending grace period does not cover. tbl_mask_array_realloc() runs in process context under ovs_mutex, so the window is preemptible and can outlast the grace period. Then mask_array_rcu_cb() frees old before the swap runs: BUG: KASAN: slab-use-after-free in flow_lookup.constprop.0+0x2bf/0x2f0 Read of size 8 at addr ffff888020b3e018 by task poc/741 flow_lookup.constprop.0+0x2bf/0x2f0 ovs_flow_tbl_lookup_stats+0x4a3/0x5c0 ovs_dp_process_packet+0x19c/0x710 ovs_vport_receive+0x243/0x390 internal_dev_xmit+0x81/0x170 Freed by task 728: kfree+0x16a/0x4e0 rcu_core+0x853/0x1030 Publish the new array before retiring the old one. The kfree_rcu() that call_rcu() replaced ran after the swap.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97612", "url": "https://ubuntu.com/security/CVE-2026-97612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: clear inner_protocol when the last label is popped skb_mpls_push() records the pre-encapsulation network header once, gated on !skb->inner_protocol. skb_mpls_pop() never clears that record, so it outlives the encapsulation it describes. Open vSwitch can then re-push MPLS onto a packet whose inner_network_header still points at the older, deeper offset: push a label, pop every label, recirculate (ovs_flow_key_update() re-derives key->eth.type and resets network_header, but leaves inner_*), then push again. ovs_fragment() trusts the record: \tskb->network_header = skb->inner_network_header; so skb_network_offset() goes negative. The bound check is signed: \tif (skb_network_offset(skb) > MAX_L2_LEN) a negative offset passes it, and prepare_frag() widens the value: \tunsigned int hlen = skb_network_offset(skb); \tmemcpy(&data->l2_data, skb->data, hlen); which is a ~4GiB memcpy out of a 30-byte per-CPU buffer. Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8): BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 prepare_frag+0x3df/0x4e0 ovs_fragment+0x589/0x7e0 do_output+0x4ce/0x5e0 do_execute_actions+0x55d2/0x7b30 ovs_execute_actions+0xea/0x450 Same root-cause shape as commit 975b5b067f52 (\"ipv6: sr: restore network header before routing and forwarding\"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path. Clear inner_protocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/act_mpls.c is the only other skb_mpls_pop() caller and gets the same fix; sch_frag.c saves and restores inner_protocol around fragmentation in the same way OVS does.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97899", "url": "https://ubuntu.com/security/CVE-2026-97899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix memory leak in query_perf_config_list() When krealloc() fails, free the original oa_config_ids before returning to avoid a memory leak. (cherry picked from commit 9977e9d84f46d4f12ad35fbbc0ec4638554bce87)", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97904", "url": "https://ubuntu.com/security/CVE-2026-97904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: initialize policy rwsem before sysfs publication cpufreq_policy_alloc() initializes policy->rwsem after kobject_init_and_add() has created the policy sysfs directory and its default attributes. A sysfs access can therefore reach a policy callback before the semaphore has been initialized. Initialize policy->rwsem before publishing the policy kobject so sysfs callbacks always see an initialized semaphore.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97905", "url": "https://ubuntu.com/security/CVE-2026-97905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: zero-initialize policy cpumask before sysfs publication cpufreq_policy_alloc() allocates policy->cpus with alloc_cpumask_var(), i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate kmalloc_node() allocation, so its bitmap holds whatever the slab allocator left behind: cpufreq_online() cpufreq_policy_alloc() alloc_cpumask_var(&policy->cpus) /* bitmap is uninitialized */ kobject_init_and_add() /* policy%u/ appears in sysfs */ cpufreq_policy_online() cpumask_copy(policy->cpus, cpumask_of(cpu)) /* first valid value */ This leaves a window in which the sysfs attributes are already reachable while policy->cpus is still garbage. show()/store() gate on policy_is_inactive(), i.e. cpumask_empty(policy->cpus), so a non-zero bitmap makes them run the attribute callbacks on a policy that is not initialized yet. Fix this by using zalloc_cpumask_var() for policy->cpus.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97909", "url": "https://ubuntu.com/security/CVE-2026-97909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: initialize IRQ lock before requesting IRQ uni_reader_init() registers the shared IRQ before initializing reader->irq_lock. A pending interrupt can invoke the handler while the lock is still uninitialized. Initialize the lock before registering the IRQ so the interrupt path always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97910", "url": "https://ubuntu.com/security/CVE-2026-97910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sprd: validate compress buffer sizes against fixed allocations sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the fixed allocations. A fragment_size larger than the 32K IRAM data area makes the stage 0 copy_from_user() overflow past the IRAM allocation, and a buffer_size larger than the 2M DDR buffer makes the wrapping copy at the end of sprd_platform_compr_copy() write fully user controlled data past the buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP state reaches the copy callback directly. Reject parameters that do not fit into the fixed buffers in set_params(), and fix the advertised max fragment size: 128K never fitted into the 32K IRAM buffer. The caps values may have been carried over from the qdsp6 driver, which allocates its buffers according to the advertised maxima, unlike this driver. With 32K as max fragment size the advertised limits are self-consistent: 32K * 64 = 2M equals the DDR buffer size. Discovered by Atuin - Automated Vulnerability Discovery Engine.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97923", "url": "https://ubuntu.com/security/CVE-2026-97923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the var ref when its initialization fails create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 (\"tracing: Use hist trigger's var_ref array to destroy var_refs\") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it. The call was correct when it was written, before var refs were taken out of destroy_hist_field(). init_var_ref() cannot free it either. The caller owns the field, so init_var_ref() undoes only its own string allocations and leaves the field alone. Freeing it there would leave create_var_ref() passing freed memory to destroy_hist_field(), which reads its flags. Call __destroy_hist_field(), which frees the field without consulting the flag.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97926", "url": "https://ubuntu.com/security/CVE-2026-97926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: validate cylinder group metadata before caching it ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: \tucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); \tucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); \tucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); \tucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: - c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32 bit count outside the s_csp allocation. - c_frotor becomes a bitmap scan start, start = c_frotor >> 3, and then length = ((s_fpg + 7) >> 3) - start. A start beyond the block bitmap wraps the unsigned length to a huge value, so ubh_scanc() walks far past the cylinder group buffers. c_irotor drives the inode bitmap the same way. A crafted image can set any of these freely, turning an ordinary allocation into an out of bounds access. Reject a cylinder group whose recorded index does not match the group being read, or whose rotors fall outside the group, before the metadata is cached. Valid filesystems keep cg_cgx equal to the group number and the rotors within the group, so only malformed images are rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97927", "url": "https://ubuntu.com/security/CVE-2026-97927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: create the root dentry after loading cylinder metadata ufs_fill_super() installed sb->s_root before it loaded the cylinder group structures for a writable mount: \tsb->s_root = d_make_root(inode); \t... \tif (!sb_rdonly(sb)) \t\tif (!ufs_read_cylinder_structures(sb)) \t\t\tgoto failed; When ufs_read_cylinder_structures() failed, the error path freed the in-core superblock information and set sb->s_fs_info to NULL while sb->s_root stayed installed. get_tree_bdev() then reached deactivate_locked_super(), and because s_root was present, generic_shutdown_super() called sync_filesystem() and the put_super operation. Both dereference UFS_SB(sb), which is now NULL, so a mount that fails only while reading the cylinder groups oopses during teardown. A crafted image whose first cylinder group cannot be read reaches this path. Load the cylinder group metadata first and create the root dentry last, so the superblock is published to the VFS only once it is fully set up. ufs_setup_cstotal() and ufs_read_cylinder_structures() take only the super_block and do not use the root inode, so the reordering is safe.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97930", "url": "https://ubuntu.com/security/CVE-2026-97930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf The in04_last array in struct usx2ydev is declared as char[24], but in04_buf is allocated as sizeof(struct us428_ctls) which is 21 bytes. In i_usx2y_in04_int(), when ctl_snapshot_last == -2 (initialization path): memcpy(usx2y->in04_last, usx2y->in04_buf, sizeof(usx2y->in04_last)); This copies 24 bytes from a 21-byte slab allocation, reading 3 bytes past the end of the source object. Introduce a USX2Y_IN04_SIZE constant defined as sizeof(struct us428_ctls) and use it consistently for the in04_last array, the in04_buf allocation, the URB transfer length, and the comparison loop, replacing the bare 24 and 21 literals throughout.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97940", "url": "https://ubuntu.com/security/CVE-2026-97940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix fib6 walker UAF on seq stop ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a never-started iterator with a zeroed private object is not treated as linked. The same stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only widens the race.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97948", "url": "https://ubuntu.com/security/CVE-2026-97948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver The commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") refactored the EEH code such that the pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken. [<0>] 0xc00000011c78f870 [<0>] __switch_to+0xfc/0x1a0 [<0>] pci_lock_rescan_remove+0x30/0x44 [<0>] eeh_rmv_device+0x290/0x2e0 [<0>] eeh_pe_dev_traverse+0x80/0x130 [<0>] eeh_reset_device+0xcc/0x23c [<0>] eeh_handle_normal_event+0x830/0xa80 [<0>] eeh_event_handler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] start_kernel_thread+0x14/0x18 The issue is seen for cases where the errors are detected on the PHB directly AND|OR for devices where the driver error_detected() returns PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no error handlers like slot_reset(), resume() etc defined).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-74743", "url": "https://ubuntu.com/security/CVE-2026-74743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: inherit needed_headroom and needed_tailroom from lowerdev macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-89792", "url": "https://ubuntu.com/security/CVE-2026-89792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds reads in share config responses Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-97951", "url": "https://ubuntu.com/security/CVE-2026-97951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands When a LUN_RESET aborts a WRITE command that is in the TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and waits for the frontend to finish processing. If the initiator subsequently sends the remaining dataout PDUs, __iscsit_check_dataout_hdr() catches the payload, stops the dataout timer if the sequence is final and finally dumps the data. However, the iSCSI target doesn't trigger the completion process for these aborted commands. Because of this, the abort path hangs indefinitely in target_put_cmd_and_wait(), leading to a deadlocked target worker thread. Fix this by explicitly calling target_complete_cmd() when the final dataout PDU is received for an aborted WRITE command. target_complete_cmd() detects the CMD_T_ABORTED flag and cleanly routes the command into target_abort_work, allowing the abort completion to successfully unblock.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-97952", "url": "https://ubuntu.com/security/CVE-2026-97952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunvdc: unmap LDC cookies when the descriptor send fails __send_request() maps the request's pages into the LDC channel's map table (ldc_map_sg()), fills in the descriptor and marks it VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger(). When the trigger fails, the error path only prints a message: the descriptor stays READY and the cookies are never unmapped. The mapping is normally released in vdc_end_one() when the peer completes the descriptor - but a descriptor whose doorbell was never sent will never complete, and since dr->prod is not advanced on failure, the reset path (vdc_requeue_inflight(), which walks [cons, prod)) never visits it either. The map table entries are leaked permanently. Since commit a11f6ca9aef9 (\"sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN\") trigger failures occur in practice under load, so every resulting I/O error also leaks one request's worth of entries from the fixed-size (8192 entries per channel) map table. Because the allocator hands out contiguous ranges, fragmentation makes large multi-segment requests fail first as the table drains, until ldc_map_sg() fails permanently and the disk is dead until reboot. It also makes any retry-based recovery unusable: requeuing the request on -EAGAIN remaps the pages on every attempt, overwriting desc->cookies and orphaning the previous mapping, so the table drains at the retry rate. This is the memory exhaustion observed when the requeue approach was first tested in October 2025. Roll back on failure: unmap the cookies, mark the descriptor FREE again and clear the request entry. If the trigger failed with -ENOTCONN, __vdc_tx_trigger() has already reset the port, which tears down and reallocates both the dring and the LDC channel including its map table - nothing to roll back, and the stale descriptor must not be touched.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97954", "url": "https://ubuntu.com/security/CVE-2026-97954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix tcp stream corruption with large pages rds_message_map_pages() assigns PAGE_SIZE bytes to every scatterlist entry, even when total_len ends in a partial page. The RDS congestion map is defined as 8192 bytes, so on systems with PAGE_SIZE greater than 8192 the scatterlist maps bytes beyond the end of the congestion map. RDS-TCP transmits the SG contents according to those lengths, so the extra bytes become part of the TCP RDS stream and are interpreted as subsequent RDS message headers, corrupting the stream. Limit the final scatterlist mapping to the number of bytes remaining. This has no effect on systems with a 4K page size and allows RDS-TCP to be used on systems with 16K and larger page sizes. The RDS selftest, which previously hung on 16K pages, now passes.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97957", "url": "https://ubuntu.com/security/CVE-2026-97957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix mailbox segment buffer overflow check_mbox_seq_id_and_seg_len() validates that seq_id does not exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed MBOX_SEG_LEN (48). However, this allows the last segment (seq_id=42) to carry a full 48-byte payload, writing to offset 42*48=2016 for 48 bytes (ending at byte 2064). The receive buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a 16-byte heap buffer overflow. The hinic3 driver already handles this correctly by defining MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it exceeds the remaining buffer space. Apply the same fix to the hinic driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97958", "url": "https://ubuntu.com/security/CVE-2026-97958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain(). If a netlink socket sends RTM_GETCHAIN requests repeatedly without recv()ing the responses, tc_ctl_chain() hogs CPU and triggers Hung Task splat. [0] As caught in the stack trace, netlink_attachskb() could confuse tc_ctl_chain() by returning -EAGAIN when the userspace netlink socket's receive buffer is full. The replay: label exists since commit 32a4f5ecd738 (\"net: sched: introduce chain object to uapi\") but was not used initially. Since commit 9f407f1768d3 (\"net: sched: introduce chain templates\"), the label is needed for RTM_NEWCHAIN because tcf_proto_lookup_ops() may release RTNL to call request_module(). However, the replay logic is unnecessary for RTM_GETCHAIN. Let's apply the replay logic only for RTM_NEWCHAIN. [0]: INFO: task repro:1018 is blocked on a mutex likely owned by task repro:1022. task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 task_flags:0x400040 flags:0x00080000 Call Trace: ? clockevents_program_event (kernel/time/clockevents.c:372) ? pskb_expand_head (net/core/skbuff.c:615) ? skb_release_data (net/core/skbuff.c:1122) ? netlink_attachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/af_netlink.c:1232) ? __netlink_lookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/af_netlink.c:499) ? tc_chain_notify (net/sched/cls_api.c:3045) ? tc_chain_notify (./include/linux/skbuff.h:1384 net/sched/cls_api.c:3041) ? netlink_unicast (net/netlink/af_netlink.c:1335) ? rtnl_unicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985) ? tc_ctl_chain (net/sched/cls_api.c:3242) ? rtnetlink_rcv_msg (net/core/rtnetlink.c:7146) ? netlink_unicast (net/netlink/af_netlink.c:1354) ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:7177) ? netlink_rcv_skb (net/netlink/af_netlink.c:2556) ? netlink_unicast (net/netlink/af_netlink.c:1319) ? netlink_sendmsg (net/netlink/af_netlink.c:1900) ? __sock_sendmsg (net/socket.c:800) ? __sys_sendto (net/socket.c:2281) ? __x64_sys_sendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284) ? do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97959", "url": "https://ubuntu.com/security/CVE-2026-97959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_route: free emptied bucket on filter move route4_change can move an existing filter to a different top-level bucket: route4_set_parms recomputes the handle from TCA_ROUTE4_TO/ FROM/IIF, and the handle-mismatch check is gated on the 'new' flag, so for an existing filter the new handle may differ from the old one and land in a different bucket. When this happens, the filter is unlinked from the old bucket, but the bucket itself is never freed once it goes empty. The stale empty bucket remains in head->table[], causing route4_delete to report *last=false even after the last live filter is gone. That pins the empty tcf_proto and causes a leak. Fix this by refcounting the filters linked to a bucket and freeing the bucket when the count drops to zero. The existing scan in route4_delete goes away with it. The count is updated at all sites that link or unlink a filter during add, change and delete, and the bucket is dropped from head->table[] as soon as it reaches zero. Conditions to recreate the bug: CONFIG_NET_CLS_ROUTE4=y, CONFIG_NET_SCH_INGRESS=y, CONFIG_NET_CLS_ACT=y. tc qdisc replace dev lo clsact tc filter add dev lo ingress protocol ip pref 100 route from 1 to 1 tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \\ route from 1 to 2 tc filter del dev lo ingress protocol ip pref 100 handle 0x10002 \\ route from 1 to 2 tc filter show dev lo ingress | grep -c 'pref 100 route chain 0 '", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97963", "url": "https://ubuntu.com/security/CVE-2026-97963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: initialize ptp_lock at probe time priv->ptp_lock is only initialized in stmmac_ptp_register(), which runs during __stmmac_open(). However, the lock is also used while the interface is down and has never been opened: tc_taprio_configure() invokes the PTP gettime64() callback to compute the EST base time when offloading a TAPRIO schedule, and stmmac_get_time() takes priv->ptp_lock. Using an uninitialized rwlock is undefined behaviour. Move the rwlock_init() to __stmmac_dvr_probe(), together with the other private locks, so that ptp_lock is always valid regardless of the interface state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97964", "url": "https://ubuntu.com/security/CVE-2026-97964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_synctty: ensure a writeable skb header ppp_sync_txmunge() checks headroom before prepending the address and control bytes, but does not ensure that the skb header is writable. A received skb can reach this function through PPP channel bridging without passing through ppp_start_xmit(), which calls skb_cow_head(). For example, a PPPoE frame may share its buffer with a clone queued to an AF_PACKET socket. If it is bridged to a synchronous tty channel, the address/control bytes can overwrite data still visible to that socket. Use skb_cow_head() to ensure both sufficient headroom and a writable header.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97969", "url": "https://ubuntu.com/security/CVE-2026-97969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix clock leak and spurious timer in settimeout() msc313e_wdt_settimeout() unconditionally calls msc313e_wdt_start() which introduces two severe bugs: 1. If the watchdog is already active, calling start() again will increase the reference count of the clock again. However stop() is only called once, the reference count is unbalance. 2. If the watchdog is stopped, calling settimeout() will start the hardware timer accidentally. Factor out the register-writing logic into a helper function. Only call it in settimeout() if the watchdog is running. Otherwise, simply update `wdev->timeout`.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97970", "url": "https://ubuntu.com/security/CVE-2026-97970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Avoid division by zero clk_get_rate() could return 0. Avoid a division by zero panic.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97981", "url": "https://ubuntu.com/security/CVE-2026-97981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Count dropped frames as NAPI work The RX loop only consumes budget when it successfully delivers a frame. Error paths keep consuming descriptors without reducing the budget, so a stream of bad frames can process the entire receive ring in one poll. Move the budget accounting to a common end-of-frame path. This counts each completed frame as NAPI work whether it was delivered or dropped, matching the behavior of the vendor driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97982", "url": "https://ubuntu.com/security/CVE-2026-97982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Fix budget accounting The gmac_rx() function returns the remaining NAPI budget, but its caller treats the return value as the number of packets received. An idle poll therefore reports a full budget and remains scheduled. Return the number of received packets instead. Preserve the existing free queue refill accounting by adding that count directly; continuing to subtract it from the budget would invert the refill behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97991", "url": "https://ubuntu.com/security/CVE-2026-97991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim_blk: reject out-of-range sector starts vdpasim_blk_check_range() logs an invalid start sector but continues validating the request. The subsequent unsigned capacity subtraction can underflow and let an out-of-range buffer offset reach the data path. The invalid offset is used by three request paths. VIRTIO_BLK_T_OUT copies guest data to blk->buffer + offset through vringh_iov_pull_iotlb(), causing an out-of-bounds write in _copy_from_iter() or memcpy(). VIRTIO_BLK_T_IN copies from blk->buffer + offset to the guest through vringh_iov_push_iotlb(), causing an out-of-bounds read in _copy_to_iter(). VIRTIO_BLK_T_WRITE_ZEROES passes blk->buffer + offset to memset(), causing an out-of-bounds write. Reject starts at or beyond the capacity before the subtraction. Treat the capacity boundary as invalid because the IN and OUT paths round byte counts down to sectors for validation but later copy the original byte counts. A sub-sector request at the capacity boundary would otherwise still access past the end of the buffer. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97993", "url": "https://ubuntu.com/security/CVE-2026-97993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx vhost_vdpa_set_config_call() swaps the eventfd_ctx_fdget() return value into v->config_ctx before checking it, so on failure the field briefly holds an ERR_PTR: \tctx = fd == VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd); \tswap(ctx, v->config_ctx); \tif (!IS_ERR_OR_NULL(ctx)) \t\teventfd_ctx_put(ctx); \tif (IS_ERR(v->config_ctx)) { \t\tlong ret = PTR_ERR(v->config_ctx); \t\tv->config_ctx = NULL; \t\treturn ret; \t} Commit 0bde59c1723a (\"vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails\") added that clearing, and spelled out the invariant the rest of the file relies on: \"we consider 'v->config_ctx' valid if it is not NULL\". The window between the swap and the clearing still breaks it. vhost_vdpa_config_cb() only tests for NULL, so a config interrupt delivered inside the window hands the ERR_PTR to eventfd_signal(). Check the fd before installing it instead. That closes the window and matches how vhost_vring_ioctl() handles the same failure for the vq call fd. It also stops a rejected fd from tearing down a config interrupt that was working: until now the swap replaced the live context and put it, so after an EBADF the device silently stopped delivering config interrupts until userspace installed a new fd.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97995", "url": "https://ubuntu.com/security/CVE-2026-97995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_console: do not free control-out buffers on remove __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): \tfree_buf \tremove_vqs \tvirtcons_remove \tunbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97998", "url": "https://ubuntu.com/security/CVE-2026-97998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: cope with concurrent instance destruction Instances are refcounted. However, only memory release happens on the 1 -> 0 transition; the unlink from hashes can occur with any refcount. Uncooperative userspace can force a situation where a queue is pending for destruction from netlink event while a different socket with same portid processes an UNBIND request. With right timing, this will unhash the instance again: Oops: general protection fault, [..] Call Trace: nfulnl_recv_config+0x31a/0xd50 nfnetlink_rcv_msg+0x7c2/0xeb0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98006", "url": "https://ubuntu.com/security/CVE-2026-98006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev The epq_in_urb object belonging to the caiaq device is coupled within the struct snd_usb_caiaqdev. After usb_submit_urb(epq_in_urb, GFP_KERNEL) executes successfully, epq_in_urb is successfully added to the urbp_list queue of the dummy HCD driver (userspace specifies dummy_hcd as the HCD layer driver for the caiaq USB device). When init_card() calls snd_usb_caiaq_send_command() which subsequently fails due to a timeout, and proceeds to call snd_card_free() to release the card, the embedded ep1_in_urb object is also freed. When the dummy HCD driver detects that the URB has been unlinked, it returns the URB (by usb_hcd_giveback_urb()), which triggers [1]. Decouple the ep1_in_urb object from the struct snd_usb_caiaqdev and switch to using a pointer instead. Separately allocate and manage the memory for ep1_in_urb to prevent the release of the snd_card memory object from interfering with it. midi_out_urb has the same issue as ep1_in_urb and is handled in the same way. [1] BUG: KASAN: slab-use-after-free in usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 Write of size 4 at addr ffff88803cee1050 by task ktimers/1/29 Call Trace: usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 dummy_timer+0xaac/0x4d50 drivers/usb/gadget/udc/dummy_hcd.c:2019 __run_hrtimer kernel/time/hrtimer.c:2067 [inline] __hrtimer_run_queues+0x3eb/0xaf0 kernel/time/hrtimer.c:2124 hrtimer_run_softirq+0x1e1/0x2e0 kernel/time/hrtimer.c:2141 Allocated by task 36: snd_card_new+0x7b/0x110 sound/core/init.c:184 create_card sound/usb/caiaq/device.c:429 [inline] snd_probe+0x236/0x1af0 sound/usb/caiaq/device.c:544 Freed by task 36: snd_card_free_when_closed sound/core/init.c:630 [inline] snd_card_free+0x138/0x1d0 sound/core/init.c:662 snd_probe+0x162b/0x1af0 sound/usb/caiaq/device.c:553", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98009", "url": "https://ubuntu.com/security/CVE-2026-98009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: clamp quantum in parse and fallback paths ets_qdisc_change() falls back to psched_mtu() with no floor for bands without an explicit quantum. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so a zero psched_mtu on a headerless device makes the deficit-refill loop spin under the qdisc lock. Move the floor into ets_quantum_parse() so explicitly configured quanta are also clamped to [256, 1<<20], not just the fallback path. Conditions to recreate the bug: CONFIG_NET_SCH_ETS=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root ets bands 3 strict 2 quanta 1 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98010", "url": "https://ubuntu.com/security/CVE-2026-98010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: drr: clamp quantum in change class drr_change_class() rejects explicit quantum==0 but falls back to psched_mtu() with no floor. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 (or a zero psched_mtu on a headerless device) makes the deficit-refill loop spin under the qdisc lock. Add clamp_t(u32, quantum, 256, 1<<20) after the zero reject and on the fallback path. The explicit-zero reject is preserved. Conditions to recreate the bug: CONFIG_NET_SCH_DRR=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root drr tc class add dev dummy0 parent 1: classid 1:1 drr quantum 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98011", "url": "https://ubuntu.com/security/CVE-2026-98011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum in change and init paths hhf_change() accepts any quantum from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) in hhf_change() matching fq_codel_change(). Clamp hhf_init() to [256, 1<<20] matching the siblings, and remove the old fallback that only set quantum=256 on overflow. Conditions to recreate the bug: CONFIG_NET_SCH_HHF=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root hhf tc qdisc change dev dummy0 root hhf quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98012", "url": "https://ubuntu.com/security/CVE-2026-98012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum in change path sfq_change() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and the init clamp. Conditions to recreate the bug: CONFIG_NET_SCH_SFQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root sfq tc qdisc change dev dummy0 root sfq quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98013", "url": "https://ubuntu.com/security/CVE-2026-98013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp quantum in change path fq_pie_change() accepts any quantum value from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Conditions to recreate the bug: CONFIG_NET_SCH_FQ_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq_pie tc qdisc change dev dummy0 root fq_pie quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98014", "url": "https://ubuntu.com/security/CVE-2026-98014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch, prevent mc_list repopulation during vport disable In mlx5_esw_vport_disable(), move esw_apply_vport_rx_mode() ahead of esw_vport_change_handle_locked() so vport->allmulti_rule is NULL before the change handler observes it. During FW-fatal recovery the disable runs while dev->state == INTERNAL_ERROR. The promisc query inside esw_update_vport_rx_mode() fails and returns early, leaving vport->allmulti_rule intact, so esw_update_vport_mc_promisc() runs and adds MLX5_ACTION_ADD entries to vport->mc_list whose flow rules are then installed in the FDB by esw_add_mc_addr(). esw_destroy_legacy_table() tears down the FDB with those refs still held, corrupting the sub-tree and leaving dangling flow_rule pointers in vport->mc_list. Two-stage failure on `echo 1 > /sys/bus/pci/devices//reset`: refcount_t: underflow; use-after-free. tree_put_node+0xef/0x110 [mlx5_core] clean_tree+0x44/0xd0 [mlx5_core] (x5) mlx5_fs_core_cleanup+0x57/0x1c0 [mlx5_core] mlx5_unload+0x65/0xd0 [mlx5_core] ... mlx5_health_try_recover BUG: unable to handle page fault for address: 0000000003000055 down_write+0x1c/0x60 mlx5_del_flow_rules+0x33/0x1f0 [mlx5_core] esw_del_mc_addr+0x7b/0x170 [mlx5_core] esw_apply_vport_addr_list+0x56/0xf0 [mlx5_core] esw_vport_change_handle_locked+0x28b/0x310 [mlx5_core] mlx5_esw_vport_enable+0x270/0x4a0 [mlx5_core] ... mlx5_load ... mlx5_health_try_recover esw_apply_vport_rx_mode(false, false) clears vport->allmulti_rule via its local state machine even when the FW del fails. With the rule NULL the !IS_ERR_OR_NULL(allmulti_rule) gate in the change handler closes, no rules are installed during disable, and the reload starts with a clean mc_list.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98015", "url": "https://ubuntu.com/security/CVE-2026-98015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put In mlx5_eswitch_termtbl_put(), the zero-ref cleanup check reads tt->ref_count after termtbl_mutex has been released. Two concurrent callers on the same mlx5_termtbl_handle race: one decrements ref_count to zero, removes the hash entry, and calls kfree(tt) while the other has already dropped the mutex and is about to evaluate if (!tt->ref_count), producing a use-after-free. Fix this by capturing the result of the decrement into a stack-local last variable before dropping the mutex. The cleanup decision is now made entirely under termtbl_mutex, and tt is not touched after kfree.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98016", "url": "https://ubuntu.com/security/CVE-2026-98016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free race in sample_restore_put() Concurrent teardown of TC sample rules sharing the same restore context may re-read restore->count after dropping restore_lock. At that point another thread may already have completed cleanup and freed the restore object. Use the result of the refcount decrement while holding restore_lock to determine whether cleanup is needed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98022", "url": "https://ubuntu.com/security/CVE-2026-98022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations Several subsystems allocate ring buffers sized by dev->tx_queue_len with no upper bound. An unprivileged user (via unshare -Urn) can set a huge tx_queue_len and exhaust global memory with ring allocations: - pfifo_fast: pfifo_fast_init() and pfifo_fast_change_tx_queue_len() allocate 3 skb_array rings of tx_queue_len entries each. - tun: tun_queue_resize() and the queue-attach path resize ptr_rings to tx_queue_len on the NETDEV_CHANGE_TX_QUEUE_LEN notifier. - tap (macvtap/ipvtap): tap_queue_resize() and tap_init() resize/init ptr_rings to tx_queue_len on the same notifier. netif_change_tx_queue_len() is the single entry point for IFLA_TXQLEN, sysfs, and the SIOCSIFTXQLEN ioctl. Cap new_len at S16_MAX (32767) there so the oversized value is rejected at set time. This takes effect whether the device is up or down, before dev->tx_queue_len is written, before any notifier fires, and before any ring is allocated. The \"> S16_MAX\" check also subsumes the previous unsigned-long truncation test, and a negative ifr_qlen from the ioctl lands far above the cap after conversion, so both old failure modes are covered by the one comparison. tx_queue_len is ambigious: both a per-ring sizing multiplier and a default queue-length/limit knob for consumers that allocate nothing at set time (pfifo/bfifo/gred/plug/sfb limits, htb direct_qlen, qfq max_classes, teql). 32767 is chosen as the largest value NLA_POLICY_FULL_RANGE can express for the u32 IFLA_TXQLEN policy in patch 2/3 while staying a legitimate queue length on high-BDP paths; the ring-memory trade-off of a shared knob is disclosed below. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn). - pfifo_fast: create veth pairs, set tx_queue_len to 500000, attach mq+pfifo_fast. ~28 iterations OOMs a 2GB guest. - tun: create 50 tun devices with IFF_MULTI_QUEUE, set tx_queue_len to 500000, open 8 queues each. ~1.6GB of ptr_ring allocations OOMs a 512MB guest. - tap: same as tun with IFF_TAP. ~960MB OOMs a 512MB guest. - On the fixed kernel the oversized tx_queue_len is rejected with -ERANGE at set time (all four paths: RTM_SETLINK, RTM_NEWLINK create, sysfs, ioctl - the latter two via this check, the former two via this check and the 2/3 parse policy respectively).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98023", "url": "https://ubuntu.com/security/CVE-2026-98023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: reject dynamic fdb entries that reference a nexthop id The commit cited in the Fixes tag allowed VXLAN FDB entries to point to FDB nexthops so that overlay traffic could be load balanced across multiple VTEPs. Such entries can only be configured from user space, cannot be learned and cannot roam. They only make sense with a user space control plane such as E-VPN where data plane learning is disabled. Despite that, the VXLAN driver does not currently prevent such entries from being configured with the \"dynamic\" flag. The per-nexthop FDB list is only protected by the per-device hash lock, which is not sufficient when two VXLAN devices point to the same FDB nexthop and therefore share the list. Aging runs in softirq context without RTNL, so an entry deleted by one device can race with an addition or deletion from the other, leading to list corruption: list_del corruption. next->prev should be ffff8881069d9548, but was dead000000000122. (next=ffff8881069d9448) WARNING: CPU: 0 PID: 90 at lib/list_debug.c:65 __list_del_entry_valid_or_report+0x1aa/0x210 ... vxlan_fdb_destroy+0x5b8/0xad0 vxlan_cleanup+0x328/0x450 call_timer_fn+0x2a/0x1c0 run_timer_softirq+0x18c/0x210 BUG: KASAN: slab-use-after-free in vxlan_fdb_destroy Fix this by rejecting the bogus configuration of dynamic FDB entries that point to FDB nexthops, both when created and when an existing entry is updated. As such, the per-nexthop FDB list is only ever mutated under the RTNL lock. Add test cases to make sure that this does not regress in the future.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98025", "url": "https://ubuntu.com/security/CVE-2026-98025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is \t} else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB \"frame\" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98027", "url": "https://ubuntu.com/security/CVE-2026-98027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer size mv88e6xxx_get_rxnfc() uses rxnfc->rule_cnt as the write index while dumping the policy IDR, clobbering the input value before it has been looked at. That input is the number of entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed policy rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Count into a local so the caller's limit survives the walk, and stop with -EMSGSIZE once it is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98030", "url": "https://ubuntu.com/security/CVE-2026-98030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size bcm_sf2_cfp_rule_get_all() walks the whole cfp.unique bitmap into rule_locs[] without consulting nfc->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed CFP rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98031", "url": "https://ubuntu.com/security/CVE-2026-98031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: Initialize extack in remove_nh_grp_entry() remove_nh_grp_entry() prints the extack message when a listener fails to replace the reduced nexthop group. However, extack is not initialized and listeners are not required to set a message when returning an error. Neither netdevsim nor mlxsw do so when an allocation fails, resulting in the dereference of an uninitialized stack pointer. Fix by zero-initializing extack, as was done in commit 6347c5314cee (\"nexthop: initialize extack in nh_res_bucket_migrate()\").", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98063", "url": "https://ubuntu.com/security/CVE-2026-98063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref in btf_var_show() btf_var_show() calls btf_type_id_resolve() unconditionally, which dereferences btf->resolved_ids. That is NULL for a base BTF - e.g. the vmlinux BTF that bpf_snprintf_btf() renders against - since base BTF is not resolved during parsing. btf_modifier_show() guards this with 'if (btf->resolved_ids)', but btf_var_show() does not. A BPF program that passes the type_id of a BTF_KIND_VAR from the vmlinux BTF to bpf_snprintf_btf() thus NULL-derefs: KASAN: probably user-memory-access in range [0x46638-0x4663f] RIP: 0010:btf_var_show (kernel/bpf/btf.c:2929) Call Trace: btf_type_show (kernel/bpf/btf.c:8259) btf_type_snprintf_show (kernel/bpf/btf.c:8329) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Resolve the var's type directly with btf_type_skip_modifiers() when resolved_ids is NULL, mirroring btf_modifier_show().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98064", "url": "https://ubuntu.com/security/CVE-2026-98064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref when showing a void BTF type btf_modifier_show() resolves the modifier and then calls btf_type_ops(t)->show() unconditionally. For the void type (type_id 0, BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL. A \"const void\" (a modifier resolving to void) cannot be a map key or value - map_check_btf() rejects it because void has no size - so the map dump path does not reach it. But bpf_snprintf_btf() takes a type_id straight from the BPF program, and passing such a \"const void\" from the vmlinux BTF NULL-derefs: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:btf_modifier_show (kernel/bpf/btf.c:2914) Call Trace: btf_type_show (kernel/bpf/btf.c:8251) btf_type_snprintf_show (kernel/bpf/btf.c:8321) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fall back to btf_df_show() when the resolved type has no show op; it emits the \"\" placeholder already used for kinds like FWD and FUNC. bpf_snprintf_btf() then returns the length as usual.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98066", "url": "https://ubuntu.com/security/CVE-2026-98066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Fix potential double-free at error path The fix for caiaq driver's resource management to handle the errors tries to release the resources in a common destructor call, but as a sashiko review for another patch suggested, some of the audio resources such as URBs have been already freed, and this may lead to a double-free. For addressing the double-free, call the common destructor function from each place, and assure that the resource pointers get cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98068", "url": "https://ubuntu.com/security/CVE-2026-98068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: don't let rds_conn_shutdown() consume a concurrent drop rds_conn_shutdown() finishes by moving the path from RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts RDS_CONN_ERROR as the starting state of that final transition, so that a FIN processed in softirq context during the teardown does not derail the shutdown into a noisy error path. But consuming that RDS_CONN_ERROR also consumes the shutdown pass that came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN is a no-op. For the FIN case that is harmless - the socket the FIN arrived on is the very socket the teardown just released. It is not harmless for a dropper that attached something to the path first. rds_tcp_accept_one() is such a dropper. Its path claim in rds_tcp_accept_one_path() transitions RDS_CONN_DOWN -> RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous socket in softirq context, an administrative reset - can put the path into RDS_CONN_ERROR between that claim and the state check that follows, which accepts RDS_CONN_ERROR. The accept then installs the freshly accepted socket with rds_tcp_set_callbacks() while the queued teardown - which sampled tc->t_sock before this socket existed - is still running. rds_connect_path_complete() fails its transition to RDS_CONN_UP and drops the path again, queueing the pass that should reap the socket it just installed. If the in-flight shutdown's final transition consumes that drop's RDS_CONN_ERROR, the queued pass finds the path in RDS_CONN_DOWN and does nothing. The installed socket is never torn down: it sits established with its callbacks armed and its rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some later event drops it again. Reproduced with widened race windows as an ever-growing receive queue on a socket owned by a path stuck in RDS_CONN_DOWN, with the peer's send path wedged behind it. Make the final transition only DISCONNECTING -> DOWN. If it fails because the path is in RDS_CONN_ERROR, a drop raced the teardown: cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one piece of the skipped tail that must not be left behind - and return, letting the pass the drop queued finish the job: it tears down whatever attached to the path in the meantime, completes the transition to RDS_CONN_DOWN, and re-arms the reconnect from its own tail. The timer quiesce in that branch matters because the racing drop does not always queue that pass: rds_conn_path_drop() returns without queueing when a destroy is pending - exactly the situation during a netns teardown or module unload, when a FIN on the dying socket is processed while rds_conn_path_destroy() flushes cp_down_w. If the flushed pass is the one that takes this return, no later pass exists, and rds_conn_path_destroy() would find cp_conn_w still armed (WARN_ON) and then free a path whose reconnect timer can still fire. With the cancel in the branch, every exit of a shutdown pass leaves the timer quiesced no matter which pass completes the transition. The FIN case keeps making progress, one pass later and still without noisy logging. Any other state keeps today's rds_conn_path_error() handling; no current cp_state writer can leave a DISCONNECTING path in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from a non-DISCONNECTING state), so that branch is defensive. On kernels without the preceding patches the same hazard exists with the sample-based quiesce; the fix applies there equally.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98069", "url": "https://ubuntu.com/security/CVE-2026-98069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire the fastpath locks in rds_conn_shutdown() rds_conn_shutdown() quiesces the transmit and receive-refill paths by waiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and then runs the transport shutdown and rds_conn_path_reset(). Sampling the bits clear is not the same as owning them: the moment after the wait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or rds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run concurrently with the teardown. The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the transmit state under it. Oracle UEK fixed the same class of crashes - a 14-year tail of BUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL dereferences in rds_ib_send_cqe_handler() during failover testing - by making the teardown path *acquire* the fastpath bit locks instead of testing them (\"rds: Make sure transmit path and connection tear-down does not run concurrently\"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed. Do the same here: take both locks before calling the transport shutdown, hold them across rds_conn_path_reset(), and release them explicitly with a wake-up afterwards. Both are released with clear_bit_unlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rds_send_path_reset() are ordered before either bit is seen clear by the next acquire_in_xmit() or acquire_refill(). The fastpath users of these bits - rds_send_xmit() and rds_ib_recv_refill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rds_tcp_reset_callbacks() is different: since the previous patch it acquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rds_tcp_accept_one() on the single-threaded krdsd workqueue and holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown(). An IB path's drain in rds_ib_conn_path_shutdown() has no round cap, but no blocking waiter either: rds_tcp_reset_callbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDS_CONN_DISCONNECTING. Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on the path's ordered cp_wq, whose only execution slot is occupied by the blocked cp_down_w itself, so they are pending at most and cancel without flushing - a reliance on cp_wq being ordered that is now noted next to those cancels (on ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98070", "url": "https://ubuntu.com/security/CVE-2026-98070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks() rds_tcp_reset_callbacks() quiesces the transmit path by setting the path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to be sampled clear before swapping the underlying socket and calling rds_send_path_reset(). Sampling the bit clear is not the same as owning it: rds_send_xmit() can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its state recheck after taking the lock is a store-buffering pattern (the resetter writes the state and reads the bit, the sender writes the bit and reads the state) and acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write and the transmit path then runs concurrently with rds_send_path_reset() rewriting cp_xmit_* state - which is exactly what the comment above rds_send_path_reset() tells its callers to prevent. Take the lock instead, hold it across the socket swap and rds_send_path_reset(), and release it with a wake-up at the end. The lock-ordering constraint documented above the wait still holds: the lock is acquired before lock_sock(), so a sender inside tcp_sendmsg() can never be waited on while we hold the socket lock. Two details of the old code go away with the same change: - t_sock is now read only after the lock is acquired. The old code cached it before waiting; the teardown in rds_conn_shutdown() releases that socket and clears t_sock, so a pointer cached before the wait can be stale by the time the accept path resumes. Reading it under RDS_IN_XMIT is what makes the exclusion complete once the teardown owns the same lock, which the next patch arranges; until then the teardown still only samples the bit, and the two paths remain as exposed to each other as they are today. - The old !osock early path called rds_send_path_reset() with no serialization at all. It now runs under the lock like the normal path. The conditional RDS_CONN_RESETTING transition of the previous patch happens before the socket check either way: a path found without a socket is either still connecting (its reconnect worker blocked on t_conn_path_lock) and legitimately goes RESETTING -> UP on the new socket, or it has been torn down meanwhile and is dropped. The in-function comment describing the old wait-based quiesce is rewritten to describe the lock-based one, and the stale block comment above the function (which still described a return value and an incomplete list of t_sock writers) is refreshed to name all four writers - the connect, accept, teardown and swap paths - and what serializes each of them.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98071", "url": "https://ubuntu.com/security/CVE-2026-98071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: clear cp_flags bits individually in rds_conn_path_reset() rds_conn_path_reset() wipes the whole flag word with a plain cp->cp_flags = 0 store. Every other accessor of that word uses atomic bitops, and some of them can run concurrently with the reset: RDS_LL_SEND_FULL is set from rds_send_xmit() and cleared from the transport completion paths, neither of which holds anything that excludes the shutdown worker. A plain store racing an atomic read-modify-write on the same word is a data race, and whichever side loses has its update silently discarded. Clear the two bits the reset is actually responsible for instead. RDS_IN_XMIT and RDS_RECV_REFILL need no store at all here: they belong to the caller, rds_conn_shutdown(), which waits for both to be clear before calling the transport shutdown and this reset. This also gives every bit in cp_flags a single well-defined writer discipline, which the following patches rely on when they turn RDS_IN_XMIT and RDS_RECV_REFILL into bit locks held across the teardown: a blanket store mid-teardown would destroy lock ownership that an atomic clear preserves. Oracle UEK carries the same conversion (\"net/rds: Preserve essential connection state flags\"), motivated by its asynchronous shutdown state machine, whose progress and destroy flags must survive the reset. UEK's variant also clears RDS_IN_XMIT and RDS_RECV_REFILL because there the reset runs as the final step of a teardown that owns both bits, making those clears its unlock. Upstream that release belongs in rds_conn_shutdown(): once a later patch in this series turns the two bits into locks held across the teardown, ending ownership needs release semantics and a wake-up that a plain clear inside the reset would not provide. Based on Oracle UEK commit \"net/rds: Preserve essential connection state flags\" by Gerd Rausch.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98072", "url": "https://ubuntu.com/security/CVE-2026-98072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in release_in_xmit() release_in_xmit() clears RDS_IN_XMIT with clear_bit_unlock() and then checks waitqueue_active() to decide whether anyone needs waking. clear_bit_unlock() is only a release operation: it orders the critical section before the bit clear, but does not order the subsequent plain load of the wait queue head after it. The waiter side does the mirror image - it adds itself to the wait queue and then tests the bit. That is the classic store-buffering pattern: the releasing CPU can read the wait queue as empty while the waiting CPU still reads the bit as set, so the sleeper is never woken. The waiters are rds_conn_shutdown() and rds_tcp_reset_callbacks(), both in uninterruptible wait_event() with no timeout. A lost wake-up strands the shutdown worker on its single-threaded workqueue until some other sender releases the bit again - and on a connection that is being torn down precisely because it failed, there may never be another sender. The barrier used to be there: release_in_xmit() did clear_bit() followed by smp_mb__after_atomic() until commit 1422f28826d2 (\"rds: introduce acquire/release ordering in acquire/release_in_xmit()\") folded both into clear_bit_unlock(), which strengthened the lock hand-off but silently dropped the full barrier the wake-up check depends on. The refill counterpart, release_refill() in net/rds/ib_recv.c, still carries its smp_mb__after_atomic() for exactly this reason. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98074", "url": "https://ubuntu.com/security/CVE-2026-98074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: do not clear curr_active_slave prematurely when releasing all slaves When releasing all slaves during bond destruction (all == true), __bond_release_one() unconditionally clears bond->curr_active_slave to NULL in every iteration. If a backup slave is released before the active slave, bond_alb_deinit_slave() triggers rlb_teach_disabled_mac_on_primary(), which increments the active slave dev promiscuity counter and sets bond_info->primary_is_promisc = 1. Because bond->curr_active_slave was prematurely cleared to NULL when releasing the backup slave, the subsequent iteration releasing the active slave evaluates oldcurrent as NULL, so bond_change_active_slave(bond, NULL) is skipped. Consequently, bond_alb_handle_active_change() is never called to decrement the promiscuity counter, permanently leaking promiscuous mode on the physical device after bond teardown. When oldcurrent == slave, bond_change_active_slave(bond, NULL) already sets bond->curr_active_slave to NULL. We only need to avoid selecting a new active slave when all == true. Replace the if (all) branch with if (!all && oldcurrent == slave).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98075", "url": "https://ubuntu.com/security/CVE-2026-98075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject BPF_PSEUDO_FUNC reference to the main program fixups.c:jit_subprogs() rewrites BPF_PSEUDO_FUNC loads to contain real function addresses. This function is invoked from bpf_jit_subprogs() only when env->subprog_cnt > 1. Meaning that for any program like below: int main(void *ctx) { void *ptr = main; ... bpf_timer_set_callback(..., ptr); ... } The 'ptr' won't be ever converted to contain an address. In combination with e.g. bpf_timer_set_callback() this would lead to a function call at a bogus address. Instead of complicating the implementation, just assume that no useful program needs main to be a sync or async callback and reject BPF_PSEUDO_FUNC loads for the main subprogram.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98076", "url": "https://ubuntu.com/security/CVE-2026-98076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/probes: Fix use-after-free on field name/type of events with multiple probes The fields of a probe-based dynamic event (kprobe, uprobe, eprobe and fprobe events) are created in traceprobe_define_arg_fields() by handing the probe_arg name/type strings to trace_define_field(), which only stores the pointers without copying. Those strings are owned by the trace_probe and are freed when that probe is removed. An event can have several probes attached. The field list is defined only once, by the first probe that registers the event, but it is kept alive by any surviving sibling probe. Deleting just that first probe by symbol - # primary A: fields are defined from A's args echo 'p:kprobes/ev vfs_read a1=$arg1' > kprobe_events # append B: shares A's event call echo 'p:kprobes/ev vfs_write a1=$arg1' >> kprobe_events # delete only A (matched by symbol), B survives echo '-:kprobes/ev vfs_read' >> kprobe_events frees A's args (trace_probe_cleanup() -> traceprobe_free_probe_arg()), but trace_probe_unlink() keeps the trace_probe_event because the probe list is not empty. The event call stays registered via B while its fields now reference freed memory. Any field lookup then reads it, e.g. echo 'a1 == 1' > events/kprobes/ev/filter BUG: KASAN: slab-use-after-free in strcmp+0xa7/0xb0 Call Trace: strcmp trace_find_event_field parse_pred process_preds create_filter apply_event_filter event_filter_write field->name references parg->name (kstrdup'd, freed with the probe) and, for array arguments, field->type references parg->fmt (kmalloc'd, freed with the probe) - the scalar type otherwise points at the static fmttype rodata, which is safe. Have traceprobe_define_arg_fields() duplicate the name and type strings and anchor the copies on the trace_probe_event, which embeds the event call and outlives every individual probe; trace_probe_event_free() releases them. The reproducer above triggers reliably; the field lookup and the delete both run under event_mutex, so this is a dangling reference after removal rather than a race. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98077", "url": "https://ubuntu.com/security/CVE-2026-98077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace() sip_skip_whitespace() returns dptr unchanged when its own loop exhausts the buffer (dptr == limit), instead of NULL like its sibling sip_follow_continuation() returns on its own \"no more data\" path. ct_sip_get_header() only checks for NULL after calling it: dptr = sip_skip_whitespace(dptr, limit); if (dptr == NULL) break; if (*dptr != ':' || ++dptr >= limit) break; so a recognized header name followed only by spaces/tabs running to the exact end of the SIP payload, with no colon, makes the very next statement read one byte past the buffer. Make both \"no more data\" outcomes return NULL, matching the convention sip_follow_continuation() already uses and that both existing callers already check for.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98078", "url": "https://ubuntu.com/security/CVE-2026-98078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix reversed sequence option serialization hton_seq() expects the host-order source first and the unaligned network-order destination second. The version 1 sync sender passes these arguments in reverse for both sequence blocks. This leaves 24 bytes of the kmalloc-backed message unwritten. It may disclose stale heap data and replace the live connection sequence state with values read from the buffer. Pass the connection sequence state as the source and the message payload as the destination for both blocks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98080", "url": "https://ubuntu.com/security/CVE-2026-98080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not force reloc root creation during qgroup_account_snapshot() [BUG] When running btrfs/252 with quota enabled through MKFS_OPTIONS=\"-O quota\", it has a high chance to trigger the following kernel warning and flips the fs RO: BTRFS info (device dm-2): relocating block group 30408704 flags metadata|dup ------------[ cut here ]------------ WARNING: fs/btrfs/extent-tree.c:879 at lookup_inline_extent_backref+0x74b/0x960 [btrfs], CPU#4: btrfs/2173 CPU: 4 UID: 0 PID: 2173 Comm: btrfs Not tainted 7.2.0-rc6-custom+ #457 PREEMPT(full) 3adc6528fb66f7a55fe1095385818e742f200aab Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:lookup_inline_extent_backref+0x74b/0x960 [btrfs] Call Trace: insert_inline_extent_backref+0x7c/0x160 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_inc_extent_ref+0xa9/0x270 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_run_delayed_refs+0x4af/0x11c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_run_delayed_refs+0x9d/0xf0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshot+0x39d/0xf00 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshots+0x9b/0xc0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_commit_transaction+0x280/0xeb0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] prepare_to_relocate+0x147/0x200 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] relocate_block_group+0x6b/0x5e0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_block_group+0x92c/0x2380 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_balance+0xa2c/0x19c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_ioctl+0x2839/0x2d30 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS info (device dm-2): leaf 4593991680 gen 233 total ptrs 175 free space 5953 owner 2 BTRFS info (device dm-2): refs 3 lock_owner 2173 current 2173 \titem 0 key (166772736 METADATA_ITEM 1) itemoff 16250 itemsize 33 \t\textent refs 1 gen 222 flags 2 \t\tref#0: tree block backref root 266 [ Skip the tree dump ] \titem 174 key (263225344 METADATA_ITEM 0) itemoff 10328 itemsize 33 \t\textent refs 1 gen 162 flags 258 \t\tref#0: tree block backref root 267 BTRFS error (device dm-2): extent item not found for insert, bytenr 179847168 num_bytes 16384 parent 4594335744 root_objectid 273 owner 0 offset 0 BTRFS error (device dm-2): failed to run delayed ref for logical 179847168 num_bytes 16384 type 182 action 1 ref_mod 1: -117 [CAUSE] The above error is showing that there is a tree reference to a metadata extent that is no longer there. With \"ref_verify\" mount option (requires CONFIG_BTRFS_DEBUG), there is some extra debug output: BTRFS error (device dm-2): dumping block entry [180961280 16384], num_refs 0, metadata 1, from disk 0 BTRFS error (device dm-2): root entry 256, num_refs 18446744073709551615 BTRFS error (device dm-2): root entry 273, num_refs 18446744073709551615 BTRFS error (device dm-2): Ref action 3, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 1 btrfs_force_cow_block+0x129/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_insert_empty_items+0x3a/0x70 [btrfs] insert_with_overflow+0x53/0x130 [btrfs] btrfs_insert_dir_item+0x125/0x290 [btrfs] btrfs_add_link+0xaa/0x410 [btrfs] btrfs_rename+0x5ea/0xcd0 [btrfs] btrfs_rename2+0x28/0x60 [btrfs] vfs_rename+0x5b2/0xe10 filename_renameat2+0x244/0x430 __x64_sys_rename+0x48/0x70 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98088", "url": "https://ubuntu.com/security/CVE-2026-98088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() dev_to_node() can return NUMA_NO_NODE (-1) on systems without NUMA topology information for the PCI device, such as single-socket boards that don't expose device-to-node affinity. Passing -1 directly into cpumask_of_node() indexes node_to_cpumask_map[-1], an out-of-bounds array read caught by UBSAN: UBSAN: array-index-out-of-bounds in arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' Fall back to cpu_online_mask when no NUMA node is available, rather than assuming dev_to_node() always returns a valid node index.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98090", "url": "https://ubuntu.com/security/CVE-2026-98090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: restore active device pointers after failed sprout btrfs_init_new_device() switches latest_dev and possibly s_bdev from the seed device to the new sprout device before creating the first writable chunks. If chunk creation or the subsequent sprout setup fails, the error path releases the new device without switching those pointers back. btrfs_show_devname() can then dereference the freed latest_dev and crash. Restore the active device pointers to the latest seed device before removing and releasing the failed sprout device.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98091", "url": "https://ubuntu.com/security/CVE-2026-98091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: detach failed sprout device from transaction update list When creating the first metadata chunk for a sprout filesystem, create_chunk() adds the new device to the transaction dev_update_list through device->post_commit_list. If the subsequent system chunk creation fails, btrfs_init_new_device() aborts the transaction and releases the device while post_commit_list is still linked. This triggers a warning in btrfs_free_device() and leaves the transaction list referencing freed memory. Detach the device while holding chunk_mutex before releasing it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98094", "url": "https://ubuntu.com/security/CVE-2026-98094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: fbtft: make dirty_lock IRQ-safe fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled. Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again. The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled: WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2} CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); lock(console_owner); *** DEADLOCK *** Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98095", "url": "https://ubuntu.com/security/CVE-2026-98095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_packet: Don't cast tpacket_hdr.tp_len to int in tpacket_parse_header(). syzbot reported BUG() in sock_sendmsg_nosec(). [0] The problem is that tpacket_parse_header() casts user-provided tpacket_hdr.tp_len, which is u32, to int. If the length is larger than INT_MAX, the following condition in tpacket_parse_header() passes, if (unlikely(tp_len > size_max)) and any negative value can be returned to the caller, up to sock_sendmsg_nosec(). The repro set tpacket_hdr.tp_len to 0xfffffdef, which is cast to -EIOCBQUEUED (-529), triggering BUG() in sock_sendmsg_nosec(). *(uint64_t*)0x200000000008 = 0xfffffdef; ... syscall(__NR_write, /*fd=*/r[0], /*buf=*/0x200000000000ul, /*count=*/1ul); Let's define the local tp_len as u32 in tpacket_parse_header(). [0]: kernel BUG at net/socket.c:803! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 5628 Comm: syz-executor176 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 RIP: 0010:sock_sendmsg_nosec+0x145/0x180 net/socket.c:803 Code: 06 67 48 0f b9 3a eb 95 e8 e8 3a 22 f8 48 89 df 4c 89 f6 4c 89 e2 4d 89 fb 2e e8 32 a5 5c 16 e9 51 ff ff ff e8 cc 3a 22 f8 90 <0f> 0b e8 c4 3a 22 f8 48 83 c3 18 48 89 d8 48 c1 e8 03 42 80 3c 28 RSP: 0018:ffffc90003aefb48 EFLAGS: 00010293 RAX: ffffffff89a578d4 RBX: ffff8880764c67c0 RCX: ffff88807fb23e80 RDX: 0000000000000000 RSI: 00000000fffffdef RDI: 00000000fffffdef RBP: 00000000fffffdef R08: ffffc90003aef747 R09: 1ffff9200075dee8 R10: dffffc0000000000 R11: fffff5200075dee9 R12: 0000000000000001 R13: dffffc0000000000 R14: ffffc90003aefbc0 R15: ffffffff8aac4310 FS: 000055559101b400(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000210 CR3: 0000000073dca000 CR4: 00000000003526f0 Call Trace: __sock_sendmsg net/socket.c:815 [inline] sock_write_iter+0x2de/0x3e0 net/socket.c:1266 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x612/0xba0 fs/read_write.c:687 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f173130ecb9 Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 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 d8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd67e44248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f173130ecb9 RDX: 0000000000000001 RSI: 0000200000000000 RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd67e44388 R13: 0000000000000002 R14: 00002000000000c0 R15: 0000000000000002 ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98096", "url": "https://ubuntu.com/security/CVE-2026-98096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: restore network header before routing and forwarding ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative. This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows. Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98098", "url": "https://ubuntu.com/security/CVE-2026-98098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL deref in tipc_named_node_up() on empty publication list User-space applications can bind a large number of service addresses to one or more sockets. Each binding of a local-scope service address inserts one entry (publication) into the TIPC name table. If the number of these publications exceeds TIPC_MAX_PUBL (65535), protocol service types (such as node state and link state) are no longer inserted into the name table. This causes two issues: 1. User-space applications subscribing to node or link up/down events stop receiving notifications. 2. A NULL pointer dereference can occur: BUG: kernel NULL pointer dereference, address: 00000000000000d0 ... CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full) ... RIP: 0010:tipc_named_node_up (./include/linux/skbuff.h:2251 net/tipc/name_distr.c:195 net/tipc/name_distr.c:221) ... Call Trace: tipc_node_write_unlock (net/tipc/node.c:428) tipc_rcv (net/tipc/node.c:934 net/tipc/node.c:2189) tipc_udp_recv (net/tipc/udp_media.c:389) Thread 1 (tipc_net_finalize) | Thread 2 (named_distribute) -----------------------------|----------------------------- | ... | list_for_each_entry(publ, pls, binding_node) { | ... | __skb_queue_tail(list, skb); | ... | } | ... | hdr = buf_msg(skb_peek_tail(list)); ... | tipc_nametbl_publish(); | If 'tipc_nametbl_publish()' (Thread 1) fails because the number of local publications reaches TIPC_MAX_PUBL, list (Thread 2) will be empty. As a result, NULL is passed to 'buf_msg()', leading to a NULL pointer dereference. Fix these issues by allowing protocol service types (node state, link state, and topology server) to be inserted into the name table unconditionally. This ensures that users subscribing to these types always receive notifications. In addition, the maximum number of local user publications is reduced to (TIPC_MAX_PUBL - 1). This ensures that the maximum bulk size calculated in tipc_link_set_queue_limits() remains valid.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98108", "url": "https://ubuntu.com/security/CVE-2026-98108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan l2cap_new_connection() sets default value of channel mode to match the parent channel. l2cap_le_connect_req() left this at the default, and created L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that mode. This causes FLAG_DEFER_SETUP channels to reply to L2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect. It can also result to stack OOB write (of l2cap_alloc_cid determined values) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not limit maximum number of deferred channels or check for duplicate ident. Fix by setting chan->mode correctly in l2cap_le_connect_req(). Also check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE instead of OOB write to make it less brittle.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98113", "url": "https://ubuntu.com/security/CVE-2026-98113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: rate limit unmapped SID errors A client can include many structurally valid but unmapped SIDs in a DACL. Logging every mapping failure lets one request generate hundreds of kernel error messages. Rate limit the message to prevent an authenticated client from flooding the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98116", "url": "https://ubuntu.com/security/CVE-2026-98116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation with an mmap_count check performed under the PCM stream lock, but the lock is released long before the buffer is actually freed: snd_pcm_sync_stop(), constraint refinement and do_free_pages() all happen in between. snd_pcm_mmap_data(), on the other hand, takes no lock at all: it validates against the old buffer's state and dma_bytes, remaps its pages into the VMA, and only then increments mmap_count. A concurrent mmap() can therefore slip in between the check and the free. remap_pfn_range() installs writable PTEs for the old buffer's pages without taking page references, and the subsequent do_free_pages() returns those pages to the page allocator while the VMA still maps them. This leaves a stale, writable mapping of freed pages: a page-level use-after-free that can be leveraged for local privilege escalation. Make snd_pcm_mmap_data() participate in the buffer-access scheme introduced for hw_params/hw_free: acquire runtime->buffer_accessing before validating and remapping, and release it afterwards. Buffer reallocation already fails with -EBUSY while accessors are active, and the mmap side now fails with -EBUSY while a reallocation is in progress, so the validate/remap sequence and the check/free sequence can no longer interleave. A reproducer that turns this race into a stale writable mapping of the freed DMA buffer pages is available on request.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98121", "url": "https://ubuntu.com/security/CVE-2026-98121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix NULL pointer dereference in PM callbacks msc313e_wdt_probe() doesn't set the driver data for the platform device. As a result, dev_get_drvdata() in msc313e_wdt_suspend() and msc313e_wdt_resume() will return NULL, leading to a NULL pointer dereference afterward. Set the platform device driver data in msc313e_wdt_probe().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98123", "url": "https://ubuntu.com/security/CVE-2026-98123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration sctp_verify_asconf() walks ASCONF-ACK parameters with sctp_walk_params(), which advances by SCTP_PAD4(length), while the consumer sctp_get_asconf_response() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset. When those bytes yield a length of zero, the while loop over asconf_ack_len makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help). The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read. Reject SCTP_PARAM_ERR_CAUSE parameters shorter than sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERR_CAUSE parameter the consumer can see, so the consumer's asconf_ack_len check is dropped and it returns err_param->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTP_PARAM_ERR_CAUSE per RFC 5061. The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98130", "url": "https://ubuntu.com/security/CVE-2026-98130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START The SCTP_CMD_TIMER_START handler checks timer_pending() before calling timer_reduce(). The timer can expire and detach between these operations, causing timer_reduce() to rearm the timer without taking the association reference required for the newly armed timer. The timer callback later unconditionally drops its association reference, which can leave the association reference count unbalanced and result in use-after-free during association teardown. Use the return value of timer_reduce() to determine whether the timer was actually armed. Take the association reference only when timer_reduce() successfully starts a new timer, closing the race between checking the timer state and rearming it. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98154", "url": "https://ubuntu.com/security/CVE-2026-98154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix -EIO cleanup order in queue_rq On -EIO, the RDMA queue_rq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete. Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98157", "url": "https://ubuntu.com/security/CVE-2026-98157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation The poll_msec sysfs store file uses simple_strtoul() which accepts an unsigned long, but the target field (poll_msec) is unsigned int. On 64-bit systems, a value > UINT_MAX is silently truncated when stored. Fix the mismatch by using kstrtouint() instead. This rejects values larger than UINT_MAX at parse time, making truncation impossible. Also add a check for value < 1 to reject the 0-delay case, which would cause the poll work to spin without delay and consume 100% CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89796", "url": "https://ubuntu.com/security/CVE-2026-89796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid infinite kdamond_merge_regions() internal loop Patch series \"mm/damon: unurgent fixes for infinite loop, NULL de-ref and races\", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-98158", "url": "https://ubuntu.com/security/CVE-2026-98158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_async: drop the errored frame instead of resetting its headroom ppp_receive_nonmp_frame() prepends a two-byte direction tag before running the pass/active BPF filters: \t*(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG); Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in ppp_async's process_input_packet() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD: \terr: \t\tif (skb) { \t\t\t/* make skb appear as freshly allocated */ \t\t\tskb_trim(skb, 0); \t\t\tskb_reserve(skb, - skb_headroom(skb)); \t\t} ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head: skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev: kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled ppp_decompress_frame() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason. Rather than restore the headroom, drop the errored frame - as ppp_synctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read. The original V1 of this patch made room in ppp_receive_nonmp_frame() with skb_cow_head(); Eric pointed out that fixing the root cause in the transport is the right approach. Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-93288", "url": "https://ubuntu.com/security/CVE-2026-93288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state sashiko reports: \"nfnl_log_net_exit() calls nf_log_unset(), which clears the logger pointer without an RCU grace period. Immediately after, ops_free_list() frees the per-net state while concurrent packets might still be executing nf_log_packet() under rcu_read_lock().\" Clear the pointer via .pre_exit to make sure rcu readers have completed before pernet storage is free'd. The change in nf_log_syslog.c is only done for consistency: it doesn't use pernet data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93782", "url": "https://ubuntu.com/security/CVE-2026-93782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: flush backend after device ioctls vhost-scsi translates guest response descriptors into userspace iovecs when commands are submitted. Target-core completes those commands asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while an in-flight command still retains response iovecs translated through the old table. If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command completion can write the response to an unrelated userspace object. Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device ioctl. This waits for in-flight commands that can still use the old response iovecs before the ioctl returns.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93783", "url": "https://ubuntu.com/security/CVE-2026-93783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr and dereferences hdr->addr and hdr->ctrl without validating skb->len first. A truncated frame with skb->len less than the minimum header size causes an out-of-bounds read of uninitialized memory. Additionally, a zero-length frame causes skb->len-- to underflow to UINT_MAX, making skb_tail_pointer() read far past the buffer. Commit 23882b828c3c (\"Bluetooth: RFCOMM: validate skb length in MCC handlers\") fixed the same class of missing-length-check bugs in the MCC sub-handlers, but the top-level rfcomm_recv_frame() was left unfixed. KMSAN reports: BUG: KMSAN: uninit-value in rfcomm_run ... Uninit was created at: __alloc_skb+0x474/0xb60 vhci_write+0xe9/0x870 Fix this by rejecting frames smaller than sizeof(struct rfcomm_hdr) + 1 (the minimum frame must have a 3-byte header and a 1-byte FCS).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93784", "url": "https://ubuntu.com/security/CVE-2026-93784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie() The KASAN allocation trace shows that a malformed IE buffer is stored via SIOCSIWGENIE (cfg80211_wext_siwgenie()) without any validation. The crash trace shows that a subsequent SIOCSIWESSID triggers a connection attempt which calls cfg80211_sme_get_conn_ies() to process the stored IE buffer, causing: - An out-of-bounds read in skip_ie() which reads ies[pos+1] (the length byte) past the end of the 1-byte buffer. - An integer underflow in the memcpy size argument when offs returned by ieee80211_ie_split() exceeds ies_len, causing unsigned subtraction to wrap to SIZE_MAX and triggering a fortify panic. Fix this by validating the IE buffer in cfg80211_wext_siwgenie() before storing it. [drop unnecessary ie_len check, update commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93785", "url": "https://ubuntu.com/security/CVE-2026-93785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate idmap key payload length The cifs.idmap key type stores its payload length in key->datalen, which is limited to U16_MAX. Accepting a larger key payload truncates the recorded length and can make later users interpret the payload using inconsistent bounds. Reject oversized preparsed payloads before allocating or copying them. This keeps key->datalen consistent with the stored data for both inline and separately allocated idmap payloads.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93789", "url": "https://ubuntu.com/security/CVE-2026-93789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: bound aligned TLV advance in FW parser Validate ALIGN(tlv_len, 4) against remaining parser length before consuming bytes from the firmware image. This avoids length underflow on malformed TLVs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93795", "url": "https://ubuntu.com/security/CVE-2026-93795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix leaks and online flag on radix_tree_insert failure When radix_tree_insert() fails in blkg_create(), the error path has two issues: 1. blkg->online is set to true unconditionally, even when the blkg was never fully inserted. Move the assignment inside the success block. 2. The error path calls blkg_put() without first calling percpu_ref_kill(). Because the refcount is still in percpu mode, percpu_ref_put() only does this_cpu_sub() without checking for zero, so blkg_release() is never triggered. This permanently leaks the blkg memory, its percpu iostat, policy data, the parent blkg reference, and the cgroup css reference — the latter preventing the cgroup from ever being destroyed. Fix by replacing blkg_put() with percpu_ref_kill(), matching the pattern used in blkg_destroy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93797", "url": "https://ubuntu.com/security/CVE-2026-93797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix an off-by-1 boundary check Before looking at the 11th byte, check the length is big enough.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93798", "url": "https://ubuntu.com/security/CVE-2026-93798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix reloc root cleanup in merge_reloc_roots() If the root we got has zero root refs in its root item, we are resetting the root's ->reloc_root without using barriers like we do everywhere else. Sashiko complained about this while reviewing another patch, and it's correct (see the Link tag below). Also, we should not clear BTRFS_ROOT_DEAD_RELOC_TREE from the root unless the root points to the reloc root we have. Fix this by using clear_reloc_root(), which issues the memory barrier after setting the root's ->reloc_root to NULL and before clearing the bit BTRFS_ROOT_DEAD_RELOC_TREE from the root.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93800", "url": "https://ubuntu.com/security/CVE-2026-93800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol() If during relocation we fail in insert_dirty_subvol() because btrfs_update_reloc_root() returned an error, we will leave a root's reloc_root field pointing to a reloc root that was freed instead of NULL, resulting later in a use-after-free, or double free attempt during unmount. The sequence of steps is this: 1) During relocation the call to btrfs_update_reloc_root() in insert_dirty_subvol() fails, so insert_dirty_subvol() returns the error to merge_reloc_root() without adding the root to the list rc->dirty_subvol_roots; 2) Then merge_reloc_root() aborts the current transaction because insert_dirty_subvol() returned an error; 3) Up the call chain, merge_reloc_roots() gets the error, adds the reloc root for root X to the local reloc_roots list and jumps to the 'out' label, where it calls free_reloc_roots() to free all the reloc roots in the local reloc_roots list. This frees the reloc root for root X; 4) We go up the call chain to relocate_block_group() which calls clean_dirty_subvols() to go over dirty roots and set their ->reloc_root field to NULL, but root X is not in the dirty_subvol_roots list, so its ->reloc_root still points to a reloc root; 5) Relocation finishes, with an error and a transaction abort, but the ->reloc_root field for root X still points to the reloc root that was freed in step 3; 6) When unmounting the fs we end up calling: btrfs_free_fs_roots() btrfs_drop_and_free_fs_root() --> calls btrfs_put_root() against root X's ->reloc_root which is not NULL and points to the already freed reloc root in step 4 above Resulting in a use-after-free to a double free attempt. Syzbot reported this with the following dmesg/syslog: [ 106.004389][ T5339] BTRFS error (device loop0 state A): Transaction aborted (error -5) [ 106.014266][ T5339] BTRFS: error (device loop0 state A) in merge_reloc_root:1655: errno=-5 IO failure [ 106.021891][ T1061] BTRFS error (device loop0 state A): error while writing out transaction: -5 [ 106.026964][ T1061] BTRFS warning (device loop0 state A): Skipping commit of aborted transaction. [ 106.033807][ T5340] BTRFS error (device loop0 state A): bdev /dev/loop0 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 [ 106.039265][ T1061] BTRFS: error (device loop0 state A) in cleanup_transaction:2067: errno=-5 IO failure [ 106.044382][ T5339] BTRFS info (device loop0 state EA): forced readonly [ 106.074329][ T5339] BTRFS: error (device loop0 state EA) in merge_reloc_roots:1887: errno=-5 IO failure [ 106.081004][ T5356] BTRFS info (device loop0 state EA): scrub: started on devid 1 [ 106.085611][ T5339] BTRFS info (device loop0 state EA): balance: ended with status: -30 [ 106.089517][ T5356] BTRFS info (device loop0 state EA): scrub: not finished on devid 1 with status: -30 [ 106.662365][ T5338] BTRFS info (device loop0 state EA): last unmount of filesystem 3a375e4e-b156-4d76-a2ad-16e198ce1409 [ 106.682946][ T5338] ================================================================== [ 106.686574][ T5338] BUG: KASAN: slab-use-after-free in btrfs_put_root+0x2f/0x250 [ 106.690090][ T5338] Write of size 4 at addr ffff88803f978630 by task syz.0.0/5338 [ 106.693173][ T5338] [ 106.694279][ T5338] CPU: 0 UID: 0 PID: 5338 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) [ 106.694293][ T5338] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 106.694300][ T5338] Call Trace: [ 106.694308][ T5338] [ 106.694314][ T5338] dump_stack_lvl+0xe8/0x150 [ 106.694331][ T5338] print_address_description+0x55/0x1e0 [ 106.694343][ T5338] ? btrfs_put_root+0x2f/0x250 [ 106.694358][ T5338] print_report+0x58/0x70 [ 106. ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93802", "url": "https://ubuntu.com/security/CVE-2026-93802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: validate beacon length before fixed buffer copy rsi_prepare_beacon() copies the mac80211 beacon frame after FRAME_DESC_SZ into a management skb whose usable tailroom may be smaller than MAX_MGMT_PKT_SIZE after alignment. Validate the beacon length against the actual tailroom before the copy and skb_put(). Leave ownership of the management skb with the caller on error, matching the existing rsi_send_beacon() cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93803", "url": "https://ubuntu.com/security/CVE-2026-93803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libipw: fix key index receive bound checks libipw_rx() reads skb->data[hdrlen + 3] to extract the WEP key index in both the software-decrypt key selection path and the hardware-decrypted IV/ICV strip path. In both places the existing guard only checks skb->len >= hdrlen + 3, which proves bytes up to hdrlen + 2 but not the byte at hdrlen + 3. Require hdrlen + 4 bytes before reading that item in both paths. This is a local source-boundary check only; it does not change the key index semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93805", "url": "https://ubuntu.com/security/CVE-2026-93805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate rx/tx MLME callback frame lengths before access cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints before rejecting frames shorter than the frame-control field. After that, they only require len >= 2 before dispatching into subtype handlers that assume their fixed fields are present. The frames that trip this are not shorter than 2 bytes; they are short relative to their subtype. mwifiex is a concrete in-tree example on the length side: mwifiex_process_mgmt_packet() only requires a 4-address ieee80211_hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and removing addr4, pkt_len can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARN_ON(len < 2) does not fire on such a frame, and cfg80211_process_deauth() then reads u.deauth.reason_code as a two-byte access starting at offset 24, immediately past the 24-byte buffer. Add a frame-control length gate, then validate each subtype's minimum frame size in an if/else-if chain that mirrors the dispatch logic. Trace only after the frame is known to be well-formed. Side effects of this change: - The WARN_ON(len < 2) is dropped. It only guarded the frame_control read, never the subtype fixed fields, and it does not fire on the frames that actually trigger the out-of-bounds read (which are >= 2). The len >= 2 check is kept as the guard before dereferencing frame_control, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93807", "url": "https://ubuntu.com/security/CVE-2026-93807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers rsi_hal_load_key() copies tx_mic_key and rx_mic_key from data[16] and data[24] whenever key data is present. Those offsets are only part of the 32-byte TKIP key layout. Shorter keys used by other ciphers, such as CCMP, do not provide those bytes, so the unconditional copies can read past the supplied key buffer. Only copy the MIC keys for TKIP, and reject malformed TKIP keys that are shorter than the expected 32-byte layout. [drop useless length check]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93808", "url": "https://ubuntu.com/security/CVE-2026-93808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: caiaq: validate EP1 reply lengths usb_ep1_command_reply_dispatch() uses buf[0] as a command byte and then reads command-specific fixed items from the same URB buffer. Several paths use buf + 1, buf[1], buf[2], or buf + 3 without first proving that urb->actual_length contains those bytes. Add per-command length checks, use a payload length derived from the bytes after the command byte for the control-state copy, and reject short analog input payloads before the input helper reads fixed offsets from the EP1 reply.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93811", "url": "https://ubuntu.com/security/CVE-2026-93811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling 1. When ndr_decode_v4_ntacl() fails, the code jumped to free_n_data which only freed n.data, skipping kfree(acl.sd_buf) and leaking the buffer. Zero-initialize struct xattr_ntacl acl, reorder error labels to out_free to release acl.sd_buf on all error paths. 2. if (acl.sd_size < sizeof(struct smb_ntsd)) is true, original code returned success without freeing sd_buf and left stale *pntsd. Set rc = -EINVAL before jumping to out_free to return error code and free buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93812", "url": "https://ubuntu.com/security/CVE-2026-93812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr ndr_encode_v4_ntacl() allocates sd_ndr.data via kzalloc() at entry. If any subsequent ndr_write_*() call returns error during encoding, the allocated sd_ndr.data won't be freed and causes memory leak. Move kfree(sd_ndr.data) into out label to ensure the buffer gets released on all success and error return paths.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93813", "url": "https://ubuntu.com/security/CVE-2026-93813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tree-checker: validate INODE_REF's namelen [BUG] A crafted btrfs image can trigger the following crash: BUG: unable to handle page fault for address: ffffd1dc42884000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page CPU: 9 UID: 0 PID: 1034 Comm: poc Not tainted 7.1.0-rc4-custom+ #383 PREEMPT(full) 46af0a92938a63be7132e0dfd71e62327c51d5c2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:memcpy+0xc/0x10 Call Trace: read_extent_buffer+0xe4/0x100 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] btrfs_get_name+0x15e/0x1e0 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] reconnect_path+0x165/0x390 exportfs_decode_fh_raw+0x337/0x400 ? drop_caches_sysctl_handler+0xb0/0xb0 ---[ end trace 0000000000000000 ]--- RIP: 0010:memcpy+0xc/0x10 Kernel panic - not syncing: Fatal exception [CAUSE] TThe crafted image has the following corrupted INODE_REF item: item 9 key (258 INODE_REF 257) itemoff 11544 itemsize 4106 \tindex 2 namelen 4096 name: d\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000 The itemsize matches the namelen, but the namelen is 4096, way larger than normal name length limit (BTRFS_NAME_LEN, 255). Meanwhile the memory of the @name is only 255 byte sized, this will cause out-of-boundary access, and cause the above crash. [FIX] Add extra namelen verification for INODE_REF, just like what we have done in ROOT_REF checks. Now the crafted image can be rejected gracefully: BTRFS critical (device dm-2): corrupt leaf: root=5 block=30572544 slot=14 ino=259, invalid inode ref name length, has 4096 expect [1, 255] BTRFS error (device dm-2): read time tree block corruption detected on logical 30572544 mirror 2 [ Rebase, add a Link: tag, add an simple cause analyze ]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93815", "url": "https://ubuntu.com/security/CVE-2026-93815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: au1000: move free_irq out of the close-time spinlocked section au1000_close() calls free_irq() while aup->lock is still held with spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ descriptor request mutex, so it does not belong inside the close-time spinlocked section. This was found by our static analysis tool and then confirmed by manual review of the in-tree au1000_close() .ndo_stop path. The reviewed path keeps aup->lock held across the MAC reset, queue stop and free_irq(dev->irq, dev). A directed runtime validation kept that ndo_stop carrier and the same free_irq(dev->irq, dev) operation under the driver lock. Lockdep reported \"BUG: sleeping function called from invalid context\" and \"Invalid wait context\" while free_irq() was taking desc->request_mutex, with au1000_close() and free_irq() on the stack. Drop aup->lock before freeing the IRQ. The protected close-time work still stops the device and queue before IRQ teardown, but the sleepable IRQ core path now runs outside the spinlocked section.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93816", "url": "https://ubuntu.com/security/CVE-2026-93816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate inline dentry name lengths before conversion Inline dentry conversion copies names out of the inline dentry area before checking that each recorded name length fits in the available filename slots. A corrupted image can therefore make the conversion path read past the inline filename storage while building the regular dentry block. Validate each inline dentry name length against the inline filename area before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93819", "url": "https://ubuntu.com/security/CVE-2026-93819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93820", "url": "https://ubuntu.com/security/CVE-2026-93820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rockchip: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93821", "url": "https://ubuntu.com/security/CVE-2026-93821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93822", "url": "https://ubuntu.com/security/CVE-2026-93822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: iproc: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93825", "url": "https://ubuntu.com/security/CVE-2026-93825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: Add NULL check for spi_get_device_id() in spi_get_device_match_data() Prevent NULL pointer dereference when spi_get_device_id() returns NULL, which can happen when using driver_override without matching SPI ID entry.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93830", "url": "https://ubuntu.com/security/CVE-2026-93830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac2: disable RBUE in default RX interrupt mask Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97407", "url": "https://ubuntu.com/security/CVE-2026-97407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in set_fmt rockchip_pdm_set_fmt() calls pm_runtime_get_sync() before accessing hardware registers, but ignores its return value. If the runtime resume fails, the function continues to perform register accesses while the device state is undefined. Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() and return early on failure to avoid unpowered register accesses.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97408", "url": "https://ubuntu.com/security/CVE-2026-97408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate connectionless PSM length Connectionless L2CAP frames carry a two-byte PSM at the start of the payload. l2cap_recv_frame() currently reads that PSM unconditionally after validating only the outer L2CAP length. A malformed connectionless frame with a zero- or one-byte payload can therefore make the parser read beyond the advertised skb payload and use tailroom bytes as part of the PSM. A VHCI-backed QEMU reproducer injected a one-byte connectionless payload and reached the unchecked read. Reject connectionless frames that cannot contain the PSM before reading or pulling it. This preserves all valid connectionless frames while dropping only structurally incomplete packets.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97411", "url": "https://ubuntu.com/security/CVE-2026-97411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ibm: emac: mal: fix potential system hang in mal_remove() napi_disable() is not idempotent and calling it on an already-disabled or unenabled NAPI context will cause the kernel to spin indefinitely waiting for the NAPI_STATE_SCHED bit to clear. In mal_remove(), napi_disable() is called unconditionally. If no MACs were registered, NAPI was never enabled. Also, if they were registered but subsequently unregistered, NAPI was already disabled in mal_unregister_commac(). In either case, calling napi_disable() causes the kernel to hang upon module removal. Fix this by only calling napi_disable() in mal_remove() if the commac list is not empty (which implies NAPI is enabled).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97413", "url": "https://ubuntu.com/security/CVE-2026-97413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Fix integer underflow in process_read and process_write usr_len is read from a network-supplied message field (le16_to_cpu) and used to compute data_len = off - usr_len without validating that usr_len <= off. A malicious RDMA client can send usr_len > off causing an integer underflow, resulting in data_len wrapping to a huge size_t value which is then passed to the rdma_ev callback as a memory length, leading to out-of-bounds memory access. Fix by reading and validating usr_len <= off before rtrs_srv_get_ops_ids() in both process_read() and process_write(), ensuring the early return path acquires no reference and has no resource leak.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97416", "url": "https://ubuntu.com/security/CVE-2026-97416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: balance: fix potential bg lookup failure in btrfs_may_alloc_data_chunk() [BUG] Running btrfs balance can trigger a null-ptr-deref before relocating a data chunk when metadata corruption leaves a chunk in the chunk tree without a corresponding block group in the in-memory cache: KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] RIP: 0010:btrfs_may_alloc_data_chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601 Call Trace: __btrfs_balance fs/btrfs/volumes.c:4217 [inline] btrfs_balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604 btrfs_ioctl_balance fs/btrfs/ioctl.c:3577 [inline] btrfs_ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313 ... [CAUSE] __btrfs_balance() iterates the on-disk chunk tree and passes the chunk logical bytenr to btrfs_may_alloc_data_chunk() before relocating a data chunk. That helper then queries the in-memory block group cache: cache = btrfs_lookup_block_group(fs_info, chunk_offset); chunk_type = cache->flags; /* cache may be NULL */ A corrupt image can contain a chunk item whose matching block group item is missing, so no block group is ever inserted into the cache. In that case btrfs_lookup_block_group() returns NULL. The code only guards this with ASSERT(cache), which becomes a no-op when CONFIG_BTRFS_ASSERT is disabled. The subsequent dereference of cache->flags therefore crashes the kernel. [FIX] Add a NULL check after btrfs_lookup_block_group() in btrfs_may_alloc_data_chunk() and print and error message for clarity.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97417", "url": "https://ubuntu.com/security/CVE-2026-97417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack() The timestamp-only fast path dereferences the option stream as *(__be32 *)ptr, which assumes 4-byte alignment that the TCP option stream does not guarantee. Use get_unaligned_be32() instead, which reads the value safely and already returns host byte order, so the htonl() on the comparison constant can be dropped. This matches the existing get_unaligned_be32() use later in the same function.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97418", "url": "https://ubuntu.com/security/CVE-2026-97418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es18xx: check control allocation before private data setup snd_es18xx_mixer() creates controls with snd_ctl_new1() and then stores bookkeeping pointers or sets private_free before calling snd_ctl_add(). snd_ctl_new1() can return NULL on allocation failure, so those writes can dereference a NULL control pointer. Check the returned control pointers before using them and return -ENOMEM on allocation failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97419", "url": "https://ubuntu.com/security/CVE-2026-97419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: broadcast netlink notifications in the device's net namespace The HSR generic netlink family sets .netnsok = true. HSR devices can live in network namespaces other than init_net. Two async notifiers broadcast events with genlmsg_multicast(). They are hsr_nl_ringerror() and hsr_nl_nodedown(). That helper delivers only on the default genl socket in init_net. So the events always land in init_net. The network namespace of the device does not matter. This has two effects. A listener in the device's own namespace never sees its own ring error and node down events. A privileged listener in init_net receives events from HSR devices in other namespaces. The payload carries the peer node MAC (HSR_A_NODE_ADDR) and the slave port ifindex (HSR_A_IFINDEX). Switch both callers to genlmsg_multicast_netns(). Other families with .netnsok = true already do this. Examples are gtp, ovpn, team, batman-adv, netdev-genl, ethtool and handshake. hsr_nl_ringerror() already has the slave port. It uses dev_net(port->dev). hsr_nl_nodedown() takes the namespace from the master port via hsr_port_get_hsr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97420", "url": "https://ubuntu.com/security/CVE-2026-97420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: NUL-terminate replaced sysctl value When writing to sysctls, proc_sys_call_handler() guarantees that the buffer passed to proc handlers is NUL-terminated. If bpf_sysctl_set_new_value() replaces the pending sysctl value, it can hand a replacement buffer directly to proc handlers. However, the helper currently copies only buf_len bytes into that buffer without appending a NUL terminator, leaving downstream parsers vulnerable to out-of-bounds access. Fix this by appending a '\\0' after the replaced value to restore the expected sysctl semantics. Since the helper already rejects buf_len greater than PAGE_SIZE - 1, there is always room for the extra byte. Reproduced in a QEMU x86_64 guest booted with KASAN while exercising the sysctl replacement path with a cgroup/sysctl BPF program. The reproducer targets `/proc/sys/net/core/flow_limit_cpu_bitmap`, fills the original user write buffer with non-zero bytes, and overrides the sysctl value so the replacement buffer lacks a terminating NUL. Under that setup, the pre-fix kernel reported: BUG: KASAN: slab-out-of-bounds in strnchrnul+0x72/0x90 Read of size 1 at addr ffff88800de57000 by task repro_patch3/66 CPU: 0 UID: 0 PID: 66 Comm: repro_patch3 Not tainted 7.1.0-rc3-00269-g8370ca1f87cc #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? strnchrnul+0x72/0x90 ? strnchrnul+0x72/0x90 kasan_report+0xca/0x100 ? strnchrnul+0x72/0x90 strnchrnul+0x72/0x90 bitmap_parse+0x37/0x2e0 flow_limit_cpu_sysctl+0xc6/0x840 ? __pfx_flow_limit_cpu_sysctl+0x10/0x10 ? __kvmalloc_node_noprof+0x5ba/0x870 proc_sys_call_handler+0x31d/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? selinux_file_permission+0x39f/0x500 ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... The buggy address is located 0 bytes to the right of allocated 4096-byte region [ffff88800de56000, ffff88800de57000) With this fix applied, rerunning the same sysctl-targeted path yields no corresponding KASAN reports.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97421", "url": "https://ubuntu.com/security/CVE-2026-97421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz() Several corner cases, especially important on 32 bits: - umem->iova is u64, the function argument should pass in u64 or iova will be truncated - Check that the length is not too large for the iova - Check that lengths > 4G don't overflow the GENMASK", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97430", "url": "https://ubuntu.com/security/CVE-2026-97430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: Prevent queuing new commands if xhci is inaccessible Refuse to queue a new command on the command ring if xHC is marked inaccessible with the HCD_FLAG_HW_ACCESSIBLE. HCD_FLAG_HW_ACCESSIBLE is set and cleared in suspend and resume. Also print a warning if xhci is being suspended with commands still pending on the command ring.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97434", "url": "https://ubuntu.com/security/CVE-2026-97434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: fix handling of NAPI on the remove path All the NAPI instances for a DPSW device are attached to the first switch port's net_device but shared by all ports. The NAPI instances get disabled only once the last port goes down. This causes an issue on the .remove() path where each port is unregistered and freed one at a time, causing the NAPI instances to be deleted even though they are not disabled. In order to avoid this, split up the unregister_netdev() calls from the free_netdev() so that we make sure all ports go down before we attempt a deletion of NAPI instances. Also, make the netif_napi_del() explicit as it is on the .probe() path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97435", "url": "https://ubuntu.com/security/CVE-2026-97435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: flower: reject cross-chip redirect dsa_port_from_netdev() may return a valid port from a different switch chip. Programming another chip's port index into the local hardware causes redirection to the wrong port, or an out-of-bounds access if the index exceeds the local chip's port count. Apply a minimal fix that adds a check to catch this case and adjusts the extack message. When cls->common.skip_sw is not set, the operation could instead redirect to the upstream port and let the software or upstream switch(es) handle the forward, but that is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97436", "url": "https://ubuntu.com/security/CVE-2026-97436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: rework FDB management on the bridge leave path On bridge leave, the dpaa2_switch_port_set_fdb() function always allocates a new FDB for the port which is becoming standalone. In case no FDB is found, then the port leaving a bridge will continue to use the current one. The above logic does not cover the case in which there are multiple bridges which have ports from the same DPSW instance. In this case, when the last port leaves bridge #1, it finds an unused FDB to switch to, but the old FDB is not marked as unused. Since the number of FDBs is equal to the number of DPSW interfaces, this will eventually lead to multiple ports sharing the same FDB. Fix this by changing how we are managing the FDBs on the leave path. Instead of directly allocating a new FDB, first verify if the current port is the last one to leave a bridge. If this is the case, then continue to use the current FDB and only allocate another FDB if there are other ports remaining in the bridge.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97437", "url": "https://ubuntu.com/security/CVE-2026-97437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e() The bounds check in ntfs_dir_emit() compares fname->name_len (a character count) against e->size (a byte count) without accounting for the 2-byte-per-character UTF-16LE encoding or the ATTR_FILE_NAME header size: if (fname->name_len + sizeof(struct NTFS_DE) > le16_to_cpu(e->size)) This computes: name_len + 16 > e_size The correct check must account for the ATTR_FILE_NAME header (66 bytes before the name) and the UTF-16LE character size (2 bytes each): sizeof(NTFS_DE) + offsetof(ATTR_FILE_NAME, name) + name_len * sizeof(short) > e_size Which computes: 16 + 66 + name_len * 2 > e_size The correct calculation already exists as fname_full_size() in ntfs.h and is used in cmp_fnames(), namei.c, and fslog.c, but was not used in the readdir path. A crafted NTFS image with an index entry containing a small e->size but large fname->name_len bypasses the current check, causing ntfs_utf16_to_nls() to read past the entry boundary. Additionally, add a key_size validation in hdr_find_e() to ensure the declared key_size does not exceed the available entry data, preventing comparison functions from reading past entry boundaries on the lookup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97438", "url": "https://ubuntu.com/security/CVE-2026-97438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate index entry key bounds [BUG] A malformed NTFS directory index entry can advertise a key_size larger than the bytes actually present in its NTFS_DE payload. Directory lookup then passes that malformed key to cmp_fnames(), which can read past the end of the kmalloc'ed index buffer. BUG: KASAN: slab-out-of-bounds in fname_full_size fs/ntfs3/ntfs.h:590 [inline] BUG: KASAN: slab-out-of-bounds in cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 Read of size 1 at addr ffff88801c313018 by task syz.6.3365/9279 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 __asan_report_load1_noabort+0x14/0x30 mm/kasan/report_generic.c:378 fname_full_size fs/ntfs3/ntfs.h:590 [inline] cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 hdr_find_e.isra.0+0x3ed/0x670 fs/ntfs3/index.c:762 indx_find+0x4b5/0x900 fs/ntfs3/index.c:1186 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... Allocated by task 9279: kasan_save_stack+0x39/0x70 mm/kasan/common.c:56 kasan_save_track+0x14/0x40 mm/kasan/common.c:77 kasan_save_alloc_info+0x37/0x60 mm/kasan/generic.c:573 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0xc3/0xd0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __do_kmalloc_node mm/slub.c:5650 [inline] __kmalloc_noprof+0x2bd/0x900 mm/slub.c:5662 kmalloc_noprof include/linux/slab.h:961 [inline] indx_read+0x41d/0xad0 fs/ntfs3/index.c:1059 indx_find+0x447/0x900 fs/ntfs3/index.c:1179 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... [CAUSE] The index-header validators only validated INDEX_HDR-level geometry. They did not walk each NTFS_DE to verify entry alignment, subnode layout, or that key_size fit inside the entry payload. They also allowed a last sentinel entry to carry a non-zero key_size. [FIX] Walk every NTFS_DE in ntfs3's index-header validators and reject entries with invalid layout, mismatched subnode state, oversized key_size, or non-zero sentinel keys before lookup or log replay can consume them.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97439", "url": "https://ubuntu.com/security/CVE-2026-97439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib [BUG] A corrupted ntfs3 image can hit a NULL function pointer call in generic_perform_write() after toggling system.ntfs_attrib and then overwriting system.dos_attrib on the same file. BUG: kernel NULL pointer dereference, address: 0000000000000000 \\#PF: supervisor instruction fetch in kernel mode \\#PF: error_code(0x0010) - not-present page PGD bed5067 P4D bed5067 PUD 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffff88801025f988 EFLAGS: 00010246 Call Trace: generic_perform_write+0x409/0x8c0 mm/filemap.c:4255 __generic_file_write_iter+0x1bb/0x200 mm/filemap.c:4372 ntfs_file_write_iter+0xcd9/0x1c20 fs/ntfs3/file.c:1253 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x63b/0xf70 fs/read_write.c:686 ksys_write+0x133/0x250 fs/read_write.c:738 __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x77/0xc0 fs/read_write.c:746 ... [CAUSE] system.ntfs_attrib updates ATTR_DATA flags via ni_new_attr_flags() and switches i_mapping->a_ops to ntfs_aops_cmpr when FILE_ATTRIBUTE_COMPRESSED is set. system.dos_attrib then overwrites ni->std_fa from a one-byte DOS attribute value, clearing the compression bit without updating ATTR_DATA or the mapping operations. Old buffered writes use is_compressed(ni) to choose __generic_file_write_iter(). That leaves generic_perform_write() calling a NULL write_begin callback from ntfs_aops_cmpr. [FIX] Treat system.dos_attrib as a low-byte DOS attribute update and preserve the existing non-DOS attribute bits in ni->std_fa. This keeps compressed and sparse state consistent with ATTR_DATA and the mapping operations while keeping the existing DOS attribute semantics intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97440", "url": "https://ubuntu.com/security/CVE-2026-97440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix node refcount leak on ctrl packet alloc failure qrtr_send_resume_tx() calls qrtr_node_lookup() which takes a reference on the returned node. If the subsequent call to qrtr_alloc_ctrl_packet() fails due to memory allocation failure, the function returns -ENOMEM without calling qrtr_node_release() to release the node reference. Add qrtr_node_release(node) before returning on the allocation failure path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97441", "url": "https://ubuntu.com/security/CVE-2026-97441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: ahci: fail probe if BAR too small for claimed ports When an AHCI controller is disabled in BIOS, its HOST_CAP register may contain a bogus value, e.g. 0xFFFFFFFF. Since CAP.NP (Number of Ports) is a zeroes based 5-bit register field, a value of 0x1f means 32 ports. If CAP.NP claims more ports than can physically fit within the mapped BAR region, accessing port registers beyond the BAR boundary causes a kernel panic. Add validation in ahci_init_one() to check that the BAR size is sufficient for the number of ports claimed in CAP.NP. The check calculates the required MMIO size as: required_size = 0x100 (global registers) + max_ports * 0x80 If required_size exceeds the actual BAR size, the probe fails with -ENODEV, preventing the panic and providing a clear error message. [cassel: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97443", "url": "https://ubuntu.com/security/CVE-2026-97443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/ftrace: Fix WARNING in __unregister_ftrace_function perf_ftrace_function_unregister() unconditionally calls unregister_ftrace_function() without checking whether the ftrace_ops was ever successfully registered. This triggers a WARN_ON in __unregister_ftrace_function() when the ops doesn't have FTRACE_OPS_FL_ENABLED set. This can happen during perf_event_alloc() error cleanup when perf_trace_destroy() is called via __free_event() on an event whose ftrace_ops registration failed or was already torn down by perf_try_init_event()'s err_destroy path. The call path is: perf_event_alloc() error cleanup -> __free_event() -> event->destroy() [tp_perf_event_destroy] -> perf_trace_destroy() -> perf_trace_event_close() -> TRACE_REG_PERF_CLOSE -> perf_ftrace_function_unregister() -> unregister_ftrace_function() -> __unregister_ftrace_function() -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to unregister. If the ops is not enabled, just free the filter and return success.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97444", "url": "https://ubuntu.com/security/CVE-2026-97444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in two places Add boundary checks in acpi_ps_get_next_namestring() and acpi_ps_peek_opcode() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97445", "url": "https://ubuntu.com/security/CVE-2026-97445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources() Enhance buffer validation in acpi_ut_walk_aml_resources() to prevent buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97446", "url": "https://ubuntu.com/security/CVE-2026-97446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package() acpi_ns_custom_package() unconditionally dereferences the first element of the package to read the _BIX version number, without checking for NULL: if ((*Elements)->Common.Type != ACPI_TYPE_INTEGER) When firmware returns a _BIX package whose first element is an unresolvable reference, ACPICA evaluates that entry to NULL. acpi_ns_remove_null_elements() does not strip NULL entries for ACPI_PTYPE_CUSTOM packages (fixed-position format would break if elements were shifted), so acpi_ns_custom_package() sees the NULL and causes a crash. Add a NULL check for the first element (version field) before dereferencing it. The caller then receives AE_AML_OPERAND_TYPE instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97448", "url": "https://ubuntu.com/security/CVE-2026-97448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add validation for node in acpi_ns_build_normalized_path() Add validation for node in acpi_ns_build_normalized_path() to prevent use-after-free vulnerabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97449", "url": "https://ubuntu.com/security/CVE-2026-97449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add package limit checks in parser functions Add package limit checks in parser functions to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97450", "url": "https://ubuntu.com/security/CVE-2026-97450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate handler object type in two places ACPICA: validate handler object type in acpi_ev_has_default_handler() and acpi_ev_find_region_handler().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97451", "url": "https://ubuntu.com/security/CVE-2026-97451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op) Add overflow check for Index + Length to prevent integer overflow when calculating the truncation length. This prevents negative size parameter being passed to memcpy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97452", "url": "https://ubuntu.com/security/CVE-2026-97452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Prevent adding invalid references Prevent adding references for local, argument, and debug objects in acpi_ut_copy_simple_object().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97453", "url": "https://ubuntu.com/security/CVE-2026-97453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate byte_count in acpi_ps_get_next_package_length() Validate package length reading in acpi_ps_get_next_package_length().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97454", "url": "https://ubuntu.com/security/CVE-2026-97454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in acpi_ps_get_next_field() Add boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97455", "url": "https://ubuntu.com/security/CVE-2026-97455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix use-after-free in acpi_ds_terminate_control_method() Fix use-after-free issue in acpi_ds_terminate_control_method() by clearing references to method locals and arguments.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97456", "url": "https://ubuntu.com/security/CVE-2026-97456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix condition check in acpi_ps_parse_loop() Fix condition check for AML_ELSE_OP in acpi_ps_parse_loop() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97472", "url": "https://ubuntu.com/security/CVE-2026-97472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: fix temp address generation after prefix deprecation When a router temporarily deprecates an IPv6 prefix (either by sending a Router Advertisement with Preferred Lifetime = 0 or by letting the lifetime expire) and later restores it, the kernel permanently loses its ability to generate temporary privacy addresses (RFC 8981) for that prefix. This happens because the address worker attempts to generate a replacement temporary address when the current one nears expiration. As the base prefix is deprecated already, the generation fails after marking the temporary address as already having spawned a replacement (ifp->regen_count++). When the router eventually restores the prefix, the temporary address becomes active again. However, once it naturally expires, the address worker sees this temporary address already tried to generate one and skips the regeneration. Fix the issue by resetting the regen_count check of the latest temp address generated for the prefix updated by the incoming RA.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97475", "url": "https://ubuntu.com/security/CVE-2026-97475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tegra/soctherma: Switch to devm cooling device registration Use devm_thermal_of_cooling_device_register() to simplify resource management and avoid manual cleanup in error paths. As a side effect this change has the benefit of solving an existing issue. Before, the function tegra_soctherm_remove() only called debugfs_remove_recursive() and never called thermal_cooling_device_unregister() for any of the cooling devices registered here. After the driver removal, the thermal framework's cdev list would still hold references to thermal_cooling_device objects whose devdata pointer (ts) pointed to memory already freed by the platform device's devm cleanup. With this change, the cooling device is unregistered when the driver is removed, thus fixing the issue above.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97476", "url": "https://ubuntu.com/security/CVE-2026-97476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: filter RDS_INFO_* getsockopt by caller's netns The RDS_INFO_* family of getsockopt(2) options reads several file-scope global lists that are not per-netns: rds_sock_info / rds6_sock_info, rds_sock_inc_info / rds6_sock_inc_info -> rds_sock_list rds_tcp_tc_info / rds6_tcp_tc_info -> rds_tcp_tc_list rds_conn_info / rds6_conn_info, rds_conn_message_info_cmn (for the *_SEND_MESSAGES and *_RETRANS_MESSAGES variants), rds_for_each_conn_info (for RDS_INFO_IB_CONNECTIONS) -> rds_conn_hash[] The handlers do not filter by the caller's network namespace. rds_info_getsockopt() has no netns or capable() check, and rds_create() has no capable() check, so AF_RDS is reachable from an unprivileged user namespace. As a result, an unprivileged caller in a fresh user_ns plus netns can read the bound address and sock inode of every RDS socket on the host, the peer address of incoming messages on every RDS socket on the host, the peer address and TCP sequence numbers of every rds-tcp connection on the host, and the peer address and RDS sequence numbers of every RDS connection on the host. The rds-tcp transport is reachable from a non-initial netns (see rds_set_transport()), so a one-shot init_net gate at rds_info_getsockopt() would deny legitimate per-netns visibility to rds-tcp callers. Instead, filter at each handler by comparing the netns of the caller's socket to the netns of the list entry, or to rds_conn_net(conn) for connection paths. Only copy entries whose netns matches the caller. Counters (RDS_INFO_COUNTERS) are aggregate statistics and remain global. Reproducer (KASAN VM, rds and rds_tcp loaded): an AF_RDS socket binds 127.0.0.1:4242 in init_net as root. A child process enters a fresh user_ns plus netns and opens AF_RDS there, then calls getsockopt(SOL_RDS, RDS_INFO_SOCKETS). Before this change, the child sees the init_net socket. After this change, the child sees zero entries. Drop the rds_sock_count, rds_tcp_tc_count, and rds6_tcp_tc_count globals. v2 used them for the size precheck and lens->nr; v3 replaced the precheck with a per-ns count from a first pass over the list, so the globals have no remaining readers. The matching increments and decrements in rds_create()/rds_destroy_sock() and rds_tcp_set_callbacks()/rds_tcp_restore_callbacks() go away with them. Reported by the kernel test robot under clang W=1.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97481", "url": "https://ubuntu.com/security/CVE-2026-97481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix possible ISR soft lockup There are rare cases in which the host gets stuck in the ISR because it is flooded with messages during the startup phase. The reason for the soft lockup in the ISR is the missing FIFO error IRQ (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers the IRQ immediately again. Fix this by adding a check for the FIFOE status and clearing the FIFO if no data is ready (DR). This behavior was observed on an AM62L device which uses the OMAP 8250 driver. Fix it for all 8250 drivers, since the OMAP driver's special IRQ setup handling may trigger this behavior more frequently, but it is not ensured that other 8250 drivers aren't affected.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97482", "url": "https://ubuntu.com/security/CVE-2026-97482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET log goku_irq() handles a number of bus events under a single ep0 path. It already guards the gadget driver suspend/resume callbacks against a NULL ->driver: \tif (dev->gadget.speed != USB_SPEED_UNKNOWN \t\t\t&& dev->driver \t\t\t&& dev->driver->resume) { \t\tspin_unlock(&dev->lock); \t\tdev->driver->resume(&dev->gadget); \t\t... \t} but the very next branch unconditionally dereferences dev->driver when an INT_USBRESET arrives: \tif (stat & INT_USBRESET) { \t\tACK(INT_USBRESET); \t\tINFO(dev, \"USB reset done, gadget %s\\n\", \t\t\tdev->driver->driver.name); \t} If the controller raises INT_USBRESET before any gadget driver has been bound (or after one has been unbound), dev->driver is NULL and the printk dereferences NULL. smatch flags the inconsistency: drivers/usb/gadget/udc/goku_udc.c:1618 goku_irq() error: we previously assumed 'dev->driver' could be null (see line 1607) Fall back to a placeholder when the gadget driver is not bound. No functional change while a gadget driver is bound.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97483", "url": "https://ubuntu.com/security/CVE-2026-97483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: hcd: fix possible deadlock in rh control transfers >From within the SCSI error handler memory allocations must not trigger IO. Handling errors in UAS and the storage driver may involve resetting a device. The thread doing the reset itself relies on VM magic. However, that is insufficient, as resetting a device involves resuming it. Resumption as well as resetting involves conrol transfers to the parent of the device to be reset. That may be a root hub. Hence usbcore must heed the flags passed to usb_submit_urb() processing control transfers to root hubs. The problem exist since the storage driver has been merged.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97484", "url": "https://ubuntu.com/security/CVE-2026-97484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vhci_hcd: fix NULL deref in status_show_vhci platform_get_drvdata() can return NULL if a VHCI host controller's probe failed (e.g. due to USB bus number exhaustion). status_show_vhci() checked for a NULL pdev but not for a NULL hcd returned by platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not return NULL - it returns a pointer offset of 0x260, causing a NULL pointer dereference when that value is subsequently dereferenced. Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move status_show_not_ready() above status_show_vhci() to make it callable from the new error path without a forward declaration.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97485", "url": "https://ubuntu.com/security/CVE-2026-97485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: omfs: handle set_blocksize failures omfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97486", "url": "https://ubuntu.com/security/CVE-2026-97486", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hpfs: handle set_blocksize failures hpfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97487", "url": "https://ubuntu.com/security/CVE-2026-97487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: handle set_blocksize failures jfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97488", "url": "https://ubuntu.com/security/CVE-2026-97488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qnx4: handle set_blocksize failures qnx4 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97489", "url": "https://ubuntu.com/security/CVE-2026-97489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bfs: handle set_blocksize failures bfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the \tBUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97490", "url": "https://ubuntu.com/security/CVE-2026-97490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: affs: handle set_blocksize failures affs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97491", "url": "https://ubuntu.com/security/CVE-2026-97491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Don't sleep inside rds_ib_conn_path_shutdown New rds rdma self tests exposed a hang when tearing down the ib network configs. This is caused by the shutdown worker thread sleeping on the wait_event call, which blocks other work items in the queue. Fix this by changing wait_event to wait_event timeout, and looping until the wait check succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97492", "url": "https://ubuntu.com/security/CVE-2026-97492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed In case reconfiguration of NAN fails, we call ieee80211_handle_reconfig_failure, that marks all interfaces as not in the driver. Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces is called to destroy all the interfaces. If we have any other interface but the NAN one, for example a BSS station, then when its state (links, stations) will be removed, we won't tell the driver about this, because we will think that the interfaces are not in the driver, and then drivers might remain with dangling pointers to objects like stations and links (at least for iwlwifi this is the case). ieee80211_handle_reconfig_failure is meant to be called after we cleaned up the state in the driver, there is no reason to call it for NAN reconfiguration failure. Fix the code to just warn in such a case, as we do in other error paths in reconfig where it is too complicated to rewind.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97502", "url": "https://ubuntu.com/security/CVE-2026-97502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: avoid NULL deref of host->data in IRQ handler mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL: if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; } So we may legitimately reach the rest of the handler with host->data == NULL (and therefore data == NULL). The DATDNE branch already guards against this with an explicit \"if (data != NULL)\" check, but the subsequent TOUTRD (\"read data timeout\") and CRCWR/CRCRD (\"data CRC error\") branches dereference data unconditionally: if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); } if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... } If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this: drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914) Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch. No functional change for callers where data is non-NULL, which is the only case in which these branches did meaningful work before this change.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97506", "url": "https://ubuntu.com/security/CVE-2026-97506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ixp4xx - fix buffer chain unwind on allocation failure chainup_buffers() builds a linked list of buffer descriptors for a scatterlist. If dma_pool_alloc() fails while constructing the list, the current code sets buf to NULL and later dereferences it unconditionally at the end of the function: buf->next = NULL; buf->phys_next = 0; This can lead to a null-pointer dereference on allocation failure. If the failure happens after part of the descriptor chain has already been allocated and DMA-mapped, the partially constructed chain also needs to be released. Fix this by terminating the partially constructed chain on allocation failure and letting the callers unwind it via their existing cleanup paths. Also fix ablk_perform() to preserve the hook pointers before checking for failure, so partially built chains can be freed correctly.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97507", "url": "https://ubuntu.com/security/CVE-2026-97507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dm1105: fix missing error check for dma_alloc_coherent The return value of dm1105_dma_map(), which handles DMA memory allocation, is ignored in dm1105_hw_init(). If dma_alloc_coherent() fails, the driver will proceed using a NULL pointer for DMA transfers, leading to a kernel oops or invalid hardware access. Fix this by checking the return value and propagating -ENOMEM on failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97508", "url": "https://ubuntu.com/security/CVE-2026-97508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Set tb->root_switch to NULL when domain is stopped Similarly what we do with the firmware connection manager. This makes tb_xdp_handle_request() return error to the remote host. However, we need to make sure we keep the uuid alive so that we can reply until the whole domain is released.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97510", "url": "https://ubuntu.com/security/CVE-2026-97510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Release request if tb_cfg_request() fails in __tb_xdomain_response() If tb_cfg_request() fails setting up the request (for example the control channel is shut down already) it returns an error without calling the callback. To avoid leaking that memory, call tb_cfg_request_put() if tb_cfg_request() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-90053", "url": "https://ubuntu.com/security/CVE-2026-90053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_htb: limit htb_classify inner-class filter hops htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent. The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification. htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90054", "url": "https://ubuntu.com/security/CVE-2026-90054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix corruption of urgent data on multi-segment retransmit On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: \t/* tcp_write_xmit() */ \tlimit = mss_now; \tif (tso_segs > 1 && !tcp_urg_mode(tp)) \t\tlimit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: \t/* __tcp_retransmit_skb() */ \tlen = cur_mss * segs;\t\t/* segs > 1, no urg_mode check */ \t... \t/* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: \tseg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) \tseg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) \tseg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90055", "url": "https://ubuntu.com/security/CVE-2026-90055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90056", "url": "https://ubuntu.com/security/CVE-2026-90056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: only stop PTP if it was initialized fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90058", "url": "https://ubuntu.com/security/CVE-2026-90058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai. Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted. Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90062", "url": "https://ubuntu.com/security/CVE-2026-90062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: move hardware offload step after building the chain blob Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90063", "url": "https://ubuntu.com/security/CVE-2026-90063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90067", "url": "https://ubuntu.com/security/CVE-2026-90067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: validate banner payload length When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (`server_feat` and `server_req_feat`). Therefore, `payload_len` must be at least 16 bytes. Fix this by adding a check in `process_banner_prefix()` to reject a `payload_len` smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90068", "url": "https://ubuntu.com/security/CVE-2026-90068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix off-by-one check on the second enum channel The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80x_mux_values. The core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which defaults off.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-93245", "url": "https://ubuntu.com/security/CVE-2026-93245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: policy_int make sure list heads are initialized before fail path If profile create fails before policy_init is complete the list heads are not properly initialized causing profile_free() sanity checks to trigger the following splat. AppArmor WARN aa_policy_destroy: (((!list_empty(&policy->profiles) && (&policy->profiles)->prev != ((void *) 0x122 + (0xdead000000000000UL))))): WARNING: security/apparmor/lib.c:509 at aa_policy_destroy+0x164/0x1b0 security/apparmor/lib.c:509, CPU#0: syz.0.17/5541 Modules linked in: CPU: 0 UID: 0 PID: 5541 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:aa_policy_destroy+0x16b/0x1b0 security/apparmor/lib.c:509 Code: 85 ed 7e 4d e8 96 bc 37 fd 5b 41 5c 41 5e 41 5f 5d e9 19 27 4e 07 cc e8 83 bc 37 fd 48 8d 3d 0c f0 d3 0b 48 c7 c6 a4 eb 38 8e <67> 48 0f b9 3a e9 04 ff ff ff e8 66 bc 37 fd 48 8d 3d ff ef d3 0b RSP: 0018:ffffc9000345eaa0 EFLAGS: 00010293 RAX: ffffffff848f530d RBX: ffff88803f734800 RCX: ffff88801af2a580 RDX: 0000000000000000 RSI: ffffffff8e38eba4 RDI: ffffffff90634320 RBP: 0000000000000000 R08: 0000000000000cc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d95913 R12: dead000000000122 R13: ffff88803f734800 R14: ffff88803f734828 R15: dffffc0000000000 FS: 00007f5f6a1836c0(0000) GS:ffff88808c519000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d02407b048 CR3: 0000000012aa9000 CR4: 0000000000352ef0 Call Trace: aa_free_profile+0x9d/0x9f0 security/apparmor/policy.c:334 aa_alloc_profile+0x1e4/0x3e0 security/apparmor/policy.c:416 unpack_profile security/apparmor/policy_unpack.c:1153 [inline] aa_unpack+0x17db/0x7430 security/apparmor/policy_unpack.c:1748 aa_replace_profiles+0x226/0x2a20 security/apparmor/policy.c:1183 policy_update+0x234/0x4a0 security/apparmor/apparmorfs.c:505 profile_load+0x1cb/0x320 security/apparmor/apparmorfs.c:522 vfs_write+0x296/0xba0 fs/read_write.c:685 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f6939e0d9 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:00007f5f6a183028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f5f69625fa0 RCX: 00007f5f6939e0d9 RDX: 0000000000000041 RSI: 0000200000000400 RDI: 0000000000000003 RBP: 00007f5f6a183090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f5f69626038 R14: 00007f5f69625fa0 R15: 00007ffe23725c18", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90070", "url": "https://ubuntu.com/security/CVE-2026-90070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Return zero on status read failure st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or error path instead of acting on an invalid status value. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90071", "url": "https://ubuntu.com/security/CVE-2026-90071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: restore skb->dev on the slave failure path teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90072", "url": "https://ubuntu.com/security/CVE-2026-90072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90073", "url": "https://ubuntu.com/security/CVE-2026-90073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare \"tc qdisc add ... hhf\" succeeds with a clamped quantum but \"tc qdisc add ... hhf limit 1000\" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90074", "url": "https://ubuntu.com/security/CVE-2026-90074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp default quantum to avoid signed overflow fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90075", "url": "https://ubuntu.com/security/CVE-2026-90075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_codel: clamp default quantum and mtu fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests \"*backlog <= params->mtu\"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memory_limit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double psched_mtu() call. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90078", "url": "https://ubuntu.com/security/CVE-2026-90078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: fix length calculations and avoid invalid header warnings syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act(): !skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55 There are a few issues in tcf_skbmod_act(): 1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets). Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90081", "url": "https://ubuntu.com/security/CVE-2026-90081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in rds_cong_map_updated() rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-89780", "url": "https://ubuntu.com/security/CVE-2026-89780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: restore skb->dev on deaggregated frames rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89789", "url": "https://ubuntu.com/security/CVE-2026-89789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets().", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90088", "url": "https://ubuntu.com/security/CVE-2026-90088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90102", "url": "https://ubuntu.com/security/CVE-2026-90102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: key the data server cache on the NFS version nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4. Two deviceids on one address with different ds_versions[0].version therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL. Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90103", "url": "https://ubuntu.com/security/CVE-2026-90103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix LAYOUTSTATS send buffer exhaustion encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that. ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for. The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held. Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90107", "url": "https://ubuntu.com/security/CVE-2026-90107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free pending qentry in smc_llc_flow_stop() before memset smc_llc_flow_stop() resets a flow struct with a blind memset: \tspin_lock_bh(&lgr->llc_flow_lock); \tmemset(flow, 0, sizeof(*flow)); \tflow->type = SMC_LLC_FLOW_NONE; \tspin_unlock_bh(&lgr->llc_flow_lock); If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object. A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct. Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90114", "url": "https://ubuntu.com/security/CVE-2026-90114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: Reject descending VLAN tunnel ranges A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90126", "url": "https://ubuntu.com/security/CVE-2026-90126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf8563: fix clock provider leak on unbind pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference. The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90128", "url": "https://ubuntu.com/security/CVE-2026-90128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: fix wrong list iterated in add_direct_chain error path In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89779", "url": "https://ubuntu.com/security/CVE-2026-89779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate ef->size covers the record's name and value When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to cover it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89781", "url": "https://ubuntu.com/security/CVE-2026-89781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read in read_log_rec_buf() read_log_rec_buf() copies a log record into a caller buffer starting at \tu32 off = lsn_to_page_off(log, lsn) + log->record_header_len; log->record_header_len (and log->data_off, used for the following pages) comes verbatim from the on-disk restart area and is only checked for 8-byte alignment in is_rst_area_valid(), so off can exceed log->page_size. \"tail = log->page_size - off\" then underflows and memcpy() reads past the page_size-sized buffer returned by read_log_page(), spilling adjacent slab memory into the replay buffer. This is reachable by mounting a crafted NTFS image: BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580 Read of size 64 at addr ffff88800a877ff8 by task exploit/127 read_log_rec_buf fs/ntfs3/fslog.c:2299 log_replay fs/ntfs3/fslog.c:4216 ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324 ntfs_fill_super fs/ntfs3/super.c:1392 get_tree_bdev_flags fs/super.c:1694 __x64_sys_mount fs/namespace.c:4360 The buggy address is located 4088 bytes to the right of the 4096-byte region [ffff88800a876000, ffff88800a877000) Reject an in-page offset outside the current page before the copy. [almaz.alexandrovich@paragon-software.com: replaced the >= sign with >]", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90140", "url": "https://ubuntu.com/security/CVE-2026-90140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cuse: wait for pending RCU callbacks on module exit Since commit 053fc4f755ad (\"fuse: fix UAF in rcu pathwalks\"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory: userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text! The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour). Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90141", "url": "https://ubuntu.com/security/CVE-2026-90141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix integer overflow in ftp helper port/address parsing ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16 (hport) and into unsigned char (p[]) without checking for overflow. A crafted FTP PASV/EPSV response with an over-long port or address octet wraps the value, so the helper configures the data connection with a truncated port/address. The netfilter conntrack FTP helper had the same defect, fixed in commit 2b413fc689ba (\"netfilter: nf_conntrack_ftp: avoid u16 overflows\"). Apply the equivalent fix here: widen the port accumulator to u32 and reject values above 65535, and reject address octets above 255.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90143", "url": "https://ubuntu.com/security/CVE-2026-90143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: kcm: Hold RCU read lock while running BPF parser kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser program. Hold the RCU read lock while running the program.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90151", "url": "https://ubuntu.com/security/CVE-2026-90151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: remove callback IDR entry on client allocation failure nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown. A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it. Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client. This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90157", "url": "https://ubuntu.com/security/CVE-2026-90157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative optlen in cgroup getsockopt hook A cgroup getsockopt BPF program can shrink ctx->optlen after the kernel getsockopt handler has run. The kernel-buffer variant, used by TCP_ZEROCOPY_RECEIVE, only rejects values larger than the original length. If BPF writes a negative optlen, that value is accepted and propagated back to the TCP getsockopt code. It can then be passed to copy_to_sockptr() as a size_t and trigger the hardened usercopy bytes > INT_MAX warning. Reject negative ctx.optlen in __cgroup_bpf_run_filter_getsockopt_kern(), matching the lower-bound validation already present in the sockptr-based getsockopt hook.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90160", "url": "https://ubuntu.com/security/CVE-2026-90160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lwt_bpf: Restore reserved headroom after xmit program ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output. That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise. On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb. Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90198", "url": "https://ubuntu.com/security/CVE-2026-90198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix use-after-free in snd_card_do_free() A use-after-free was detected in snd_card_do_free() when a sound card managed by devres is unbound while a user-space application still holds an open file descriptor. For managed cards, the memory is allocated using devres_alloc(), and its release function is set to __snd_card_release(), which calls snd_card_free(). When the device is unbound, the unbind thread calls snd_card_free(), which drops a reference to the card's device. If the user thread still has an open file descriptor, the reference count does not reach zero, and the unbind thread blocks on wait_for_completion(&released). When the user thread closes the file descriptor, it drops the final reference, invoking the device release callback release_card_device(), which calls snd_card_do_free(). snd_card_do_free() performs cleanup and calls complete(card->release_completion). This wakes up the unbind thread, which returns from snd_card_free() and __snd_card_release(). The devres core then immediately frees the memory block containing the snd_card structure. Meanwhile, the user thread continues execution in snd_card_do_free() and evaluates `if (!card->managed)`. It reads the `managed` boolean from the snd_card structure that was just freed by the unbind thread, triggering a KASAN use-after-free. Fix this by caching the value of card->managed in a local variable before calling complete(). This ensures that the card pointer is not dereferenced after the unbind thread has been woken up and potentially freed the card. BUG: KASAN: use-after-free in snd_card_do_free sound/core/init.c:604 [inline] BUG: KASAN: use-after-free in release_card_device+0x1ab/0x1b0 sound/core/init.c:153 Read of size 1 at addr ffff8881912ec909 by task syz-executor130/5857 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description+0x55/0x1e0 mm/kasan/report.c:378 print_report+0x58/0x70 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 snd_card_do_free sound/core/init.c:604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c:153 device_release+0xc4/0x1f0 drivers/base/core.c:-1 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x222/0x550 lib/kobject.c:737 snd_card_file_remove+0x331/0x390 sound/core/init.c:1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c:2986 __fput+0x418/0xa50 fs/file_table.c:512 fput_close_sync+0x11f/0x240 fs/file_table.c:617 __do_sys_close fs/open.c:1511 [inline] __se_sys_close fs/open.c:1496 [inline] __x64_sys_close+0x7e/0x110 fs/open.c:1496 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90202", "url": "https://ubuntu.com/security/CVE-2026-90202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers _base_release_memory_pools() unconditionally frees every ioc->pcie_sg_lookup[] entry, including ones the setup loop never allocated after a partial failure, causing a \"bad dma\" warning on debug kernels or a NULL pointer dereference otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90203", "url": "https://ubuntu.com/security/CVE-2026-90203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check block offset is not negative If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93252", "url": "https://ubuntu.com/security/CVE-2026-93252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix circular locking dependency in ocfs2_init_acl() A lockdep warning indicates a circular locking dependency between `&oi->ip_xattr_sem` and `&journal->j_trans_barrier`: WARNING: possible circular locking dependency detected is trying to acquire lock: (&oi->ip_xattr_sem){++++}-{4:4}, at: ocfs2_init_acl+0x2fd/0x7e0 fs/ocfs2/acl.c:367 but task is already holding lock: (&journal->j_trans_barrier){.+.+}-{4:4}, at: ocfs2_start_trans+0x3ab/0x700 fs/ocfs2/journal.c:369 The deadlock involves two code paths: Path 1 (setxattr) where `ocfs2_xattr_set()` acquires `ip_xattr_sem` (write) and then starts a transaction, which acquires `j_trans_barrier` (read); and Path 2 (mkdir/mknod) where `ocfs2_mknod()` starts a transaction (`j_trans_barrier` read) and then calls `ocfs2_init_acl()`, which attempts to acquire `ip_xattr_sem` (read) on the parent directory to retrieve the default ACL. Because rw_semaphores are subject to writer priority, a pending writer on `j_trans_barrier` (e.g., the journal commit thread) can cause Path 1 to block, while Path 2 is blocked waiting for Path 1 to release `ip_xattr_sem`. The patch fixes the lock ordering by precomputing the ACL state before starting the OCFS2 transaction, while preserving POSIX ACL storage semantics and the existing inode/security initialization order. By reading the parent directory's default ACL and preparing the new inode's ACLs outside the transaction, `ip_xattr_sem` is always acquired before `j_trans_barrier`. `struct ocfs2_acl_state` encapsulates the prepared ACL state, while `ocfs2_acl_init_prepare()` and `ocfs2_acl_init_release()` avoid code duplication between `ocfs2_mknod()` and `ocfs2_init_security_and_acl()`. `ocfs2_calc_xattr_init()` and `ocfs2_init_acl()` use this precomputed state, removing internal `ip_xattr_sem` acquisition and redundant disk reads. Additionally, remove the `ip_xattr_sem` acquisition from `ocfs2_xattr_set_handle()`. This function is only used while initializing a new inode that has not yet been inserted into the inode hash or attached to a dentry, meaning there is no risk of concurrent access and the lock is unnecessary.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90209", "url": "https://ubuntu.com/security/CVE-2026-90209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/debug: Fix deadlock during unregister Unregistering an s390dbf debug area while one of the associated debugfs files is being written to can cause a deadlock: $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs write debugfs_file_get() debug_unregister() mutex_lock(debug_mutex) debugfs_remove() wait for debugfs_file_put() debug_file_ops.write() debug_input() mutex_lock(debug_mutex) ==> DEADLOCK Fix this by splitting debug_unregister() into an s390dbf and debugfs part, and running only the s390dbf part with debug_mutex locked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90214", "url": "https://ubuntu.com/security/CVE-2026-90214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: fix stream_data leak on open error In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream. Free stream_data and clear the stream pointer on the error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90216", "url": "https://ubuntu.com/security/CVE-2026-90216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubi: Fix rollback for explicit UBI device numbers ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90218", "url": "https://ubuntu.com/security/CVE-2026-90218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix WARNING in res_to_rt syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via addr_handler() during asynchronous address resolution: \" WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ib_addr process_one_req RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c:624 process_one_work kernel/workqueue.c:3375 [inline] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c:3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 \" In addr_handler(), cma_acquire_dev_by_src_ip() is called to populate id_priv->cma_dev and bind the associated ib_device to id_priv->id.device. If cma_acquire_dev_by_src_ip() returns an error (non-zero status), the ID remains unassociated with any RDMA device. Previously, rdma_restrack_add(&id_priv->res) was invoked unconditionally even when cma_acquire_dev_by_src_ip() failed, passing a resource with a NULL dev pointer and triggering the WARN_ON assertion in res_to_rt(). Fix this by only adding the resource to restrack when acquiring the device succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90219", "url": "https://ubuntu.com/security/CVE-2026-90219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Free debugfs on registration failure c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev. Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90221", "url": "https://ubuntu.com/security/CVE-2026-90221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing nci_core_init_rsp_packet_v1() and nci_core_init_rsp_packet_v2() parse the CORE_INIT_RSP packet without validating that the skb contains enough data. A malformed response (e.g. injected via virtual_ncidev) can declare a large num_supported_rf_interfaces while providing insufficient data, causing reads of uninitialized slab memory. This is later used in nci_init_complete_req(), triggering a KMSAN uninit-value warning. Add skb length checks before accessing packet fields: - Validate the skb has at least 1 byte for the status field. - Validate the skb can hold the fixed-size header before parsing. - In v2, bounds-check each variable-length rf_interface entry and its extension parameters within the parsing loop. - In v1, verify the skb is large enough for both the variable-length rf_interfaces array and the trailing rsp_2 structure.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90222", "url": "https://ubuntu.com/security/CVE-2026-90222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: hold a reference to the request skb during send_frame __pn533_send_async() publishes the command and then calls dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame can be matched to this command: the I2C threaded IRQ runs pn533_recv_frame(), which queues cmd_complete_work, and pn533_send_async_complete() frees cmd->req with consume_skb(). On the I2C transport, pn533_i2c_send_frame() still dereferences the same skb after i2c_master_send() returns, so a completion that races the send can free the skb while the transport is still using it. The request skb is owned by the command object and may be freed by command completion at any time after dev->cmd is published, so the transport send path must not assume it stays alive. Hold a temporary reference to the request skb across the send_frame() call so the transport always sees a live skb even if completion races the send. Add a pn533_send_cmd_frame() helper and use it from all three send paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90223", "url": "https://ubuntu.com/security/CVE-2026-90223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound SNL TLV parsing to the skb and add length checks nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed: - For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made \"service_name_len = length - 1\" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90224", "url": "https://ubuntu.com/security/CVE-2026-90224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix double completion race in nci_data_exchange_complete nci_close_device() and nci_rx_work can both call nci_data_exchange_complete() concurrently. After commit 4527025d440ce8 (\"nfc: nci: fix circular locking dependency in nci_close_device\") moved flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock), rx_work is no longer serialized with the explicit completion call in the close path. Both callers read the non-NULL callback pointer and invoke rawsock_data_exchange_complete(), which calls sock_put() -- but only one sock_hold() was taken, so the second sock_put() underflows the refcount and frees the socket while it is still in use. Replace the bare clear_bit(NCI_DATA_EXCHANGE) with test_and_clear_bit() so that only the first caller proceeds to invoke the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90225", "url": "https://ubuntu.com/security/CVE-2026-90225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: read llcp_sock->local under the socket lock in getsockopt nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and then dereferenced the cached pointer inside the locked region. llcp_sock_bind() assigns and clears llcp_sock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on lock_sock(), and then dereference a freed nfc_llcp_local once bind() has unwound. Move the llcp_sock->local read and the NULL check inside the lock_sock(sk) region so bind() cannot mutate or free the pointer between the load and the use.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90226", "url": "https://ubuntu.com/security/CVE-2026-90226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: avoid userspace overflow on invalid optlen nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90228", "url": "https://ubuntu.com/security/CVE-2026-90228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() When a host issues an Identify command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89784", "url": "https://ubuntu.com/security/CVE-2026-89784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6 rpcb_register_inet4() and rpcb_register_inet6() store the result of rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL. rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROC_SET encode path: rpcb_register_call() -> rpc_call_sync() -> rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel. The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890) rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910) rpcauth_wrap_req_encode (net/sunrpc/auth.c:745) call_encode (net/sunrpc/clnt.c:1966) __rpc_execute (net/sunrpc/sched.c:952) rpc_run_task (net/sunrpc/clnt.c:1243) rpc_call_sync (net/sunrpc/clnt.c:1272) rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500) svc_generic_rpcbind_set nfsd_rpcbind_set svc_register svc_setup_socket svc_addsock write_ports nfsctl_transaction_write vfs_write The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFP_KERNEL kstrdup() in rpc_sockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check. Mirror that handling: bail out with -ENOMEM when rpc_sockaddr2uaddr() returns NULL, before the address is fed into the encoder.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90245", "url": "https://ubuntu.com/security/CVE-2026-90245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: kyro: Validate overlay viewport coordinates The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90248", "url": "https://ubuntu.com/security/CVE-2026-90248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: fix teardown of an adopted proto on insert-race loss In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90249", "url": "https://ubuntu.com/security/CVE-2026-90249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes The IIO core does not filter duplicate writes to the event enable attribute, so writing the same value twice invokes write_event_config() twice. Enabling twice leaks a runtime PM reference, preventing the device from ever suspending again; disabling twice underflows the usage count and triggers a \"Runtime PM usage count underflow\" warning. Bail out early when the requested state matches the current state. While at it, switch to pm_runtime_resume_and_get() so a failed resume is propagated to userspace instead of silently marking the event enabled.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90251", "url": "https://ubuntu.com/security/CVE-2026-90251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: \tif (skb->len < sizeof(*rp)) { \t\tbt_dev_err(hdev, \"MSFT supported features length mismatch\"); \t\tgoto failed; \t} evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so \tmsft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, \t\t\t\t GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes (\"skb->len=11 evt_prefix_len=255\", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with \"MSFT event prefix length mismatch\" and msft->evt_prefix is left unset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90257", "url": "https://ubuntu.com/security/CVE-2026-90257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: avoid OOB read of build info string The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read Build Information) and hands the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length. A backend that answers with status only leaves that pointer past the end of the received data, so the walk reads adjacent slab memory until it meets a NUL. Those bytes reach the kernel log and the firmware-info debugfs file. To fix this, print the string with a bounded \"%.*s\" limited to skb->len - 1. A short or unterminated response then prints as much as arrived instead of failing setup. This mirrors commit dd068ef04412 (\"Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()\"), which fixed the identical pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90274", "url": "https://ubuntu.com/security/CVE-2026-90274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: etm4x: fix underflow for usage of (nrseqstate - 1) According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR is implemented only when TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000. IOW, the number of usage in the initialisation or setting TRCSEQEVR with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000. Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR relevant fields setup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90281", "url": "https://ubuntu.com/security/CVE-2026-90281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend Runtime PM must be enabled before creating the PHY, since phy_create() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference. Take a runtime PM usage reference with pm_runtime_get_noresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90283", "url": "https://ubuntu.com/security/CVE-2026-90283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: release subpool on fill_super failure hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size mount options are specified. hugepage_new_subpool() may also reserve huge pages for min_size. If root dentry creation fails after the subpool is created, the failure path frees the subpool with kfree(). This bypasses hugepage_put_subpool() and can leave min_size reservations charged. Use hugepage_put_subpool() on the failure path, matching the normal put_super path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90284", "url": "https://ubuntu.com/security/CVE-2026-90284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: do not queue completed sysfs fallback requests fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to pending_fw_head. device_add() publishes the fallback loading interface, so a userspace helper which discovers the device by scanning sysfs can write 0 to the loading attribute and complete the request before it is queued as pending. In that interleaving firmware_loading_store() calls fw_state_done() while pending_list still points to itself, so it cannot remove an entry from pending_fw_head. The subsequent unconditional list_add() then queues an already-completed fw_priv. Once the request is released, pending_fw_head can retain a pointer to freed memory and the next fallback request can fault while validating the list. Only in-flight fallback requests need suspend or reboot abort handling. If the request is already DONE after device_add(), return success from the fallback path without sending another uevent, waiting again, or queueing it as pending. This preserves the invariant that pending_fw_head contains only active fallback requests.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90285", "url": "https://ubuntu.com/security/CVE-2026-90285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path qla2x00_sysfs_read_vpd() called ha->isp_ops->read_optrom() a second time after releasing optrom_mutex. The repeated read is redundant and, unlike the first, runs without optrom_mutex held, exposing flash access to concurrent optrom operations. Drop the duplicate call.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90286", "url": "https://ubuntu.com/security/CVE-2026-90286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx6: Use PFP on the compute queues too On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90290", "url": "https://ubuntu.com/security/CVE-2026-90290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Restore DAIF state on error Sashiko AI has reported that if swsusp_mte_save_tags() for some reason fails we return from swsusp_arch_suspend() with DAIF being masked - that is not what we'd expect. Restore the saved DAIF state before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93256", "url": "https://ubuntu.com/security/CVE-2026-93256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: mask DAIF before restoring hibernated kernel The arm64 hibernate code manages the exception masking in an unsound way, leading to potential crashes and/or warnings during resume. When a hibernation image is saved in `swsusp_arch_suspend()`, all DAIF exceptions are masked (by virtue of `local_daif_save()`), and the suspended image is saved assuming that all DAIF exceptions will remain masked when the image is restored. When a hibernation image is resumed by `swsusp_arch_resume()`, only interrupts are masked (by virtue of `local_irq_disable()` in `resume_target_kernel()`). When pseudo-NMI is enabled the DAIF.IF bits will be clear, and regardless of pseudo-NMI the DAIF.DA bits will be clear. This means that there are two problems: (1) It is possible to take Debug, SError, or pseudo-NMI exceptions during the resume process. This is unsafe, as during the resume process both the old ane new kernels will tranisently be in an inconsistent state, and swsusp_arch_suspend_exit() won't retain an executable mapping of any exception vectors. Any exception taken here will be fatal and silent. (2) When re-entering the resumed kernel, some DAIF bits will be clear unexpectedly. This permits Debug, SError, or pseudo-NMI exceptions to be taken for a short period while the resumed kernel is not yet in a consistent state. This is detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING. Avoid these issues by masking all DAIF exceptions during resume.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90292", "url": "https://ubuntu.com/security/CVE-2026-90292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix use-after-free in siw_accept() siw_accept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it. The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association. Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90293", "url": "https://ubuntu.com/security/CVE-2026-90293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: post the full-feature receive buffers after session registration isert_put_login_tx() posts the full-feature receive buffers before __transport_register_session() runs, so an initiator that does not wait for the final Login Response can still have a SCSI command executed against an se_session whose se_tpg is NULL - the same oops as the previous patch, at target_submit+0xbe. Post them from isert_get_rx_pdu(), which the previous patch already uses to send that response, and post them before that send: the receive queue is filled at the moment the initiator is told it may use it. Allocating there keeps the existing property that a memory allocation failure cannot happen once the final Login Response is on the wire. The receive queue is already empty between the final Login Request and isert_post_recvm(); this moves the second point later, from a median of 92 us to 172 us over 1200 logins. Only an initiator that sends before it has been told to can reach that window, and on IB and RoCE its send is retried there until the buffers appear - isert_rdma_accept() asks for rnr_retry_count = 7. iWARP has no RNR flow control, so there the same send terminates the connection instead. Measured over rxe, 400 login cycles per run, with an initiator that does not wait: an instrumented build counted no entries to isert_recv_done() before the buffers are posted in 10 runs, where that initiator oopsed 8 of 10 unpatched runs and 5 of 10 with only the previous patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90294", "url": "https://ubuntu.com/security/CVE-2026-90294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: delay the final Login Response until the session is registered isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90295", "url": "https://ubuntu.com/security/CVE-2026-90295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: \timx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), \t\t\t\t GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90296", "url": "https://ubuntu.com/security/CVE-2026-90296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix devres accumulation across driver rebind imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system. Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver(). That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release. Tested by rebinding the driver on qemu's mcimx6ul-evk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90297", "url": "https://ubuntu.com/security/CVE-2026-90297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: crtc: Propagate layer initialization error sun4i_crtc_init() returns plain NULL when layer initialization fails, while all its other error paths return an error pointer. The only caller, sun4i_tcon_bind(), checks the result with IS_ERR() and happily continues with tcon->crtc set to NULL. sun4i_rgb_init() and sun4i_lvds_init() then dereference it in drm_crtc_mask(), which oopses. Return the error pointer instead.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90298", "url": "https://ubuntu.com/security/CVE-2026-90298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: tcon: Drop TCON TOP device reference of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90302", "url": "https://ubuntu.com/security/CVE-2026-90302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: synchronize heartbeat callbacks with o2net teardown Patch series \"ocfs2: harden heartbeat teardown races\". This series fixes two OCFS2 heartbeat/o2net teardown races found by KASAN. This patch (of 2): Heartbeat callbacks stay registered while configfs local-node teardown enters o2net_stop_listening(). A node-down event can still run through o2net_disconnect_node() and o2net_set_nn_state() while teardown is destroying o2net_wq, so the later queue/flush operations can hit a dead workqueue. KASAN has caught this as a slab-use-after-free in __queue_work() with the call chain: KASAN slab-use-after-free in __queue_work+0x56/0xa90 Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __queue_work+0x56/0xa90 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __queue_delayed_work+0x58/0x1e0 queue_delayed_work_on+0xb4/0xc0 o2net_set_nn_state+0x467/0x840 o2net_disconnect_node+0x7b/0xe0 o2net_hb_node_down_cb+0x54/0x60 o2hb_run_event_list+0x236/0x2d0 o2hb_check_slot+0xad4/0xbc0 lock_release+0xc8/0x290 o2hb_check_slot+0x9ea/0xbc0 trace_hardirqs_on+0x18/0x130 o2hb_do_disk_heartbeat+0x646/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) __lock_acquire+0x466/0x2260 lockdep_hardirqs_on_prepare+0xea/0x1a0 ktime_get_with_offset+0xe9/0x230 o2hb_thread+0x14e/0x770 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 __switch_to+0x2e9/0x730 ret_from_fork_asm+0x1a/0x30 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x292/0x760 __alloc_workqueue+0x736/0xc60 alloc_workqueue_noprof+0xb1/0x110 o2net_start_listening+0xe5/0x430 o2nm_node_local_store+0x184/0x310 configfs_write_iter+0x18a/0x210 vfs_write+0x469/0x810 ksys_write+0xd2/0x170 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 rcu_core+0x4f4/0x1320 handle_softirqs+0x156/0x660 queue_delayed_work_on o2net_set_nn_state o2net_disconnect_node o2net_hb_node_down_cb o2hb_run_event_list Keep heartbeat callbacks registered so quorum state still tracks node state, but stop them from driving o2net reconnect/disconnect work once local teardown starts. Mark the transport offline before destroying o2net_wq, wait for any in-flight heartbeat callback to finish, and delay bring-up replay until the new local node is published through o2nm_this_node(). The replay also has to stay serialized with heartbeat callback delivery. Otherwise a live-node snapshot can be copied, a real hb_down callback can install -ENOTCONN for a peer, and the stale replay can call o2net_hb_node_up() for that same peer and queue reconnect work even though heartbeat is already down. The buggy scenario involves two paths, with each column showing the order within that path: local-node teardown: heartbeat node-down callback: 1. configfs local-off enters 1. o2hb_run_event_list() invokes o2net_stop_listening(). o2net_hb_node_down_cb(). 2. teardown heads for 2. the callback reaches destroy_workqueue(o2net_wq). o2net_disconnect_node() and o2net_set_nn_state(). 3. teardown destroys and NULLs 3. the callback flushes or queues o2net_wq. work through o2net_wq.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90303", "url": "https://ubuntu.com/security/CVE-2026-90303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults When CONFIG_DEBUG_USER=y, and cmdline \"user_debug=31\" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the \"oops\" state, acquiring a lock may risk a deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90307", "url": "https://ubuntu.com/security/CVE-2026-90307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it: BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8) Without KASAN the returned bytes are whatever is next in the slab. One run returned \".strtab\". rsp->data[3] in srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90314", "url": "https://ubuntu.com/security/CVE-2026-90314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression \"table_sz - offset - sizeof(*hdr)\", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90316", "url": "https://ubuntu.com/security/CVE-2026-90316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/omap: dsi: Do not copy isr table To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90318", "url": "https://ubuntu.com/security/CVE-2026-90318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: release buffer head after rebuilding parent fat_scan_logstart() leaves the matching directory entry's buffer head in sinfo.bh for the caller to release, just like fat_scan(). fat_rebuild_parent() uses the directory entry to rebuild the parent inode for the nostale_ro NFS export path, but does not release sinfo.bh after a successful scan. Release it once fat_build_inode() has consumed the directory entry data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90319", "url": "https://ubuntu.com/security/CVE-2026-90319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: clear mport->net when rio_add_net() fails rio_alloc_net() stores the newly allocated rio_net in mport->net before rio_scan_alloc_net() registers the device. If rio_add_net() fails, rio_scan_alloc_net() drops the device reference with put_device(), which releases the rio_net through the device release callback. However, mport->net is left pointing at the freed object. A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rio_net again. Clear mport->net in the rio_add_net() failure path, matching the cleanup done for the destID table allocation failure path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90327", "url": "https://ubuntu.com/security/CVE-2026-90327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: do not write beyond optlen in getsockopt pep_getsockopt() clamps the reported length to the caller's buffer with min_t(), but then stores the value with put_user(val, (int __user *) optval), which always writes sizeof(int) bytes. A getsockopt() call with an optlen smaller than sizeof(int) thus reports the clamped length yet writes a full int, one to three bytes past the user buffer. Write the value with copy_to_user() bounded by len, so at most optlen bytes are copied, matching the length reported back to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90329", "url": "https://ubuntu.com/security/CVE-2026-90329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: synchronize input before cleaning up a failed probe hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90334", "url": "https://ubuntu.com/security/CVE-2026-90334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: clear cdev pointer after cdev_add() failure tty_cdev_add() drops the cdev reference when cdev_add() fails, but leaves driver->cdevs[index] pointing to freed memory. tty_unregister_device() later passes that stale pointer to cdev_del(), causing a use-after-free. Clear the slot after dropping the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90341", "url": "https://ubuntu.com/security/CVE-2026-90341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: coreboot: Validate table bounds The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90348", "url": "https://ubuntu.com/security/CVE-2026-90348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90360", "url": "https://ubuntu.com/security/CVE-2026-90360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: use system_freezable_wq for init complete work schedule_delayed_work() uses system_wq, which is non-freezable, allowing regulator_init_complete_work to run concurrently with system suspend. This work fires ~30s after boot to disable unused regulators via I2C. When it races with PM suspend, the I2C adapter may already be suspended, triggering a -ESHUTDOWN warning in __i2c_transfer(): WARNING: ... at __i2c_transfer+0x36c/0x3c8 Call trace: __i2c_transfer i2c_transfer regmap_i2c_write _regmap_update_bits regulator_disable_regmap _regulator_do_disable regulator_late_cleanup regulator_init_complete_work_function process_one_work Switch to system_freezable_wq so the work is frozen before any device is suspended, eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90361", "url": "https://ubuntu.com/security/CVE-2026-90361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix leak in ath11k_service_ready_ext_event() Currently, during ath11k_service_ready_ext_event() processing, svc_rdy_ext.mac_phy_caps can be allocated during TLV parsing. This is a temporary allocation that is freed on the success path, but not on the error path. If parsing succeeds far enough to allocate mac_phy_caps and then fails on a later TLV, the allocation leaks. So free the allocation on the error path. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90362", "url": "https://ubuntu.com/security/CVE-2026-90362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Drop dev_pm_opp_set_rate(0) dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Drop the explicit call to it. Every call site of ops->link_clk_disable() is followed by pm_runtime_put(), so the power vote will be rescinded if deemed safe. Patchwork: https://patchwork.freedesktop.org/patch/742783/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90372", "url": "https://ubuntu.com/security/CVE-2026-90372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss If a peer's VHT/HE MCS map has no supported spatial stream (all fields 0x3), the loop exits with nss == 0 and the function returned (u8)-1 (255), which was then written into the firmware sta_rec_bf beamforming fields. Clamp the result to 0.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90378", "url": "https://ubuntu.com/security/CVE-2026-90378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt792x: Fix memory leak in SDIO TX path When tx_prepare_skb() returns an error in the SDIO TX path, the skb is not freed, leading to a memory leak. This can occur when zero-length frames (such as WNM NULL frames) are dropped to prevent potential hardware TX hangs. Fix this by properly releasing the skb with ieee80211_tx_status_ext() when tx_prepare_skb() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90382", "url": "https://ubuntu.com/security/CVE-2026-90382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set. Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf (\"mt76x2: remove some harmless WARN_ONs in tx status and rx path\") did for the neighboring rx and tx status paths. Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93261", "url": "https://ubuntu.com/security/CVE-2026-93261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/lockdep: Fix NULL pointer dereference in __lock_set_class() register_lock_class() can return NULL when the lock class pool is exhausted, graph_lock() fails, or key validation fails. However, __lock_set_class() uses the return value directly in pointer arithmetic without a NULL check: class = register_lock_class(lock, subclass, 0); hlock->class_idx = class - lock_classes; If class is NULL, this computes a wild offset that corrupts hlock->class_idx. The subsequent reacquire_held_locks() call will invoke hlock_class() with this corrupted index, leading to a NULL or out-of-bounds pointer dereference. Add the missing NULL check, consistent with how __lock_acquire() already handles this case at the same call site.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93283", "url": "https://ubuntu.com/security/CVE-2026-93283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix device_register() error path When device_register() fails in i3c_master_register_new_i3c_devs(), put_device() is called to drop the reference taken by device_register(). That drops the last reference, so the device's release callback i3c_device_release() runs and frees the i3c_device. Two problems follow from that: i3c_device_release() does WARN_ON(i3cdev->desc), so it warns because desc->dev->desc still points back at the descriptor. Clear it before calling put_device(). After put_device() frees the i3c_device, desc->dev is left pointing at freed memory, so clear desc->dev as well. That prevents, for example, i3c_master_unregister_i3c_devs() seeing desc->dev as non-NULL and dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90386", "url": "https://ubuntu.com/security/CVE-2026-90386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90388", "url": "https://ubuntu.com/security/CVE-2026-90388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Check atomic pool allocation result directly The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90391", "url": "https://ubuntu.com/security/CVE-2026-90391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone dmirror_fault() is called from the dmirror_read() and dmirror_write() retry loops after dmirror_do_read() or dmirror_do_write() finds a missing device page table entry. If the mirrored mm has already exited, mmget_not_zero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress. Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90393", "url": "https://ubuntu.com/security/CVE-2026-90393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF in bpf_netns_link_update_prog In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90394", "url": "https://ubuntu.com/security/CVE-2026-90394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sc2731_charger: cancel work on remove The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released. Set the platform drvdata used by remove, then cancel the work after unregistering the notifier. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90395", "url": "https://ubuntu.com/security/CVE-2026-90395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: isp1704_charger: cancel work on remove The USB notifier and initial VBUS detection can schedule isp->work. The remove path unregisters the notifier and power supply, but does not wait for queued or running work before tearing down the power supply state. Cancel the work after unregistering the notifier. Do this before unregistering the power supply. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93262", "url": "https://ubuntu.com/security/CVE-2026-93262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5-ppl: fix use-after-free in ppl_do_flush() The loop in ppl_do_flush() continues iterating after calling ppl_io_unit_finished(), touching io->pending_flushes and leading to a use-after-free. Add a break statement to stop the loop once io is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90403", "url": "https://ubuntu.com/security/CVE-2026-90403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix error path in rtl_pci_probe() In the last error path in rtl_pci_probe(), the cleanup functions are skipped due to a wrong goto label. Moreover, the successful call to rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to be reverted. Fix this issue by updating the labels and adding the relevant cleanup functions to the last error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90411", "url": "https://ubuntu.com/security/CVE-2026-90411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request __nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the rsp_iu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmd_iu unmapped and still marked the op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call .exit_request() when .init_request() fails, the cmd_iu mapping is leaked for every op whose rsp_iu mapping fails. Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and returns the error without marking the op idle, so it stays in the FCPOP_STATE_UNINIT state set by the initial memset().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90413", "url": "https://ubuntu.com/security/CVE-2026-90413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject login PDUs declaring more data than was received isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), \tpayload_length = ntoh24(login_req->dlength); \ttmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90414", "url": "https://ubuntu.com/security/CVE-2026-90414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject PDUs declaring more data than was received isert_recv_done() hands each received PDU to the opcode handlers without ever looking at wc->byte_len, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) - out of the fixed-size descriptor: isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len); Because the declared length is never checked against wc->byte_len, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer. Nothing upstream of isert closes this door: - __iscsit_check_dataout_hdr() bounds the inbound payload against conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check. - iscsi_set_connection_parameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsi_check_acceptor_state(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling. - isert never clamps the negotiated value to its own fixed receive descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated. The imm_data_len == data_len path is more than an over-read: it aliases the receive descriptor via sg_set_buf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated. Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN: BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 isert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout() (ib_isert.c:1160), inlined through isert_rx_opcode(). Validate wc->byte_len against the framing in isert_recv_done() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISER_HEADERS_LEN (commit 29e7b925ae6d (\"IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN\")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all. isert reads the data segment from a fixed offset: isert_get_data() returns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum against wc->byte_len bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything furth ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90415", "url": "https://ubuntu.com/security/CVE-2026-90415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: free STAG index when TPT entry write fails write_tpt_entry() allocates a new STAG index with c4iw_get_resource() and bumps stats.stag.cur before programming the entry. When write_adapter_mem() fails, it returns the error without releasing the index or reversing the statistic. No MR is inserted into rhp->mrs, so deregistration never reclaims it, leaking the index until device teardown. Record whether this call allocated the index and, on a failed write, return it to tpt_table and decrement stats.stag.cur. Key the rollback on both the write error and that flag, not the error alone: a non-reset update carries a caller-owned STAG that this call did not allocate and must not free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90416", "url": "https://ubuntu.com/security/CVE-2026-90416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed \"%d\" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as \"-2147483648\\n\" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with \"%u\" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90419", "url": "https://ubuntu.com/security/CVE-2026-90419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent out-of-bounds read in super root block parsing super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90420", "url": "https://ubuntu.com/security/CVE-2026-90420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix infinite loop in nilfs_clean_segments() syzbot reported a hung task in nilfs_transaction_begin(). This occurs because the cleaner ioctl falls into an infinite loop if nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device is remounted as read-only after an I/O error). Currently in nilfs_clean_segments(), if err is non-zero, it logs the error and sleeps but doesn't abort when it encounters a terminal error like -EROFS. This causes the thread to loop forever. Fix this by breaking out of the loop if nilfs_segctor_construct() returns -EROFS. This matches the behaviour in nilfs_segctor_write_out(), which also handles -EROFS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93264", "url": "https://ubuntu.com/security/CVE-2026-93264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Fix PBL chunk length computation On register MR, when creating the PBL, if it's an indirect PBL we create a chunk list to hold the PBL pages pointers. Each chunk is 4KB in size and can hold 510 addresses (EFA_PTRS_PER_CHUNK) and has a 12-byte control buffer at the end of it holding the next chunk's pointer and its length. If the PBL number of pages is a multiple of EFA_PTRS_PER_CHUNK, the calculated last chunk length is wrongly computed as 0, even though that chunk is fully populated with 510 real page pointers. This wrong length is used both to DMA map the chunk and is propagated to the device, causing the device to see the chunk as empty and reject the memory registration. Fix the calculation so it will be performed only if the number of pages isn't a multiple of EFA_PTRS_PER_CHUNK, if it is, its already handled in the above loop correctly. Also prevent out-of-bounds reach in the chunks array in such scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89782", "url": "https://ubuntu.com/security/CVE-2026-89782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject restart table growth beyond U16_MAX entries During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): \trt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90431", "url": "https://ubuntu.com/security/CVE-2026-90431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: Prevent crash handling to race with rproc_del() There's no synchronization between rproc_crash_handler_work() and rproc_del(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues. To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds. In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a \"deleting\" flag is introduced. This is similar to the RPROC_DELETE state that was introduced to ensure that \"start\" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the \"state\" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90434", "url": "https://ubuntu.com/security/CVE-2026-90434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: release zisofs block pointer buffer head zisofs_fill_pages() reads the compressed block pointer table. The error paths release the current buffer_head, the loop also releases the old buffer_head when it advances. However, the success path leaves the last buffer_head referenced. Release it before returning success.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90435", "url": "https://ubuntu.com/security/CVE-2026-90435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix integer overflow of user QP buffer size set_user_buf_size() computes the QP buffer size by left-shifting the user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers. A sufficiently large rq.wqe_cnt causes signed integer overflow, which is undefined behavior, and yields a small or negative buf_size, causing ib_umem_get() to map a buffer smaller than the hardware will actually write into. Replace the shifts and addition with check_shl_overflow() and check_add_overflow(), rejecting invalid user inputs. Moreover, guard the identical shift computing qp->sq.offset in _create_user_qp() before set_user_buf_size() is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92476", "url": "https://ubuntu.com/security/CVE-2026-92476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Initialize completion before requesting IRQ kmb_ocs_aes_probe() requests the device IRQ before initializing irq_completion. Once the handler is registered it can run immediately, and ocs_aes_irq_handler() unconditionally calls complete(). An interrupt in this window would therefore use an uninitialized completion. Initialize the completion before requesting the IRQ, as the sibling OCS HCU and ECC drivers already do.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89785", "url": "https://ubuntu.com/security/CVE-2026-89785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89787", "url": "https://ubuntu.com/security/CVE-2026-89787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check dir entry fits before reading the hash trailer in ext4_search_dir() For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4_DIRENT_HASHES()), at an offset derived from de->name_len. On the sb_no_casefold_compat_fallback() path ext4_match() reads that trailer, but ext4_search_dir()'s by-hand pre-check only tests de->name + de->name_len <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4_DIRENT_HASHES(de) lands past the block end, so ext4_match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object: BUG: KASAN: use-after-free in ext4_match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4_match (fs/ext4/namei.c:1435) ext4_search_dir (fs/ext4/namei.c:1470) __ext4_find_entry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4_lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filename_lookup (fs/namei.c:2842) vfs_statx (fs/stat.c:353) __do_sys_newfstatat (fs/stat.c:538) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4_match(). This is the same bound ext4_check_dir_entry() already enforces via ext4_dir_rec_len(), so no well-formed entry is rejected. The other caller, ext4_find_dest_de(), runs ext4_check_dir_entry() first and is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92494", "url": "https://ubuntu.com/security/CVE-2026-92494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix buffer_head leak in ext4_init_orphan_info ext4_init_orphan_info() reads orphan file blocks with ext4_bread() and stores the returned buffer_head in oi->of_binfo[i].ob_bh. If ext4_bread() succeeds but the orphan block magic or checksum validation fails, the function jumps to out_free. However, the old out_free loop starts releasing buffers from i - 1, so the current buffer_head at index i is skipped. This leaks the buffer_head reference obtained by ext4_bread() on the bad magic and bad checksum error paths. Fix this by tracking the number of successfully read buffer_heads and releasing exactly those buffer_heads on the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92496", "url": "https://ubuntu.com/security/CVE-2026-92496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx() Currently, in ath11k_wmi_tlv_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Add an upfront length check before dereferencing skb->data as a wmi_cmd_hdr. The check is placed before the trace_ath11k_wmi_event() call to preserve the existing trace semantics (tracing the full raw WMI event including the header), unlike the analogous ath12k fix which could use skb_pull_data() directly. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92498", "url": "https://ubuntu.com/security/CVE-2026-92498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: avoid buffer overreads in WMI event handlers The following WMI event handlers currently read from the event buffer without first verifying that the message was large enough to hold the expected event: ath6kl_wmi_scan_complete_rx() ath6kl_wmi_addba_req_event_rx() ath6kl_wmi_delba_req_event_rx() Add length checks to prevent overread.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92501", "url": "https://ubuntu.com/security/CVE-2026-92501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drain in-flight DIO before buffered write fallback generic/746 started failing intermittently on ext3 (no-extent inodes). The test triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO. Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied, post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback) ----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared() iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async) dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0, 8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range() iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages() invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO) This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92504", "url": "https://ubuntu.com/security/CVE-2026-92504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int3400: clean up ODVP on probe failures evaluate_odvp() creates per-ODVP sysfs files before the thermal zone and later probe resources are registered. The current unwind path only calls cleanup_odvp() from the late sysfs failure path, so failures after evaluate_odvp() but before that label, including thermal_tripless_zone_device_register() failures, leave the ODVP files and storage behind. Move the ODVP cleanup to the common ART/TRT unwind path so every failure after evaluate_odvp() releases the ODVP state. Also clear the cached ODVP pointers in cleanup_odvp(), because evaluate_odvp() can already call it for partial setup failures while probe continues.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92508", "url": "https://ubuntu.com/security/CVE-2026-92508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_free_cq() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93268", "url": "https://ubuntu.com/security/CVE-2026-93268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: skip extra isize expansion during mount to prevent deadlock ext4_try_to_expand_extra_isize() is called from __ext4_mark_inode_dirty() while holding an active jbd2 handle. During mount (!SB_ACTIVE), the expand path may move xattrs to external blocks and release ea_inodes via iput(). When !SB_ACTIVE, iput() calls write_inode_now() which acquires s_writepages_rwsem, creating a circular lock dependency: s_writepages_rwsem --> jbd2_handle --> xattr_sem --> s_writepages_rwsem This can be triggered via: ext4_process_orphan() -> ext4_truncate() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() or: ext4_evict_inode() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() Skip expansion when !SB_ACTIVE. This is a minor loss of functionality (extra isize won't grow for these inodes during mount), which e2fsck can resolve later if needed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89786", "url": "https://ubuntu.com/security/CVE-2026-89786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bounds read in ext4_read_inline_dir() ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: \tdir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic \".\" and \"..\" land at their block-dir offsets. A dirent is formed at \"dir_buf + pos - extra_offset\", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92521", "url": "https://ubuntu.com/security/CVE-2026-92521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92522", "url": "https://ubuntu.com/security/CVE-2026-92522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: validate MADT IOAPIC entry bounds The IOAPIC hotplug lookup parses both MADT and _MAT records directly. The MADT walk previously used a subtable's declared length to advance the cursor after only locating a generic header. The _MAT path likewise passed a generic header to the IOAPIC helper. Validate that a current record has a complete generic header, that its declared length is contained in the available record range, and that a typed IOAPIC record contains the full fixed IOAPIC body before reading its fields. Use the same relation for both MADT and _MAT provider paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92524", "url": "https://ubuntu.com/security/CVE-2026-92524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc() When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93037", "url": "https://ubuntu.com/security/CVE-2026-93037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Propagate sdma_txinit_ahg() errors set_txreq_header_ahg() ignores the return value of sdma_txinit_ahg(). If sdma_txinit_ahg() fails, it returns before initializing tx->txreq. However, set_txreq_header_ahg() ignores the error and returns the AHG change count, causing the caller to continue processing the request as though initialization had succeeded. Propagate sdma_txinit_ahg() failures to the caller and abort request processing when initialization fails. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93039", "url": "https://ubuntu.com/security/CVE-2026-93039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: Keep link pointers valid on realloc failure meson_card_reallocate_links() grows the DAI link and private data arrays with two consecutive krealloc() calls and updates the owner pointers only after both calls have succeeded. A successful krealloc() may move the data: it frees the old block and returns a new one. When that happens for the link array and the second krealloc() then fails, card->dai_link still points to the block that krealloc() already freed, and the error path frees the new block too. The probe error path then calls meson_card_clean_references(), which dereferences card->dai_link and kfree()s it again, resulting in a use-after-free and a double free. Commit card->dai_link and card->num_links right after the first krealloc() succeeds, so the pointer always refers to a valid allocation that meson_card_clean_references() can walk and free. krealloc() with __GFP_ZERO zero-initializes the added entries, so walking them on the error path is safe. With both failure paths reduced to a plain return, drop the goto labels and the error message.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93040", "url": "https://ubuntu.com/security/CVE-2026-93040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize channel state checks pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent. For example, pause() can observe EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93041", "url": "https://ubuntu.com/security/CVE-2026-93041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize abort state updates dw_edma_abort_interrupt() drops vc.lock before changing request and status. issue_pending() can acquire the lock in that small window, observe the old busy state, and skip starting queued descriptors. Then the abort handler overwrites the channel status as idle, leaving the new descriptors stranded for good. Keep descriptor completion and the state transition in the same critical section.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93046", "url": "https://ubuntu.com/security/CVE-2026-93046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: software node: Fix software_node_get_reference_args() with index -1 The bounds check for the index passed to software_node_get_reference_args() was failing when passed UINT_MAX, this in turn would lead to an out of bound access in the property array. Fix the bound check to also cover the UINT_MAX case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93048", "url": "https://ubuntu.com/security/CVE-2026-93048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior. Commit 5daa7b21496a (\"mtd: prepare partition add and del functions for ioctl requests\") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e (\"mtd: add a flags for partitions which should just leave smth. after them\") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value. With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers: WARN_ON((!mtd->erasesize || !master->_erase) && \t\t!(mtd->flags & MTD_NO_ERASE)) in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the \"out of reach\" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error. Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93049", "url": "https://ubuntu.com/security/CVE-2026-93049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdswap: Avoid freeing registered blktrans device twice In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice. add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev. The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89777", "url": "https://ubuntu.com/security/CVE-2026-89777", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio_msi_cap_len() lazily allocates the per-device MSI permission table: \tvdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); \tif (!vdev->msi_perm) \t\treturn -ENOMEM; \tret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); \tif (ret) { \t\tkfree(vdev->msi_perm); \t\treturn ret;\t\t/* vdev->msi_perm left dangling */ \t} When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at \"if (vdev->msi_perm) return len;\" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93051", "url": "https://ubuntu.com/security/CVE-2026-93051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ad525x_dpot: use driver core groups for sysfs files ad_dpot_probe() creates per-RDAC sysfs files manually and then optionally creates the command sysfs group. This leaves probe responsible for rolling back partial sysfs state and makes remove responsible for matching every file that probe created. Move the device attributes into driver core dev_groups for the I2C and SPI drivers and use an is_visible() callback to expose only the attributes supported by the probed device. With this shape, the driver core creates the sysfs files only after probe succeeds and removes them before the remove callback frees the driver data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93052", "url": "https://ubuntu.com/security/CVE-2026-93052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: bcm-vk: Use acquire/release for msgq_inited bcm_vk_sync_msgq() fills the message queue information and then sets msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the message queues and their cached queue information. atomic_set()/atomic_read() do not order those accesses. A reader can see msgq_inited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate. Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the gate and does not publish queue state to readers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93053", "url": "https://ubuntu.com/security/CVE-2026-93053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: speakup: keyhelp: guard letter_offsets possible out-of-range indexing help_init() builds letter_offsets[] by using the first byte of each function name as an index via `(start & 31) - 1`. If function_names are overridden from sysfs (root) with a name starting outside [a–z], the index underflows or exceeds the array, leading to OOB write. Function names can be overridden with the following commands as root: modprobe speakup_soft echo \"0 _bad\" > /sys/accessibility/speakup/i18n/function_names # then press Insert+2 on /dev/tty This fix checks the first letter in help_init(), and if it is not in the [a–z] range the function returns an error to the caller. Eventually this error is propagated to drivers/accessibility/speakup/main.c:2217, which causes a bleep sound.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93054", "url": "https://ubuntu.com/security/CVE-2026-93054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same \"device gone\" state as normal uio_unregister_device().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93055", "url": "https://ubuntu.com/security/CVE-2026-93055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: UDF symlink pathComponent header OOB read udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93056", "url": "https://ubuntu.com/security/CVE-2026-93056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: remove broken string configfs attributes The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for the fn_play, fn_cap, and fn_cntl string options. The store function contains an inverted null check on the kstrndup() return value. This means every write attempt returns -ENOMEM on success and dereferences a NULL pointer on allocation failure. The attributes have been broken and unused for many years. Remove the UAC1_STR_ATTRIBUTE macro and the three attributes it generated. The internal defaults (FILE_PCM_PLAYBACK, FILE_PCM_CAPTURE, FILE_CONTROL) set in f_audio_alloc_inst() are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93061", "url": "https://ubuntu.com/security/CVE-2026-93061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Avoid stack over-read in debug output helpers host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93067", "url": "https://ubuntu.com/security/CVE-2026-93067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clamps an AUX read to the payload limit: \tsize_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: \tif (size) \t\tsize = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 (\"drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer\").", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93271", "url": "https://ubuntu.com/security/CVE-2026-93271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate ath11k can receive HT/VHT/HE frames whose reported MCS is above the maximum that can be expressed in the corresponding mac80211 rate space (e.g. an HE frame reported with MCS 12, while HE tops out at MCS 11). The frame itself is valid and decodes correctly, but for such a frame ath11k_dp_rx_h_rate() leaves rx_status->rate_idx set to the out-of-range value and never assigns rx_status->encoding, so it stays RX_ENC_LEGACY from the ath11k_dp_rx_h_ppdu() initialization. Once that frame reaches mac80211 it trips the rate sanity check and the frame is dropped with a splat: ath11k_pci 0000:03:00.0: Received with invalid mcs in HE mode 12 WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:5433 ieee80211_rx_list+0xb0a/0xe90 [mac80211] Dropping the frame would discard otherwise valid data, so instead cap the reported MCS to the maximum the rate space can express and deliver the frame. Set rx_status->encoding before the range check and assign rate_idx from the capped value, so a frame with an out-of-range MCS no longer leaves partial or bogus rate metadata behind. Also downgrade the logging level since they are not treated as invalid frames now. The only loss is that such a frame is reported as the capped MCS in the rx rate statistics. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93095", "url": "https://ubuntu.com/security/CVE-2026-93095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: validate thread record before delete key rebuild hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93098", "url": "https://ubuntu.com/security/CVE-2026-93098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: glink: fix deadlock in endpoint destroy during driver detach During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89778", "url": "https://ubuntu.com/security/CVE-2026-89778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: fix out-of-bounds page array access on empty zisofs block zisofs_uncompress_block()'s empty-block fast path returns pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the decompression path which returns bytes produced relative to poffset. zisofs_fill_pages() uses that return to advance its page cursor, so when the zisofs block size is below PAGE_SIZE and a sub-page block leaves poffset partway into a page, a following empty block over-counts and advances pages[] one element past its end, after which \"if (poffset && *pages)\" reads pages[1] out of bounds. rock.c only rejects a block-size shift > 17, so a crafted \"ZF\" Rock Ridge record can set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a compressed file on such a mounted ISO9660 image. Return the byte count relative to poffset and zero only [poffset, PAGE_SIZE) of the first page, matching the decompression path. The page-aligned case (poffset == 0) is unaffected. BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290) Read of size 8 at addr ffff88800f5eac48 by task exploit/142 zisofs_read_folio (fs/isofs/compress.c:290) read_pages (mm/readahead.c:184) ... filemap_read (mm/filemap.c:2814) vfs_read (fs/read_write.c:574) __x64_sys_pread64 (fs/read_write.c:769) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address is located 0 bytes to the right of the allocated 8-byte region in the kmalloc-8 cache", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93102", "url": "https://ubuntu.com/security/CVE-2026-93102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Free RX data on late probe failure hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning. If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears down the device data without calling hfi1_free_rx(). This leaks netdev_rx and its dummy netdev. Free the RX support after IB unregistration and before postinit_cleanup(), as done on normal device removal.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93103", "url": "https://ubuntu.com/security/CVE-2026-93103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89783", "url": "https://ubuntu.com/security/CVE-2026-89783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use \"sp->len >= XFRM_MAX_DEPTH\", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]'", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93108", "url": "https://ubuntu.com/security/CVE-2026-93108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ipoib: Drain RCU callbacks during module teardown IPoIB reclamation completions can be signaled from inside an RCU callback. Teardown can wake before the callback returns and unload ib_ipoib while its code is still executing. Client registration failure can also remove already-added devices and queue callbacks. Wait after client and workqueue teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93109", "url": "https://ubuntu.com/security/CVE-2026-93109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Drain RCU callbacks during module teardown devx_free_subscription() can remain queued after the last DevX event file drops its module reference or an auxiliary driver detaches its devices. mlx5_ib can then unload before the callback runs. Registration error unwind has the same risk because driver registration can attach existing devices before failing. Wait after all drivers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93110", "url": "https://ubuntu.com/security/CVE-2026-93110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Wait for RCU callbacks before unloading ib_core put_gid_ndev() is queued with call_rcu() and implemented in ib_core. Stopping the workqueues does not drain callbacks already queued, so RCU could invoke it after the module code has been unloaded. synchronize_rcu() does not wait for callbacks. Wait for them after all producers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93114", "url": "https://ubuntu.com/security/CVE-2026-93114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/surface: acpi-notify: Check ACPI companion before use Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 (\"ACPI: driver: Check ACPI_COMPANION() against NULL during probe\") does for the core ACPI platform drivers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93115", "url": "https://ubuntu.com/security/CVE-2026-93115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93120", "url": "https://ubuntu.com/security/CVE-2026-93120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93130", "url": "https://ubuntu.com/security/CVE-2026-93130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix resource leak on module load failure We need to properly clean up the SMBIOS request and the privacy driver when the module load fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93131", "url": "https://ubuntu.com/security/CVE-2026-93131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-privacy: Fix race condition Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93138", "url": "https://ubuntu.com/security/CVE-2026-93138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire(). Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93140", "url": "https://ubuntu.com/security/CVE-2026-93140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 (\"udf: Mark LVID buffer as uptodate before marking it dirty\"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline] vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline] __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93141", "url": "https://ubuntu.com/security/CVE-2026-93141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: r8a66597: avoid double free of ep0_req in probe error path If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL. Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once. Issue found using a prototype static analysis tool and confirmed by code review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93145", "url": "https://ubuntu.com/security/CVE-2026-93145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister() gdsc_unregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pm_genpd_remove() on the individual generic_pm_domain structures registered by gdsc_init(): \tvoid gdsc_unregister(struct gdsc_desc *desc) \t{ \t\tstruct device *dev = desc->dev; \t\tsize_t num = desc->num; \t\tgdsc_pm_subdomain_remove(desc, num); \t\tof_genpd_del_provider(dev->of_node); \t} That leaves dangling entries on the global gpd_list. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdsc_init() will end up trying to re-register a name that is still in the list and pm_genpd_init() returns -EEXIST. While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh of_genpd_get_from_provider() call racing with the teardown could attach to a domain that is mid-removal. Iterate the scs[] array and pm_genpd_remove() each registered domain after the subdomain links are torn down. The regulators stay devm- managed (devm_regulator_get_optional() in gdsc_register()), so the release happens automatically when the underlying device is unbound; just the genpd accounting needs to be undone explicitly.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93278", "url": "https://ubuntu.com/security/CVE-2026-93278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown cvm_oct_rx_shutdown calls free_irq and netif_napi_del without disabling the napi instance first. As the free_irq only waits for completion of hard interrupt handlers, the napi poll function could still be active. If cvm_oct_remove proceeds to free the plat structure (which holds the NAPI instances), the active poll function will access freed memory, resulting in a use-after-free crash.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93279", "url": "https://ubuntu.com/security/CVE-2026-93279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown The TX cleanup tasklet can be scheduled by the watchdog IRQ handler to execute cvm_oct_tx_do_cleanup. There can be a pending tasklet in the queue which might run after the cvm_oct_remove() frees net_device structures, causing a use-after-free in cvm_oct_tx_do_cleanup() as it iterates cvm_oct_device[] which is an array of netdevice pointers. Add tasklet_kill() after free_irq() to ensure the tasklet is no longer scheduled or running before teardown proceeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93280", "url": "https://ubuntu.com/security/CVE-2026-93280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: greybus: audio: bound the topology section sizes against the fetched size gb_audio_gb_get_topology() fetches a topology blob of a module-supplied size, and gbaudio_tplg_parse_data() then walks it by adding the module-supplied size_dais, size_controls and size_widgets fields to form the control, widget and route section offsets. Those le32 sizes are never checked against the fetched blob, so a module reporting a small topology size but large section sizes makes the offsets point past the allocation, and parsing reads out of bounds. Reject a topology whose section sizes do not fit within the fetched size before it is parsed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93151", "url": "https://ubuntu.com/security/CVE-2026-93151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: fix response resource leak on queue teardown When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm \"kworker/2:1H\", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 unreferenced object 0xffff88814bd05e80 (size 64): comm \"kworker/3:1H\", pid 148, jiffies 4295195428 backtrace (crc e35510cb): __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources() that frees up the RDMA read/write context and the request SGLs of such responses.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93158", "url": "https://ubuntu.com/security/CVE-2026-93158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul - stop probe if context pool creation fails sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool. Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93159", "url": "https://ubuntu.com/security/CVE-2026-93159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes. If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated work_data is not usable for producing RNG output and must not remain associated with the hwrng state. Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data. Fix this by freeing the pending work_data. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93160", "url": "https://ubuntu.com/security/CVE-2026-93160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-ecc - reject hardware ECDH without a public key The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm. atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93161", "url": "https://ubuntu.com/security/CVE-2026-93161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - clear AES key schedule from stack qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame. Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93165", "url": "https://ubuntu.com/security/CVE-2026-93165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Fix memory overread in ring handler `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93167", "url": "https://ubuntu.com/security/CVE-2026-93167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: csky: Fix a4/a5 restoration in syscall trace path The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93170", "url": "https://ubuntu.com/security/CVE-2026-93170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93177", "url": "https://ubuntu.com/security/CVE-2026-93177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup vddInd, vddciInd and mvddInd from VBIOS-parsed tables index into vddc, vddci and vddmem lookup tables without bounds checks across nine sites. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93178", "url": "https://ubuntu.com/security/CVE-2026-93178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93274", "url": "https://ubuntu.com/security/CVE-2026-93274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: bcm2835: Don't remove an unregistered GPIO chip If the devm_pinctrl_register() function fails, bcm2835_pinctrl_probe() calls gpiochip_remove() before gpiochip_add_data() has registered the GPIO chip. This means that upon failure the gpio_chip.gpiodev is NULL resulting in a null pointer dereference inside the gpiochip_remove() function. Remove the unnecessary function call to gpiochip_remove(). No GPIO cleanup is required because the GPIO chip has not yet been registered. Without this change there is potential for a kernel panic upon registration failure", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93183", "url": "https://ubuntu.com/security/CVE-2026-93183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/lima: call drm_mm_init() with a valid allocation range lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2: [ 1.736297] ------------[ cut here ]------------ [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931! [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.750697] Modules linked in: [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree) [ 1.769446] Workqueue: events_unbound deferred_probe_work_func [ 1.775261] PC is at drm_mm_init+0x9c/0xa4 [ 1.779339] LR is at lima_vm_create+0x144/0x17c [ ... ] Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93185", "url": "https://ubuntu.com/security/CVE-2026-93185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rt700-sdw: always drain jack work on remove rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93188", "url": "https://ubuntu.com/security/CVE-2026-93188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: bound device-supplied profile index kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93189", "url": "https://ubuntu.com/security/CVE-2026-93189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path (\"hwmon: prevent packets from going to driver for probe\", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93191", "url": "https://ubuntu.com/security/CVE-2026-93191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix incorrect task context in smack_msg_queue_msgrcv The smack_msg_queue_msgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task. In the msgsnd() syscall path, if a receiver is already waiting, the pipelined_send() optimization is used to push the message directly to the receiver task: ipc/msg.c`pipelined_send(): ` smp_store_release(&msr->r_msg, msg) In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->r_tsk, passed as the 'target' parameter): ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, target := msr->r_tsk,,) However, smack_msg_queue_msgrcv() ignores the 'target' and checks 'current': smack_msg_queue_msgrcv(…) ` smk_curacc_msq(isp, MAY_READWRITE); // current task 'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy. Test: 1) create a sysv message queue with label “foo” 2) echo \"bar foo r\" >/smack/load2 3) msgrcv(,,,0,MSG_NOERROR) in \"bar\"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a \"foo\"-labeled task: \"bar\"-labeled task gets the message. This patch fixes the issue by checking permission on the 'target' task instead of 'current'. (2008-02-04, Casey Schaufler)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2025-40123", "url": "https://ubuntu.com/security/CVE-2025-40123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce expected_attach_type for tailcall compatibility Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-89947", "url": "https://ubuntu.com/security/CVE-2026-89947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: meson: align gxbb_32k_clk_sel number of parents with actual count The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c (\"clk: amlogic: gxbb: drop non existing 32k clock parent\") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80671", "url": "https://ubuntu.com/security/CVE-2026-80671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf sched: Fix register_pid() overflow, strcpy, and BUG_ON register_pid() has several issues when processing untrusted perf.data: 1. Integer overflow: (pid + 1) * sizeof(struct task_desc *) can wrap to a small value on 32-bit systems when pid is large (e.g. 0x40000000), causing realloc to return a tiny buffer followed by out-of-bounds writes in the initialization loop. 2. Heap buffer overflow: strcpy(task->comm, comm) copies the untrusted comm string into a fixed 20-byte COMM_LEN buffer with no length check. 3. BUG_ON on allocation failure: perf.data is untrusted input, so allocation failures should be handled gracefully rather than killing the process. 4. Realloc of sched->tasks assigned directly back, leaking the old pointer on failure; nr_tasks incremented before the realloc, leaving corrupted state on failure. Cap pid at PID_MAX_LIMIT (4194304, matching the kernel's maximum on 64-bit), replace strcpy with strlcpy, guard against NULL comm, replace BUG_ON with NULL returns using safe realloc patterns, and add NULL checks in callers that dereference the result.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-93203", "url": "https://ubuntu.com/security/CVE-2026-93203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: avoid CRC corruption due to parallel claim add batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either * add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone But when the \"new\" claim code was running in parallel to the \"change backbone\" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the \"new\" claim code path: * CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point. * CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc. * CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc The CRC is then wrong for both: * claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs. To avoid this, split the functionality in clear separate parts: * new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back) * update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93204", "url": "https://ubuntu.com/security/CVE-2026-93204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: atomically update mac addresses When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2025-22039", "url": "https://ubuntu.com/security/CVE-2025-22039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix overflow in dacloffset bounds check The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl(). This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer. This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.", "cve_priority": "high", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-21651", "url": "https://ubuntu.com/security/CVE-2025-21651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: don't auto enable misc vector Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below: [ 16.324639] Call trace: [ 16.324641] __queue_delayed_work+0xb8/0xe0 [ 16.324643] mod_delayed_work_on+0x78/0xd0 [ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge] [ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge] [ 16.324666] __handle_irq_event_percpu+0x64/0x1e0 [ 16.324667] handle_irq_event+0x80/0x170 [ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc [ 16.324671] __handle_domain_irq+0x84/0xfc [ 16.324673] gic_handle_irq+0x88/0x2c0 [ 16.324674] el1_irq+0xb8/0x140 [ 16.324677] arch_cpu_idle+0x18/0x40 [ 16.324679] default_idle_call+0x5c/0x1bc [ 16.324682] cpuidle_idle_call+0x18c/0x1c4 [ 16.324684] do_idle+0x174/0x17c [ 16.324685] cpu_startup_entry+0x30/0x6c [ 16.324687] secondary_start_kernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]--- So don't auto enable misc vector when request irq..", "cve_priority": "low", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43088", "url": "https://ubuntu.com/security/CVE-2026-43088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: zero aligned sockaddr tail in PF_KEY exports PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE` Fix those paths by clearing only the aligned sockaddr tail after `pfkey_sockaddr_fill()`.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31420", "url": "https://ubuntu.com/security/CVE-2026-31420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: mrp: reject zero test interval to avoid OOM panic br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock. The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames. Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2025-22103", "url": "https://ubuntu.com/security/CVE-2025-22103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix NULL pointer dereference in l3mdev_l3_rcv When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-21649", "url": "https://ubuntu.com/security/CVE-2025-21649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is sent on HIP08 devices Currently, HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL. But the tx process would still try to set hardware time stamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash. [ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge] [ 128.292938] sp : ffff800059b93140 [ 128.297200] x29: ffff800059b93140 x28: 0000000000003280 [ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080 [ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001 [ 128.315969] x23: 0000000000000000 x22: 0000000000000194 [ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000 [ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000 [ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24 [ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000 [ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368 [ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02 [ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0 [ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000 [ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff [ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294 [ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080 [ 128.390626] Call trace: [ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3] [ 128.405468] xmit_one.constprop.0+0xc4/0x200 [ 128.410600] dev_hard_start_xmit+0x54/0xf0 [ 128.415556] sch_direct_xmit+0xe8/0x634 [ 128.420246] __dev_queue_xmit+0x224/0xc70 [ 128.425101] dev_queue_xmit+0x1c/0x40 [ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch] [ 128.435409] do_output+0x60/0x17c [openvswitch] [ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch] [ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch] [ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch] [ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch] [ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch] [ 128.471460] xmit_one.constprop.0+0xc4/0x200 [ 128.476561] dev_hard_start_xmit+0x54/0xf0 [ 128.481489] __dev_queue_xmit+0x968/0xc70 [ 128.486330] dev_queue_xmit+0x1c/0x40 [ 128.490856] ip_finish_output2+0x250/0x570 [ 128.495810] __ip_finish_output+0x170/0x1e0 [ 128.500832] ip_finish_output+0x3c/0xf0 [ 128.505504] ip_output+0xbc/0x160 [ 128.509654] ip_send_skb+0x58/0xd4 [ 128.513892] udp_send_skb+0x12c/0x354 [ 128.518387] udp_sendmsg+0x7a8/0x9c0 [ 128.522793] inet_sendmsg+0x4c/0x8c [ 128.527116] __sock_sendmsg+0x48/0x80 [ 128.531609] __sys_sendto+0x124/0x164 [ 128.536099] __arm64_sys_sendto+0x30/0x5c [ 128.540935] invoke_syscall+0x50/0x130 [ 128.545508] el0_svc_common.constprop.0+0x10c/0x124 [ 128.551205] do_el0_svc+0x34/0xdc [ 128.555347] el0_svc+0x20/0x30 [ 128.559227] el0_sync_handler+0xb8/0xc0 [ 128.563883] el0_sync+0x160/0x180", "cve_priority": "medium", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2023-52676", "url": "https://ubuntu.com/security/CVE-2023-52676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Guard stack limits against 32bit overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904", "cve_priority": "high", "cve_public_date": "2024-05-17 15:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "low", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-90015", "url": "https://ubuntu.com/security/CVE-2026-90015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89816", "url": "https://ubuntu.com/security/CVE-2026-89816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used Commit 1c6ceeee6ebb (\"drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits\") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93234", "url": "https://ubuntu.com/security/CVE-2026-93234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: validate TV mode names before creating enum property The GUD protocol returns TV mode names as fixed-size GUD_CONNECTOR_TV_MODE_NAME_LEN entries and requires each name to be NUL-terminated. gud_connector_add_tv_mode() currently passes each fixed-size entry directly to drm_mode_create_tv_properties_legacy(), which eventually reaches drm_property_add_enum() and strlen(). If a device returns an entry without a terminating NUL byte, strlen() reads past the end of the slot and can run beyond the allocated buffer, triggering an out-of-bounds read. Validate that each returned TV mode name contains a NUL terminator within its fixed-size slot before passing it to the DRM property code. If a malformed entry is found, reject the device response with -EIO. This fixes the out-of-bounds read without changing the handling of valid devices, and avoids silently truncating malformed protocol data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89817", "url": "https://ubuntu.com/security/CVE-2026-89817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: NUL-terminate TV mode names read from the device gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89821", "url": "https://ubuntu.com/security/CVE-2026-89821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid divide-by-zero in __is_lut_linear() __is_lut_linear() computes the expected value of each entry with \texpected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89823", "url": "https://ubuntu.com/security/CVE-2026-89823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: fix race between partial drm_dev_register() failure and ioctl If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89843", "url": "https://ubuntu.com/security/CVE-2026-89843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89845", "url": "https://ubuntu.com/security/CVE-2026-89845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89846", "url": "https://ubuntu.com/security/CVE-2026-89846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: \tif (IS_FWI2_CAPABLE(ha)) { \t\tsense_data += rsp_info_len; \t\tpar_sense_len -= rsp_info_len; \t} rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): \tif (sense_len > par_sense_len) \t\tsense_len = par_sense_len; \tmemcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89847", "url": "https://ubuntu.com/security/CVE-2026-89847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid double completion in async IOCB timeout qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates \"if (sp->comp) complete(sp->comp)\"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93242", "url": "https://ubuntu.com/security/CVE-2026-93242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb() qla24xx_process_response_queue() advances ring_ptr past the head IOCB before dispatching, so by the time __qla_consume_iocb() runs, ring_ptr already points at the first continuation IOCB. The function however looped purex->entry_count times starting at ring_ptr. As entry_count includes the head, this consumed one entry too many: it stamped RESPONSE_PROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked. Mark the head processed and account for it, then consume only the entry_count - 1 continuation IOCBs, matching __qla_copy_purex_to_buffer().", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89849", "url": "https://ubuntu.com/security/CVE-2026-89849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path qla2x00_status_entry() filters out non-TYPE_SRB entries and the SRB_NVME_CMD, SRB_BIDI_CMD and SRB_TM_CMD types, then falls through to a SCSI fast path that assumes the command is an SRB_SCSI_CMD. The first thing on that path, qla_chk_edif_rx_sa_delete_pending(), and the subsequent handling both evaluate GET_CMD_SP(sp), i.e. sp->u.scmd.cmd. The srb u union overlays the SCSI command pointer with other command layouts (bsg_job, iocb_cmd). If firmware delivers an unexpected STATUS_TYPE IOCB for a non-SCSI handle, sp->u.scmd.cmd can read as a non-NULL garbage pointer, bypassing the NULL checks in qla_chk_edif_rx_sa_delete_pending() and at the cp == NULL test, and leading to a wild pointer dereference. Reject any SRB whose type is not SRB_SCSI_CMD before entering the fast path. The outstanding_cmds slot is left untouched so a genuinely non-SCSI command still completes through its proper handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89850", "url": "https://ubuntu.com/security/CVE-2026-89850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Don't query firmware state while chip is down qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89851", "url": "https://ubuntu.com/security/CVE-2026-89851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace enable parsing in debugfs qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as \"disable\" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89852", "url": "https://ubuntu.com/security/CVE-2026-89852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89853", "url": "https://ubuntu.com/security/CVE-2026-89853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89854", "url": "https://ubuntu.com/security/CVE-2026-89854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix cs84xx use-after-free on host teardown qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89855", "url": "https://ubuntu.com/security/CVE-2026-89855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize flash version read in reset handler The \"update cache versions without reset\" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89856", "url": "https://ubuntu.com/security/CVE-2026-89856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as \"ha->max_req_queues = ha->msix_count - 1\" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent \"ha->max_req_queues--\" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following \"ha->req_q_map[0] = req\" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89858", "url": "https://ubuntu.com/security/CVE-2026-89858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89861", "url": "https://ubuntu.com/security/CVE-2026-89861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89863", "url": "https://ubuntu.com/security/CVE-2026-89863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check qla_chk_edif_rx_sa_delete_pending() obtains the SCSI command via GET_CMD_SP(sp) and immediately dereferences cmd->sc_data_direction. That command pointer can be NULL: the firmware may post a status completion for a command that has already been returned or aborted. The caller qla2x00_status_entry() acknowledges this on the very same status path, re-fetching GET_CMD_SP(sp) and bailing out with the \"Command already returned\" message when it is NULL -- but that check runs only after qla_chk_edif_rx_sa_delete_pending() has already dereferenced the pointer, so a NULL cmd crashes the kernel in interrupt context. Return early when cmd is NULL, before touching cmd->sc_data_direction.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89864", "url": "https://ubuntu.com/security/CVE-2026-89864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: \tstruct qla_i2c_access { \t\tuint16_t device, offset, option, length; \t\tuint8_t buffer[0x40]; \t} __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89865", "url": "https://ubuntu.com/security/CVE-2026-89865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: \tif (len == 1) \t\topt |= BIT_0; \tif (opt & BIT_0) \t\tlen = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89871", "url": "https://ubuntu.com/security/CVE-2026-89871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89872", "url": "https://ubuntu.com/security/CVE-2026-89872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. [Sakari Ailus: Fix subject prefix and coding style a little.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89876", "url": "https://ubuntu.com/security/CVE-2026-89876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tda18250: fix possible integer overflow Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89878", "url": "https://ubuntu.com/security/CVE-2026-89878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: check firmware size before reading trailing marker s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89879", "url": "https://ubuntu.com/security/CVE-2026-89879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: bound JPEG frame size before copying into the buffer s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: \tpayload = le32_to_cpu(pdword[3]); \tif (payload > vc->req_image_size)\t/* payload is checked ... */ \t\treturn -EINVAL; \tvc->pkt_size = payload; \tvc->jpg_size = le32_to_cpu(pdword[4]);\t/* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89880", "url": "https://ubuntu.com/security/CVE-2026-89880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89881", "url": "https://ubuntu.com/security/CVE-2026-89881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89883", "url": "https://ubuntu.com/security/CVE-2026-89883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: sunxi-cir: Unregister rc device on probe failure After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93236", "url": "https://ubuntu.com/security/CVE-2026-93236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common When VIDIOC_TRY_FMT is called with an unsupported pixel format on the OUTPUT queue, vdec_try_fmt_common() falls back to V4L2_PIX_FMT_MPEG2. However, if a distro has locally patched MPEG2 support out (as it has been broken for some time) the platform format table does not contain MPEG2 so find_format() returns NULL and the subsequent dereference of fmt_out->max_width triggers a NULL pointer dereference. Fix this by falling back to the first format in the platform's format array instead of hardcoding V4L2_PIX_FMT_MPEG2. This is always valid since every platform defines at least one format.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89887", "url": "https://ubuntu.com/security/CVE-2026-89887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov7740: fix use-after-destroy in remove The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89888", "url": "https://ubuntu.com/security/CVE-2026-89888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov02a10: fix endpoint parsing use-after-free The ov02a10_check_hwcfg() function calls fwnode_handle_put(ep) immediately after allocating and parsing the endpoint. However, it subsequently calls fwnode_property_read_u32() using the same 'ep' handle, leading to a potential use-after-free. Additionally, reading the optional 'ovti,mipi-clock-voltage' property used to overwrite the 'ret' variable. If the property was missing, 'ret' would become negative, and this failure code would be incorrectly returned at the end of the function, causing probe to fail entirely. Fix the use-after-free by moving fwnode_property_read_u32() before the endpoint is parsed and freed. Avoid the error leak by not assigning the result of fwnode_property_read_u32() to 'ret'.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89890", "url": "https://ubuntu.com/security/CVE-2026-89890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: go7007: defer the ALSA v4l2 put until card release go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89891", "url": "https://ubuntu.com/security/CVE-2026-89891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free of dev_next->devlist on disconnect When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 (\"USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89892", "url": "https://ubuntu.com/security/CVE-2026-89892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: defer audio-only extension registration The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89893", "url": "https://ubuntu.com/security/CVE-2026-89893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: cancel NetUP CI work before teardown netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89894", "url": "https://ubuntu.com/security/CVE-2026-89894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: reject geometry changes while the VBI queue is busy vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: \toffset = lines_completed * (dev->width << 1) + ...; \tif (dma_q->current_field == 2) \t\toffset += dev->width * 2 * dma_q->lines_per_field; \tmemcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89895", "url": "https://ubuntu.com/security/CVE-2026-89895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cobalt: Avoid freeing ALSA private data twice snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89896", "url": "https://ubuntu.com/security/CVE-2026-89896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: fix memory leak in cedrus_init_ctrls() In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89897", "url": "https://ubuntu.com/security/CVE-2026-89897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: Serialize exclusive follower delivery cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89901", "url": "https://ubuntu.com/security/CVE-2026-89901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89923", "url": "https://ubuntu.com/security/CVE-2026-89923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Free guest debug data on vcpu destroy kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89924", "url": "https://ubuntu.com/security/CVE-2026-89924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix old_data leak in guest debug error path __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89925", "url": "https://ubuntu.com/security/CVE-2026-89925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory leak in guest debug handling bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89926", "url": "https://ubuntu.com/security/CVE-2026-89926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix length check __import_wp_info() struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: \twp_info->len = bp_data->len; \t[...] \tif (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) \t\treturn -EINVAL; \twp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89927", "url": "https://ubuntu.com/security/CVE-2026-89927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89930", "url": "https://ubuntu.com/security/CVE-2026-89930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter KVM services local TLB flushes on \"full\" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89932", "url": "https://ubuntu.com/security/CVE-2026-89932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always flush vpid02 on first use Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89936", "url": "https://ubuntu.com/security/CVE-2026-89936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: dac: m62332: Fix regulator reference count imbalance m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89937", "url": "https://ubuntu.com/security/CVE-2026-89937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sgp30: Handle IAQ thread creation failure kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89939", "url": "https://ubuntu.com/security/CVE-2026-89939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89945", "url": "https://ubuntu.com/security/CVE-2026-89945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l34: drain threaded IRQ before runtime suspend cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89946", "url": "https://ubuntu.com/security/CVE-2026-89946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89948", "url": "https://ubuntu.com/security/CVE-2026-89948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89949", "url": "https://ubuntu.com/security/CVE-2026-89949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89951", "url": "https://ubuntu.com/security/CVE-2026-89951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix stale receive device on merged fragments Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89952", "url": "https://ubuntu.com/security/CVE-2026-89952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89953", "url": "https://ubuntu.com/security/CVE-2026-89953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89954", "url": "https://ubuntu.com/security/CVE-2026-89954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: afs: validate v2 image info bounds The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89964", "url": "https://ubuntu.com/security/CVE-2026-89964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: eisa: Fix infinite loop when parsing invalid IRQ value When an invalid value is passed via the \"eisa_irq_edge=\" kernel command line parameter (e.g. \"eisa_irq_edge=16,5\"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89965", "url": "https://ubuntu.com/security/CVE-2026-89965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: reject an arena whose nfree is below the lane count The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89968", "url": "https://ubuntu.com/security/CVE-2026-89968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: reject unsolicited H2CData PDUs nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the \"list_add double add\" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89969", "url": "https://ubuntu.com/security/CVE-2026-89969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as \tqueue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89973", "url": "https://ubuntu.com/security/CVE-2026-89973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: check the data direction of a C2HData PDU nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89979", "url": "https://ubuntu.com/security/CVE-2026-89979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race between non-atomic ops and trigger-start We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89980", "url": "https://ubuntu.com/security/CVE-2026-89980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: harmony: initialize locks before requesting IRQ snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89982", "url": "https://ubuntu.com/security/CVE-2026-89982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89983", "url": "https://ubuntu.com/security/CVE-2026-89983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89984", "url": "https://ubuntu.com/security/CVE-2026-89984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \\ \t./perf bench syscall basic --loop 1000 | \\ \t./perf script -i - --fields brstack|tr ' ' '\\n'| \\ \tgrep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89989", "url": "https://ubuntu.com/security/CVE-2026-89989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89993", "url": "https://ubuntu.com/security/CVE-2026-89993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Initialize IRQ data before requesting IRQs dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89997", "url": "https://ubuntu.com/security/CVE-2026-89997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix resume-vs-remove race If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89999", "url": "https://ubuntu.com/security/CVE-2026-89999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: validate report length in wacom_intuos_pro2_bt_irq wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: \twacom_intuos_pro2_bt_pen(wacom); \tif (type == INTUOSP2_BT || type == INTUOSP2S_BT) { \t\twacom_intuos_pro2_bt_touch(wacom); \t\twacom_intuos_pro2_bt_pad(wacom); \t\twacom_intuos_pro2_bt_battery(wacom); \t} else { \t\twacom_intuos_gen3_bt_pad(wacom); \t\twacom_intuos_gen3_bt_battery(wacom); \t} Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] \t(the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT (\"gen3\"): wacom_intuos_gen3_bt_battery() reads data[45], \tso the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 (\"HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq\") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90000", "url": "https://ubuntu.com/security/CVE-2026-90000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: rmi: fix OOB access with undersized RMI reports The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: \tdata->input_report_size = hid_report_len(input_report); \tdata->output_report_size = hid_report_len(output_report); \talloc_size = data->output_report_size + data->input_report_size; \tdata->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); \tdata->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly \"this probe validated the reports\"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90007", "url": "https://ubuntu.com/security/CVE-2026-90007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Use rollback index when freeing MSI-X vectors pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90011", "url": "https://ubuntu.com/security/CVE-2026-90011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where \tpadding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90017", "url": "https://ubuntu.com/security/CVE-2026-90017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: \tconst u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); \t... \tc = frame_body[0]; \t... \ta = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90018", "url": "https://ubuntu.com/security/CVE-2026-90018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: \tif (attr_ptr + 4 > wps_ie + wps_ielen) \t\tbreak; \tu16 attr_id = get_unaligned_be16(attr_ptr); \tu16 attr_data_len = get_unaligned_be16(attr_ptr + 2); \tu16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: \tmemcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack \"u8 sr\"/\"u8 selected_registrar\" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The \"attr_ptr + 4 > wps_ie + wps_ielen\" header check above was added by commit 1463ca3ec6601 (\"staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()\"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90019", "url": "https://ubuntu.com/security/CVE-2026-90019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: fix null pointer dereference in usb_put_function_instance() usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90020", "url": "https://ubuntu.com/security/CVE-2026-90020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90025", "url": "https://ubuntu.com/security/CVE-2026-90025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix OOB altmode array index The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90031", "url": "https://ubuntu.com/security/CVE-2026-90031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90032", "url": "https://ubuntu.com/security/CVE-2026-90032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: usbtv: keep device alive while ALSA card exists The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90033", "url": "https://ubuntu.com/security/CVE-2026-90033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90034", "url": "https://ubuntu.com/security/CVE-2026-90034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2025-38097", "url": "https://ubuntu.com/security/CVE-2025-38097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: remove encap socket caching to avoid reference leak The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used \"recently\", but it's a lot more complex than just not caching the socket.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2026-89515", "url": "https://ubuntu.com/security/CVE-2026-89515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables() During fuzz testing, the following issue was discovered: BUG: KMSAN: uninit-value in __dma_map_sg_attrs+0x217/0x310 __dma_map_sg_attrs+0x217/0x310 dma_map_sg_attrs+0x4a/0x70 ata_qc_issue+0x9f8/0x1420 __ata_scsi_queuecmd+0x1657/0x1740 ata_scsi_queuecmd+0x79a/0x920 scsi_queue_rq+0x4472/0x4f40 blk_mq_dispatch_rq_list+0x1cca/0x3ee0 __blk_mq_sched_dispatch_requests+0x458/0x630 blk_mq_sched_dispatch_requests+0x15b/0x340 __blk_mq_run_hw_queue+0xe5/0x250 __blk_mq_delay_run_hw_queue+0x138/0x780 blk_mq_run_hw_queue+0x4bb/0x7e0 blk_mq_sched_insert_request+0x2a7/0x4c0 blk_execute_rq+0x497/0x8a0 sg_io+0xbe0/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Uninit was created at: __alloc_pages+0x5c0/0xc80 alloc_pages+0xe0e/0x1050 blk_rq_map_user_iov+0x2b77/0x6100 blk_rq_map_user_io+0x2fa/0x4d0 sg_io+0xad6/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Bytes 14-15 of 16 are uninitialized Memory access of size 16 starts at ffff88800cbdb000 When processing the last unaligned element of the scatterlist, it is supplemented with missing bytes in the amount of pad_len. These bytes remain uninitialized, which leads to a problem. Extend last_sg->length by pad_len first, then use sg_zero_buffer() to zero those pad_len bytes. sg_zero_buffer() uses sg_miter internally, which correctly handles sg entries spanning multiple pages and padding that crosses a page boundary. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80689", "url": "https://ubuntu.com/security/CVE-2026-80689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions mmio_trace_rw() and mmio_trace_mapping() retrieve mmio_trace_array into tr and pass it to __trace_mmiotrace_rw() and __trace_mmiotrace_map(). If these functions are invoked while mmio_trace_array is NULL (e.g. before initialization or after disabled), accessing tr->array_buffer.buffer will result in a NULL pointer dereference crash. Fix this by adding an explicit NULL check for tr at the beginning of __trace_mmiotrace_rw() and __trace_mmiotrace_map().", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80888", "url": "https://ubuntu.com/security/CVE-2026-80888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: drop dma_buf reference on foreign-fd prime import ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-80912", "url": "https://ubuntu.com/security/CVE-2026-80912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: reject an unclaimed class value in security_get_classes() security_get_classes() sizes an array by p_classes.nprim and fills it at value - 1, so a class value the policy never defines leaves a NULL. sel_make_classes() passes every entry to sel_make_dir(), reaching the same d_alloc_name() dereference as the permission array. The class symbol table is allowed to be sparse (policydb_class_isvalid() exists to absorb that), but this getter builds its own array straight from the hash table and has no such predicate. Fail the lookup when a value went unclaimed instead of handing out the NULL. Conforming policies define every class they declare and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-89595", "url": "https://ubuntu.com/security/CVE-2026-89595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix stale object mask after concurrent mark updates When a mark gets a new event bit, fanotify and inotify may avoid recalculating the object mask if the cached aggregate already contains that bit. This is racy with a recalculation triggered by a concurrent update to another mark on the same connector. The concurrent scan can read the mark before the new bit is added, while the updater reads the old aggregate before that scan publishes its result. The updater then skips recalculation and the scan publishes a mask without the bit, leaving the object mask stale after both updates complete. This can be reproduced with two fanotify groups watching the same inode: one thread removes FAN_MODIFY from one existing mark while another thread adds FAN_MODIFY to the other mark. After both fanotify_mark() calls return, writes can fail to produce FAN_MODIFY for the group whose mark now contains the bit. This was reproduced on an unmodified v6.12.95 kernel. The equivalent inotify interleaving loses IN_MODIFY events. For normal fanotify additions, recalculate whenever the raw mark mask changes. The normal mask is not cleared asynchronously, so an unchanged addition cannot introduce missing interest. Always recalculate ignore-mask updates because FS_MODIFY handling may clear the ignore mask without taking mark->lock, making snapshot comparisons unreliable. Always recalculate after updating an existing inotify watch. Its replace path temporarily sets mark->mask to zero, so a concurrent scan can observe zero even when the old and final masks are equal. Assigning the replacement mask directly would avoid the transient zero, but existing-watch updates are infrequent, so unconditional recalculation is simpler.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89603", "url": "https://ubuntu.com/security/CVE-2026-89603", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-74378", "url": "https://ubuntu.com/security/CVE-2026-74378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe get_srq_wqe() reads wqe->dma.num_sge from the shared receive queue buffer, which is mapped into userspace. It validates num_sge against max_sge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify num_sge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe. Read num_sge into a local variable and use it for both the bounds check and the size calculation.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-89488", "url": "https://ubuntu.com/security/CVE-2026-89488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix CT limit teardown use-after-free Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state. An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down. Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists. Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization. The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90049", "url": "https://ubuntu.com/security/CVE-2026-90049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80977", "url": "https://ubuntu.com/security/CVE-2026-80977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't touch shared zerocopy state in skb_tx_error() skb_tx_error() completes the zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone shares, while the caller only owns the reference it is about to drop. Through a clone it tells the producer its pages are free and drops SKBFL_SHARED_FRAG for an skb that is still in flight. Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC: clone_execute() sends a skb_clone() into ovs_dp_process_packet() while do_execute_actions() keeps forwarding the original, and skb_clone() does not privatise the frags here -- skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN. A flow miss on the clone then strips the marker from the packet still being forwarded, and a later local ESP delivery decrypts in place over frags it does not own privately. Skip it for a cloned skb. Nothing is lost: skb_release_data() clears the zerocopy state once the last reference to the shared data goes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80928", "url": "https://ubuntu.com/security/CVE-2026-80928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix cred UAF in smack_file_send_sigiotask() When inspecting the credentials of another task, objective credentials (->real_cred, accessed with __task_cred()) must always be used. Accessing ->cred on a non-current task is forbidden unless that task is being created or destroyed; a task is allowed to change its own ->cred pointer with no synchronization, and changing ->cred should only affect the current syscall. smack_file_send_sigiotask() was accessing both sets of credentials: First tsk->cred, then __task_cred(tsk). Fix it, always access the objective credentials here. I have tested that this bug can lead to a KASAN-reported UAF of struct cred in smack_file_send_sigiotask(), and that this fix prevents the race.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-93222", "url": "https://ubuntu.com/security/CVE-2026-93222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: avoid shared siginfo namespace rewrites send_signal_locked() rewrites sender ids for the target namespace. Group sends reuse the same siginfo, so one recipient can affect the next. Copy the siginfo before changing it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-80930", "url": "https://ubuntu.com/security/CVE-2026-80930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80931", "url": "https://ubuntu.com/security/CVE-2026-80931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: ds28e17: reject an oversize length on an I2C block read w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the device. The downstream slave puts a length byte in buf[0]. The driver then reads that many bytes into buf[1] with w1_f19_i2c_read(). buf[0] is controlled by the device and can be 0 to 255. w1_f19_i2c_read() only rejects a zero count. The caller buffer is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read run past it, up to about 222 bytes out of bounds. The SMBus core does check buf[0] against I2C_SMBUS_BLOCK_MAX. That check runs after master_xfer returns. By then the write is already done. i2c-algo-bit rejects an oversize length before it copies, and returns -EPROTO. Reject a length above I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites, the same way i2c-algo-bit does.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80932", "url": "https://ubuntu.com/security/CVE-2026-80932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: flush works in dependency order virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work. In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it. KASAN reported: BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80938", "url": "https://ubuntu.com/security/CVE-2026-80938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex mt7615_suspend() acquired the mt76 mutex and then called cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the same mutex via mt7615_mutex_acquire() at the top of the worker, so if mac_work is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against. Flush scan_work and mac_work before taking the mutex, matching the suspend paths in mt7921 and mt7925. scan_work only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps mac_work from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80941", "url": "https://ubuntu.com/security/CVE-2026-80941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb() The skb passed to the rtw_hci_tx_write() is expected to be freed when the function fails, but the error path in rtw_txq_push_skb() does not free the skb before returning. This can lead to a memory leak in rtw_txq_push() where a dequeued skb is passed to rtw_txq_push_skb().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80944", "url": "https://ubuntu.com/security/CVE-2026-80944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Detach sync cmd buffer on interrupted wait mwifiex synchronous commands keep the caller-provided data buffer in cmd_node->data_buf. Several callers pass stack-allocated objects there. If wait_event_interruptible_timeout() is interrupted, the caller can return and release that stack object while the firmware command is still the current command. A late firmware response then reaches the normal response handler, which can copy data through cmd_node->data_buf into the stale stack address. This fixes a stack corruption observed during repeated association and disassociation cycles. The panic trace showed the command wait being interrupted immediately before a bad pointer dereference: cmd_wait_q terminated: -512 Unable to handle kernel paging request at virtual address 002c583837384662 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted ... Tainted: [M]=MACHINE_CHECK The fault address decodes as little-endian ASCII: 0x002c583837384662 -> \"bF878X,\\0\" which is a fragment of the VERSION_EXT firmware string exposed as debugfs \"verext\": w8997o-V4, RF878X, FP92, 16.92.21.p153.7 The same runs also showed corrupted control data containing: 0x2400372e333531 -> \"153.7\\0$\" which is the tail of the same VERSION_EXT string. This points at a late VERSION_EXT response writing through a stale stack-backed data_buf after the interrupted wait returned. After cancelling pending commands on an interrupted or timed-out wait, detach the caller-owned data buffer from the still-current command. This preserves the existing command cancellation behaviour while preventing a late response from writing through a pointer whose lifetime ended with the waiting caller. Tested on an i.MX8MP board using an 88W8997.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80949", "url": "https://ubuntu.com/security/CVE-2026-80949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() The memory allocated for buf is not freed in some of the error paths in brcmf_sdio_read_control(). Fix that by adding vfree() calls. [arend: rework as suggested by Johannes]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80951", "url": "https://ubuntu.com/security/CVE-2026-80951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: bound IBI payload to the requested max_payload_len svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into the IBI slot. The loop is bounded by the hardware FIFO size (SVC_I3C_FIFO_SIZE), not by the slot size. slot->data points into the IBI pool, which i3c_generic_ibi_alloc_pool() sizes at max_payload_len per slot. svc_i3c_master_request_ibi() only rejects a max_payload_len larger than SVC_I3C_FIFO_SIZE, so a driver can request a smaller one. mctp-i3c requests 1. Each readsb() then copies the controller RXCOUNT bytes (up to 31) with no check against the slot size. A device that sends more bytes than the slot holds writes past slot->data, an out-of-bounds write into the IBI pool. Bound the loop by dev->ibi->max_payload_len and clamp each read to the space left in the slot, the same way dw-i3c does. A device can still send more than the requested payload. Flush the leftover bytes from the RX FIFO so they do not leak into the next transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80952", "url": "https://ubuntu.com/security/CVE-2026-80952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix info leak and UAF in device unregister path i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During device_unregister(), device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct i3c_device_info, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind. Keep desc valid until device_unregister() has completed. Since device_unregister() drops the device reference and may free the device, take an extra reference with get_device() before unregistering. Clear desc afterwards and release the extra reference with put_device(). This preserves the release-time invariant that desc must be NULL while avoiding both the information leak and a potential use-after-free from writing desc after the device has been released.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80963", "url": "https://ubuntu.com/security/CVE-2026-80963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-stats: fix a crash if allocation of per-cpu data fails If \"dm_kvzalloc(percpu_alloc_size, cpu_to_node(cpu))\" fails, the code jumps to the \"out\" label and calls dm_stat_free. dm_stat_free does \"for_each_possible_cpu(cpu) { dm_kvfree(s->stat_percpu[cpu][0].histogram, s->histogram_alloc_size);\", which crashes with NULL pointer dereference if s->stat_percpu[cpu] is NULL. This commit fixes the bug by testing s->stat_percpu[cpu] for NULL before using it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80964", "url": "https://ubuntu.com/security/CVE-2026-80964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: virmidi: Check card index validity at probe virmidi driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80965", "url": "https://ubuntu.com/security/CVE-2026-80965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: serial-u16550: Check card index validity at probe serial-u16550 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80966", "url": "https://ubuntu.com/security/CVE-2026-80966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: portman2x4: Check card index validity at probe Although portman2x4 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80967", "url": "https://ubuntu.com/security/CVE-2026-80967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcxhr: initialize mutexes before requesting threaded IRQ pcxhr_probe() requests pcxhr_threaded_irq() before initializing mgr->lock, even though the threaded handler takes that mutex. Initialize the manager locks before request_threaded_irq() so an early interrupt cannot run against uninitialized mutex state during probe.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80968", "url": "https://ubuntu.com/security/CVE-2026-80968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mts64: Check card index validity at probe Although mts64 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80969", "url": "https://ubuntu.com/security/CVE-2026-80969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mpu401: Check card index validity at probe mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80971", "url": "https://ubuntu.com/security/CVE-2026-80971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: clear the URB pointers on disconnect bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind: \tusb_kill_urb(bcd2k->midi_out_urb); \tusb_kill_urb(bcd2k->midi_in_urb); \tusb_free_urb(bcd2k->midi_out_urb); \tusb_free_urb(bcd2k->midi_in_urb); The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core: \tbcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE; \t... \tret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC); usb_kill_urb() does not stop a later submission either, so a submit that races the disconnect can requeue the URB after it has been reaped. midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits it from the completion handler. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000] Write of size 4 at addr ffff00001827d388 by task bpoc/168 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 Freed by task 168: usb_free_urb bcd2000_disconnect [snd_bcd2000] BUG: KASAN: slab-use-after-free in usb_submit_urb Read of size 8 at addr ffff00001827d3b8 by task bpoc/168 Clear both pointers after freeing and test them on the paths that can still run. Poison the URBs before freeing them: usb_poison_urb() waits for a running completion handler and rejects any later submission, so after it returns the input path is quiesced and only the rawmidi trigger path can still reach bcd2000_midi_send(). No unpoison is needed; the URBs are freed on the next line. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80972", "url": "https://ubuntu.com/security/CVE-2026-80972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Check card index validity at probe aloop driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80973", "url": "https://ubuntu.com/security/CVE-2026-80973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: bound the MIDI event length from the device usb6fire_comm_receiver_handler() forwards a MIDI event using a length byte the device supplies, with no bound and no check that the transfer delivered that many bytes: \tif (!urb->status) { \t\tif (rt->receiver_buffer[0] == 0x10) /* midi in event */ \t\t\tif (midi_rt) \t\t\t\tmidi_rt->in_received(midi_rt, \t\t\t\t\t\trt->receiver_buffer + 2, \t\t\t\t\t\trt->receiver_buffer[1]); \t} receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the device chooses, so a device that answers with 0x10 and a length of 0xFF makes snd_rawmidi_receive() read 255 bytes starting two bytes into a 64-byte object. The bytes past the buffer are handed to userspace through the rawmidi read path. urb->actual_length is not consulted either, so a short transfer leaves both the type byte and the length byte at their previous values and the handler acts on stale data. The receiver URB is submitted from usb6fire_comm_init() at probe, so the read happens on plug with no user action; forwarding to userspace also needs a MIDI input substream open, since usb6fire_midi_in_received() only calls snd_rawmidi_receive() when rt->in is set. KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device: BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive Read of size 255 at addr ffff000009f64682 by task bash/183 __asan_memcpy snd_rawmidi_receive usb6fire_midi_in_received [snd_usb_6fire] usb6fire_comm_receiver_handler [snd_usb_6fire] Allocated by task 11: usb6fire_comm_init [snd_usb_6fire] usb6fire_chip_probe [snd_usb_6fire] The buggy address is located 2 bytes inside of allocated 64-byte region [ffff000009f64680, ffff000009f646c0) Reject the event when the length exceeds the bytes that follow the header, and require the transfer to have delivered the header plus that many bytes. The receiver URB is submitted with a 64-byte transfer_buffer_length, so a genuine device cannot deliver an event longer than those 62 bytes and nothing valid is dropped. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80976", "url": "https://ubuntu.com/security/CVE-2026-80976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: reset IP6CB after IPv6 decapsulation decap_and_validate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags. End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet. The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports: BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu ip6_protocol_deliver_rcu+0x1118/0x1450 ip6_input_finish+0x11b/0x240 seg6_local_input_core+0xed/0x2e0 lwtunnel_input+0x1e9/0x4e0 ipv6_rthdr_rcv+0x525f/0x6c50 ip6_protocol_deliver_rcu+0xcb7/0x1450 Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field. Use IP6CB(skb)->iif rather than skb->skb_iif because VRF processing can replace skb_iif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKB_L3SLAVE for the same reason.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80978", "url": "https://ubuntu.com/security/CVE-2026-80978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap advertised IP tunnel headroom IP tunnel devices derive their advertised needed_headroom from lower output devices. A stack of user-created devices can make the derived value larger than the 16-bit skb header offsets can represent. Once IP output reserves it, skb head expansion can wrap those offsets. The runtime transmit path already caps a growing needed_headroom at 512. Apply the same cap when tunnel configuration publishes needed_headroom derived from a lower output device. Capping the advertised value is safe: IP tunnel transmit still expands the skb when a packet needs more headroom. A nonsensical stacked configuration can therefore incur an extra reallocation, but it cannot publish an unbounded reservation to upper layers.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80983", "url": "https://ubuntu.com/security/CVE-2026-80983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket refcount leak in smc_switch_conns() smc_switch_conns() takes a reference on the SMC socket before dropping lgr->conns_lock, so the connection stays alive while the CDC slot is fetched: sock_hold(&smc->sk); read_unlock_bh(&lgr->conns_lock); /* pre-fetch buffer outside of send_lock, might sleep */ rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend); if (rc) goto err_out; The err_out label only drops the wr_tx link reference, so this early exit returns without the matching sock_put(). The second error exit is not affected, because sock_put() has already run by then. A leaked sk_refcnt means the smc_sock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down. smc_cdc_get_free_slot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smc_switch_conns() run in the first place. Restructure so there is a single sock_put() covering both outcomes, instead of adding a second one to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80987", "url": "https://ubuntu.com/security/CVE-2026-80987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Reject oversized TX buffers ntb_process_tx() handles an oversized buffer by calling tx_handler() with a NULL data pointer and returning success. ntb_netdev therefore neither frees the skb in its completion callback nor takes its enqueue error path, leaking it. Reject oversized buffers in ntb_transport_tx_enqueue() before acquiring a queue entry and return -EMSGSIZE. The caller retains ownership of the buffer, and the preceding netdev patch frees the skb when enqueue returns this permanent error.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80988", "url": "https://ubuntu.com/security/CVE-2026-80988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Fail TX enqueue when the QP link is down Commit f195a1a6fe41 (\"ntb: Drop packets when qp link is down\") meant to make ntb_transport_tx_enqueue() drop packets submitted while the QP link is down, but it only returns 0 without consuming the packet. Zero means success by this function's contract, so ntb_netdev reports NETDEV_TX_OK and forgets the skb: nothing queued it, nothing frees it, and it leaks, one skb for every transmit racing a link-down. Return -ENOLINK instead, restoring the contract that a non-zero return leaves the buffer owned by the caller. With the preceding patch, ntb_netdev frees the skb on non-retryable enqueue failures and returns NETDEV_TX_OK, so a packet racing with link-down is dropped without leaking or entering a busy retry loop.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80994", "url": "https://ubuntu.com/security/CVE-2026-80994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix flow mask use-after-free on flow deletion The commit in the Fixes tag below made so flow->mask free is scheduled via RCU right after it is removed from the flow table. The pointer stays in the flow structure and it can be accessible while in the same RCU critical section. This is done to avoid requiring ovs_mutex for the ovs_flow_free(). However, while removing the flow during processing of CMD_DEL, we do not take RCU read lock before the removal, and ovs_flow_cmd_fill_info() uses the flow->mask pointer afterwards. The RCU read lock is taken, but it's already late at that point. The comment on that line acknowledges that the lock is cosmetic and doesn't serve a real purpose. This leads to use-after-free if the RCU grace period passes between removal and the filling. It is a short race window, but it is there and can lead to a real crash in case memory allocation for the info takes a bit longer: BUG: KASAN: slab-use-after-free in __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 BUG: KASAN: slab-use-after-free in ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 Read of size 4 at addr ffff88801ee89970 by task ovs_flow_del_ec/9487 Call Trace: __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c:930 ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c:1467 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Allocated by task 9487: mask_alloc net/openvswitch/flow_table.c:967 flow_mask_insert net/openvswitch/flow_table.c:1012 ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c:1084 ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c:1086 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Freed by task 9485: rcu_free_sheaf+0x1e/0x100 mm/slub.c:5978 rcu_do_batch kernel/rcu/tree.c:2645 rcu_core+0x59c/0x10c0 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9a0 kernel/softirq.c:622 ... instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 ovs_flow_tbl_remove() must be called after the ovs_flow_cmd_fill_info() to avoid this race. This also helps with cleaning up the forced cast and the cosmetic RCU read lock. Before the commit in the Fixes tag the order did not matter as long as the flow object itself was not freed. A wider RCU critical section could be another option, but we have a GFP_KERNEL allocation in the way. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-32042.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81000", "url": "https://ubuntu.com/security/CVE-2026-81000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tun: bound receive headroom tun_get_user() uses tun->align both as skb headroom and when choosing how much packet data to keep linear. OVS can propagate an oversized headroom request from another port to TUN or TAP. When align is larger than the usable space in a one-page skb head, SKB_MAX_HEAD(align) underflows and the result becomes negative when stored in good_linear. That value later wraps when assigned to the size_t linear variable, and tun_alloc_skb() can place skb->data outside the allocated head. Bound the headroom stored by TUN to the one-page skb-head budget and the largest non-sentinel 16-bit skb header offset. Leave one linear byte for raw TUN and a complete Ethernet header for TAP, including NET_IP_ALIGN. Also pull the raw-TUN protocol byte and the TAP Ethernet header before accessing them, so these checks remain safe for nonlinear skbs supplied by other allocation paths.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81001", "url": "https://ubuntu.com/security/CVE-2026-81001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: fix use-after-free in sl_sync() slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor. priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop: \t/* Snapshot list, allow later requests */ \tlist_replace_init(&net_todo_list, &list); \t__rtnl_unlock(); \t... \t\tif (dev->priv_destructor) \t\t\tdev->priv_destructor(dev);\t/* slip_devs[i] = NULL */ \t\tif (dev->needs_free_netdev) \t\t\tfree_netdev(dev); \t\t... \t\t/* Free network device */ \t\tkobject_put(&dev->dev.kobj); So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed */ sl = netdev_priv(dev) if (sl->tty || sl->leased) /* use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860 Commit e58c19124189 (\"slip: Fix use-after-free Read in slip_open\") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it. Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: the ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81002", "url": "https://ubuntu.com/security/CVE-2026-81002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xdp: fix zero-copy frame layout xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page and advertises PAGE_SIZE as its frame size. It allows the copied frame to occupy the page tail needed by skb_shared_info and records zero headroom even when metadata separates the frame header from packet data. An AF_XDP zero-copy packet redirected through cpumap can therefore make the skb overlap skb_shared_info or place it beyond the allocated page. Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result. BUG: KASAN: slab-out-of-bounds in skb_gro_receive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skb_gro_receive (net/core/gro.c:174) udp_gro_receive (net/ipv4/udp_offload.c:812) inet_gro_receive (net/ipv4/af_inet.c:1539) dev_gro_receive (net/core/gro.c:515) gro_receive_skb (net/core/gro.c:633) cpu_map_kthread_run (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Kernel panic - not syncing: KASAN: panic_on_warn set ...", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81003", "url": "https://ubuntu.com/security/CVE-2026-81003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: filter frames in afiucv_hs_rcv() by ingress device afiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-byte name fields in the transport header alone. No check is made against the net_device the frame arrived on. This can cause a frame arriving on any netdev to be delivered to an AF_IUCV socket. Three problems follow. First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL. iucv_sock_bind() takes the classic path whenever the requested userid matches iucv_userid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucv_hs_callback_syn() for such a match inherits hs_dev = NULL and transport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable. Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections Third, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() calls sk_alloc(&init_net, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAP_NET_RAW capability valid within that namespace can send a raw ETH_P_AF_IUCV frame on its own lo device and have it matched against init_net sockets. Fix all three by skipping any socket whose hs_dev does not match the ingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hs_dev is always a device in init_net (iucv_sock_bind() scans for_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket. Note that AF_IUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81005", "url": "https://ubuntu.com/security/CVE-2026-81005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: si: Fix NULL pointer dereference after failed registration try_smi_init() allocates new_smi->si_sm and later calls ipmi_register_smi_mod(), which maps to ipmi_add_smi(). During ipmi_add_smi(), the upper IPMI message handler obtains the initial BMC device information through __bmc_get_device_id(). This can fail if the BMC does not return a successful response to the Get Device ID command. When the BMC returns a nonzero completion code, the device-id helper retries the command and eventually returns -EIO if the device ID still cannot be fetched. On this failure path, ipmi_add_smi() logs \"Unable to get the device id\" and goes to out_err_started, where it invokes the lower driver's shutdown callback. try_smi_init() then logs the returned registration failure: ipmi_si IPI0001:00: IPMI message handler: Unable to get the device id: -5 ipmi_si IPI0001:00: Unable to register device: error -5 For ipmi_si, the shutdown callback is shutdown_smi(), which cleans up the SI state machine data, frees smi_info->si_sm, and sets smi_info->si_sm and smi_info->intf to NULL. However, intf->in_shutdown is not set on this failed-registration rollback path. Therefore, the asynchronous redo_bmc_reg work item can still retry BMC device-id probing after the lower driver has already cleared its SI state machine data. In the observed case, that retry path reached start_next_msg(), which passed the NULL smi_info->si_sm pointer to the selected KCS state machine handler: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Workqueue: events redo_bmc_reg [ipmi_msghandler] RIP: start_kcs_transaction+0x2c/0x190 [ipmi_si] Call Trace: start_next_msg+0x50/0x80 [ipmi_si] check_start_timer_thread.part.9+0x3b/0x50 [ipmi_si] sender+0x69/0x80 [ipmi_si] i_ipmi_request+0x2ac/0x9d0 [ipmi_msghandler] __get_device_id.isra.29+0xaa/0x180 [ipmi_msghandler] __bmc_get_device_id+0xef/0x950 [ipmi_msghandler] redo_bmc_reg+0x52/0x60 [ipmi_msghandler] process_one_work+0x1a7/0x360 Set intf->in_shutdown on the out_err_started path before invoking the lower driver's shutdown callback. This prevents later redo_bmc_reg retries from using an interface whose lower driver state has been cleaned up, and applies the same shutdown state to other IPMI interfaces as well.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81007", "url": "https://ubuntu.com/security/CVE-2026-81007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: validate write message length ipmb_write() read message fields before validating the length byte. A zero or short write can read uninitialized stack bytes. A length smaller than the SMBus header underflows the block write length. Require a non-empty buffer and the minimum IPMB request length. Also require the length byte plus payload before parsing the message.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81008", "url": "https://ubuntu.com/security/CVE-2026-81008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: interconnect: Fix use after free in icc_get() and of_icc_get_by_index() In of_icc_get_by_index() and icc_get(), if the dynamic allocation for path->name fails via kasprintf(), the error handling path directly calls kfree(path) to free the path object and returns an error. However, prior to this point, path_find() calls path_init(), which already links the path's requests into the req_list of the respective interconnect nodes via hlist_add_head(). Directly invoking kfree(path) leaves dangling pointers in the hlist. A subsequent call to icc_get() or icc_set_bw() will traverse or modify these corrupted lists, triggering a slab use afterfree. KASAN report showing the vulnerability when reproducing via debugfs: BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0 Fix this by replacing kfree(path) with the proper teardown function, icc_put(path), which safely removes the requests from the req_list using hlist_del() and drops the provider usage references before freeing the memory. Additionally, in icc_get(), ensure that the icc_lock mutex is released prior to calling icc_put(path) to avoid a deadlock, as icc_put() internally acquires the same lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81017", "url": "https://ubuntu.com/security/CVE-2026-81017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Bound the EC-reported sensor number Each EC FIFO event carries an 8-bit sensor number (in->sensor_num). cros_ec_sensorhub_ring_handler() validates the FIFO event count, the per-read count and the ring bound, but not the sensor number, which cros_ec_sensor_ring_process_event() then uses unchecked to index sensorhub->batch_state[] - allocated with only sensorhub->sensor_num entries. A sensor number of sensor_num or larger is an out-of-bounds read and write of batch_state[]. Validate the sensor number in the ring handler, where each event is read from the EC, and drop a malformed event before it is used.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89440", "url": "https://ubuntu.com/security/CVE-2026-89440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: via-sdmmc: stop card-detect handling on probe failure request_irq() registers the SD card-detect interrupt and the probe enables it before mmc_add_host() runs. If mmc_add_host() fails, the error path only unmaps the registers and returns: the interrupt stays registered, so the handler keeps running against the host once it is freed. via_sdc_isr() dereferences sdhost and its MMIO base and schedules carddet_work, which via_sdc_card_detect() also runs against freed memory through its container_of() dereference. Add a probe-error path that disables and frees the interrupt and cancels carddet_work before unmapping. carddet_work can re-enable the device interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it again after cancelling the work. This issue was found by an in-house static analysis tool and confirmed by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89444", "url": "https://ubuntu.com/security/CVE-2026-89444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer set_attribute() populates the security area of the BIOS attribute request buffer with the current admin password via populate_security_buffer(), then dumps the whole request buffer with print_hex_dump_bytes(). This can expose the plaintext admin password in the kernel log. The same issue was fixed for the password attribute path by commit d1a196e0a6dc (\"platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data\"). Remove the remaining dump from the BIOS attribute path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93206", "url": "https://ubuntu.com/security/CVE-2026-93206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/proc: Use file_ns_capable() when checking config space read access proc_bus_pci_read() decides how much of the config space is readable based on capable(CAP_SYS_ADMIN), which checks the credentials of the task calling read(), not the credentials of the process that opened the file. The sysfs equivalent, pci_read_config(), has checked the credentials of the opening process since commit de139a339395 (\"pci: check caps from sysfs file open to read device dependent config space\"), so a privileged process can open the config space file and pass the file descriptor to an unprivileged process (for example, a process running a KVM guest with an assigned device), which can then read the entire config space. The check was subsequently routed through the LSM framework in commit 47970b1b2aa6 (\"pci: use security_capable() when checking capablities during config space read\") and converted to the dedicated helper in commit ab0fa82b2df9 (\"pci-sysfs: use proper file capability helper function\"). Thus, the two interfaces check the same capability against different credentials. Checking the credentials of the task calling read() makes the outcome depend on who reads rather than who opened, so the restriction is bypassed whenever a more privileged process reads through the descriptor. Checking the credentials recorded in file->f_cred settles the decision at open() time and ties it to the file, where it cannot change with the caller. Use file_ns_capable() to check CAP_SYS_ADMIN against the credentials in effect when the file was opened, bringing the procfs interface in line with the sysfs behaviour. As a result, a file descriptor opened by a privileged process and passed to an unprivileged one now allows the entire config space to be read through procfs, matching sysfs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89456", "url": "https://ubuntu.com/security/CVE-2026-89456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Propagate partial completion length across ERP recovery dasd_default_erp_postaction() copies the timing and device state from the finished ERP request back to the original request but drops proc_bytes. A request that was partially completed, an ESE read of a not-yet-allocated track returns fewer bytes than requested, and then recovered through the ERP chain loses its partial-completion length. __dasd_cleanup_cqr() then sees proc_bytes == 0 and completes the whole request instead of requeueing the remainder, silently returning zeroed data for the part that was never read. Carry proc_bytes over to the original request like the other per-request state.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89457", "url": "https://ubuntu.com/security/CVE-2026-89457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Guard sysfs discipline callbacks against unallocated private data Several sysfs show/store handlers call a discipline callback that dereferences device->private, either directly or through the DASD_DEFINE_ATTR() macro. During dasd_generic_set_online() the discipline is assigned before check_device() allocates device->private, so an unprivileged read of one of these world-readable attributes in that window dereferences a NULL pointer and panics. Guard the dereference inside each callback that actually touches device->private.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89458", "url": "https://ubuntu.com/security/CVE-2026-89458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Do not complete a failed ESE read as successful dasd_int_handler() completes an NRF read of an unallocated ESE track by calling ese_read() and unconditionally marking the request DASD_CQR_SUCCESS. dasd_eckd_ese_read() can return an error before it has zeroed the destination buffer: a failed sense-data parse or a current track outside the requested range both return early, leaving the destination pages untouched. The request is still completed successfully, so the block layer is handed stale / uninitialized memory instead of zeros. Check the ese_read() return value and fail the request through the normal error path instead of forcing DASD_CQR_SUCCESS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89461", "url": "https://ubuntu.com/security/CVE-2026-89461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: synchronize work cancellation on suspend max17040_work() requeues itself after every poll. cancel_delayed_work() only cancels a pending instance and does not wait for a callback that is already running. If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns. Use cancel_delayed_work_sync() to ensure polling is quiesced before suspend completes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89463", "url": "https://ubuntu.com/security/CVE-2026-89463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ucs1002: fix use-after-free on remove ucs1002 has no remove callback, so unbind runs entirely through devm. The alert IRQ handler queues the health_poll delayed work, and the work reschedules itself while the chip reports a bad-health condition. devm frees the alert IRQ, which only synchronizes the handler; it does not cancel the delayed work, which can then run after devm frees the driver data and dereference it. Register health_poll with devm_delayed_work_autocancel() before the alert IRQ is requested. devm then frees the IRQ before cancelling the work, so the handler can no longer queue it and the work is cancelled before the driver data is freed. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89464", "url": "https://ubuntu.com/security/CVE-2026-89464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: twl4030_charger: cancel workers via devm bci is devm-allocated. Two workers (bci->work and bci->current_worker) dereference it. twl4030_bci_remove() disables charging and masks interrupts. It cancels neither worker. A worker pending at remove() can run after devm frees bci. The USB transceiver comes from devm_usb_get_phy_by_node(). devm unregisters its notifier only after remove() returns. A cancel_work_sync() in remove() can then race a notifier reschedule. devm_work_autocancel() and devm_delayed_work_autocancel() avoid that. They cancel the workers during devm release, before bci is freed. The current_worker is registered first, since devm will cancel in reverse order and bci->work can reschedule current_worker. [Move comment about order into the commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89469", "url": "https://ubuntu.com/security/CVE-2026-89469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: lp8727: fix use-after-free in lp8727_release_irq() lp8727_isr_func(), the threaded IRQ handler, is the only caller that arms pchg->work via schedule_delayed_work(). lp8727_release_irq() currently cancels the work before freeing the IRQ, so an IRQ delivered in between can re-arm the work through the threaded handler. After .remove returns the devm layer frees pchg while lp8727_delayed_func() may still run and dereference it. Free the IRQ first so the threaded handler is quiesced and can no longer queue work, then cancel the delayed work to drain the final generation. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89470", "url": "https://ubuntu.com/security/CVE-2026-89470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS Currently the cros_usbpd-charger driver probe iterates based on raw charger port count returned by the embedded controller. The only check is against the number of USB PD ports which the embedded controller also defines. A malicious embedded controller could return an inaccurate port count (up to 255) resulting in an out of bounds write and subsequent memory corruption. Update helper functions in cros_usbpd-charger to limit port counts to EC_USB_PD_MAX_PORTS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89471", "url": "https://ubuntu.com/security/CVE-2026-89471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd-charger: bound the EC-reported port count cros_usbpd_charger_probe() reads two port counts from the EC and uses one of them, num_charger_ports, as the loop bound when populating a fixed-size array: \tstruct port_data *ports[EC_USB_PD_MAX_PORTS];\t/* 8 entries */ \t... \tfor (i = 0; i < charger->num_charger_ports; i++) \t\tcharger->ports[charger->num_registered_psy++] = port; Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports (from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The only validation is a sanity check that compares the two EC-reported values against each other: \tif (num_charger_ports < num_usbpd_ports || \t num_charger_ports > num_usbpd_ports + 1) \t\treturn -EPROTO; It never checks either count against EC_USB_PD_MAX_PORTS, the size of the ports[] array. A malfunctioning, malicious or compromised EC that reports num_usbpd_ports == num_charger_ports == N for any N > 8 (for example both 255) passes this check, and the loop then writes N pointers into the 8-entry ports[] array embedded in the devm_kzalloc()'d charger_data, overflowing it by up to 255 - 8 = 247 entries (~1976 bytes): a slab out-of-bounds write. Reject a port count larger than the ports[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89474", "url": "https://ubuntu.com/security/CVE-2026-89474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: drain usb_work before freeing the charger The USB-PHY notifier queues usb_work, whose handler calls power_supply_changed(bq->charger). The reset devm action only unregisters the notifier and was registered before the power supplies, so devm frees bq->charger on unwind before the action runs; a usb_work still queued can then dereference it. Register the reset action after the power supplies, so it unregisters the notifiers and drains usb_work before the supplies are released. Initialize usb_work and obtain the PHY references before registering the notifiers, so the worker cannot run before the supplies exist. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89475", "url": "https://ubuntu.com/security/CVE-2026-89475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq24257: fix use-after-free on remove The STAT-pin interrupt is devm-managed, so it stays armed until the devm cleanup that runs after remove() returns. remove() cancels bq->iilimit_setup_work while the threaded handler can still fire; that handler reschedules the work and dereferences bq, so the work runs against freed memory once devm frees bq. Make the delayed work device-managed with devm_delayed_work_autocancel(), registered before the interrupt request. The devm cleanup then releases the interrupt first, so the handler can no longer reschedule the work, and cancels the work before bq is freed. The explicit cancel_delayed_work_sync() in remove() is no longer needed and is dropped. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89476", "url": "https://ubuntu.com/security/CVE-2026-89476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix stream->outcnt underflow on duplicate RECONF responses A cached RECONF chunk may contain more than one request parameter. A duplicate response can therefore find and process the same ADD_OUT request again while another parameter is still outstanding, rolling back outcnt twice and possibly underflowing it. Track outstanding request types as bits and clear each bit after its first response. Later responses for the same request are then ignored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89477", "url": "https://ubuntu.com/security/CVE-2026-89477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix NULL deref on untransmitted RECONF completion sctp_process_strreset_outreq(), sctp_process_strreset_addstrm_out() and sctp_process_strreset_resp() complete a pending stream reconfiguration request by stopping the reconf timer on the transport it was sent on: \tt = asoc->strreset_chunk->transport; \tif (timer_delete(&t->reconf_timer)) \t\tsctp_transport_put(t); chunk->transport is assigned by __sctp_packet_append_chunk() when the chunk is appended to an outbound packet, and sctp_outq_flush_ctrl() arms the reconf timer at that same point. A request already published in asoc->strreset_chunk but not yet transmitted has neither, so completing it dereferences NULL. Two ways to get there. sctp_send_asconf_del_ip() sets asoc->src_out_of_asoc_ok without sending anything when the address being removed is the association's last one, and sctp_outq_flush_ctrl() then leaves every non-ASCONF control chunk queued; as only sctp_process_asconf_ack() clears that flag, it persists. An unprivileged process that removes such an address and then asks for a stream reset panics the kernel from softirq. A peer needs neither ASCONF nor local help: sctp_cmd_interpreter() uncorks the outqueue only once the whole packet has been processed, so a reply built while walking a RECONF chunk stays untransmitted for the rest of that walk, and one RECONF chunk carrying [Incoming SSN Reset Request, Outgoing SSN Reset Request, Response] -- or two RECONF chunks in one packet -- reaches the same dereference. KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef] RIP: 0010:timer_delete+0x67/0x110 Call Trace: sctp_process_strreset_addstrm_out (net/sctp/stream.c:832) sctp_sf_do_reconf (net/sctp/sm_statefuns.c:4212) sctp_do_sm (net/sctp/sm_sideeffect.c:1172) sctp_assoc_bh_rcv (net/sctp/associola.c:1044) sctp_rcv (net/sctp/input.c:243) ip_local_deliver (net/ipv4/ip_input.c:262) process_backlog (net/core/dev.c:6680) A response can only acknowledge a request that was actually sent, so do not match asoc->strreset_chunk while chunk->transport is NULL. Guarding the lookup covers all three completion sites.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89478", "url": "https://ubuntu.com/security/CVE-2026-89478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: drop a chunk if its transport was removed sctp_rcv() resolves the transport once per packet and leaves it in chunk->transport. The lookup reference, or the one sctp_add_backlog() takes if the socket is owned by userspace, keeps it around until the chunk has been processed. An authenticated ASCONF DEL-IP can remove it in the meantime. sctp_assoc_rm_peer() takes the transport out of the association and calls sctp_transport_free(), which tags it dead and drops the reference the association held. There is a window on both paths: the packet can sit on the socket backlog, and on the direct path the lookup completes before bh_lock_sock(). The DATA chunk in that packet puts the removed transport back into asoc->peer.last_data_from. Once the packet is done that reference goes away and the transport is freed by RCU, so the next delayed SACK carries the pointer into the SACK chunk and sctp_outq_select_transport() reads the freed transport's state. Drop the chunk in sctp_inq_push(), next to the existing rcvr->dead check. Both paths reach it with the association's socket lock held. The peer retransmits it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89479", "url": "https://ubuntu.com/security/CVE-2026-89479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stop processing a packet once its association is deleted sctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference. A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(), so the association and its transports are freed. The endpoint loop has no counterpart to the asoc->base.dead check in sctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed transport and is then passed to sctp_do_sm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context. The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctp_inq_free() releases the chunk on the association receive path. sctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89480", "url": "https://ubuntu.com/security/CVE-2026-89480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: reject a read that transferred too few bytes nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above. A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target. Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89482", "url": "https://ubuntu.com/security/CVE-2026-89482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone Commit 25e5cb780e62 (\"nvme-tcp: fix possible crash in write_zeroes processing\") established that blk_rq_payload_bytes() must not be read without first checking blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight, because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now tests the same two.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89483", "url": "https://ubuntu.com/security/CVE-2026-89483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: zero the discard fallback page nvme_setup_discard() always maps sizeof(struct nvme_dsm_range) * NVME_DSM_MAX_RANGES = 4096 bytes as the DSM payload however many ranges the command declares, because some devices ignore the 'Number of Ranges' field - the Fixes: commit records two that read past the declared ranges. A single-range discard fills only the first 16 bytes. Normally the buffer comes from kzalloc() and the other 4080 bytes are zero. When that allocation fails the code falls back to the per-controller ctrl->discard_page, which nvme_init_ctrl() obtains with alloc_page(GFP_KERNEL) and nothing ever zeroes, so those 4080 bytes are whatever the page last held and are handed to the controller. Reaching it requires the kzalloc(GFP_ATOMIC | __GFP_NOWARN) to fail, that is memory pressure; it is not remotely triggerable. Failing the allocation under KMSAN reproduces it, with the leaked tail full of vmemmap struct page pointers. The extent in the report is a partial transfer of the payload, not the whole 4096 bytes; the 16-byte boundary in it is the one declared range: [ 11.991601] BUG: KMSAN: uninit-value in dma_map_phys+0x14c8/0x1900 [ 11.991969] dma_map_phys+0x14c8/0x1900 [ 11.992220] dma_map_page_attrs+0xcf/0x130 [ 11.992485] e1000_xmit_frame+0x4099/0x6d10 [ 11.992768] dev_hard_start_xmit+0x22f/0xa80 [ 11.993068] sch_direct_xmit+0x35c/0xcb0 [ 11.993315] __dev_queue_xmit+0x1ee5/0x5eb0 [ 11.993608] ip_finish_output2+0x1903/0x1c30 [ 11.993881] ip_finish_output+0x288/0x870 [ 11.994125] ip_output+0x15e/0x400 [ 11.994365] __ip_queue_xmit+0x1e85/0x1fb0 [ 11.994639] ip_queue_xmit+0x60/0x80 [ 11.994899] __tcp_transmit_skb+0x4e71/0x5fa0 [ 11.995210] tcp_write_xmit+0x3a36/0x9160 [ 11.995533] __tcp_push_pending_frames+0xc5/0x3c0 [ 11.995854] tcp_push+0x7dc/0x840 [ 11.996076] tcp_sendmsg_locked+0x766c/0x8400 [ 11.996371] tcp_sendmsg+0x4b/0x90 [ 11.996572] inet_sendmsg+0x134/0x2a0 [ 11.996823] __sock_sendmsg+0x265/0x360 [ 11.997076] sock_sendmsg+0x100/0x1e0 [ 11.997293] nvme_tcp_try_send+0x196f/0x6370 [ 11.997605] nvme_tcp_queue_rq+0x1d54/0x20b0 [ 11.997882] blk_mq_dispatch_rq_list+0x5ee/0x2e50 [ 11.998175] __blk_mq_sched_dispatch_requests+0x16dc/0x24a0 [ 11.998539] blk_mq_sched_dispatch_requests+0x11b/0x2c0 [ 11.998865] blk_mq_run_work_fn+0x13b/0x280 [ 11.999146] process_scheduled_works+0x966/0x1ad0 [ 11.999465] worker_thread+0xe44/0x1480 [ 11.999709] kthread+0x53b/0x600 [ 11.999927] ret_from_fork+0x29f/0x7c0 [ 12.000191] ret_from_fork_asm+0x1a/0x30 [ 12.000460] [ 12.000558] Uninit was created at: [ 12.000788] __alloc_frozen_pages_noprof+0x8bf/0xd30 [ 12.001096] alloc_pages_mpol+0x1d0/0x5f0 [ 12.001326] alloc_pages_noprof+0x102/0x290 [ 12.001627] nvme_init_ctrl+0x5a3/0x9f0 [ 12.001891] nvme_tcp_create_ctrl+0xd75/0x19b0 [ 12.002170] nvmf_dev_write+0x4c68/0x4fd0 [ 12.002426] vfs_write+0x587/0x1a10 [ 12.002636] __x64_sys_write+0x207/0x4f0 [ 12.002874] x64_sys_call+0x2ff0/0x3ea0 [ 12.003123] do_syscall_64+0x147/0x3b0 [ 12.003400] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 12.003680] [ 12.003777] Bytes 16-2843 of 2844 are uninitialized [ 12.004068] Memory access of size 2844 starts at ffff888109f82000 [ 12.004412] [ 12.004530] CPU: 0 UID: 0 PID: 101 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMECTL-gf5098b6bae76 #1 PREEMPT(lazy) [ 12.005127] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 12.005762] Workqueue: kblockd blk_mq_run_work_fn [ 12.006073] ===================================================== Allocate the page with __GFP_ZERO. The single allocation site covers every use of it: bytes no discard has written stay zero, and bytes one did write hold that controller's own range list, which it has already been sent.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89485", "url": "https://ubuntu.com/security/CVE-2026-89485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: pin next file across nlm_inspect_file lock-drop nlm_traverse_files() pins the current file with f_count++ across a mutex_unlock for nlm_inspect_file(), but nothing pins the saved next pointer. A concurrent nlm_release_file() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step. Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock. Always call nlm_file_release() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlm_file_inuse(), which does a live walk of the inode lock list, rather than the cached f_locks field, so skipped files that never ran nlm_inspect_file() are evaluated correctly. Because every file in a hash bucket is now pinned and released, files skipped by the is_failover_file predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89487", "url": "https://ubuntu.com/security/CVE-2026-89487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: only skb_tx_error() a packet we are about to drop queue_userspace_packet() borrows the packet skb -- it only copies it into a private netlink message (user_skb) and does not own it; on return do_execute_actions() keeps forwarding it through the flow's remaining actions. Its error path nevertheless calls skb_tx_error(skb), which via skb_zcopy_clear() does skb_shinfo(skb)->flags &= ~SKBFL_ALL_ZEROCOPY, stripping SKBFL_SHARED_FRAG from that live skb (skb_tx_error()'s kerneldoc says \"skb must be freed afterwards\"). For a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG is what makes esp_input() skb_cow_data() before in-place AEAD; once it is stripped a later local ESP-in-UDP delivery decrypts in place over pages the sender does not own -- an unprivileged page-cache write (the \"Fragnesia\" primitive). do_execute_actions() ignores output_userspace()'s return value, so any action after a failed USERSPACE upcall inherits the stripped skb. Move the skb_tx_error() to the flow-miss drop path - the \"default\" branch of ovs_dp_process_packet()'s switch(error), before kfree_skb(). The call has been here since commit 36d5fe6a0007 (\"core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors\") but was harmless until esp_input() began relying on SKBFL_SHARED_FRAG to gate in-place decrypt; only then did stripping it on a still-forwarded skb become a page-cache write primitive.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89489", "url": "https://ubuntu.com/security/CVE-2026-89489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openrisc: fix arbitrary kernel memory access via or1k_atomic syscall sys_or1k_atomic() (syscall 244 in the \"or1k\" ABI) takes two user pointers, v1 and v2, and swaps the words they point to in hand-written assembly. l.lwz r29,0(r4) l.lwz r27,0(r5) l.sw 0(r4),r27 l.sw 0(r5),r29 The pointers are not checked with access_ok(). The four memory accesses also have no exception table entries. A caller passes a kernel address as either pointer, and the syscall reads from and writes to it directly. This gives an unprivileged process a kernel read/write primitive. It overwrites kernel data such as the sys_call_table, gaining code execution in kernel context. Check both pointers before entering the critical section. Add fixups for the four memory accesses so faults on valid but unmapped user addresses return -EFAULT. [shorne@gmail.com: fix comment style]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89490", "url": "https://ubuntu.com/security/CVE-2026-89490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix readdir position truncation on 32-bit kernels In ocfs2_dir_foreach_blk_el(), the directory cookie position is rebuilt with \tctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset; `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask \t~(sb->s_blocksize - 1) is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB block size). In the AND expression with the 64-bit `ctx->pos`, that unsigned operand is zero-extended to 64 bits per the usual arithmetic conversions, yielding 0x00000000fffff000. The high 32 bits of `ctx->pos` are silently cleared, even though directory size is allowed to exceed 4 GiB. When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position is reset back into the first 4 GiB block, making the re-validation path re-enumerate already-returned dirents indefinitely. This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken for all non-inline directories, so a directory large enough to cross 4 GiB reaches it. This is the same class of bug that commit 3dce5bb82c97 (\"exfat: Fix bitwise operation having different size\") fixed in exfat, and the fix mirrors the equivalent ext4 fix in this series. Cast the operand to loff_t so the mask is 64-bit before the AND: \tctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89491", "url": "https://ubuntu.com/security/CVE-2026-89491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cluster: don't sleep while holding o2hb_live_lock in o2hb_region_pin() Patch series \"ocfs2: cluster: o2hb_region_pin() fixes\", v2. This series fixes three related issues in o2hb_region_pin(), all are from the original implementation in commit: 58a3158a5d17 (\"ocfs2/cluster: Pin/unpin o2hb regions\"): 1) It is called with o2hb_live_lock (a spinlock) held, but the underlying configfs_depend_item() sleeps (takes inode rwsem and pins the filesystem). This triggers BUG under CONFIG_DEBUG_ATOMIC_SLEEP. 2) When called from the configfs drop_item callback, it creates a lock order inversion: parent inode_lock -> configfs root inode_lock, which can deadlock against subsystem unregistration paths taking root -> parent. 3) If pinning fails partway through o2hb_region_inc_user(), the o2hb_dependent_users counter is leaked and partially-pinned regions are never released, leaving heartbeat regions unprotected on subsequent mounts. Patch 1 reworks o2hb_region_pin() to drop o2hb_live_lock across each sleeping configfs_depend_item() call, using a config_item reference to keep the region alive while unlocked. Patch 2 adds a from_callback parameter to select configfs_depend_item_unlocked() when called from configfs context, avoiding the inode_lock nesting. Patch 3 fixes the error path in o2hb_region_inc_user() to unpin and decrement the counter on failure. This patch (of 3): o2hb_region_pin() is always called with the o2hb_live_lock spinlock held (from o2hb_region_inc_user() and o2hb_heartbeat_group_drop_item()), but it calls o2nm_depend_item() -> configfs_depend_item(), which sleeps: it pins the configfs filesystem and takes the configfs root inode rwsem. Under CONFIG_DEBUG_ATOMIC_SLEEP this triggers: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c in_atomic(): 1, ... name: mount.ocfs2 down_write configfs_depend_item o2hb_region_pin o2hb_region_inc_user o2hb_register_callback dlm_register_domain_handlers ... ocfs2_dlm_init ocfs2_mount_volume ocfs2_fill_super Rework o2hb_region_pin() to pin one region at a time with the lock dropped across the sleeping call: under o2hb_live_lock find the next eligible region and take a config_item reference to keep it alive, drop the lock, call o2nm_depend_item(), then retake the lock and record the pin. The config_item_put() is done with the lock released as well, since o2hb_region_release() also acquires o2hb_live_lock and can sleep. The region list may change while unlocked, so the scan restarts from the top after each pin. Local heartbeat still pins only the matching region; global heartbeat pins all eligible regions. The unpin path is unaffected: configfs_undepend_item() only takes a spinlock and does not sleep.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89493", "url": "https://ubuntu.com/security/CVE-2026-89493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate rl_used against rl_count in refcount block validator ocfs2_find_refcount_rec_in_rl() walks the on-disk refcount record array with: \tfor (; i < le16_to_cpu(rb->rf_records.rl_used); i++) { \t\trec = &rb->rf_records.rl_recs[i]; \t\t... rl_recs[] lives in a single metadata block (4096 bytes on the common configuration), so its real capacity is fixed by ocfs2_refcount_recs_per_rb(sb) (247 records for a 4K block with the 16-byte ocfs2_refcount_rec). rl_used and rl_count are both read directly off disk by ocfs2_validate_refcount_block() and are never checked against that capacity, nor against each other, before any refcount/reflink/CoW operation walks the array. A crafted (or corrupted) refcount block with rl_used == 0xffff makes the loop above walk far past the end of the block, dereferencing rl_recs[i] for i up to 65534. The resulting index is then handed to the sibling ocfs2_insert_refcount_rec(), whose insert-shift does: \tif (index < le16_to_cpu(rf_list->rl_used)) \t\tmemmove(&rf_list->rl_recs[index + 1], \t\t\t&rf_list->rl_recs[index], \t\t\t(le16_to_cpu(rf_list->rl_used) - index) * \t\t\t sizeof(struct ocfs2_refcount_rec)); i.e. a memmove() of up to (0xffff - index) * 16 bytes (~1 MiB) from an offset already past the block. This is reachable from an ordinary reflink (FICLONE) against a crafted/corrupted ocfs2 image: attaching an extent whose cpos sorts past every real record in the leaf forces the lookup to run off the end instead of returning early on a match. The attacker model is local: CAP_SYS_ADMIN mounting a crafted or corrupted ocfs2 image, or a raw write to the block device backing an already-mounted ocfs2 filesystem. ocfs2_validate_refcount_block() already validates the block's ECC, signature, rf_blkno and rf_fs_generation, but never rl_count/rl_used against the block's actual on-disk capacity. This is the same class of gap that ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) already closes for the sibling extent-list header, which checks both the record capacity and the \"used\" bound before any code walks h_list.l_recs[]: \tif (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) { \t\trc = ocfs2_error(...); \t\tgoto bail; \t} \tif (le16_to_cpu(eb->h_list.l_next_free_rec) > \t le16_to_cpu(eb->h_list.l_count)) { \t\trc = ocfs2_error(...); \t\tgoto bail; \t} Add the equivalent pair of checks to ocfs2_validate_refcount_block(): reject a refcount block whose rl_count does not match the fixed per-block capacity returned by ocfs2_refcount_recs_per_rb(), and reject rl_used > rl_count. Both checks are skipped when OCFS2_REFCOUNT_TREE_FL is set, because in that case the same union bytes hold an ocfs2_extent_list (rf_list), not the refcount record list (rf_records) -- that layout is already validated separately by ocfs2_validate_extent_block() when the referenced extent block is read. This mirrors the existing \"!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)\" guard used elsewhere in this file (e.g. ocfs2_get_refcount_rec()) to decide whether rf_records or rf_list is the live member of the union. With this in place, a forged rl_used/rl_count is caught at block validation time (ocfs2_error()), consistent with every other corruption check in this function, instead of driving an out-of-bounds read in ocfs2_find_refcount_rec_in_rl() and a subsequent out-of-bounds memmove() in ocfs2_insert_refcount_rec(). Verified against a crafted image on a v6.19 KASAN (KASAN_GENERIC) build: replaying the same reflink (FICLONE) reliably hit a KASAN report in __ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() before this patch, and triggers no report once ocfs2_validate_refcount_block() rejects the forged rl_used/rl_count.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89494", "url": "https://ubuntu.com/security/CVE-2026-89494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate lengths in dlm_mig_lockres_handler A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres->ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain. Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres->lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len <= DLM_LOCKID_NAME_MAX, num_locks <= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89495", "url": "https://ubuntu.com/security/CVE-2026-89495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: bound namelen in dlm_migrate_request_handler Patch series \"ocfs2/dlm: bound peer-controlled lengths in the o2dlm\". The o2dlm receive handlers trust u8 length and count fields from the wire without bounding them, so a node in a DLM domain can corrupt or panic any other node with a malformed message. Three defects: - dlm_migrate_request_handler() passes migrate->namelen unchecked to dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an o2dlm_mle slab object: a heap out-of-bounds write of up to ~215 attacker-controlled bytes. - dlm_mig_lockres_handler() passes mres->lockname_len unchecked to dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname slab object: a heap out-of-bounds write of up to ~223 bytes. - the same handler trusts mres->num_locks without checking that the message is large enough to hold that many entries, so dlm_process_recovery_data() walks mres->ml[] past the kmalloc(data_len) copy and trips a BUG_ON (an out-of-bounds read ending in a panic). The other o2dlm receive handlers already reject an oversized name; the migration and recovery handlers have omitted it since the DLM was added (see the Fixes tags). Patch 1 bounds namelen; patch 2 validates lockname_len, num_locks, and the payload size. Conforming recovery and migration traffic is unaffected. o2net authenticates peers only by the DLM domain key, so any node that has joined the domain -- including a compromised or malicious member -- can send these messages. There is no local trigger; the attacker must already be a member of the cluster. Each sink was confirmed under KASAN with an out-of-tree module mirroring it exactly -- a kmem_cache/kmalloc of the real destination size, then the same unclamped memcpy/loop: slab-out-of-bounds Write for the two writes, Read for the recovery walk, and a panic. A userspace AddressSanitizer build faults identically under -m32 and -m64. Scrubbed logs are available on request. I reported this privately to security@kernel.org and the ocfs2 maintainers on 2026-06-20; with no response after the standard embargo period I am posting the fix publicly. I have no embargo requirement. This patch (of 2): A node receiving a DLM_MIGRATE_REQUEST message trusts the peer-supplied name length (migrate->namelen) without bounding it. dlm_init_mle() then copies that many bytes into the fixed DLM_LOCKID_NAME_MAX-byte mname[] array of an o2dlm_mle slab object, so a malformed message from a cluster peer overflows the slab object by up to ~215 bytes: a heap out-of-bounds write of attacker-controlled data, reachable by any node in the domain. Reject an oversized name, the way dlm_master_request_handler() and the other o2dlm receive handlers already do; the migration handler omits the check entirely. Conforming messages are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89496", "url": "https://ubuntu.com/security/CVE-2026-89496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: always run deallocs on copy-on-write completion Local fuzzing of 6.12.94 has found the following memory leak caused by doing 'copy_file_range()' within the same filesystem: unreferenced object 0xffff88812192c980 (size 32): comm \"syz.0.49\", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................ c0 c5 92 21 81 88 ff ff 00 02 00 00 00 06 00 00 ...!............ backtrace (crc 7068d63f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] ocfs2_find_per_slot_free_list fs/ocfs2/alloc.c:6618 [inline] ocfs2_cache_block_dealloc+0x155/0x4b0 fs/ocfs2/alloc.c:6786 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:944 [inline] direct_splice_actor+0x232/0x480 fs/splice.c:1167 splice_direct_to_actor+0x4b4/0xb60 fs/splice.c:1111 do_splice_direct_actor fs/splice.c:1210 [inline] do_splice_direct+0x10f/0x1c0 fs/splice.c:1236 do_sendfile+0x430/0xbf0 fs/read_write.c:1388 unreferenced object 0xffff88812192c5c0 (size 32): comm \"syz.0.49\", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 29 70 00 00 00 00 00 00 19 00 00 00 00 00 00 00 )p.............. backtrace (crc afec850f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ocfs2_cache_block_dealloc+0x25c/0x4b0 fs/ocfs2/alloc.c:6793 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:9 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89497", "url": "https://ubuntu.com/security/CVE-2026-89497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: skip leading spaces before parsing client debug masks orangefs_prepare_cdm_array() sizes each client debug keyword buffer with strcspn(cds_head, \" \"), but then parses the keyword with %s. The %s conversion skips leading whitespace, while strcspn() does not. If a client debug entry starts with a space, the allocation can be sized for an empty keyword while sscanf() copies the following non-empty token. This can write past the end of the allocated keyword buffer. Skip leading spaces before computing the keyword length so the allocation matches the string parsed by sscanf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89498", "url": "https://ubuntu.com/security/CVE-2026-89498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix double-free of trailer_buf on readdir copy failure On a readdir downcall, orangefs_devreq_write_iter() frees op->downcall.trailer_buf with vfree() when copy_from_iter_full() fails, but does not clear the pointer before goto Efault. The waiter in do_readdir() is then woken with a negative status and frees the same pointer again on its r < 0 path, causing a deterministic double-free. A client holding /dev/pvfs2-req triggers it by sending a readdir downcall whose declared trailer_size exceeds the bytes it supplies. Clear the pointer after freeing so the readdir-side vfree() becomes a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89504", "url": "https://ubuntu.com/security/CVE-2026-89504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: as3722_get_regulator_dt_data: fix premature of_node_put leaving dangling of_node pointer In as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a reference on np, which is then assigned to pdev->dev.of_node. The function immediately calls of_node_put(np), releasing the reference and leaving pdev->dev.of_node as a dangling pointer. Remove the of_node_put(np) call to let the device hold the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89508", "url": "https://ubuntu.com/security/CVE-2026-89508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Lock the handler in ucma_set_ib_path() ucma_set_ib_path() calls ucma_event_handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference: \tmutex_lock(&ctx->file->mut);\t\t\t/* file A */ \tlist_add_tail(&uevent->list, &ctx->file->event_list);\t/* file B */ \tmutex_unlock(&ctx->file->mut);\t\t\t/* file B */ \twake_up_interruptible(&ctx->file->poll_wait);\t/* file B */ A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION caller sleeps in mutex_lock(), so the list_add_tail() lands on file B's event_list while only file A's mutex is held, racing every other user of that list: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0 Read of size 8 at addr ffff888153c6a418 by task poc_corr/486 Call Trace: __list_add_valid_or_report+0x1aa/0x1c0 ucma_event_handler+0x1be/0xc00 ucma_set_ib_path+0x45e/0x710 ucma_set_option+0x32e/0x590 ucma_write+0x1f9/0x330 Allocated by task 505: ucma_write_cm_event+0x1a1/0x660 Freed by task 505: kfree+0x1da/0x4c0 ucma_get_event+0x5d5/0x7e0 The freed object is a ucma_event that another thread dequeued from file B's list under file B's mutex. File A's mut is left held on top of that, wedging its next writer in uninterruptible sleep. This path needs a bound and address-resolved cm_id, so it requires an RDMA device to be present. Take the handler lock around the call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89510", "url": "https://ubuntu.com/security/CVE-2026-89510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Cancel reg_work before freeing device on remove c4iw_uld_state_change() queues reg_work to register the RDMA device. c4iw_remove() can free ctx->dev while this work is pending or running, leaving c4iw_register_device() accessing the freed device. Cancel reg_work before removing the device. The registration work can tear down ctx->dev when registration fails, so do not unregister or deallocate it again in that case. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89511", "url": "https://ubuntu.com/security/CVE-2026-89511", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: Fix NULL pointer dereference in TPA fragment processing Under memory pressure, the qede driver encounters NULL pointer dereferences when processing TPA continuation fragments. Commit 8a8633978b84 (\"qede: Add build_skb() support.\") accidentally dropped the assignment of tpa_info->buffer.data in qede_tpa_start(). When memory pressure causes an SKB allocation failure in qede_tpa_start(), the driver sets tpa_start_fail = true and attempts to recycle the physical page later in qede_tpa_end() via qede_reuse_page(). However, because buffer.data was left uninitialized (NULL), qede_reuse_page() pushes a \"ghost\" BD (valid DMA mapping but NULL data pointer) back into the active Rx ring. The next time the hardware uses this ring slot, it passes a NULL page to qede_fill_frag_skb(), causing a kernel panic. Example crash from production system: BUG: unable to handle kernel NULL pointer dereference at 0x8 RIP: qede_fill_frag_skb+0x96/0x430 [qede] Call Trace: qede_rx_int+0xb06/0x1de0 qede_poll+0x2f4/0x6c0 __napi_poll+0x2d/0x130 Fix the root cause by restoring the tpa_info->buffer.data assignment in qede_tpa_start(), ensuring valid pages are correctly tracked and recycled. Additionally, update the stale comment for struct qede_agg_info::buffer to reflect its current usage.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89512", "url": "https://ubuntu.com/security/CVE-2026-89512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: scp: Fix device reference leak on failed lookup Make sure to drop the reference taken to the SCP device when attempting to look up its driver data before the driver has been bound. Note that holding a reference to a device does not prevent its driver data from going away.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89524", "url": "https://ubuntu.com/security/CVE-2026-89524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: clamp assoc request/response lengths before subtracting IE offsets ath6kl_cfg80211_connect_event() subtracts fixed IE offsets from assoc_req_len (-= 4) and assoc_resp_len (-= 6), both u8, with no lower bound. The aggregate check recently added to ath6kl_wmi_connect_event_rx() bounds the declared lengths from above (their sum must fit the received event), but an assoc request/response shorter than its fixed offset still underflows here: the u8 wraps to ~250, and cfg80211_connect_result() / cfg80211_roamed() then treat that wrapped value as the IE length and copy that many bytes out of the small assoc_info buffer to user space via nl80211, disclosing adjacent slab memory. Clamp both lengths to their offsets before subtracting. Found by 0sec (https://0sec.ai) using automated source analysis; the missing lower bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89525", "url": "https://ubuntu.com/security/CVE-2026-89525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: reject VAT indexes equal to the entry count UDF 1.50 virtual partition mapping uses the VAT as an array of physical block mappings. s_num_entries stores the number of entries in that array, not the highest valid index. The valid VAT indexes are therefore below s_num_entries. udf_get_pblock_virt15() currently rejects only indexes greater than s_num_entries. A crafted image can request index s_num_entries, pass the bounds check, and make the kernel read one entry past the allocated VAT table. Change the check to reject block >= s_num_entries, so the count is handled as an exclusive upper bound. A crafted UDF image reproduced this on origin/master commit 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53 with a KASAN slab-out-of-bounds report in udf_get_pblock_virt15(). Trail of Bits has a reproducer that triggers kernel panic demonstrating the bug, and can share it if needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89532", "url": "https://ubuntu.com/security/CVE-2026-89532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix pcl_for_each_segment for empty chunks When a parsed chunk list contains a chunk whose ch_segcount is zero, pcl_for_each_segment computes its inclusive upper bound as &chunk->ch_segments[ch_segcount - 1]. ch_segcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the ch_segments flex array. The loop body then walks unrelated memory at sizeof(struct svc_rdma_segment) stride until it faults. A zero-segcount chunk is reachable from the wire: xdr_check_write_chunk() only rejects segcount values greater than rc_maxpages, and pcl_alloc_write() links a freshly allocated chunk onto rc_write_pcl/rc_reply_pcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves ch_segcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svc_rdma_get_inv_rkey() iterates all four PCLs with pcl_for_each_segment and dereferences segment->rs_handle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault. xdr_check_write_list / xdr_check_reply_chunk pcl_alloc_write() chunk = pcl_alloc_chunk(...) /* ch_segcount = 0 */ list_add_tail(&chunk->ch_list, &pcl->cl_chunks) /* fill loop iterates zero times for wire segcount 0 */ svc_rdma_get_inv_rkey() pcl_for_each_chunk(rc_write_pcl) pcl_for_each_segment(segment, chunk) pos <= &ch_segments[0u - 1u] /* 0xFFFFFFFF */ segment->rs_handle /* OOB read -> GPF */ Fix by switching the macro to a half-open upper bound that uses ch_segcount directly. For ch_segcount == 0 the loop start equals the loop end and the body is skipped; for ch_segcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and net/sunrpc/xprtrdma/svc_rdma_rw.c remain correct under the new bound, so no caller changes are needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89533", "url": "https://ubuntu.com/security/CVE-2026-89533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix offset arithmetic in read_chunk_range svc_rdma_read_chunk_range() walks a Read chunk's segment list to build a sub-range starting at byte offset and spanning length bytes for a Position-Zero or Call chunk. Two arithmetic defects in the per-segment loop produce wrong DMA lengths and a u32 underflow: pcl_for_each_segment(segment, chunk) { if (offset > segment->rs_length) { offset -= segment->rs_length; continue; } dummy.rs_handle = segment->rs_handle; dummy.rs_length = min_t(u32, length, segment->rs_length) - offset; dummy.rs_offset = segment->rs_offset + offset; First, the skip predicate uses '>' instead of '>='. When offset equals the segment's full rs_length, the segment is fully consumed and should be skipped, but the loop falls through into the body. The resulting dummy.rs_length is min_t(u32, length, rs_length) - rs_length, which underflows to a near-UINT_MAX u32 when length is smaller than rs_length, or is zero otherwise. Second, the length formula subtracts offset from the min_t() result rather than from segment->rs_length before the cap. For offset > 0 the segment's residual is rs_length - offset, not rs_length, so the cap must be applied to the residual. With the current bracketing, whenever length is smaller than rs_length - offset the per-segment length becomes length - offset instead of length, silently dropping offset bytes from the rebuilt chunk. Combined with the boundary case above it also enables the u32 underflow path, which propagates a huge nr_bvec into svc_rdma_build_read_segment() and a multi-MiB kmalloc_array_node() in svc_rdma_get_rw_ctxt(). Additionally, svc_rdma_read_call_chunk() can invoke this function with length == 0 when the last Read chunk ends exactly at the end of the Call chunk. With the corrected >= predicate, every segment is skipped and the function returns the initial -EINVAL, rejecting a valid request. Return success immediately when length is zero. Also break out of the loop once length is fully consumed to avoid passing zero-length segments to svc_rdma_build_read_segment(). Fix by using '>=' so a fully-consumed segment is skipped, by moving '- offset' inside min_t() so the cap is applied to the segment's residual length, by returning success for zero-length requests, and by stopping iteration when the requested range has been consumed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89538", "url": "https://ubuntu.com/security/CVE-2026-89538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field gss_krb5_unwrap_v2() sets buf->len to a logical length, which can be much smaller than head[0].iov_len (the allocated receive-page capacity). It then calls xdr_buf_trim() with a trim length derived from the 16-bit \"extra count\" (ec) field in the Kerberos v2 token header. The ec field is authenticated by the post-decrypt memcmp() against the encrypted header copy, so a randomly-mutated value is rejected. However, any peer holding a valid GSS context can legitimately encrypt a token whose ec exceeds the plaintext length. Per RFC 4121, such a token is structurally malformed. Although xdr_buf_trim() now clamps the buf->len subtraction to avoid unsigned underflow, the buffer is still left in a semantically invalid state (zero length, inconsistent iov lengths) when ec is oversized. Reject these tokens before calling xdr_buf_trim(), giving callers a well-defined GSS_S_DEFECTIVE_TOKEN error and keeping the xdr_buf internally consistent. The wrapped blob begins at a nonzero offset -- both callers pass len as offset + opaque_len -- so buf->len still counts the offset bytes that precede the blob. Compare the trim length against the remaining wrapped segment, buf->len - offset, rather than the whole buffer; comparing against buf->len alone leaves an offset-wide window in which an oversized ec passes the test and xdr_buf_trim() cuts into the bytes ahead of the blob.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89540", "url": "https://ubuntu.com/security/CVE-2026-89540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: init gssp_lock before publishing proc entry create_use_gss_proxy_proc_entry() publishes /proc/net/rpc/use-gss-proxy via proc_create_data() before init_gssp_clnt() runs mutex_init() on sn->gssp_lock. Once the dentry is linked under proc_subdir_lock it is immediately reachable from userspace, so a write that lands in the window drives set_gssp_clnt() into mutex_lock() on a zero-initialized struct mutex. create_use_gss_proxy_proc_entry(net) proc_create_data(\"use-gss-proxy\", ...) /* dentry live */ init_gssp_clnt(sn) mutex_init(&sn->gssp_lock) /* too late */ write_gssp() set_gssp_clnt(net) mutex_lock(&sn->gssp_lock) /* uninitialized */ gssp_rpc_create(...) sn->gssp_clnt = clnt mutex_unlock(&sn->gssp_lock) The window spans only the two statements between proc_create_data() returning and init_gssp_clnt(), so a writer reaches it only if the registering thread is preempted there while another task is already opening the freshly published file. register_pernet_subsys() runs in preemptible context under pernet_ops_rwsem, so that preemption is possible, and the window widens on auth_rpcgss module load, when the proc entry is created for every live net namespace whose tasks are already running. A writer that wins the race locks a zero-filled struct mutex. On CONFIG_DEBUG_MUTEXES the missing magic value trips a \"lock used without init\" splat; on a production kernel the fast path acquires the lock via CMPXCHG(owner, 0, current). In the latter case a second writer that arrives before init_gssp_clnt() re-zeroes owner can enter set_gssp_clnt() concurrently, shut down the first writer's clnt while it is still in use, and leak the loser's clnt. Fix by initializing sn->gssp_lock in sunrpc_init_net() so its lifetime matches the sunrpc_net it lives in. sn->gssp_clnt is already NULL from the kzalloc that backs net_generic storage, so the lazy helper is no longer needed; drop init_gssp_clnt(), its prototype, and the call from create_use_gss_proxy_proc_entry(). sunrpc.ko is a build-time dependency of auth_rpcgss.ko, so sunrpc_init_net() has always run on every netns before any auth_gss pernet init can publish the proc entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89541", "url": "https://ubuntu.com/security/CVE-2026-89541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_unwrap_resp_priv length checks gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 (\"SUNRPC: svcauth_gss: enforce krb5 token minimum length\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89542", "url": "https://ubuntu.com/security/CVE-2026-89542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_krb5_unwrap_v2 against short tokens gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and ptr+6 before validating that the token is at least GSS_KRB5_TOK_HDR_LEN (16) bytes long, and its rotate_left() helper passes buf->len - base to xdr_buf_subsegment() without verifying that base <= buf->len. When a caller hands in a sub-16-byte token, or a token whose declared len leaves base past the end of the buffer, three distinct failures follow: gss_krb5_unwrap_v2(offset, len, buf) ptr = buf->head[0].iov_base + offset ec = *(ptr + 4) /* OOB read on short head */ rrc = *(ptr + 6) /* OOB read on short head */ rotate_left(offset + 16, buf, rrc) xdr_buf_subsegment(buf, &subbuf, base, buf->len - base) /* u32 wrap when base > len */ _rotate_left(&subbuf, shift) shift %= buf->len /* divide-by-zero when base == len */ After decryption, the cleanup arithmetic has the same shape: movelen = min_t(unsigned int, buf->head[0].iov_len, len); movelen -= offset + GSS_KRB5_TOK_HDR_LEN + headskip; BUG_ON(offset + GSS_KRB5_TOK_HDR_LEN + headskip + movelen > buf->head[0].iov_len); The BUG_ON re-adds the value just subtracted, so it reduces to min(A, B) > A and is permanently false; it cannot catch the unsigned underflow of movelen, which then drives a ~UINT_MAX-byte memmove(). Add four defense-in-depth guards inside the unwrap core so it is safe regardless of what its callers validate: - reject tokens with len - offset < GSS_KRB5_TOK_HDR_LEN before touching ptr+4/ptr+6; - bail from rotate_left() when buf->len <= base, covering both the underflow and zero-length cases; - return early from _rotate_left() when buf->len is zero, so the shift %= buf->len modulo cannot fault; - replace the dead BUG_ON with a live check that returns GSS_S_DEFECTIVE_TOKEN before the movelen subtraction.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89548", "url": "https://ubuntu.com/security/CVE-2026-89548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: always drain cache_cleaner before destroying a cache_detail sunrpc_destroy_cache_detail() only cancels the global cache_cleaner delayed_work when cache_list is empty. During per-netns teardown cache_list is never empty because init_net's caches remain registered, so the cancel never fires. After unlink, the caller proceeds to cache_destroy_net() which kfrees the cache_detail while cache_clean() may still hold a dangling pointer to it. The result is a use-after-free: cache_dequeue() takes cd->queue_lock on freed memory, and cache_put() dereferences cd->cache_put as a function pointer from freed slab. Drop the list_empty guard so that cancel_delayed_work_sync() always runs, ensuring any in-flight cache_clean() completes before the cache_detail is freed. Re-arm the cleaner afterwards if other caches are still registered.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89549", "url": "https://ubuntu.com/security/CVE-2026-89549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: route to a populated pool in svc_pool_for_cpu() svc_set_num_threads() spreads the requested threads evenly across the service's pools (base = nrservs / sv_nrpools). When a service runs fewer threads than it has pools -- e.g. an nfsd configured with fewer threads than the host has NUMA nodes while running in \"pernode\" or \"percpu\" mode -- the trailing pools are left with no threads at all. svc_xprt_enqueue() selects a pool from the CPU servicing the transport, queues the transport on that pool's sp_xprts, and only wakes a thread from the same pool. Each thread services exclusively its own pool, so a transport that lands on a threadless pool is enqueued on sp_xprts and never picked up: the connection hangs indefinitely. Have svc_pool_for_cpu() skip pools that currently have no threads, falling back to the next populated pool. This trades NUMA locality for a guarantee that the work is actually serviced. sp_nrthreads is only updated under the service mutex; the lockless read here is a best-effort routing hint, so annotate it with data_race().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89551", "url": "https://ubuntu.com/security/CVE-2026-89551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow xdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by walking the tail, pages, and head iovecs. Each per-section step uses min_t() so it never removes more bytes than that section holds, but the final accounting at the fix_len label subtracts the total bytes actually consumed from buf->len without any clamp: fix_len: buf->len -= (len - trim); When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches xdr_buf_trim() in exactly that state: buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip; buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip); xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip); buf->len is a small wire-derived value while the iov_lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder. Fix by clamping the decrement so buf->len bottoms out at zero: buf->len -= min_t(unsigned int, buf->len, len - trim); On the normal path where the iov_lens sum to buf->len, (len - trim) is always <= buf->len and the result is identical to before. No callers change behavior outside the underflow case.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89554", "url": "https://ubuntu.com/security/CVE-2026-89554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection. Restore subflow_req->local_id from the cookie entry, as done for the other fields.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89555", "url": "https://ubuntu.com/security/CVE-2026-89555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: reload header after pskb_may_pull() mpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop when an MPLS route has multiple nexthops. While walking the MPLS label stack, the hash routine caches hdr for the current label. After finding the bottom-of-stack label, it calls pskb_may_pull() before reading the inner IP header. If an skb is constructed with the inner IP header in nonlinear data and insufficient tailroom in the linear head, pskb_may_pull() calls pskb_expand_head() to replace the skb head and free the old one. This leaves hdr pointing to freed memory. The IPv6 path can invalidate hdr again when it performs a second pull for the larger header. The issue was found through static analysis. A reproducer sending a legal Geneve packet through a bareudp/MPLS multipath setup triggered the same KASAN report in 2 of 2 unpatched runs: BUG: KASAN: slab-use-after-free in mpls_select_multipath Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23 Call Trace: mpls_select_multipath mpls_forward __netif_receive_skb_list_core netif_receive_skb_list_internal napi_complete_done gro_cell_poll __napi_poll net_rx_action Freed by task 23: kfree pskb_expand_head __pskb_pull_tail mpls_select_multipath Reload hdr from the current skb head after each successful pull before deriving the inner IPv4 or IPv6 header pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89557", "url": "https://ubuntu.com/security/CVE-2026-89557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: do overflow check for sb->bblog_shift in super_1_load() In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 } bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c. Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller. This may avoid unnecessary check, make the badblocks API code more simple and elegant.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89559", "url": "https://ubuntu.com/security/CVE-2026-89559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Prevent integer overflow in __nd_label_validate() The on-media namespace index field nslot is a u32 read from the DIMM label storage area. __nd_label_validate() bounds it against the config area size, but sizeof_namespace_label() returns unsigned, so the product nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before the comparison. A crafted nslot passes the bound and is then used as the loop trip count in nd_label_data_init(), whose memset() walks off the end of the config_size buffer: an out-of-bounds write. The field is not trusted -- it comes from the medium, or from userspace via ND_CMD_SET_CONFIG_DATA. Evaluate the product in 64-bit so the bound check is exact; conforming labels are unaffected. The check was safe when introduced by commit 4a826c83db4e (\"libnvdimm: namespace indices: read and validate\"): it multiplied by sizeof(struct nd_namespace_label), a size_t, so on a 64-bit build the product did not wrap. Commit 564e871aa66f (\"libnvdimm, label: add v1.2 nvdimm label definitions\") narrowed it to 32 bits when the label size became a runtime value read via sizeof_namespace_label().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93226", "url": "https://ubuntu.com/security/CVE-2026-93226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU iterator to dump route exceptions rt6_nh_dump_exceptions() uses hlist_for_each_entry() to iterate over RCU-protected exception lists. The caller holds rcu_read_lock(), but does not hold rt6_exception_lock, so rt6_insert_exception() can concurrently add an entry with hlist_add_head_rcu(). KCSAN reports this race (irrelevant details omitted): ================================================================== BUG: KCSAN: data-race in rt6_insert_exception / rt6_nh_dump_exceptions write (marked) to 0xffff8a7c44c59620 of 8 bytes by interrupt on cpu 5: rt6_insert_exception+0x3bb/0x760 __ip6_rt_update_pmtu+0x4fe/0x750 ip6_sk_update_pmtu+0x19a/0x3b0 udpv6_err+0x3ff/0x800 icmpv6_notify+0x1e1/0x440 icmpv6_rcv+0x8c0/0xab0 ip6_protocol_deliver_rcu+0x616/0x840 ip6_input_finish+0xb9/0x160 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff8a7c44c59620 of 8 bytes by task 549 on cpu 14: rt6_nh_dump_exceptions+0xb3/0x260 rt6_dump_route+0x53e/0x5f0 fib6_dump_node+0x6d/0xf0 fib6_walk_continue+0x290/0x2d0 fib6_dump_table+0x28d/0x360 inet6_dump_fib+0x37d/0x620 rtnl_dumpit+0x7b/0xd0 netlink_dump+0x3ae/0x7e0 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f 4 locks held by dumper/549: ... #1: (rcu_read_lock){....}-{1:3}, at: inet6_dump_fib+0x88/0x620 #2: (&tb->tb6_lock){+.-.}-{3:3}, at: fib6_dump_table+0x1e9/0x360 #3: (rcu_read_lock){....}-{1:3}, at: rt6_dump_route+0x483/0x5f0 value changed: 0xffff8a7c44e05700 -> 0xffff8a7c45d60100 Reported by Kernel Concurrency Sanitizer on: CPU: 14 UID: 0 PID: 549 Comm: dumper Not tainted 7.2.0-rc7-virtme #38 PREEMPT(lazy) ... Use hlist_for_each_entry_rcu() to safely iterate over the exception list.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89562", "url": "https://ubuntu.com/security/CVE-2026-89562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: fix hardware header length for NBMA tunnels ip6gre_tnl_link_config_route() accumulates the lower device's hardware header length into dev->hard_header_len whenever header_ops is set. This is incorrect for both users of header_ops. ip6gretap and ip6erspan have a fixed Ethernet hardware header length. For an NBMA ip6gre tunnel, ip6gre_header() creates only the GRE header, the optional FOU or GUE header, and the outer IPv6 header. The lower device header is headroom needed later, not part of the tunnel device's hardware header. Keep the lower device header in needed_headroom. Set hard_header_len to the tunnel header length only for ARPHRD_IP6GRE devices with header_ops, and leave the fixed Ethernet header length unchanged for tap and erspan devices.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89563", "url": "https://ubuntu.com/security/CVE-2026-89563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit() ip6_tnl_xmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skb_realloc_headroom(), copies skb->sk ownership, consumes the original skb, and then continues processing with the replacement skb kept only in its local variable. That is safe only if the helper cannot fail afterwards. But this helper still has post-reallocation error exits. collect_md tunnels reject non-NONE encap after the replacement, and ip6_tnl_encap() can also fail later. In those cases the helper returns an error to its callers while the caller still only has the original skb pointer. Both ip6_tnl_start_xmit() and the IPv6 GRE paths free the caller skb on error, so they can end up freeing an skb that ip6_tnl_xmit() already consumed. Use skb_cow_head() instead. It provides the required headroom and writability without privately replacing the caller-owned skb, so later error returns cannot leave callers with a stale pointer. The Ethernet users, ip6gretap and ip6erspan, clear IFF_TX_SKB_SHARING and already call skb_cow_head() before entering ip6_tnl_xmit(). They do not rely on the removed skb_shared() reallocation. This also makes the IPv6 tunnel path consistent with ip_tunnel_xmit().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89569", "url": "https://ubuntu.com/security/CVE-2026-89569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: serialize security confirmation handling rfcomm_security_cfm() looks up a session on session_list and then walks its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown uses rfcomm_mutex, krfcommd can close and free the same session and DLCs concurrently: hci_rx_work krfcommd ----------- --------- rfcomm_session_get() rfcomm_lock() rfcomm_session_close() rfcomm_dlc_unlink() rfcomm_session_del() kfree(s) rfcomm_unlock() walk s->dlcs The callback can then read a freed session list head and touch freed DLCs while updating their flags or timers. Serialize the session lookup and DLC traversal in rfcomm_security_cfm() with rfcomm_mutex. This matches the existing RFCOMM session lifetime rules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink() from tearing the objects down while the callback is using them. KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440 Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89 Workqueue: hci0 hci_rx_work Call Trace: rfcomm_security_cfm+0x41c/0x440 hci_encrypt_cfm+0x139/0x590 hci_encrypt_change_evt+0x37b/0xc40 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 69: rfcomm_session_add+0x9e/0x2f0 rfcomm_run+0x44b/0x41e0 Freed by task 69: kfree+0x131/0x3c0 rfcomm_session_del+0x188/0x220 rfcomm_run+0x1985/0x41e0", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89573", "url": "https://ubuntu.com/security/CVE-2026-89573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm array: reject an array block whose value size is not the caller's array_block_check() can only compare the header against itself, so a block with value_size 4 and max_entries 1018 is internally consistent and passes. dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and the roots for both live in the superblock. Point the mappings root at a hint block and __load_mappings() walks it through an info whose value size is 8, so element_at() strides 8 bytes over 4-byte entries and reaches offset 8160 of a 4096-byte block. get_ablock() and __shadow_ablock() are the two places that hold the block and the caller at once. Reject there when the two value sizes disagree. Arrays only ever read their own blocks, so this fires on crafted metadata only.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89575", "url": "https://ubuntu.com/security/CVE-2026-89575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm raid1: reserve space for NUL-terminator in build_constructor_string() Reserve space for the termination NUL after the maximum 20 decimal digits of a long long value to avoid buffer overflow in sprintf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89576", "url": "https://ubuntu.com/security/CVE-2026-89576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-era: fix shadowed superblock leak on take-snap failure metadata_take_snap() bumps the live superblock refcount and then dm_tm_shadow_block() allocates a new block for the metadata snapshot. If the subsequent dm_sm_inc_block() of writeset_tree_root or era_array_root fails, the function only unlocks the clone and returns. The newly allocated shadow block is never returned to the metadata space map, so each failed take-snap permanently leaks one metadata block. Free the clone with dm_sm_dec_block() on those error paths, matching the final step of metadata_drop_snap().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89582", "url": "https://ubuntu.com/security/CVE-2026-89582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix double free in bnx2x_init_firmware() error path bnx2x_init_firmware() frees bp->init_ops, bp->init_data and bp->init_ops_offsets in its error path without setting them to NULL. The cleanup function bnx2x_release_firmware() frees the same three pointers unconditionally, so if init_firmware fails and release_firmware is later called (e.g. from __bnx2x_remove or through the function state machine), all three are freed a second time. Set each pointer to NULL after kfree() in the error path so that the subsequent kfree(NULL) in bnx2x_release_firmware() is a safe no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89585", "url": "https://ubuntu.com/security/CVE-2026-89585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: auxdisplay: charlcd: cancel backlight work on registration failure With CONFIG_CHARLCD_BL_FLASH, charlcd_init() schedules bl_work before charlcd_register() calls misc_register(). If registration fails, the caller frees the charlcd object while delayed work still contains its address. Add charlcd_deinit() to cancel the delayed work and turn the backlight off. Use it for both registration rollback and normal unregistration.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89586", "url": "https://ubuntu.com/security/CVE-2026-89586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes ata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the UNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command. The TRIM descriptor is built by ata_format_dsm_trim_descr() into the 2048-byte ata_scsi_rbuf staging buffer, and the number of bytes copied is compared against the logical sector size by the caller: \tsize = ata_format_dsm_trim_descr(scmd, trmax, block, n_block); \tif (size != len)\t\t/* len == sdp->sector_size */ \t\tgoto invalid_param_len; ata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE (2048). On a device whose logical sector size exceeds that (e.g. a 4Kn device, where sector_size == 4096) the function can never return more than 2048, while the caller expects it to return sector_size. The comparison therefore always fails, so every TRIM is rejected with \"Parameter list length error\" and WARN_ON() splats on each attempt. TRIM / discard is thus completely broken on such devices. The descriptor was incorrectly sized from the logical sector size. A DSM TRIM payload is a list of 512-byte pages, each holding up to ATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical sector size. The Block Limits VPD page already advertises a single such page as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical blocks), so the block layer never sends a request that needs more than one page. Emit exactly one 512-byte page, independent of the logical sector size, and transfer only that page (COUNT == 1). For a 512-byte-sector device this is unchanged; devices with larger logical sectors now work instead of failing every TRIM.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89594", "url": "https://ubuntu.com/security/CVE-2026-89594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device The OMAP SSI driver uses a synthetic HSI controller device allocated via hsi_alloc_controller(), which does not go through the normal OF/platform device initialization path. As a result, the embedded struct device does not have a DMA mask initialized by default. After recent DMA API hardening changes, dma_map_sg() and related helpers now require a valid dma_mask to be present, otherwise the driver may crash or trigger warnings when attempting DMA mapping operations. Fix this by explicitly initializing the DMA mask for the SSI controller device and setting a 32-bit DMA mask, which matches the hardware capabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89596", "url": "https://ubuntu.com/security/CVE-2026-89596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix off-by-one when saving/restoring non-PCI config space nv_suspend() and nv_resume() walk the non-PCI configuration space with \tfor (i = 0; i <= np->register_size/sizeof(u32); i++) which runs one iteration too many. saved_config_space is declared as \tu32 saved_config_space[NV_PCI_REGSZ_MAX/4]; and NV_PCI_REGSZ_VER3 is equal to NV_PCI_REGSZ_MAX (0x604), so on a VER3 device register_size/sizeof(u32) is exactly the array length and the last iteration addresses one element past the end. The element it lands on is np->name_rx[0..3]: saved_config_space[] is followed immediately by char name_rx[IFNAMSIZ + 3], and char needs no padding. Nothing observable is corrupted by that, because nv_request_irq() rewrites name_rx with sprintf() before it is ever passed to request_irq(). The bug is the out-of-bounds access itself, which UBSAN reports and which CONFIG_UBSAN_TRAP=y turns into a trap that aborts the running kernel code, plus an MMIO read and, on resume, an MMIO writel() to base + 0x604, one dword past the range the driver mapped: \tnp->base = ioremap(addr, np->register_size); VER1 and VER2 devices stay inside the array, but they too get the stray read and the stray write one dword past their own window. Caught by UBSAN on an Apple Macmini3,1 (MCP79) during a deep S3 cycle. The splat below is trimmed: the build path in the file name, the CPU and taint lines, the Workqueue line, the \"?\" hint frames, and the frames below device_suspend are all cut. The kernel was tainted, with an out-of-tree nouveau and CPU_OUT_OF_SPEC; forcedeth itself was the stock module. UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c:6225:25 index 385 is out of range for type 'u32 [385]' Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... Both loops are hit. UBSAN reports each source location only once per module load (__ubsan_handle_out_of_bounds() calls suppress_report(), which does test_and_set_bit(REPORTED_BIT, ...) on the struct source_location), so the two splats land in the first S3 cycle after the module is loaded and later cycles are silent even though the access still runs off the end every time. In that first cycle line 6225 is reported from pci_pm_suspend and line 6240 from pci_pm_resume. The same off-by-one was fixed in nv_get_regs() by commit ba9aa134287f (\"forcedeth: fix buffer overflow\") in 2012; these two loops were missed. The suspend and resume side was reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix, but the patch was attached rather than sent inline and the thread ended there. Use < instead of <=, which saves and restores exactly register_size bytes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89597", "url": "https://ubuntu.com/security/CVE-2026-89597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: unregister connector callback on init failure uvesafb_init() registers the v86d connector callback before registering the platform driver. If platform_driver_register() fails, the function returns the error directly and leaves the connector callback registered. The later platform-device failure path already unregisters the callback. Add the same cleanup before the final return when platform-driver registration fails. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89599", "url": "https://ubuntu.com/security/CVE-2026-89599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: panel-dsi-cm: initialize lock before registering display dsicm_probe() registers the display before initializing ddata->lock. Once omapdss_register_display() publishes the display, another consumer can reach a dsicm callback that takes this mutex while it is still uninitialized. Initialize the mutex before registering the display so the published callbacks always see a valid lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89605", "url": "https://ubuntu.com/security/CVE-2026-89605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: release message context on send failure ecryptfs_send_message_locked() moves a message context from the free list to the allocated list before sending the request to the userspace daemon. If ecryptfs_send_miscdev() fails, the context is left on the allocated list and cannot be reused. Move it back to the free list on failure and clear the caller's pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89606", "url": "https://ubuntu.com/security/CVE-2026-89606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject too-small tag 70 packets ecryptfs_parse_tag_70_packet() subtracts fixed metadata fields from the parsed packet body size to derive the encrypted filename size. A malformed packet with a body smaller than those fixed fields can underflow that size calculation. Reject tag 70 packets before the subtraction unless the body contains the signature, cipher code, and at least one byte of encrypted filename data.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89607", "url": "https://ubuntu.com/security/CVE-2026-89607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key() sets decrypted_key_size = encrypted_key_size and performs two out-of-bounds writes: 1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into decrypted_key[64] via scatterlist, overflowing into the parent ecryptfs_auth_tok struct. 2. memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes into crypt_stat->key[64], corrupting root_iv, keysig_list, and mutexes in ecryptfs_crypt_stat. Only AES-192 (cipher code 0x08) enables this because it sets crypt_stat->key_size = 24 independently of encrypted_key_size, allowing crypto_skcipher_setkey() to succeed while encrypted_key_size exceeds ECRYPTFS_MAX_KEY_BYTES. The PKI decryption path (parse_tag_65_packet) already validates decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path omits this check. Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also protects the 512-byte encrypted_key[] buffer, so the former 512-byte check is removed as redundant. [tyhicks: Adjust the code comment to refer to macros representing the buffer sizes rather than mentioning the buffer size values since they may change in the future]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89608", "url": "https://ubuntu.com/security/CVE-2026-89608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: pass packet set buffer size to parser ecryptfs_parse_packet_set() receives a pointer into the file header, but it calculates the remaining packet buffer size from PAGE_SIZE - 8. For version 1 headers the packet set starts later in the header, so this can overstate the available buffer. Pass the actual packet set buffer length from the caller and calculate per-packet limits from the remaining bytes in that buffer. Recompute the remaining length after consuming a tag 3 packet before parsing the following tag 11 packet.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89609", "url": "https://ubuntu.com/security/CVE-2026-89609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: hold msg ctx list lock when cleaning daemon queue ecryptfs_exorcise_daemon() drops queued messages from a dying daemon without holding ecryptfs_msg_ctx_lists_mux, but ecryptfs_msg_ctx_alloc_to_free() requires that lock. Take the list lock while moving the queued contexts back to the free list to avoid racing with other global msg ctx list users.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89615", "url": "https://ubuntu.com/security/CVE-2026-89615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound page_lcns[] index by the log record The copy_lcns loop and the redo shorten loop index page_lcns[] at j + i, where i runs up to the log record's lcns_follow. That count is checked only against the record's own length, not the target entry, so check_dp_table() (which validates the entry's lcns_follow) does not cover it: the copy_lcns entry may even be freshly allocated after that check, and find_dp() bounds j but not i. A crafted record thus overflows page_lcns[] of an otherwise valid entry. Add dp_range_ok() and reject, before each loop, any record whose run does not fit the entry. These are the only two page_lcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded. [almaz.alexandrovich@paragon-software.com: original patch contained changes to the problem already handled, applied partly]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89616", "url": "https://ubuntu.com/security/CVE-2026-89616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame() ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target pages and then trusts decompress_lznt()'s return value: unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem, frame_size); if ((ssize_t)unc_size < 0) err = unc_size; else if (!unc_size || unc_size > frame_size) err = -EINVAL; decompress_lznt() stops as soon as the compressed stream is exhausted (e.g. a zero chunk header) and returns the number of bytes it actually wrote, which may be far less than frame_size. The bytes between unc_size and frame_size are never written. The only memset() that follows zeroes the region beyond i_valid; when the frame lies entirely within the file's valid size that memset() does not run, so the gap retains whatever was in the just-vmapped pages. All pages are then marked uptodate and returned to userspace, disclosing uninitialized (recently-freed) kernel page memory. A crafted compressed file whose stream decompresses to only a few bytes leaks the remainder of every frame on a plain read(2), which is enough to recover kernel pointers and defeat KASLR. Zero the [unc_size, frame_size) tail immediately after a successful LZNT decompress so the remainder reads back as zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89617", "url": "https://ubuntu.com/security/CVE-2026-89617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate dirty page table on log replay Each DIR_PAGE_ENTRY ends in a page_lcns[] array whose length is the on-disk lcns_follow field. check_rstbl() validates the table bookkeeping but never checks that this array fits in the entry, so a crafted lcns_follow lets the v0->v1 conversion memmove and later replay passes run off the entry. Add check_dp_table() to reject, right after check_rstbl(), any entry larger than its size claims via struct_size() (the same expression used to allocate these entries, so the check is overflow-safe by construction). All consumers can then trust lcns_follow as the real capacity. This covers every page_lcns[] access whose index is bounded by the entry itself (the conversion memmove, the HotFix store via find_dp(), and the self-bounded scan loops). Accesses whose index comes from the log record need a separate bound and are handled in a follow-up patch.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89621", "url": "https://ubuntu.com/security/CVE-2026-89621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: mcp2221: validate report size in mcp2221_raw_event() mcp2221_raw_event() never validates the size of incoming HID reports. In the MCP2221_I2C_GET_DATA path it trusts the device-supplied data[3] as the copy length without checking that 4 + data[3] bytes actually exist in the received report. A malicious or misbehaving USB device can send a short report with a large data[3], causing the memcpy to read past the valid report data in the HID transfer buffer and leak uninitialized kernel memory back to userspace through the I2C/SMBus read path. Add a minimum size check at entry and validate that the source range fits within the received report before the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89626", "url": "https://ubuntu.com/security/CVE-2026-89626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix field sysfs group cleanup on failure hid_sensor_custom_add_attributes() creates one sysfs group for each custom sensor field. If sysfs_create_group() fails after some groups have already been created, the function returns the error without removing the previously created groups. Add a local unwind path to remove the groups that were already created. With enable_sensor exposed only after the field attributes are ready, this path can free sensor_inst->fields without leaving enable_sensor able to access pointers into that array.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89627", "url": "https://ubuntu.com/security/CVE-2026-89627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: free buffered reports when destroying device roccat_report_event() duplicates each report with kmemdup() and stores the allocation in a circular-buffer slot. The allocation is released only when that slot is reused. The device destruction paths free struct roccat_device without releasing reports still stored in cbuf[]. This makes those allocations unreachable and leaks up to ROCCAT_CBUF_SIZE report buffers per device. Add a small destructor that frees every buffered report before freeing the device, and use it in both paths that can destroy a registered device.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89628", "url": "https://ubuntu.com/security/CVE-2026-89628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: picolcd: clamp eeprom debugfs read to bytes actually received picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte supplied by the device in its REPORT_EE_DATA reply -- clamped only to the caller's read() count: \tret = resp->raw_data[2]; \tif (ret > s) \t\tret = s; \tif (copy_to_user(u, resp->raw_data+3, ret)) It never checks resp->raw_size, the number of bytes picolcd_raw_event() actually copied into the 64-byte raw_data[] of the kmalloc'd struct picolcd_pending. A device (or a spoofed picoLCD) returning a length byte of 0xff, read with a count >= 255, makes copy_to_user() read past raw_data[] into adjacent slab memory and return it to userspace through the debugfs \"eeprom\" file: \tBUG: KASAN: slab-out-of-bounds in _copy_to_user \tRead of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd] The debug-dump path in the same file already validates the device length byte against the received size before trusting it; this read does not. The file is created S_IRUSR (root-only) and a crafted device is needed, so it is neither unprivileged- nor remotely-triggerable. Clamp the copy length to resp->raw_size - 3 (the payload actually received, minus the 3-byte header), floored at 0 for short replies.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89643", "url": "https://ubuntu.com/security/CVE-2026-89643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: avoid dropping live tree ref on fsnotify rule autoremove audit_del_rule() is used for both netlink deletion templates and internal fsnotify autoremove. The former passes a parsed template which owns a temporary tree reference; the latter passes the installed entry itself. The unconditional audit_put_tree() at the end of audit_del_rule() assumes the template case. For mixed AUDIT_DIR plus AUDIT_EXE rules, an fsnotify autoremove event therefore drops the installed rule's live tree reference. Repeating this across rules sharing the same tree can free the tree while another rule still references it, and a later autoremove dereferences the freed pathname while comparing rules. Move the temporary-tree put to audit_rule_change(), the caller that owns deletion templates. Keep it in the AUDIT_DEL_RULE cleanup so both successful deletion and -ENOENT still release the parser-owned tree. [PM: dropped unnecessary comment for line length reasons]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89649", "url": "https://ubuntu.com/security/CVE-2026-89649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound xattr value length in __build_xattrs() __build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare \"p += len\" and no ceph_decode_need() check that \"len\" bytes remain in the blob. For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob. The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space. Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89650", "url": "https://ubuntu.com/security/CVE-2026-89650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound num_export_targets array for mds info v2/v3 ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from each per-mds info record and advances the decode cursor by num_export_targets * sizeof(u32) without first checking that many bytes remain. The only upper-bound check that catches a runaway cursor (*p > info_end) is gated on info_v >= 4, because info_end is left NULL for info_v 2 and 3. When the monitor sends an MDS map whose per-mds info version is 2 or 3 with an oversized num_export_targets, the cursor moves past the message front buffer and the later export-targets loop calls the unchecked ceph_decode_32() on out-of-bounds memory. A kernel client processes CEPH_MSG_MDS_MAP from its monitor session (net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an on-path attacker on an unsigned/unencrypted messenger session, can therefore drive an out-of-bounds read in the client kernel; on x86_64 with KASAN it is reported as a slab-out-of-bounds read in ceph_mdsmap_decode(). The decoded values land in the internal info->export_targets[] array, so the consequence is a kernel out-of-bounds read, not an information leak to the attacker. Impact: a malicious or compromised Ceph monitor sending an MDS map with a per-mds info version of 2 or 3 and an oversized num_export_targets field triggers an out-of-bounds read in the CephFS client kernel. Add a ceph_decode_need() for the export-targets array before advancing the cursor, so the bound is enforced for every info_v >= 2, not only info_v >= 4. This mirrors the count-then-need idiom already used for m_data_pg_pools later in the same function. Compute the export-targets byte count with size_mul() and reuse that checked length when advancing the cursor, so the attacker-controlled num_export_targets multiplication fails closed on overflow rather than relying on the later kcalloc() guard.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89653", "url": "https://ubuntu.com/security/CVE-2026-89653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode MDSMap export_targets entries are monitor controlled. check_new_map() uses each entry as a bit number in a fixed stack bitmap, so a rank outside the protocol namespace can make set_bit() write past the end of the array. Reject ranks outside CEPH_MAX_MDS while decoding the map. Do not validate against possible_max_rank here because maps may legitimately reference ranks beyond a temporarily reduced max_mds.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89655", "url": "https://ubuntu.com/security/CVE-2026-89655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock list_for_each_entry() iterates ci->i_cap_flush_list but drops i_ceph_lock to send cap messages. During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid <= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock. When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next on freed memory. The race timeline: __kick_flushing_caps() handle_cap_flush_ack() ----------------------- ----------------------- holds i_ceph_lock <--- iterates to cf (tid=10) prepares FLUSH message drops i_ceph_lock <--- __send_cap() ── FLUSH(tid=10) \t MDS sends FLUSH_ACK(tid=10) ---> acquires i_ceph_lock cf->tid(10) <= flush_tid(10), detaches cf from i_cap_flush_list drops i_ceph_lock ceph_free_cap_flush(cf) <- frees it! acquires i_ceph_lock <--- for-loop advances: cf = list_next_entry(cf, i_list) -- UAF on freed cf->i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS may respond with FLUSH_ACK quickly enough that handle_cap_flush_ack() frees cf before __kick_flushing_caps can finish the iteration. Fix by converting to a manual while loop: save the next pointer under i_ceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89656", "url": "https://ubuntu.com/security/CVE-2026-89656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject buckets with mismatched CRUSH ids crush_decode() stores bucket data by array slot, and the mapper later derives the per-bucket workspace index from the decoded bucket id. A malformed map can therefore make one bucket reuse another bucket's workspace by encoding an id different from -1 - slot. For uniform buckets, the second replica selection expands the source bucket's permutation into that aliased workspace buffer. If the source bucket is larger than the aliased bucket, the write runs past the smaller permutation array and can escape the kvmalloc'd CRUSH workspace. KASAN reports a slab OOB write of 4 bytes in bucket_perm_choose(). Reject buckets whose encoded id does not match their array slot. Valid CRUSH maps already use the canonical negative id corresponding to the bucket slot, so this restores the invariant expected by work->work[-1 - in->id] without changing valid map behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89662", "url": "https://ubuntu.com/security/CVE-2026-89662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent lock owner use-after-free during client teardown __destroy_client() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on cl_ownerstr_hashtbl. client_has_state() does not count a bare owner, so DESTROY_CLIENTID can reach __destroy_client() with such owners present. __destroy_client() then walks the table, calling remove_blocked_locks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flc_owner. The per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently of client state. The two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks(). nfsd4_release_lockowner() holds a reference across the same call; __destroy_client() does not. Hold cl_lock across the walk, taking a reference and unhashing each owner, then drop it before remove_blocked_locks() and nfs4_put_stateowner(), which take blocked_locks_lock and cl_lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89663", "url": "https://ubuntu.com/security/CVE-2026-89663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: revoke copy-notify stateids before dropping their reference Copy-notify stateids live in the s2s_cp_stateids IDR and on their parent stid's sc_cp_list, pinned by a single membership reference. _free_cpntf_state_locked() only unlinks an entry once its refcount reaches zero, so any revoke path that runs while a concurrent find_cpntf_state()/manage_cpntf_state() holder has elevated cs_count drops the reference without unlinking, leaving the entry discoverable with its membership reference already consumed. A second revoke or a laundromat tick then frees it while the reader still holds the pointer -- a KASAN-detectable use-after-free at the reader's nfs4_put_cpntf_state(). This affected all three revoke paths: - The parent-stid drain (nfs4_free_cpntf_statelist()) repeatedly called _free_cpntf_state_locked() on the first list entry; a holder that had bumped cs_count made it return early, so the next iteration re-decremented and burned the holder's reference. - OFFLOAD_CANCEL (manage_cpntf_state()) and laundromat expiry likewise used _free_cpntf_state_locked() and could drop 2->1 without unlinking. Add revoke_cpntf_state_locked(), which unhashes the entry from the IDR and sc_cp_list first (deferring the final free to any holder), and use it from all three revoke paths. The drain now walks with list_for_each_entry_safe() and revokes each entry unconditionally, so it terminates in one pass per entry regardless of cs_count. The unhash is gated on !list_empty(&cps->cp_list); the idr_remove() gate matters because idr_alloc_cyclic() may have recycled the so_id by then. Keep _free_cpntf_state_locked() for the reference-holder put path only, where a concurrent revoke may already have unlinked the entry (its list_del_init() then a no-op).", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89665", "url": "https://ubuntu.com/security/CVE-2026-89665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE The NFSv2 sattr decoder converts the wire useconds to nanoseconds in svcxdr_decode_sattr(): \tiap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC; tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds value such as 4294968 wraps to tv_nsec == 704. The corruption therefore happens during decode, before any proc function can inspect the value, and a later range check on tv_nsec would see an in-range result and accept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply. NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return for a malformed time argument, and the check cannot move to the proc function the way the v3/v4 nsec range checks do. Guard the raw useconds before the multiplication and reject values greater than 1000000. useconds == 1000000 is kept: it is the Sun convention for \"set to the current server time\", and the in-tree Linux NFSv2 client emits it in both the atime and the mtime field for a plain touch / utimes(file, NULL) (see encode_sattr() and xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000 would turn that common operation into a hard decode failure for both SETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap on ILP32, so the Sun convention value passes through safely. Only genuinely out-of-range values (> 1000000) are rejected. The atime and mtime guards are therefore symmetric. The decoder only applied the Sun convention in the mtime block, which clears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a client puts 1000000 in the atime field but not in the mtime field, the atime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET set, so the bogus value reached the filesystem. Apply the convention in the atime block as well, clearing ATTR_ATIME_SET so the server uses its current time and ignores the value. Only ATTR_ATIME_SET is cleared there. The mtime block keeps its existing behavior, where 1000000 means \"set both atime and mtime to now\". [ cel: various tweaks, addenda, and clean-ups ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89669", "url": "https://ubuntu.com/security/CVE-2026-89669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: initialize copy-notify stateid before publishing it nfsd4_copy_notify() finished initializing the cpntf state after nfs4_alloc_init_cpntf_state() had already linked it into the s2s_cp_stateids IDR and the parent's sc_cp_list, with cs_count == 1 (the membership reference) and none held for the caller. A racing OFFLOAD_CANCEL (crafted cl_id == nn->s2s_cp_cl_id plus the guessable so_id) could reach manage_cpntf_state() and free the entry, turning the caller's subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid writes into use-after-free. The owning clientid was also only recorded after publication, so it could not gate an ownership check in that window. Record cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state() before nfs4_init_cp_state() publishes the entry, and return it with an extra reference. The caller reads the stateid under that reference and drops it with nfs4_put_cpntf_state(); on a late error the laundromat reaps the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89673", "url": "https://ubuntu.com/security/CVE-2026-89673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo nfsd4_ff_encode_getdeviceinfo() computes the da_addr_body reservation as 16 + netid_len + addr_len, but the subsequent xdr_encode_opaque() calls emit 8 + round_up(netid_len, 4) + round_up(addr_len, 4) bytes. The mismatch means the declared da_addr_body length exceeds the actual encoded data by 2-8 bytes on every flexfile GETDEVICEINFO reply, leaking stale reply-page content to the client and mis-aligning the subsequent version list decode. Use xdr_align_size() for each string length to match what xdr_encode_opaque() actually writes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89674", "url": "https://ubuntu.com/security/CVE-2026-89674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client: - fh_len doesn't account for XDR padding on the file handle data - uid and gid lengths use \"8 + len\" but xdr_encode_opaque() actually writes \"4 + xdr_align_size(len)\" bytes - ds_len omits the flags and stats_collect_hint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client. Fix this by breaking out every encoded field explicitly in the ds_len calculation, using xdr_align_size() for all variable-length opaque fields, and correcting the header constants.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89684", "url": "https://ubuntu.com/security/CVE-2026-89684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix cpntf publish race in nfs4_init_cp_state nfs4_alloc_init_cpntf_state() published the new cpntf entry into the s2s_cp_stateids IDR (with cs_type set) in one s2s_cp_lock section, then took the lock again to list_add() it onto p_stid->sc_cp_list. In the gap the entry is reachable by so_id but cp_list is still {NULL,NULL} from kzalloc. A racing OFFLOAD_CANCEL (so_id is echoed to the client as cnr_stateid, so any NFSv4.2 client can drive it) reaches manage_cpntf_state() -> _free_cpntf_state_locked() and does list_del() on the zeroed list_head, oopsing the server. Fold the cs_type assignment and the list_add() into the same critical section as idr_alloc_cyclic(), so a concurrent lookup either misses the entry or sees a fully linked cp_list. INIT_LIST_HEAD() the entry after allocation and switch _free_cpntf_state_locked() to list_del_init() so a stale unlink is a no-op. nfs4_init_copy_state() passes NULL p_stid and skips the list_add, preserving NFS4_COPY_STID semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89694", "url": "https://ubuntu.com/security/CVE-2026-89694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: check client ownership when cancelling a copy-notify stateid On the OFFLOAD_CANCEL path (clp != NULL), manage_cpntf_state() freed the target cpntf state without checking ownership. The lookup key st->si_opaque.so_id is allocated cyclically (guessable) and the embedded clientid is the fixed per-net nn->s2s_cp_cl_id, so any authenticated NFSv4.2 client could cancel and free another client's copy-notify stateid. Compare the creating clientid recorded in state->cp_p_clid against the requesting client's cl_clientid and return nfserr_bad_stateid on a mismatch instead of freeing the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89696", "url": "https://ubuntu.com/security/CVE-2026-89696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref When CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return success with fh_dentry and fh_export both NULL if fh_verify() returns nfserr_stale and putfh->no_verify is true. The NFSD4_FH_FOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserr_nofilehandle check -- it does not prevent subsequent ops from running with a NULL fh_dentry. A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes check_if_stalefh_allowed() to set no_verify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fh_want_write() which dereferences fh_export->ex_path.mnt without calling fh_verify() first, causing a NULL pointer dereference in the nfsd kthread. Fix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set and fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow) and ops with ALLOWED_WITHOUT_FH (which don't need a resolved filehandle) may proceed. All other ops receive nfserr_stale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERR_STALE returned at that point.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89697", "url": "https://ubuntu.com/security/CVE-2026-89697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: add fh_want_write() for early-verified SETATTR in nfsd_proc_setattr() The BOTH_TIME_SET branch calls fh_verify() early so setattr_prepare() can inspect the dentry. This causes nfsd_setattr() to skip fh_want_write(), so notify_change() runs without a mount write reference. Add the missing fh_want_write() call after the early fh_verify().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89699", "url": "https://ubuntu.com/security/CVE-2026-89699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: validate symlink target length in NFSv4 CREATE nfsd4_decode_create() accepts an unbounded cr_datalen from the wire for NF4LNK symlink targets, allowing a client to force a kmalloc of up to the maximum RPC payload size (several MiB) per COMPOUND op that persists until compound teardown. The VFS rejects oversized targets with ENAMETOOLONG, but the allocation has already occurred. Reject cr_datalen == 0 early with nfserr_inval and cr_datalen greater than NFS4_MAXPATHLEN (PATH_MAX) with nfserr_nametoolong to bound the allocation.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89704", "url": "https://ubuntu.com/security/CVE-2026-89704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: sample writeback error cursor before async COPY loop _nfsd_copy_file_range() samples dst->f_wb_err into \"since\" after the copy loop, then uses it to detect writeback errors via filemap_check_wb_err() once vfs_fsync_range() returns. Because the nfsd_file cache reuses a single struct file across requests targeting the same inode, a concurrent COMMIT or stable WRITE on dst advances dst->f_wb_err to the current mapping->wb_err via file_check_and_advance_wb_err() during its own vfs_fsync_range(). If that advancement lands between the writeback error appearing in mapping->wb_err and the COPY worker sampling \"since\", the worker captures the already-advanced cursor, errseq_check() sees cur == since and returns zero, and NFSD4_COPY_F_COMMITTED is set even though writeback failed. CB_OFFLOAD then encodes wr_stable_how = FILE_SYNC4, the client treats the copied data as durable, and the failure becomes silent data loss. Sample since once at the start of the function. The cursor then reflects state in effect before this COPY issues any writes, and filemap_check_wb_err() detects any error that occurs during the copy regardless of which thread first observes it. This matches the pattern used by nfsd_vfs_write() and nfsd4_clone_file_range().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89706", "url": "https://ubuntu.com/security/CVE-2026-89706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: Reset write verifier when async COPY writeback fails Async COPY captures nn->writeverf at request time and reports it to the client via CB_OFFLOAD after the worker kthread completes. When the post-copy vfs_fsync_range() or filemap_check_wb_err() in _nfsd_copy_file_range() reports an error, the worker correctly leaves NFSD4_COPY_F_COMMITTED clear so that CB_OFFLOAD encodes wr_stable_how as NFS_UNSTABLE, but the server's write verifier is not rotated. A client that receives NFS_UNSTABLE in CB_OFFLOAD follows up with COMMIT to make the copied data durable. With the verifier unchanged, COMMIT returns the same value the client just received via CB_OFFLOAD, and the client concludes the copy is durable -- silently dropping the data whose writeback in fact failed. This violates the UNSTABLE+COMMIT durability contract (RFC 7862 section 15.1, RFC 8881 section 18.32) and matches the bug just fixed in nfsd_vfs_write() and nfsd_commit(). Rotate nn->writeverf at the writeback-failure site. The async COPY worker has no svc_rqst, so commit_reset_write_verifier() is not available here; calling nfsd_reset_write_verifier() directly mirrors the trace-less reset already used by nfsd_file_check_write_error() for the same purpose. Filter out -EAGAIN and -ESTALE, matching commit_reset_write_verifier(), since neither indicates a durable-storage failure.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89710", "url": "https://ubuntu.com/security/CVE-2026-89710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget path When the server returns a new layout stateid while a valid one is still held, pnfs_layout_process() calls pnfs_mark_matching_lsegs_return() on the on-stack free_me list and jumps to out_forget. Segments whose reference count drops to zero are unlinked from lo->plh_segs and moved to free_me by mark_lseg_invalid(); for an idle cached segment the layout header holds the only reference, so this happens on the first decrement. out_forget never drains free_me -- only the success path calls pnfs_free_lseg_list(). Commit 814b84971388 (\"pNFS/NFSv4: Fix a layout segment leak in pnfs_layout_process()\") added the drain; commit 08bd8dbe8882 (\"pNFS/NFSv4: Try to return invalid layout in pnfs_layout_process()\") removed it while switching the destination to lo->plh_return_segs, which is drained elsewhere. Commit fb700ef02676 (\"NFSv4.1: Simplify layout return in pnfs_layout_process()\") switched the destination back to free_me without restoring the drain. Restore the pnfs_free_lseg_list() call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89711", "url": "https://ubuntu.com/security/CVE-2026-89711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check The header for commit e75b23f9e323 (\"nfsd: check d_can_lookup in fh_verify of directories\") details the assumption that justified adding the WARN_ON_ONCE to nfsd_mode_check(), that assumption is invalid (in the case of NFS reexport). When NFSD exports an NFS filesystem it is very possible for nfsd_mode_check() to encounter a @dentry that doesn't have i_op->lookup (see nfs_fhget()'s NFS_ATTR_FATTR_MOUNTPOINT and NFS_ATTR_FATTR_V4_REFERRAL handling, and d_flags_for_inode()). So remove nfsd_mode_check()'s WARN_ON_ONCE(). The nfserr_notdir return on that branch must stay. It guards the subsequent lookup_one_unlocked() -> __lookup_slow() path, which calls inode->i_op->lookup() with no NULL check, so returning nfserr_notdir is what keeps a client LOOKUP into such a @dentry from dereferencing a NULL method pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89712", "url": "https://ubuntu.com/security/CVE-2026-89712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock nfsd4_ssc_expire_umount() walks nn->nfsd_ssc_mount_list with list_for_each_entry_safe(ni, tmp, ...). For each expired entry it sets nsui_busy = true, drops nfsd_ssc_lock to run mntput() on the source vfsmount, then reacquires the lock to list_del + kfree the entry and continue iterating via the macro's saved tmp pointer. The nsui_busy flag protects the current ni from concurrent nfsd4_ssc_setup_dul() finders during the lock-drop window, but it does not pin tmp. Another nfsd RPC thread that fails its source- server mount and reaches nfsd4_ssc_cancel_dul() will, during that same window, take nfsd_ssc_lock, list_del + kfree its own ssc_umount item, and release the lock. If that item is the saved tmp of the expire walk, the next iteration dereferences a freed nfsd4_ssc_umount_item. Restart the walk from the head after the mntput() unlock window so no saved next pointer survives the lock-drop. The list is bounded by the number of active inter-server source mounts (typically small) and the expire delayed-work runs periodically rather than per-IO, so the restart is cheap.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89720", "url": "https://ubuntu.com/security/CVE-2026-89720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: fix out-of-bounds read in signature length check ubifs_sb_verify_signature() bounds the on-disk ubifs_sig_node->len field before handing the signature payload to verify_pkcs7_signature(), but the check has the wrong sign: \tif (le32_to_cpu(signode->len) > snod->len + sizeof(struct ubifs_sig_node)) The signature bytes start sizeof(struct ubifs_sig_node) (UBIFS_SIG_NODE_SZ, 64 bytes) into the node, so the payload is at most \tsnod->len - sizeof(struct ubifs_sig_node) bytes long. Adding the header size instead of subtracting it accepts a declared length up to 2 * UBIFS_SIG_NODE_SZ larger than the node actually holds -- past the end of c->sbuf, which is vmalloc(c->leb_size). verify_pkcs7_signature() -> pkcs7_parse_message() -> asn1_ber_decoder() is then handed that inflated length and reads beyond the allocation while walking the DER headers. The node length comes straight from the mounted image, so a crafted signed UBIFS image reaches this via ubifs_read_superblock() before the signature is cryptographically checked. snod->len is guaranteed to be >= UBIFS_SIG_NODE_SZ by the node scanner (c->ranges[UBIFS_SIG_NODE].min_len == UBIFS_SIG_NODE_SZ), so the corrected subtraction cannot underflow. Legitimately signed images are unaffected: a correct superblock never declares a signature longer than the node it is embedded in.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93213", "url": "https://ubuntu.com/security/CVE-2026-93213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: of: fix out-of-bounds read in of_alias_scan() stem parser The stem parser tests isdigit(*(end - 1)) before checking end > start and so reads one byte before the property name when the name is empty or all digits. Check the bound first.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89723", "url": "https://ubuntu.com/security/CVE-2026-89723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after truncation Shuangpeng Bai reported that KASAN detected a slab-out-of-bounds error in nilfs_direct_propagate() during testing. Analysis revealed that after truncating a file, a node block immediately below the B-tree root was not deleted. Instead, it remained in the B-tree node cache in a dirty state. The log writer subsequently detected this block and incorrectly invoked nilfs_direct_propagate() on it, which is designed to handle only data blocks in direct mapping. B-tree nodes in the cache are managed by virtual block numbers, and their logical keys typically exceed the range expected by direct mapping. Consequently, processing such a node as a direct mapping entry triggers a slab-out-of-bounds access. The root cause is that when a B-tree mapping collapses into a direct mapping during truncation, an intermediate node block pointed to by the root node is left behind as garbage instead of being explicitly deleted. This resolves the issue by adding a nilfs_btree_discard() operation to delete the remaining intermediate node block during the conversion. A 'deform' flag is added to the bop_delete interface to explicitly signal that the deletion is part of a mapping transformation. This allows the B-tree mapping implementation to perform the necessary cleanup and discarding of the residual node structure that would be otherwise be left orphaned after the transition.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89724", "url": "https://ubuntu.com/security/CVE-2026-89724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vicodec: fix out-of-bounds write in FWHT encoder vidioc_s_fmt_vid_out() sizes the encoder CAPTURE buffer from the compressed descriptor pixfmt_fwht, whose sizeimage_mult is 3: coded_w * coded_h * 3 + sizeof(struct fwht_cframe_hdr). fwht_encode_frame() encodes one plane per component, and an incompressible plane takes the FWHT_FRAME_UNENCODED path in encode_plane(), copying the plane verbatim. For a 4-component pixel format all four planes are full resolution (width_div == height_div == 1), so a frame that forces every plane through the unencoded fallback writes sizeof(struct fwht_cframe_hdr) + 4 * coded_w * coded_h bytes, overrunning the plane by coded_w * coded_h, which can result in corruption of adjacent kernel heap memory. Bump pixfmt_fwht.sizeimage_mult from 3 to 4, matching the largest components_num among the supported raw formats, so the capture buffer is always large enough for the unencoded fallback.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89725", "url": "https://ubuntu.com/security/CVE-2026-89725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: stm32: prevent out-of-bounds write on RX overflow stm32_rx_done() appends each received CEC byte to rx_msg.msg[] using rx_msg.len as the write index, incrementing it on every RXBR (receive-byte-ready) interrupt without checking it against the buffer size: \tcec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF; rx_msg.msg[] is a fixed CEC_MAX_MSG_SIZE (16) byte array in struct cec_msg, and rx_msg.len is only reset on RXACKE/RXOVR or after a completed message (RXEND). The number of bytes received before RXEND is decided by the remote CEC device (it sets EOM), not by the driver. A peer that keeps sending bytes without ending the message drives RXBR repeatedly, pushing rx_msg.len past 16 and writing peer-controlled bytes out of bounds into the surrounding memory. This is reachable in normal operation once the driver has probed and receiving is enabled, from the IRQ thread, without any local privilege. The length check in the CEC core runs on the consumer side, after the byte has been stored, so it does not prevent the overflow. Bound the index in the driver before the store, as the other platform CEC drivers already do (e.g. tegra_cec), dropping the excess bytes of an overlong frame. Found by static analysis tool CodeQL.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89726", "url": "https://ubuntu.com/security/CVE-2026-89726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen() Patch series \"lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()\", v2. This series fixes an off-by-one out-of-bounds read in ucs2_strnlen(). The first patch is the real fix, the second patch comes as a bonus and fixes the code indentation. This patch (of 2): ucs2_strnlen() checks the current character before checking whether the caller-provided maximum length has been reached. If the input is not NUL-terminated within that bound, the loop can read one ucs2_char_t past the limit. Test the length before dereferencing to prevent an off-by-one out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89729", "url": "https://ubuntu.com/security/CVE-2026-89729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature sensor_hub_get_feature() clamps its return value to the caller's buffer size, but the copy loop still copies field->report_size / 8 bytes for each report value. A malicious HID descriptor can advertise a large feature field size while an IIO caller supplies a small stack buffer, such as a single s32, causing an out-of-bounds write. HID core stores parsed report values in __s32 slots and clamps extracted values to 32 bits. Reject feature fields that require more than one slot per value, guard the total byte count calculation, and clamp each per-value copy to the remaining caller buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89730", "url": "https://ubuntu.com/security/CVE-2026-89730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write The trailing byte path in altera_cvp_send_block() dereferences a u32 pointer even when only 1-3 bytes remain in the input buffer. If the buffer ends at a page or scatterlist boundary, this can read past the valid image data and fault. Copy the remaining bytes into a zero-initialized u32 before writing the final word so only valid bytes are read from the input buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89732", "url": "https://ubuntu.com/security/CVE-2026-89732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Prevent deadlock during ep0 read loop Currently, ffs_ep0_read() holds ffs->mutex when it prepares to go to sleep waiting for an event. When no setup events are pending, it calls wait_event_interruptible_exclusive_locked_irq() with the mutex still held. The wait macro deliberately drops the waitqueue spinlock before sleeping but does not drop the mutex. If a userspace daemon is polling ep0 via read() and the gadget is asynchronously torn down via configfs (e.g., echo \"\" > UDC), a deadlock can occur: 1. The configfs teardown calls functionfs_unbind(), which queues a FUNCTIONFS_UNBIND event. 2. The daemon wakes up, consumes the event, and drops the mutex. 3. However, if the daemon loops and immediately issues another read() before exiting, it reacquires ffs->mutex and again goes into an interruptible sleep. 4. Meanwhile, functionfs_unbind() continues execution and attempts to acquire ffs->mutex to tear down ep0req. 5. The kernel deadlocks because the configfs thread is stuck in an uninterruptible sleep waiting for the mutex, while the userspace daemon is in an interruptible sleep holding the mutex forever because no more events will arrive. To fix this, we drop both the waitqueue spinlock and ffs->mutex before going to sleep, and use wait_event_interruptible_exclusive() instead. Upon waking up, we jump back to the `retry` label to safely reacquire the mutex and re-evaluate the state machine. By not sleeping with ffs->mutex held, we natively decouple gadget teardowns (which require the mutex) from userspace polling.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89733", "url": "https://ubuntu.com/security/CVE-2026-89733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and uvc_function_unbind() In uvc_function_bind() error path, we use usb_ep_free_request which uses uvc->control_req but does not set it to NULL afterwards. Thus, uvc->control_req is a dangling pointer causing a UAF. Also we do not set the uvc->control_buf pointer to NULL after freeing it, which is another dangling pointer. Fix it by setting uvc->control_req to NULL after we run usb_ep_free_request() and uvc->control_buf to NULL after kfree. Do the same for uvc_function_unbind().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93214", "url": "https://ubuntu.com/security/CVE-2026-93214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: fix deadlock in usbg_make_tpg() usbg_make_tpg() held dep_lock while calling configfs_depend_item_unlocked(), which acquires the configfs root inode lock when operating across subsystems. This creates a circular lock dependency with configfs_rmdir(): dep_lock -> configfs root inode lock -> su_mutex -> dep_lock In usbg_make_tpg(), dep_lock only serialized the read of opts->ready, which is a monotonic flag that transitions from false to true exactly once (in tcm_set_name()) and never reverts. Remove dep_lock from usbg_make_tpg() entirely and use READ_ONCE/WRITE_ONCE to access opts->ready locklessly instead.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89736", "url": "https://ubuntu.com/security/CVE-2026-89736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: Fix use-after-free on sound card disconnect g_audio_cleanup() invokes snd_card_free_when_closed() to initiate sound card teardown and immediately frees the underlying struct snd_uac_chip context. However, snd_card_free_when_closed() returns asynchronously while ALSA control elements (kctls) remain open in userspace. When userspace control applications access or close these open file descriptors, kctl callbacks attempt to dereference kctl->private_data pointing to &uac->c_prm or &uac->p_prm within the freed uac structure, resulting in a use-after-free (UAF) memory corruption. Fix this issue by deferring the destruction of struct snd_uac_chip until all references to the ALSA sound card are released. Register a custom card->private_free callback (u_audio_card_free) during g_audio_setup() that frees uac and its associated playback/capture request and ring buffers only when the sound card reference count drops to zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89741", "url": "https://ubuntu.com/security/CVE-2026-89741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"media: v4l2-dev: fix error handling in __video_register_device()\" This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a. The intentions of that patch were good, but it doesn't work. The idea is that if device_register fails, you have to do a put_device to let the ref counter release resources. However, the V4L2 API says that if video_register_device() fails, then you have to call video_device_release(), which kfree()s the video_device struct. But the put_device() will already have freed the struct, so you end up in a double-free scenario. There is not really a good way of fixing this without breaking video_register_device() into two parts, one that initializes everything, and one that does the actual device_register, and then converting all V4L2 drivers to this new model. That is a massive job, and it is very unlikely that device_register will fail. So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89742", "url": "https://ubuntu.com/security/CVE-2026-89742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: mport_cdev: fix use-after-free in dma_req_free() dma_req_free() acquires buf_mutex through req->map, drops the mapping reference with kref_put(), and then dereferences req->map again to unlock the mutex. If kref_put() drops the last reference, mport_release_mapping() frees the mapping, and the subsequent mutex_unlock() dereferences a freed object. This is a use-after-free. Fix this by caching map and md before kref_put(), clearing req->map while holding buf_mutex, and using the cached md for mutex unlocking. The bug is reachable from userspace via the RapidIO mport character device interface.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89749", "url": "https://ubuntu.com/security/CVE-2026-89749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix crash passing ERR_PTR to kthread_stop() event_test_stuff() calls kthread_run() and unconditionally passes the returned task_struct pointer to kthread_stop(). kthread_run() returns an error pointer such as ERR_PTR(-ENOMEM) when kthread creation fails, for example under memory pressure during the boot-time event self-test. kthread_stop() then dereferences the invalid pointer, crashing the kernel. Check the result of kthread_run() before passing it to kthread_stop(). Use WARN_ON() so that a failure to create the self-test thread does not go unnoticed, matching the ring-buffer self-test fix in commit 91542863abad (\"ring-buffer: Fix crash passing ERR_PTR to kthread_stop()\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89752", "url": "https://ubuntu.com/security/CVE-2026-89752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: memcg: stop reclaim when a limit update is superseded kernfs serializes file operations only per open file, so separate open files can update the same memory.high or memory.max file concurrently. Both handlers store the new limit before synchronous reclaim, but continue to use the writer's local target in the reclaim loop. If another writer raises or removes the limit, the first writer can continue reclaiming toward a stale target. For memory.max, this can leave the writer looping indefinitely once reclaim retries are exhausted. The OOM path sees sufficient margin under the current limit and returns true without killing, while the writer still compares usage against its stale target and records another OOM event. Check the current limit at the start of each reclaim iteration and stop if it no longer matches the writer's target. Reproducer: Populate a cgroup with anonymous memory and disable swapping. Lower memory.max from one open file, then restore it to \"max\" through another open file after the new limit becomes visible. Without the patch, the first writer remains blocked and repeatedly increments the OOM event counter. With the patch, it returns normally. This was not motivated by a reported production workload. We found it through automated randomized testing for our cgroup observability work and reduced it to the reproducer above.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89753", "url": "https://ubuntu.com/security/CVE-2026-89753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: \t0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 \ttask:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89765", "url": "https://ubuntu.com/security/CVE-2026-89765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers/itimer: Zero-init old itimerval before copy to userspace On native sparc64, struct __kernel_old_timeval contains a four-byte hole after tv_usec because tv_sec is 64-bit while __kernel_suseconds_t is 32-bit. put_itimerval() fills only the named fields in a stack-allocated __kernel_old_itimerval and copies the entire object to userspace, so getitimer() can expose the two padding holes. Zero-initialize the aggregate before assigning the fields so implicit padding is deterministic before it crosses the user/kernel boundary.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93219", "url": "https://ubuntu.com/security/CVE-2026-93219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/timer-sun4i: Advertise a real minimum delta sun4i_clkevt_next_event() compensates for the timer stop/start synchronization delay by programming evt - TIMER_SYNC_TICKS into the hardware interval register. The clockevent device currently advertises TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed to call set_next_event() with evt == TIMER_SYNC_TICKS. That programs a zero-tick interval. With oneshot/highres/nohz timer operation this can leave the next event stuck, which was observed as a boot hang on Allwinner D1 after the clockevents core started reusing forced minimum-delta events. Advertise one extra tick instead, so the smallest event accepted by the core still programs at least one hardware tick after the synchronization compensation.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-23191", "url": "https://ubuntu.com/security/CVE-2026-23191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix racy access at PCM trigger The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers. For addressing the UAF, this patch changes two things: - It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.", "cve_priority": "high", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-80824", "url": "https://ubuntu.com/security/CVE-2026-80824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbfs: fix use-after-free of usb_device in usbdev_release() usbdev_release() drops its reference to the struct usb_device before draining the list of completed async URBs, but that drain path reads back through the same object: free_async() calls dec_usb_memory_use_count() for any URB whose buffer came from the usbfs mmap() region, and its first statement is bus_to_hcd(ps->dev->bus). After a disconnect the usbfs reference can be the last one, in which case usb_put_dev() frees the device and the subsequent loop reads offset 80 of freed memory and uses the result as a struct usb_hcd *, which hcd_buffer_free_pages() then dereferences. This is reachable by an unprivileged process that has read/write access to a /dev/bus/usb node: mmap() the fd, submit one URB with a buffer inside the mapping, wait for the device to be unplugged, then munmap() and close(). It reproduces on every attempt rather than being a race, because a live MAP_SHARED vma holds a reference on the struct file, so usbdev_release() cannot run until the last vma is gone and the freeing branch of dec_usb_memory_use_count() is always taken. BUG: KASAN: slab-use-after-free in dec_usb_memory_use_count+0x3ae/0x410 Read of size 8 at addr ffff8880122ee050 by task poc/769 CPU: 1 UID: 1000 PID: 769 Comm: poc Tainted: G B 6.12.94 #3 Call Trace: dec_usb_memory_use_count+0x3ae/0x410 free_async+0x2aa/0x4f0 usbdev_release+0x375/0x460 __fput+0x3ea/0xb50 __x64_sys_close+0x86/0x100 Allocated by task 11: usb_alloc_dev+0x55/0xd90 hub_event+0x2524/0x43d0 Freed by task 769: kfree+0x121/0x360 device_release+0xd2/0x280 usb_put_dev+0x23/0x30 usbdev_release+0x2d8/0x460 Release the device reference after the drain loop instead. Nothing between the two points requires it to have been dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80826", "url": "https://ubuntu.com/security/CVE-2026-80826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: c67x00: fix use-after-free in c67x00_add_iso_urb() When TD creation fails for the last packet of an isochronous URB, c67x00_add_iso_urb() gives the URB back before updating the endpoint scheduling state. c67x00_giveback_urb() frees the URB private data, and the completion callback may release the final URB reference. The following accesses to urbp->ep_data, urb->interval, and urbp->cnt can therefore use freed memory. Update next_frame and cnt before giving back the failed final packet, making the giveback the last operation that uses the URB and its private data.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80827", "url": "https://ubuntu.com/security/CVE-2026-80827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: option: fix slab OOB read in interrupt URB callback The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. [ johan: use dev_err(); split signals declaration and initialisation ]", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80828", "url": "https://ubuntu.com/security/CVE-2026-80828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Complete cleanup after system-resume errors A failed system resume can leave the card unusable until reboot. usb_audio_resume() jumps to err_out when snd_usb_pcm_resume() or snd_usb_mixer_resume() fails. The error path skips the out: block, which restores D0 and decrements chip->num_suspended_intf. The card stays in SNDRV_CTL_POWER_D3hot, so later control access blocks in snd_power_ref_and_wait(). USB core logs an interface resume callback error. It does not retry that callback, so a later callback cannot complete the skipped cleanup. usb_audio_suspend() increments num_suspended_intf before returning success. A system-resume callback must consume the system-suspend count even if a component resume fails. Otherwise, the stranded count skews later suspend and resume cycles. Do not apply this cleanup to runtime-resume errors. Runtime PM can retry -EAGAIN or -EBUSY without another suspend callback. The count must continue to describe that suspended interface. Other runtime-resume errors latch runtime_error in the PM core and do not cause an immediate callback retry. Both parts of the system-resume error path are longstanding. Commit 88a8516a2128a (\"ALSA: usbaudio: implement USB autosuspend\") introduced err_out past the D0 restore. Commit 862b2509d157c (\"ALSA: usb-audio: Fix inconsistent card PM state after resume\") later moved num_suspended_intf-- into the out: block. The error path now skips both operations. No third-party code is needed to reach the error path. snd_usb_mixer_resume() ends in snd_usb_mixer_activate(), which returns the result of usb_submit_urb() for devices that have a mixer status URB. Its mixer->private_resume hook can also fail through scarlett2_init_notify(). snd_usb_pcm_resume() issues a SET_CUR request to a UAC3 power domain. It can return -EPIPE or -EIO when the device stalls the request. Route a component error through out: only when system_suspend is nonzero. Continue to return runtime-resume errors through err_out. Later component resume stages remain skipped. The original error still reaches USB core. A later transfer can fail if the device did not recover. I reproduced the system-resume failure on an Audient iD14 MkI with an out-of-tree diagnostic mixer resume hook. An injected -EIO on the unpatched core left control readers in uninterruptible sleep in snd_power_ref_and_wait() until a reboot. With this patch, the same failure restored control access. A second system suspend and resume also succeeded after I disabled fault injection.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80829", "url": "https://ubuntu.com/security/CVE-2026-80829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output() snd_usbmidi_novation_output() lays out a two-byte header at transfer_buffer[0..1] and passes &transfer_buffer[2] together with a length of ep->max_transfer - 2 to snd_rawmidi_transmit(): \tcount = snd_rawmidi_transmit(ep->ports[0].substream, \t\t\t\t &transfer_buffer[2], \t\t\t\t ep->max_transfer - 2); ep->max_transfer comes from the output endpoint's wMaxPacketSize via usb_maxpacket(). A malformed or malicious device can advertise a bulk OUT endpoint with a wMaxPacketSize of 1 - the USB core only clamps this value downwards - so ep->max_transfer becomes 1 and the count argument becomes -1. snd_rawmidi_transmit() passes the negative count on to __snd_rawmidi_transmit_peek(), where \"if (count1 > count) count1 = count\" leaves count1 negative; get_aligned_size() keeps it negative for a byte-stream substream, so the following memcpy(buffer, ..., count1) runs with a (size_t)-1 length and writes far past the transfer buffer, which was allocated with usb_alloc_coherent(ep->max_transfer). This is the same class of bug that was fixed for snd_usbmidi_akai_output() in commit 0970274613fb (\"ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()\"); the novation output routine was left unguarded. Bail out when the endpoint cannot hold the two-byte header plus at least one payload byte.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80830", "url": "https://ubuntu.com/security/CVE-2026-80830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: Add lock to usb_wakeup_notification() Add a spin lock to usb_wakeup notification to prevent a race condition with dereferencing freed memory. This could be hit by the xHCI driver as it calls this function from an IRQ and could race with the hub_disconnect() function, which properly grabs this lock to protect the state of the device.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80921", "url": "https://ubuntu.com/security/CVE-2026-80921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: zero stale crypto bits When shadowing crypto access bits from a format0 apcb (crycb 0 or 1), the bits 64..255 are unchanged from whatever is in the vsie page in the crycb and thus in the apcb. This gives a nested guest potential access to a device no longer available. Zero out the remaining bits.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80831", "url": "https://ubuntu.com/security/CVE-2026-80831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: mxs-dcp - fix source scatterlist length access mxs_dcp_aes_block_crypt() uses sg_dma_len() without mapping the source scatterlist with dma_map_sg() first. Therefore, sg_dma_len() is invalid and could return zero or a stale DMA length, causing encryption and decryption to process the wrong number of bytes when CONFIG_NEED_SG_DMA_LENGTH=y. Use the original scatterlist length instead.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80832", "url": "https://ubuntu.com/security/CVE-2026-80832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qce - fix CCM AAD buffer underallocation The AAD buffer allocated in qce_aead_ccm_prepare_buf_assoclen() can be smaller than the length later programmed into the DMA scatterlist. The allocation size is currently calculated as: ALIGN(assoclen, 16) + MAX_CCM_ADATA_HEADER_LEN while the DMA length is set to: ALIGN(assoclen + adata_header_len, 16) Since ALIGN() does not distribute over addition, the allocation can be smaller than the DMA length. For example, when assoclen = 32 and adata_header_len = 2: allocation = ALIGN(32, 16) + 6 = 38 DMA length = ALIGN(32 + 2, 16) = 48 As a result, the QCE hardware can read beyond the allocated buffer while computing the CBC-MAC over the associated data. The extra bytes are folded into the authentication tag, resulting in an incorrect tag and causing CCM self-test failures such as: alg: aead: ccm-aes-qce encryption test failed (wrong result) on test vector 8 Fix the allocation by adding the maximum possible AAD header length before alignment: ALIGN(assoclen + MAX_CCM_ADATA_HEADER_LEN, 16) This guarantees that the allocated buffer is large enough for the fully padded AAD data for all supported header sizes.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80840", "url": "https://ubuntu.com/security/CVE-2026-80840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: seg6: clear IPv4 control block on IPIP decapsulation End.DX4 and End.DT4 decapsulate an IPv4 packet through decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), which normally clears IPCB before IPv4 interprets skb->cb. The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts. The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40. Both tcp_v4_save_options() and __ip_options_echo() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls __ip_options_echo(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte option-data area. Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced: BUG: KASAN: slab-out-of-bounds in __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm. Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80842", "url": "https://ubuntu.com/security/CVE-2026-80842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: fix use-after-free of a master VLAN's multicast context br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so once it is cleared under the lock no reader can arm the context again. For a master VLAN the handshake never runs. __vlan_del() clears BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so br_multicast_toggle_one_vlan(masterv, false) returns early on !br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is never taken. br_vlan_put_master() then drains the context in br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a reader still inside rcu_read_lock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no br_vlan_is_brentry() test and flips the flag under br->multicast_lock, so it is not affected. The reader is the bridge transmit path. For a master VLAN br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after br_multicast_ctx_deinit() has already stopped them. BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 Allocated by task 610: br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 Only test br_vlan_is_brentry() when enabling, like the br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before br_multicast_ctx_deinit() drains the context.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80843", "url": "https://ubuntu.com/security/CVE-2026-80843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix xfrm_state_construct() auth-trunc leak attach_auth_trunc() can allocate x->aalg while leaving x->props.aalgo at zero when the selected auth algorithm has no sadb_alg_id. One real case is cmac(aes). xfrm_state_construct() then treats !x->props.aalgo as \"no auth algorithm attached yet\" and calls attach_auth(). That overwrites x->aalg and loses the first allocation. Any later failure or teardown only frees the replacement pointer. Check whether x->aalg is already attached instead of inferring that state from x->props.aalgo.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80844", "url": "https://ubuntu.com/security/CVE-2026-80844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah6: validate routing header segments_left AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6_rearrange_rthdr() assumes that segments_left is not larger than the number of addresses described by the routing header's hdrlen field. That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segments_left value. With segments_left equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access. Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80846", "url": "https://ubuntu.com/security/CVE-2026-80846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: drop ESP-in-TCP packets with no ingress device ESP-in-TCP receives records through the TCP strparser. handle_esp() restores skb->dev from the saved skb_iif before passing the packet into the XFRM input path. Queued TCP data can be processed after the original ingress device has been removed, for example during veth or net namespace teardown. In that case dev_get_by_index_rcu() returns NULL. The XFRM IPv4 and IPv6 input paths both expect skb->dev to be valid while building the route lookup, so queued ESP-in-TCP data can dereference a NULL device. Drop the packet if the saved ingress device can no longer be resolved. Such a packet can no longer be routed through the normal XFRM receive path, and this preserves the existing behaviour for packets whose ingress device still exists.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80848", "url": "https://ubuntu.com/security/CVE-2026-80848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: fix UAF during close ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80854", "url": "https://ubuntu.com/security/CVE-2026-80854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: keep port count until LUN teardown completes tcm_usbg_drop_nexus() permits session removal once tpg_port_count reaches zero. However, usbg_port_unlink() currently decrements that count from the fabric_pre_unlink() callback, before core_dev_del_lun() waits for active se_lun references to drain. If removal of the last LUN races a nexus removal, the latter can observe a zero port count and call target_remove_session(). This frees sess_cmd_map while an in-flight struct usbg_cmd, including its work item, can still be accessed. Overlapping the last-LUN unlink with nexus removal reproduces this lifetime violation as a DEBUG_OBJECTS \"free active\" warning for usbg_cmd_work, followed by a target-core BUG/Oops. The generic target-core unlink path has no callback after core_dev_del_lun() completes. Add an optional fabric_post_unlink() callback and use it for the f_tcm port count. The count now remains nonzero until core_dev_del_lun() has finished draining active LUN references, preventing nexus removal from freeing the session during command completion.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80855", "url": "https://ubuntu.com/security/CVE-2026-80855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on open O_TRUNC DAX failure fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open(\"file\", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80856", "url": "https://ubuntu.com/security/CVE-2026-80856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on setattr writeback failure fuse_do_setattr() takes filemap_invalidate_lock() for a DAX truncate (fault_blocked = true) and releases it at the out:/error: labels. But when a writeback flush is also needed, a write_inode_now() failure returns directly and leaks the lock, so any later fault or truncate on the file stalls on the stale rwsem. For example, truncate(2) on a setuid file reaches fuse_do_setattr() with both ATTR_SIZE and ATTR_MODE set: truncate(2) └─ do_truncate() ├─ dentry_needs_remove_privs() # S_ISUID └─ notify_change() # KILL_SUID -> ATTR_MODE └─ fuse_setattr() # no killpriv: │ # ia_valid |= ATTR_MODE └─ fuse_do_setattr() ├─ filemap_invalidate_lock() # IS_DAX && is_truncate └─ write_inode_now() # is_wb && ATTR_MODE └─ if (err) # e.g. daemon -> -EIO return err # <- lock leaked Fix this by adding an unlock label that releases the lock before returning the error, and use it for the fuse_dax_break_layouts() failure path as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80923", "url": "https://ubuntu.com/security/CVE-2026-80923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: dbgtty: Fix unregister on tty_register_driver() failure If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80768", "url": "https://ubuntu.com/security/CVE-2026-80768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: ft260: fix stack-use-after-return write in I2C read race ft260_i2c_read() points dev->read_buf at a caller-supplied buffer (often an on-stack variable), arms a completion and waits up to five seconds for the device to return the data. The HID input callback ft260_raw_event() runs in the input/IRQ path, independent of the dev->lock mutex held by the read path, and copies the device-supplied payload into dev->read_buf after a plain NULL check. These two paths share read_buf, read_idx and read_len with no serialization. If the device delays its response until the read times out, ft260_i2c_read() resets the controller, clears read_buf and returns, unwinding the stack frame the buffer lived in. A response that arrives at that moment lets ft260_raw_event() pass the NULL check and then memcpy() the device-controlled payload into the now-freed stack location, a bounded but attacker-influenced stack-use-after-return write triggerable by malicious or malfunctioning hardware. Add a dedicated spinlock that serializes every access to read_buf, read_idx and read_len. ft260_raw_event() now holds it across the NULL check, the memcpy and the index update, while the read path takes it when arming and when clearing the buffer, so the teardown can no longer slip between the check and the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80766", "url": "https://ubuntu.com/security/CVE-2026-80766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: fix use-after-free of inrange_timer on remove uclogic_remove() cancels the pen in-range timer and then stops the device: \ttimer_delete_sync(&drvdata->inrange_timer); \thid_hw_stop(hdev); timer_delete_sync() only guarantees the timer is idle at that instant. uclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop() stops the transport several lines later, and every report with pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer: \tmod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); A report landing between the timer_delete_sync() call and the transport teardown in hid_hw_stop() re-arms inrange_timer after it was cancelled. uclogic_remove() then returns and the devm drvdata is freed, while hid_hw_stop() has already freed the input device drvdata->pen_input points at, so when the timer fires ~100 ms later uclogic_inrange_timeout() dereferences freed memory -- a use-after-free in timer-softirq context. Swapping the two calls is not a fix: stopping the device first frees drvdata->pen_input via hidinput_disconnect() while the timer may still be pending, so a timer already armed before removal fires on the freed input device in the window before timer_delete_sync() runs. Use timer_shutdown_sync() before hid_hw_stop() instead. It cancels the timer, waits for a running callback while pen_input is still valid, and prevents any further re-arming -- a later mod_timer() from an in-flight report is silently ignored -- so the timer is provably dead before hid_hw_stop() frees the inputs. This is the ordering the timer core documents for this \"timer re-armed from another path\" teardown case.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80789", "url": "https://ubuntu.com/security/CVE-2026-80789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: bound SGL data length before allocating command buffers nvmet_tcp_map_data() reads the host-controlled 32-bit sgl->length and, for the in-capsule offset descriptor (type 0x01), checks it against port->inline_data_size before use. Any other SGL descriptor type -- including the non-inline transport SGL data-block descriptor (type (NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, the type a real host uses for out-of-capsule writes) skips that check entirely and falls straight through to: \tcmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt); with len taken directly from the wire, unbounded up to 4 GiB. nvmet_req_init() only parses the command and never inspects sgl->length, and nvmet_check_transfer_len() -- the only other place transfer_len is validated -- runs later, from req->execute(), after the allocation has already happened. For a write command the target responds with an R2T and parks the command waiting for the host to send the data; if the host (or an unauthenticated peer that simply never follows up) never does, the sgl_alloc() buffer stays resident for the life of the command. NVMe/TCP has no mandatory authentication in the default configuration, so any peer able to reach the target portal and complete a Fabrics connect can drive this with a single crafted command, repeatable across queues and connections for amplification. This is unbounded kernel memory allocation triggered by a remote, effectively unauthenticated peer. Validate len against the same NVMET_TCP_MAXH2CDATA ceiling this file already uses to bound per-PDU H2C data, for every SGL descriptor type, before doing any allocation. This closes the gap for the non-inline descriptor while leaving the existing, tighter inline_data_size check in place for the in-capsule case. Runtime-verified on a v6.19 KASAN stand: with this bound in place, a crafted write command carrying an oversized non-inline SGL length is rejected before sgl_alloc() runs, where the same request previously drove an unbounded ~256 MiB kernel allocation (up to 4 GiB) that stayed resident pending an R2T the host never satisfies.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80783", "url": "https://ubuntu.com/security/CVE-2026-80783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event() magicmouse_raw_event() handles DOUBLE_REPORT_ID (0xf7) packets, which pack two touch reports into one, by splitting the packet and calling itself on each half. The only guard against runaway recursion is a \"size < 1\" check, which stops zero-sized calls but does not bound the recursion depth. A malicious HID device that matches this driver can send a report starting with DOUBLE_REPORT_ID and filled with the sequence [0xf7, 0x00]. Each level consumes two bytes and recurses on the remainder, so an incoming report of up to HID_MAX_BUFFER_SIZE (16 KiB) drives roughly 8000 nested calls. That easily exhausts the 16 KiB kernel stack, leading to a stack overflow: a panic with CONFIG_VMAP_STACK, or memory corruption without it. A double report only ever wraps two normal reports; it is never legitimately nested. Refuse to re-enter the DOUBLE_REPORT_ID case from a recursive call so the recursion depth is bounded to two, while all valid packets keep being parsed exactly as before.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80796", "url": "https://ubuntu.com/security/CVE-2026-80796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: add data_len bound checks to activation parameter extractors nci_extract_activation_params_iso_dep() and nci_extract_activation_params_nfc_dep() read an inner length byte from the NCI RF_INTF_ACTIVATED_NTF payload and use it to memcpy() into fixed kernel buffers, but neither function receives the caller-validated activation_params_len. A crafted NCI notification with activation_params_len=1 and an inner length byte of up to 20 (NFC-A) or 50 (NFC-B) causes memcpy() to read that many bytes past the one valid byte in the activation params region -- a slab out-of-bounds read of kernel memory adjacent to the NCI skb. The sibling nci_extract_rf_params_*() family was given equivalent protection by commit 571dcbeb8e63 (\"net: nfc: nci: Fix parameter validation for packet data\"), but the two activation parameter extractors were not updated at that time. Add a data_len parameter to both functions, guard against an empty region before consuming the inner length byte, decrement the remaining count after consuming it, and clamp the copy length to what is actually available. Update both call sites to pass ntf.activation_params_len, which is already validated against the skb at ntf.c:801.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80807", "url": "https://ubuntu.com/security/CVE-2026-80807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid block index in GC ioctl Syzbot reported list corruption caused by a double list_add_tail() call on bh->b_assoc_buffers within nilfs_lookup_dirty_data_buffers(). Analysis revealed that the root cause was the insertion of a page/folio with a page index of ULONG_MAX into the page cache via the GC ioctl. filemap_get_folios_tag(), called by nilfs_lookup_dirty_data_buffers(), repeatedly detects a dirty folio with a page index of ULONG_MAX due to index wrap-around, leading to duplicate processing of dirty buffers. As a preparatory step, the GC ioctl loads the page/folio of the block to be moved during GC and inserts it into the page cache based on information in the nilfs_vdesc structure passed as an argument. Normally, this does not cause issues because the user-space GC library configures the nilfs_vdesc structure properly. However, since there is no range check on the parameters determining the page index, a request with artificially crafted parameters -- such as those generated by Syzbot -- can result in a page/folio being inserted with a page index of ULONG_MAX, triggering the above problem. This resolves the issue by checking the ranges of 'vd_offset' and 'vd_vblocknr' in the nilfs_vdesc structure that determine the page index, thereby preventing the invalid page/folio insertions.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80916", "url": "https://ubuntu.com/security/CVE-2026-80916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcov: fix data corruption and race conditions on PREEMPT_RT syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area. On PREEMPT_RT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state. Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites. Note that while the temporary storage is now on a per-thread basis, the per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that kcov_remote_start() and kcov_remote_stop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state. It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when __init function of built-in module runs. But this patch also fixes crashing the kernel when vmalloc_node() in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in (1) doing vmalloc() in kcov_remote_start() despite !in_task() context (2) out-of-array-bounds access if (1) succeeded but kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE (3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes problems.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-43437", "url": "https://ubuntu.com/security/CVE-2026-43437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain() In the drain loop, the local variable 'runtime' is reassigned to a linked stream's runtime (runtime = s->runtime at line 2157). After releasing the stream lock at line 2169, the code accesses runtime->no_period_wakeup, runtime->rate, and runtime->buffer_size (lines 2170-2178) — all referencing the linked stream's runtime without any lock or refcount protecting its lifetime. A concurrent close() on the linked stream's fd triggers snd_pcm_release_substream() → snd_pcm_drop() → pcm_release_private() → snd_pcm_unlink() → snd_pcm_detach_substream() → kfree(runtime). No synchronization prevents kfree(runtime) from completing while the drain path dereferences the stale pointer. Fix by caching the needed runtime fields (no_period_wakeup, rate, buffer_size) into local variables while still holding the stream lock, and using the cached values after the lock is released.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-53089", "url": "https://ubuntu.com/security/CVE-2026-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in offloaded map/prog info fill When querying info for an offloaded BPF map or program, bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns() obtain the network namespace with get_net(dev_net(offmap->netdev)). However, the associated netdev's netns may be racing with teardown during netns destruction. If the netns refcount has already reached 0, get_net() performs a refcount_t increment on 0, triggering: refcount_t: addition on 0; use-after-free. Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains valid, they cannot prevent the netns refcount from reaching zero. Fix this by using maybe_get_net() instead of get_net(). maybe_get_net() uses refcount_inc_not_zero() and returns NULL if the refcount is already zero, which causes ns_get_path_cb() to fail and the caller to return -ENOENT -- the correct behavior when the netns is being destroyed.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2025-40102", "url": "https://ubuntu.com/security/CVE-2025-40102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000) Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-39925", "url": "https://ubuntu.com/security/CVE-2025-39925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: j1939: implement NETDEV_UNREGISTER notification handler syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 (\"can: j1939: move j1939_priv_put() into sk_destruct callback\") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on \"struct j1939_priv\" held by j1939_sk_bind() call prevents \"struct net_device\" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. [mkl: remove space in front of label]", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2024-58095", "url": "https://ubuntu.com/security/CVE-2024-58095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before txBeginAnon() call Added a read-only check before calling `txBeginAnon` in `extAlloc` and `extRecord`. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes. Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-58094", "url": "https://ubuntu.com/security/CVE-2024-58094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before truncation in jfs_truncate_nolock() Added a check for \"read-only\" mode in the `jfs_truncate_nolock` function to avoid errors related to writing to a read-only filesystem. Call stack: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) If the `isReadOnly(ip)` condition is triggered in `jfs_truncate_nolock`, the function execution will stop, and no further data modification will occur. Instead, the `xtTruncate` function will be called with the \"COMMIT_WMAP\" flag, preventing modifications in \"read-only\" mode.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-46754", "url": "https://ubuntu.com/security/CVE-2024-46754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Remove tst_run from lwt_seg6local_prog_ops. The syzbot reported that the lwt_seg6 related BPF ops can be invoked via bpf_test_run() without without entering input_action_end_bpf() first. Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a (\"ipv6: sr: Add seg6local action End.BPF\"). The reason is that the per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self test case but each BPF function expects it. Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.", "cve_priority": "low", "cve_public_date": "2024-09-18 08:15:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-80806", "url": "https://ubuntu.com/security/CVE-2026-80806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't enable DAX on new encrypted files Currently, when a new encrypted regular file is created, the call to ext4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made before EXT4_INODE_ENCRYPT is set. As a result, it can set S_DAX if the filesystem is mounted with \"-o dax=always\". EXT4_INODE_ENCRYPT then actually gets set a bit later in __ext4_new_inode(), when it calls fscrypt_set_context() which calls ext4_set_context(). ext4_set_context() sets EXT4_INODE_ENCRYPT and calls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too. This was intended to clear S_DAX as well. However, this was broken by commit 043546e46dc7 (\"fs/ext4: Only change S_DAX on inode load\"). This causes data written to the file to bypass encryption, also causing xfstests failures such as generic/548 (when \"-o dax=always\" is used). Fix this by simplifying the flow by making __ext4_new_inode() set EXT4_INODE_ENCRYPT earlier. This makes it take effect in ext4_set_inode_flags(inode, init=true), making S_DAX never be set. Similarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first place on new encrypted inodes. Then it doesn't need to be cleared. As a result of these simplifications, ext4_set_context() no longer needs to change inode flags or state when 'handle != NULL'. Remove that too.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80863", "url": "https://ubuntu.com/security/CVE-2026-80863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix OOB in free_rd_atomic_resources() free_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic. Updating max_dest_rd_atomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] BUG: KASAN: slab-out-of-bounds in rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 Write of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063 CPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xf7/0x600 mm/kasan/report.c:482 kasan_report+0xe4/0x120 mm/kasan/report.c:595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fefc75a70cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fefc8495018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd RDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007 RBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0 Allocated by task 11063: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5296 [inline] __kmalloc_noprof+0x32a/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:155 [inline] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_ma ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80590", "url": "https://ubuntu.com/security/CVE-2026-80590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 (\"net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list\") and by commit 9e4b7a99a03a (\"net: gso: fix panic on frag_list with mixed head alloc types\") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 (\"tun: Allow GSO using virtio_net_hdr\"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80765", "url": "https://ubuntu.com/security/CVE-2026-80765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: validate initial device info bounds The Hyper-V synthetic HID host supplies SYNTH_HID_INITIAL_DEVICE_INFO messages that contain a HID descriptor followed by the report descriptor bytes. mousevsc_on_receive_device_info() trusts bLength and wDescriptorLength without checking that the received packet contains both byte ranges. A malformed host or backend message can therefore make the guest read past the received VMBus packet while copying the report descriptor. Pass the received initial-device-info size into the parser and reject descriptor lengths that exceed the packet. Impact: A malicious Hyper-V host or backend can crash a guest by sending a short initial device-info message with an oversized HID report descriptor length.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80767", "url": "https://ubuntu.com/security/CVE-2026-80767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix use-after-free in enable_sensor enable_sensor_store() can call set_power_report_state(), which dereferences sensor_inst->power_state and sensor_inst->report_state. These pointers refer to entries in sensor_inst->fields. Create the field attributes before exposing the enable_sensor sysfs attribute, so enable_sensor cannot be accessed before the state it depends on has been initialized. On remove, delete enable_sensor before freeing the field attributes, so a concurrent sysfs write cannot dereference freed memory through power_state or report_state.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80918", "url": "https://ubuntu.com/security/CVE-2026-80918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix number/pointer type confusion on long items When fetch_item() is called by hid_scan_report() on an item with HID_ITEM_TAG_LONG, it stores a pointer to the item data in item->data.longdata instead of storing a value directly in item->data.{u8/u16/u32}. When item_udata() or item_sdata() encounters such an item, it incorrectly assumes that the item is in short format, and therefore returns the lower part of a kernel pointer reinterpreted as a number. When a HID device is connected whose descriptor contains a HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this causes the lower half of a kernel pointer to be printed into dmesg as a number, like this: hid (null): invalid report_size 107953555 To fix it, let item_udata() and item_sdata() verify that the item is in short format. Note that this bug only affects hid_scan_report(), while the main parsing pass hid_parse_collections() will always bail out when encountering a long item. Sidenote: There are currently no users of data.longdata; maybe we should just remove any parsing of long-format descriptors as a follow-up.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80889", "url": "https://ubuntu.com/security/CVE-2026-80889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix timer drain order, wakeup handling and tx_gen ordering This patch is a follow-up to commit cf070fe33bfb (\"can: isotp: serialize TX state transitions under so->rx_lock\") which addresses following sashiko-bot findings: - isotp_sendmsg(): drain so->txfrtimer first so a stale callback can't re-arm echotimer after the claim - isotp_release(): wake so->wait after forcing ISOTP_SHUTDOWN so a sleeping sendmsg() claim isn't stranded - isotp_sendmsg(): have both wait_event_interruptible() calls in isotp_sendmsg() also wake on ISOTP_SHUTDOWN and do not return claim to IDLE to avoid corrupting a concurrent isotp_release() process. - isotp_sendmsg(): handle potential claim of a new transfer when the wait_event_interruptible() call returns in CAN_ISOTP_WAIT_TX_DONE mode. Don't touch timers and states of the new transfer if a new thread incremented so->tx_gen before getting the lock at err_event_drop. - isotp_sendmsg(): handle a stuck can_send() and omit timer and state changes if a new transfer was claimed. wait_tx_done() returns the error recorded in so->tx_result[], tagged with the caller's own generation. - isotp_tx_timeout(): on a claimed timeout, record the ECOMM error for the timed-out transfer's own generation in so->tx_result[]; sk->sk_err is raised unconditionally, same as every other error path here. - isotp_tx_gen_done()/isotp_tx_timeout(): always read tx.state (acquire) before tx_gen - the reverse order let a weakly ordered CPU pair a fresh tx.state with a stale tx_gen/tx_result slot. - isotp_sendmsg(): wait_tx_done: drain sk_err via sock_error() once we have read the result from so->tx_result[], so an already-reported error doesn't stay latched for a later poll()/SO_ERROR. Also align the remaining lock-free so->tx.state/rx.state/cfecho accesses and use skb->hash as unique loopback echo frame indicator.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-46170", "url": "https://ubuntu.com/security/CVE-2026-46170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: free sk if last When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on \"itself\".", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46158", "url": "https://ubuntu.com/security/CVE-2026-46158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: always decrease sk refcount When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as \"unlikely\".", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-80555", "url": "https://ubuntu.com/security/CVE-2026-80555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Free all memory if cp_init() fails The routine cp_free() is called to unpin/free any memory once an I/O is completed successfully, or if cp_prefetch() fails. But if cp_init() fails, and cp->initialized is not enabled, the same routine cannot be used to free all the memory. An attempt to address this exists in ccwchain_handle_ccw(), where a single call to ccwchain_free() is made for the currently-processed CCW segment. But this will leak other segments (created as a result of a Transfer in Channel) that had been allocated as part of the same channel program. Address this by performing the cleanup outside of the recursive ccwchain_handle_ccw()/ccwchain_loop_tic() logic.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2025-68794", "url": "https://ubuntu.com/security/CVE-2025-68794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: adjust read range correctly for non-block-aligned positions iomap_adjust_read_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio. Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-80781", "url": "https://ubuntu.com/security/CVE-2026-80781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix OOB read of field->usage in hid_set_field() hid_set_field() hands field->usage + offset to hid_dump_input() before the guard that bounds offset: \thid_dump_input(field->report->device, field->usage + offset, value); \tif (offset >= field->report_count) { \t\thid_err(...); \t\treturn -1; \t} Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is allocated inline with the hid_field in hid_register_field() and holds field->maxusage entries, so an offset past it reads off the end of the kvzalloc()ed allocation and into a neighbouring object. Had the guard run first, offset < report_count <= maxusage would already have confined the pointer to the array. A caller supplies such an offset today. picolcd_fb_send_tile() validates only report->maxfield before issuing hid_set_field(report->field[0], 11 + i, ...) for i = 0..31, so its offsets are fixed at 11..42 and are never checked against the bound field. When the device registers that field with fewer usages, the framebuffer deferred-io work drives the read on every tile. KASAN reports a 4-byte slab-out-of-bounds read in hid_dump_input() below hid_set_field(), and the same boot logs \"offset (1) exceeds report_count (1)\" from the guard that runs only afterwards. Move the hid_dump_input() call below the guard. Because field->maxusage >= field->report_count, the guard then establishes that field->usage + offset lies inside the array before it is dereferenced, for every caller and without changing behaviour on the valid path. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80782", "url": "https://ubuntu.com/security/CVE-2026-80782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: do not keep a stale msc->input if no input is claimed magicmouse_input_mapping() caches the first hid_input's input_dev in msc->input while the report descriptor is parsed, and the rest of the driver treats a non-NULL msc->input as proof that an input device was registered. That does not hold on the hid-input error path. If hidinput_connect() fails -- for instance because input_register_device() returns an error -- it unwinds through hidinput_disconnect(), which frees every input_dev it created, including the one cached in msc->input. The failure does not abort the probe. hid_connect() only skips the claim: \tif ((connect_mask & HID_CONNECT_HIDINPUT) && !hidinput_connect(hdev, \t\t\t\tconnect_mask & HID_CONNECT_HIDINPUT_FORCE)) \t\thdev->claimed |= HID_CLAIMED_INPUT; and the \"device has no listeners\" bailout below it does not fire for this driver, which sets ->raw_event; on the USB Magic Mouse 2 / Magic Trackpad 2 paths hidraw and hiddev are claimed as well. hid_hw_start() therefore returns 0 and magicmouse_probe() continues with msc->input pointing at freed memory. Being non-NULL, it passes the \"input not registered\" check in probe and the NULL checks in ->raw_event and ->event, so the next input report dereferences freed memory. Clear msc->input when the HID core did not claim an input device, so the existing NULL checks cover this case as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-80583", "url": "https://ubuntu.com/security/CVE-2026-80583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses The \"DEC0 MODE\" to \"DEC7 MODE\" controls are enumerated, but tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 (\"ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type\") and commit 0ea5eff7c606 (\"ASoC: codecs: va-macro: fix accessing array out of bounds for enum type\"), but tx-macro was missed. On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value sanity check catches the 4 bytes written past the enumerated item and every read of these controls fails with -EINVAL: snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80587", "url": "https://ubuntu.com/security/CVE-2026-80587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid combining some incoming suboptions Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80547", "url": "https://ubuntu.com/security/CVE-2026-80547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Implement a crw lock Unlike the channel_program struct, which covers synchronous I/O submissions and asynchronous interrupts, the CRW region relies exclusively on asynchronous events coming from hardware. Implement a lock to manage the list of those payloads, to ensure they are read cohesively.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80548", "url": "https://ubuntu.com/security/CVE-2026-80548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Selectively expand io_mutex The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80552", "url": "https://ubuntu.com/security/CVE-2026-80552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure index for read/write regions are within range The introduction of the capability chain rightly clamped the region indexes to the range of the capabilities itself, but neglected to do so for the existing read/write regions which should also be enforced.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80788", "url": "https://ubuntu.com/security/CVE-2026-80788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations When fuzzing the nvme target code, I tripped a kernel warning in nvmet_tcp_map_data() because the length passed into the allocator is controlled by the remote initiator. A remote initiator that sends a command with an SGL claiming a huge number, can create a scatterlist and iovec allocation of over 1 million entries, which causes the backing kmalloc call to exceed MAX_PAGE_ORDER and then the page allocator will trip on a WARN_ON_ONCE_GFP() message: WARNING: mm/page_alloc.c:5280 __alloc_frozen_pages_noprof Workqueue: nvmet_tcp_wq nvmet_tcp_io_work ... sgl_alloc_order nvmet_tcp_map_data nvmet_tcp_try_recv_pdu As it's never good to trip a kernel warning remotely due to many systems having panic-on-warn enabled, let's silence it by just add GFP_NOWARN to the allocation flags.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80790", "url": "https://ubuntu.com/security/CVE-2026-80790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: fix invalid free in LS IOD error path nvmet_fc_alloc_ls_iodlist() advances iod while initializing the LS IOD array. If an rqstbuf allocation or response buffer DMA mapping fails, the unwind loop decrements iod past the start of the array. The final kfree(iod) therefore frees an address before the allocated object. This can be reproduced with nvme-fcloop and failslab by setting fail-nth to 6 before creating a target port. KASAN reports: BUG: KASAN: invalid-free in nvmet_fc_register_targetport Free of addr ffff88816cf8ff48 by task nvmet_fail_nth/9552 Free the original allocation base stored in tgtport->iod instead. With this fix applied, the same sysfs write with fail-nth=6 returns -ENOMEM without any KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80792", "url": "https://ubuntu.com/security/CVE-2026-80792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix use-after-free in ip6_finish_output2() ip6_finish_output2() caches a pointer to the IPv6 destination address (daddr) before invoking lwtunnel_xmit(). The LWT-BPF transmit path or other encapsulation operations within lwtunnel_xmit() can reallocate the skb head, freeing the memory that daddr points to. When lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, the function continues to use the stale daddr pointer to compute the nexthop and to look up or create the neighbour entry. This results in a use-after-free read, which can leak sensitive kernel data, pollute the neighbour table with arbitrary values, misdirect traffic, or crash the system. Fix this by re-fetching the IPv6 header and the destination address pointer after lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, ensuring that the subsequent nexthop computation and neighbour lookup operate on valid memory.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80793", "url": "https://ubuntu.com/security/CVE-2026-80793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: reject undersized MTUs in ip_do_fragment() ip_do_fragment() subtracts the IPv4 header length from the effective MTU and passes the resulting payload MTU to ip_frag_next(). If the effective MTU is smaller than hlen + 8, ip_frag_next() rounds the fragment payload length down to zero. The fragmentation state then never makes forward progress: state->left, state->ptr and state->offset stay unchanged while ip_do_fragment() keeps allocating and transmitting header-only fragments until the softlockup detector fires. This is reproducible with a route installed using \"mtu lock 20\", but it is also reproducible without route MTU lock, for example by forwarding a packet to a device whose MTU is 20. Fix it in ip_do_fragment() by rejecting mtu < hlen + 8 with -EMSGSIZE, matching the existing IPv6 fragmentation check.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80557", "url": "https://ubuntu.com/security/CVE-2026-80557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix OOB read in decode_watchers() via missing bounds check ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80794", "url": "https://ubuntu.com/security/CVE-2026-80794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix uninit-value in the RF discover/activated NTF handlers nci_rf_discover_ntf_packet() and nci_rf_intf_activated_ntf_packet() each parse a notification into an on-stack struct (nci_rf_discover_ntf / nci_rf_intf_activated_ntf) that is not initialised. The RF technology-specific parameters are only extracted when rf_tech_specific_params_len is non-zero, so a notification that reports a zero length leaves the rf_tech_specific_params union uninitialised - and both handlers then pass it to nci_add_new_protocol(), which reads it: - discover: nci_add_new_target() -> nci_add_new_protocol(); - activated: nci_target_auto_activated() -> nci_add_new_protocol(). nci_add_new_protocol() uses nfca_poll->nfcid1_len as both a branch condition and a memcpy() length and copies nfcid1/sens_res/sel_res into ndev->targets, which is later exposed to user space via NFC_CMD_GET_TARGET. BUG: KMSAN: uninit-value in nci_add_new_protocol+0x624/0x6c0 nci_add_new_protocol+0x624/0x6c0 nci_ntf_packet+0x25b2/0x3c30 nci_rx_work+0x318/0x5d0 process_scheduled_works+0x84b/0x17a0 worker_thread+0xc10/0x11b0 kthread+0x376/0x500 Local variable ntf.i created at: nci_ntf_packet+0xbc2/0x3c30 Zero-initialise both on-stack notifications so the union reads back as zero when no technology-specific parameters are present.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80795", "url": "https://ubuntu.com/security/CVE-2026-80795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix out-of-bounds write in nci_target_auto_activated() nci_target_auto_activated() appends a target to the fixed-size array ndev->targets[NCI_MAX_DISCOVERED_TARGETS] and increments ndev->n_targets without first checking the array is full; unlike its sibling nci_add_new_target(), which bails out when n_targets already equals NCI_MAX_DISCOVERED_TARGETS. ndev->n_targets is only cleared by nci_clear_target_list(), so an NFCC that repeatedly re-runs discovery (RF_DISCOVER_RSP, which re-enters NCI_DISCOVERY without clearing the target list) and reports an auto-activated target (RF_INTF_ACTIVATED_NTF) drives n_targets past the limit. The append then writes a struct nfc_target past the end of the array (a slab out-of-bounds write), and nfc_targets_found() goes on to walk the array with the inflated count: BUG: KASAN: slab-out-of-bounds in nci_add_new_protocol+0x94/0x2ac [nci] Write of size 2 at addr ffff0000c7299a18 by task kworker/u8:0/12 Workqueue: nfc0_nci_rx_wq nci_rx_work [nci] Call trace: nci_add_new_protocol+0x94/0x2ac [nci] nci_ntf_packet+0xddc/0x11a0 [nci] nci_rx_work+0x15c/0x1e0 [nci] process_one_work+0x2dc/0x500 worker_thread+0x240/0x460 kthread+0x1c0/0x1d0 ret_from_fork+0x10/0x20 The buggy address belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1024 bytes to the right of allocated 1560-byte region [ffff0000c7299000, ffff0000c7299618) Guard nci_target_auto_activated() with the same check used by nci_add_new_target().", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80823", "url": "https://ubuntu.com/security/CVE-2026-80823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: validate ATR_REQ length against the received frame st21nfca_tm_recv_atr_req() checks that the received ATR_REQ frame is at least ST21NFCA_ATR_REQ_MIN_SIZE and that the self-declared atr_req->length is at least sizeof(struct st21nfca_atr_req), but never checks that atr_req->length does not exceed the actual received length (skb->len). st21nfca_tm_send_atr_res() then trusts the declared length: \tgb_len = atr_req->length - sizeof(struct st21nfca_atr_req); \t... \tmemcpy(atr_res->gbi, atr_req->gbi, gb_len); so an RF peer that sends a short frame but sets atr_req->length larger than the frame makes gb_len exceed the general bytes actually present, and the memcpy reads out of bounds past the received skb. Those bytes are placed in the ATR_RES and sent back to the peer (kernel-memory disclosure to a proximity attacker); a larger declared length is an out-of-bounds read (DoS). Reject frames whose declared length exceeds the received length. The adjacent nfc_tm_activated() path in the same function already derives its general-bytes length from skb->len rather than the declared field. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80797", "url": "https://ubuntu.com/security/CVE-2026-80797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: purge fragmented skbs during cleanup pn53x_common_clean() purges resp_q before freeing the common PN533 state, but it leaves fragment_skb untouched. The fragmentation helpers queue transmit fragments there while sending large initiator or target-mode frames, and those skbs remain owned by the driver until they are sent or discarded. If the device is removed while fragments are still queued, the common cleanup path frees the PN533 state without releasing the queued fragment skbs, leaking them. Purge fragment_skb during cleanup alongside resp_q.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80798", "url": "https://ubuntu.com/security/CVE-2026-80798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: reject PDUs shorter than the LLCP header Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes before parsing it. nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/ nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a CONNECT or CC PDU then computes \ttlv_array_len = skb->len - LLCP_HEADER_SIZE; as a size_t and hands it to the TLV walk. When the frame is shorter than the header the subtraction wraps to a huge value and the walk runs far past the buffer, an out-of-bounds read. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Guard the common receive choke point __nfc_llcp_recv(), shared by both the target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so a short skb is dropped before the rx_work worker parses it. Use pskb_may_pull() rather than a skb->len test so the two header bytes are guaranteed to sit in the skb linear area even for a non-linear skb, matching how the sibling NCI and HCI receive paths validate their headers. Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on linux-next. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80799", "url": "https://ubuntu.com/security/CVE-2026-80799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain three related bugs in their TLV parsing loops: 1. 'offset' is declared u8 but tlv_array_len is u16. When TLV data advances offset past 255 it silently wraps to zero, causing infinite loops or double-processing of buffer data. 2. Before reading tlv[0] (type) and tlv[1] (length) there is no check that offset+2 <= tlv_array_len. A truncated TLV causes an OOB read of one byte past the buffer end. 3. After reading the length field, the value bytes are accessed without checking offset+2+length <= tlv_array_len. A crafted length=0xFF on a short buffer causes up to 255 bytes of OOB read past the buffer end. Both functions are reachable without authentication via nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes directly into nfc_llcp_parse_gb_tlv() with no additional validation. Fix all three issues by widening offset from u8 to u16 and adding bounds checks for both the TLV header and value field before each access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80800", "url": "https://ubuntu.com/security/CVE-2026-80800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound the connect_sn TLV walk to the skb Commit 27256cdb290e (\"nfc: llcp: bound SNL TLV parsing to the skb and add length checks\") fixed the unbounded TLV walk in nfc_llcp_recv_snl(), and commit d8bd2dedbde5 (\"nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers\") subsequently bounded nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv(). One sibling parser sharing the same pattern remains unbounded: nfc_llcp_connect_sn(). nfc_llcp_connect_sn() walks a TLV list, reading a two-byte header (type, length) followed by length bytes of value, without checking that the two header bytes or the declared length stay within the buffer. It returns a pointer to a service name of up to 255 bytes that may point past the end of the skb; it is subsequently consumed by memcmp() in nfc_llcp_sock_from_sn(). In addition tlv_array_len was computed as \"skb->len - LLCP_HEADER_SIZE\" in size_t, so a CONNECT/CC frame shorter than the LLCP header underflows to a huge length and the walk runs far past the buffer. nfc_llcp_connect_sn() is reachable from nfc_llcp_recv_connect() and nfc_llcp_recv_cc(), i.e. from received CONNECT and CC PDUs. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP, and the nfc_llcp_rx_skb() dispatcher applies no minimum-length guard. Walk the TLV list by pointer, bounded by skb_tail_pointer(skb), and validate each declared length before use, matching the approach already used for nfc_llcp_recv_snl(). Starting the walk at &skb->data[LLCP_HEADER_SIZE] against the tail pointer also removes the size_t underflow for short frames. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80801", "url": "https://ubuntu.com/security/CVE-2026-80801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: microread: validate target discovery payload lengths microread_target_discovered() parses target discovery payloads from skb->data according to the HCI gate. The fixed field offsets and UID copies were checked only against the destination nfc_target buffers, not against the actual skb length. Validate that each gate-specific payload contains the fixed fields and UID bytes before reading or copying them.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80802", "url": "https://ubuntu.com/security/CVE-2026-80802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: bound the device-reported read length and fix an skb leak fdp_nci_i2c_read() takes the next packet length from two device-supplied bytes and never validates it. The value is a u16 used as the i2c_master_recv() count into a 261-byte on-stack buffer: a malicious, counterfeit or malfunctioning controller (or an i2c bus interposer) can drive it far past the buffer for a stack out-of-bounds write that clobbers the canary and return address, or below the minimum frame size (directly, or by truncating the computed sum) so the header/LRC strip and the next length read run past a short receive. Reject a length outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD], as a corrupted packet already is, and force resynchronization. The same loop allocates one data skb per iteration and assumes a length packet followed by a data packet; a device that sends two data packets in one call leaks the first skb when the second allocation overwrites it. Free a previously allocated skb before allocating the next.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80803", "url": "https://ubuntu.com/security/CVE-2026-80803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: digital: clamp SENSF_RES length to the destination buffer digital_in_recv_sensf_res() memcpy()s resp->len bytes from a remote NFC-F device response into the NFC_SENSF_RES_MAXSIZE-byte target.sensf_res field without an upper-bound check. A nearby malicious NFC-F device can send an oversized SENSF_RES response to overflow the stack-local struct nfc_target. Clamp resp->len to NFC_SENSF_RES_MAXSIZE before the copy. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80536", "url": "https://ubuntu.com/security/CVE-2026-80536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: bounds-check buffer log item's dirty bitmap xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: \tmemcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), \t\titem->ri_buf[i].iov_base, \t\tnbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80553", "url": "https://ubuntu.com/security/CVE-2026-80553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Cancel existing workqueues The initialization of the io_work and crw_work workqueues begs the question of whether they should be un-initialized. Add the corresponding cleanup tags in _release_dev to ensure work isn't dispatched after the private struct is free'd.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74662", "url": "https://ubuntu.com/security/CVE-2026-74662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: publish queues before arming timer inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74666", "url": "https://ubuntu.com/security/CVE-2026-74666", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: synchronize pressure clearing with ring reconfiguration packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74663", "url": "https://ubuntu.com/security/CVE-2026-74663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: reject overly deep qdisc hierarchies Deep qdisc hierarchies can lead to excessive recursion in qdisc tree walkers and exhaust the kernel stack. The existing loop check does not cover the create-and-graft path, so a hierarchy can still be extended by creating a new child qdisc below an already deep parent. Store the hierarchy depth in struct Qdisc and update it when qdiscs are grafted. Reject new child qdiscs once the parent is already at the maximum allowed depth.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74668", "url": "https://ubuntu.com/security/CVE-2026-74668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in TX_RING send path tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative. Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb(). The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74582", "url": "https://ubuntu.com/security/CVE-2026-74582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in non-ring send paths packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-80737", "url": "https://ubuntu.com/security/CVE-2026-80737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: synchronize DMA teardown dmaengine_terminate_all() does not wait for a running callback, so the TX callback can still touch the TX buffer after it is freed. The RX poll timer reads the RX buffers without the port lock. Switch to dmaengine_terminate_sync() and delete the RX timer before freeing the buffers.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74626", "url": "https://ubuntu.com/security/CVE-2026-74626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_netdev: Preserve RX queue depth on allocation failure ntb_netdev_rx_handler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception. A retry path could refill the queue later, but ntb_netdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74637", "url": "https://ubuntu.com/security/CVE-2026-74637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix group leader use-after-free after sibling detach perf_group_detach() handles leader and sibling detach differently. When the group leader is detached, all siblings are promoted to singleton events and their group_leader pointer is reset to themselves. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. That is harmless when the sibling is being closed and freed immediately, as in the DETACH_DEAD path. It is not safe when the sibling is detached but kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the sibling is removed from the context, while its file descriptor can still keep it alive. A typical failing sequence is: - A group contains leader L and sibling S. - CPU hot-unplug detaches S with DETACH_GROUP, removing it from L->sibling_list but leaving S->group_leader == L. - L is later closed and freed. - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and dereferences the freed leader. This was reproduced by running the perf event fuzzer, CPU hotplug, and a stress workload concurrently: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT pc : perf_ioctl+0x34c/0xc68 x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908) Call trace: perf_ioctl+0x34c/0xc68 (P) __arm64_sys_ioctl+0xa0/0xf4 invoke_syscall+0x58/0xe4 el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x40/0xc0 el0t_64_sync_handler+0x68/0xdc el0t_64_sync+0x1c4/0x1c8 The fault happened in perf_ioctl(), where perf_event_for_each() follows the stale group_leader pointer and perf_event_for_each_child() then dereferences the freed leader's context. Fix the use-after-free by promoting the detached sibling to a singleton. Also fix __event_disable() cgroup accounting and event state change.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74647", "url": "https://ubuntu.com/security/CVE-2026-74647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Remove buffer from list prior to unmap operation fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74632", "url": "https://ubuntu.com/security/CVE-2026-74632", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix huge_zero_pfn race Patch series \"mm/huge_memory: fix huge_zero_pfn race\", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80562", "url": "https://ubuntu.com/security/CVE-2026-80562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: ml-ioh: use raw_spinlock_t for the register lock ioh_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irq_set_type callback additionally emits a dev_warn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same fix as commit a02b8950d619 (\"gpio: pch: use raw_spinlock_t for the register lock\"); this driver shares the same structure as gpio-pch.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80805", "url": "https://ubuntu.com/security/CVE-2026-80805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: validate attr entry pointer before field access xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen, valuelen) before checking if the entry pointer itself is within bounds. If nameidx is crafted to point near the end of the buffer, these field accesses can read out-of-bounds before the bounds check at name_end > buf_end is performed. Add explicit bounds checks for entry pointers before accessing their fields. Use offsetof() to check that the start of the flexible array member (nameval/name) is within bounds, which ensures all preceding fields are safe to access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80808", "url": "https://ubuntu.com/security/CVE-2026-80808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: stop retrying saturated xattr cache entries ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked. Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop. Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition. Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80809", "url": "https://ubuntu.com/security/CVE-2026-80809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix missing metadata reservation for large xattrs [BUG] lsetxattr() panics the kernel when setting a large xattr value on a fragmented filesystem where the file already has an external xattr block. [CAUSE] ocfs2_calc_xattr_set_need() never reserves metadata blocks for a new xattr value's extent tree when the file already has an external xattr block. The not_found path leaves meta_add at zero, so meta_ac is NULL when ocfs2_xattr_extend_allocation() runs. A new value root has room for a single extent record. On a fragmented filesystem, the allocator cannot satisfy the xattr value in one contiguous run, so each non-contiguous run requires its own extent record. When the value root's extent list is full and meta_ac is NULL, ocfs2_add_clusters_in_btree() returns RESTART_META, and ocfs2_xattr_extend_allocation() hits BUG_ON(why == RESTART_META). [FIX] The case where no xattr block exists yet already calls ocfs2_extend_meta_needed(&def_xv.xv.xr_list) to reserve value tree metadata. Add the same reservation to the case where an xattr block already exists, making the two cases consistent. Replace the BUG_ON with a -ENOSPC return so that if RESTART_META is returned despite the reservation, the error propagates to userspace instead of panicking the kernel.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80812", "url": "https://ubuntu.com/security/CVE-2026-80812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dummy: Check card index validity at probe snd_dummy_probe() blindly trusts that the given devptr->id value is within the proper card index range. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80814", "url": "https://ubuntu.com/security/CVE-2026-80814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rndis_host: add overflow check in rndis_rx_fixup() Add an overflow check to ensure that data_offset + data_len + 8 does not wrap, which would enable an OOB read of the USB data buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80819", "url": "https://ubuntu.com/security/CVE-2026-80819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept rfcomm_sock_recvmsg() completes a deferred setup by calling rfcomm_dlc_accept() without holding any RFCOMM lock: \tif (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { \t\trfcomm_dlc_accept(d); \t\treturn 0; \t} and rfcomm_dlc_accept() dereferences the session on its first line: \tstruct sock *sk = d->session->sock->sk; Every other path that touches d->session runs under rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). rfcomm_connect_ind() is even documented as \"called under rfcomm_lock()\". This call site is the only one that skips it. The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against teardown, since __rfcomm_dlc_close() returns early when it wins the test_and_clear. But rfcomm_recv_disc() forces the state first: \td->state = BT_CLOSED; \t__rfcomm_dlc_close(d, err); and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2. With the state already BT_CLOSED that switch does not match, the bit is never consulted, and __rfcomm_dlc_close() falls through to rfcomm_dlc_unlink(), which sets d->session = NULL. So a remote DISC on a deferred dlc clears the session while leaving RFCOMM_DEFER_SETUP set. The next recvmsg() then passes the test_and_clear and dereferences a NULL session. No timing window is needed: once the DISC has been processed, the dereference is unconditional. Give rfcomm_dlc_accept() the same shape as rfcomm_dlc_open() and rfcomm_dlc_close(): an exported wrapper that takes rfcomm_mutex and re-checks the session, around a __rfcomm_dlc_accept() that the two in-core callers, which already hold the mutex, keep using. Reproduced on a KASAN + PROVE_LOCKING kernel with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session, opens a dlc on a channel bound with BT_DEFER_SETUP, and sends DISC after the socket is accepted. recv() on the accepted socket then hits: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10 is the offset of sock in struct rfcomm_session. With this patch the same run completes with recv() returning 0 and no report, and lockdep stays quiet, confirming rfcomm_mutex is still taken before lock_sock on this path as it is on the thread side.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80917", "url": "https://ubuntu.com/security/CVE-2026-80917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems On 32-bit systems the config space is too large to ioremap in one go, so pci_ecam_create() maps each bus segment separately and relies on the ->add_bus callback (pci_ecam_add_bus) to populate the per-bus mapping in cfg->winp[]. pci_ecam_map_bus() then uses that mapping as the base for every config access. The generic ECAM ops (pci_generic_ecam_ops) already provide the ->add_bus and ->remove_bus callbacks, but the CAM (legacy) ops in pci-host-generic.c do not. As a result, on a 32-bit host using \"pci-host-cam-generic\" the per-bus mapping is never set up and the first config read dereferences a NULL base, crashing during bus enumeration: Unable to handle kernel NULL pointer dereference at virtual address 00000800 Oops [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 6.9.7+ #43 Hardware name: Digilent Nexys-Video-A7 RV32 (DT) epc : pci_generic_config_read+0x40/0xb0 ra : pci_generic_config_read+0x2c/0xb0 [] pci_generic_config_read+0x40/0xb0 [] pci_bus_read_config_dword+0x50/0xb0 [] pci_bus_generic_read_dev_vendor_id+0x3c/0x1ec [] pci_scan_single_device+0xa4/0x11c [] pci_scan_slot+0x9c/0x23c [] pci_scan_child_bus_extend+0x58/0x2f4 [] pci_scan_root_bus_bridge+0x64/0xe8 [] pci_host_probe+0x20/0xc8 [] pci_host_common_probe+0x144/0x1e4 Fix this by giving the CAM ops the same ->add_bus/->remove_bus callbacks. Since pci_ecam_add_bus() and pci_ecam_remove_bus() are static to ecam.c, move the CAM ops definition there as pci_generic_cam_ops (mirroring pci_generic_ecam_ops) and export it for pci-host-generic.c to reference. [mani: removed timestamp from log]", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1111.116 -proposed tracker (LP: #2170108)", "", " [ Ubuntu: 5.15.0-202.212 ]", "", " * jammy/linux: 5.15.0-202.212 -proposed tracker (LP: #2170970)", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603)", " - bus: fsl-mc: wait for the MC firmware to complete its boot", " - ALSA: usb-audio: Propagate write errors in generic mixer put callbacks", " - ima: return error early if file xattr cannot be changed", " - tee: optee: Allow MT_NORMAL_TAGGED shared memory", " - PCI: Stop setting cached power state to 'unknown' on unbind", " - hfsplus: fix issue of direct writes beyond end-of-file", " - wifi: mac80211: always allow transmitting null-data on TXQs", " - kcsan: Silence -Wmaybe-uninitialized when calling __kcsan_check_access()", " - bridge: Do not suppress ARP probes and DAD NS unconditionally", " - soundwire: validate DT compatible before parsing it", " - media: rc: mceusb: Add support for 04eb:e033", " - s390/cio: Purge based on the cdev's online status", " - thunderbolt: Keep the domain reference while processing hotplug", " - net: dsa: mv88e6xxx: fix number of g1 interrupts for 6320 family", " - net: dsa: mv88e6xxx: define .pot_clear() for 6321", " - net: dsa: mv88e6xxx: enable .rmu_disable() for 6320 family", " - media: em28xx-video: fix missing res_free() on init_usb_xfer failure", " - clk: renesas: cpg-mssr: Add number of clock cells check", " - ASoC: ti: omap3pandora: update board check to use DT compatible", " - mmc: core: Add validation for host-provided max_segs", " - drm/amd/display: Fix CRC open failure during active rendering", " - hfsplus: rework hfsplus_readdir() logic", " - drm/gud: Add RCade Display Adapter VID/PID pair", " - integrity: Check for NULL returned by asymmetric_key_public_key", " - scsi: pm8001: Reject firmware update in fatal error state", " - scsi: pm8001: Reject non-fatal dump when controller is crashed", " - crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y", " - crypto: atmel-ecc - add support for atecc608b", " - media: imon: Add iMON VFD HID OEM v1.2 key mappings", " - RDMA/mlx5: Use QP port when decoding responder CQEs", " - mailbox: Make mbox_send_message() return error code when tx fails", " - ALSA: usx2y: Drain pending US-428 pipe-4 output commands", " - 9p: invalidate readdir buffer on seek", " - arm64/daifflags: Make local_daif_*() helpers __always_inline", " - firmware: arm_scmi: Validate SENSOR_UPDATE payload size", " - firmware: arm_scmi: Validate BASE_ERROR_EVENT payload size", " - bitfield: wire __bf_shf to __builtin_ctzll", " - net: usb: qmi_wwan: add MeiG SRM813Q", " - net: bridge: remove stale rcu_barrier() in br_multicast_dev_del()", " - net/sched: sch_drr: make cl->quantum lockless", " - befs: handle set_blocksize failures", " - minix: handle set_blocksize failures", " - isofs: handle set_blocksize failures", " - usb: host: add ARCH_AIROHA in XHCI MTK dependency", " - char/nvram: Remove redundant nvram_mutex", " - netlabel: fix IPv6 unlabeled address add error handling", " - rds: annotate data-race around rs_seen_congestion", " - s390/zcore: Removed unused variables", " - clk: socfpga: agilex: implement l3_main_free_clk", " - drm/panel: simple: Add AM-1280800W8TZQW-T00H", " - mips: cps: Assemble jr.hb with an R2 ISA level", " - iio: adc: qcom-spmi-iadc: balance enable_irq_wake() on driver unbind", " - irqchip/gic-v4: Don't advertise VLPIs if no ITS is probed", " - ALSA: usb-audio: Add quirk for Novation Mininova", " - drm/amd/pm/si: Fix updating clock limits from power states", " - ACPICA: Improve argument parsing in acpi_ps_get_next_simple_arg()", " - hfs: rework hfsplus_readdir() logic", " - host1x: bus: Fix missing ops null check in error teardown", " - scripts: modpost: detect and report truncated buf_printf() output", " - ASoC: Intel: catpt: Complete coredump handling", " - soundwire: only handle alert events when the peripheral is attached", " - mmc: davinci: fix mmc_add_host order in probe", " - mmc: renesas_sdhi: Add OF entry for RZ/G2N SoC", " - mmc: renesas_sdhi: Add OF entry for RZ/G2E SoC", " - iio: accel: mma8452: switch to non-devm request_threaded_irq()", " - libbpf: Also reset {insn,data}_cur on realloc failure", " - net: ibm: emac: Reserve VLAN header in MJS limit", " - ASoC: codecs: pcm3168a: Drop CONFIG_PM-conditional preproc directive", " - ACPI: PCI: Clear _DEP dependencies after PCI root bridge attach", " - iommu/rockchip: disable fetch dte time limit", " - ASoC: codecs: rk3328: Use managed GPIO and clock helpers", " - ALSA: seq: oss: Reject reads that cannot fit the next event", " - dpaa2-switch: fix the error path in dpaa2_switch_rx()", " - clk: keystone: don't cache clock rate", " - ALSA: hda/realtek: Add quirk for ASUS VivoBook X509DAP", " - ipmi: si: Use platform_get_irq_optional() to retrieve interrupt", " - wifi: nl80211: Increase ie_len size to prevent truncated IEs in new peer", " notifications", " - RDMA/mlx5: Fix state and counter desync on loopback enable failure", " - net: cpsw_new: unregister devlink on port registration failure", " - xprtrdma: Add request-pool slack for delayed recycling", " - configfs_depend_prep(): pass configfs_dirent instead of dentry", " - platform/x86: dell-laptop: add Inspiron N5110 to touchpad LED quirk", " table", " - wifi: mt76: transform aspm_conf for pci_disable_link_state", " - btrfs: protect sb_write_pointer() with invalidate lock", " - hwmon: (adt7462) Add of_match_table to support devicetree", " - ata: libata-pmp: add JMicron JMS562 quirk", " - platform/x86: intel-hid: Add HP ProBook x360 440 G1 to", " button_array_table", " - sctp: Unwind address notifier registration on failure", " - PCI: Avoid SBR for Qualcomm WCN6855/WCN7850 WiFi, SDX62/SDX65 modems", " - dmaengine: dw-axi-dmac: fix PM for system sleep and channel alloc", " - hwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i", " - ASoC: rockchip: rockchip_pdm: Reorder clock enable sequence", " - ASoC: rockchip: spdif: Restore regcache cache-only mode on sync failure", " - sparc64: uprobes: add missing break", " - ptp: ocp: add shutdown callback", " - vsock: use sk_acceptq_is_full() helper in all transports", " - e1000e: limit endianness conversion to boundary words", " - net/sched: act_csum: don't mangle UDP tunnel GSO packets", " - i3c: mipi-i3c-hci: Tolerate i3c_master_add_i3c_dev_locked() failures in", " DAA", " - sparc: Disable compat support with LLD", " - fuse: set ff->flock only on success", " - scsi: bfa: Reduce kernel stack usage in", " bfa_fcs_lport_fdmi_build_portattr_block()", " - gpio: pisosr: Read \"ngpios\" as u32", " - ALSA: hda/conexant: Add pin config quirk for Lenovo IdeaPad Slim 5", " 16AKP10", " - leds: uleds: Return -EFAULT on copy_to_user() failure", " - leds: pca9532: Don't stop blinking for non-zero brightness", " - mfd: rsmu: Add 8a34002 support", " - ALSA: usb-audio: Add quirk for YAMAHA CDS3000", " - md/raid5: account discard IO", " - md/raid5: let stripe batch bm_seq comparison wrap-safe", " - rtc: aspeed: add AST2700 compatible", " - ksmbd: use connection ClientGUID for lease lookup", " - ksmbd: treat unnamed DATA stream as base file", " - ksmbd: apply create security descriptor first", " - ksmbd: break RH leases before delete-on-close", " - PCI/sysfs: Use kstrtobool() to parse the ROM attribute input", " - rtc: bq32000: add delay between RTC reads", " - fbdev: pm2fb: unwind WC setup on probe failure", " - drm/arm/malidp: use clk_bulk API in runtime PM resume and suspend", " - netfilter: nf_conntrack_expect: zero at allocation time", " - drm/arm/komeda: fix error handling for clk_prepare_enable() and callers", " - ksmbd: fix n.data memory leak in ksmbd_vfs_set_dos_attrib_xattr", " - xen/front-pgdir-shbuf: free grant reference head on errors", " - freevxfs: don't BUG() on unknown typed-extent type", " - xen/gntalloc: validate grant count before allocation", " - ksmbd: fix credit charge calculation for SMB2 QUERY_INFO", " - wifi: ralink: RT2X00: init EEPROM properly", " - wifi: mac80211: validate deauth frame length before reason access", " - wifi: libertas: reject short monitor TX frames", " - ksmbd: find bound sessions during reauthentication", " - ksmbd: mark invalid session responses as signed", " - ksmbd: validate SID namespace before mapping IDs", " - gpio: dwapb: Mask interrupts at hardware initialization", " - netfilter: ipset: mark the rcu locked areas properly", " - btrfs: only account delalloc bytes for regular file inodes in", " btrfs_getattr()", " - wifi: iwlwifi: mvm: fix sched scan IE sizing", " - arm64: fixmap: Allow 256K early_ioremap() at any offset", " - arm64: kprobes: Allow reentering kprobes while single-stepping", " - drm/amd/pm/si: Don't schedule thermal work when queue isn't initialized", " - ALSA: usb-audio: Add FIXED_RATE quirk for JBL Quantum650 Wireless", " - wifi: mwifiex: replace one-element arrays with flexible array members", " - regulator: core: clamp voltage constraints before applying apply_uV", " - wifi: mac80211_hwsim: reject undersized HWSIM_ATTR_TX_INFO", " - drm/gma500: return errors from Oaktrail HDMI I2C reads", " - phonet: check register_netdevice_notifier() error in", " phonet_device_init()", " - ALSA: hda/realtek: Add mute LED quirk for HP Laptop 14s-dr1xxx", " - ice: pass the return value of skb_checksum_help()", " - powerpc/pseries: Ensure vpa,slb_shadow & dtl are unregistered during", " crash", " - ALSA: usb-audio: Add quirk for Corsair Virtuoso (later revision)", " - ASoC: rt5645: Perform the initial jack detect at probe", " - clk: at91: pmc: #undef field_{get,prep}() before definition", " - Revert \"Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU\"", " - Revert \"Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU\"", " - ARM: 9484/1: enable interrupts when unhandled user faults are triggered", " - EDAC/igen6: Fix interleave boundary condition", " - EDAC/igen6: Fix channel selection hash", " - EDAC/igen6: Fix channel address decode for non-hash mode", " - drm/virtio: Fix a NULL vs ERR_PTR() bug in", " virtio_gpu_user_framebuffer_create()", " - selftests/cgroup: Fix cg_run_in_subcgroups ignoring arg parameter", " - net/sched: act_api: budget all shared attributes in notify skbs", " - net/sched: act_api: size the RTM_GETACTION reply from the actions", " - smb: client: transport: Fix debug printing in __release_mid()", " - net: amd-xgbe: discard rx packets with bad FCS", " - OPP: of: Fix potential multiplication overflow when calculating freq", " - Bluetooth: L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM", " - Bluetooth: hci_mrvl: Fix wrong return value check of", " wait_on_bit_timeout()", " - ASoC: ab8500: Reset the audio block before configuring it", " - ASoC: ab8500: Repair the DAPM capture graph", " - ASoC: ab8500: Update to modern clocking terminology", " - ASoC: ab8500: Correct digital interface format setup", " - ASoC: ab8500: Validate and program TDM slots correctly", " - tty: make tty_ldisc_ops::hangup return void", " - ppp: ppp_async: simplify tty disc_data access", " - ASoC: amd: renoir: fix disable_pdm_interrupts() to clear mask bits", " - btrfs: consolidate device_list_mutex in prepare_sprout to its parent", " - scsi: mpt3sas: Use irq_set_affinity_and_hint()", " - perf/core: Skip empty AUX records with only format flags", " - locking/lockdep: Introduce lock_sync()", " - locking/lockdep: Improve the deadlock scenario print for sync and read", " lock", " - lockdep: Add lock_set_cmp_fn() annotation", " - locking/lockdep: Invalidate stale class_cache entries for zapped classes", " - ASoC: ux500: Fix MSP stream lifecycle handling", " - ASoC: ux500: remove platform_data support", " - ASoC: ux500: Propagate MSP setup errors", " - ASoC: ux500: Correct MSP frame and bit clock setup", " - ASoC: ux500: Validate MSP DAI configuration", " - ASoC: ux500: remove stedma40 references", " - ASoC: ux500: Request the MSP MMIO resource", " - ASoC: ux500: Program the MSP FIFO watermarks", " - net/rds: use clear_bit_unlock() in release_refill()", " - net/rds: tcp: don't force RDS_CONN_RESETTING over a concurrent shutdown", " - net: stmmac: reconfigure RX packet parser table in stmmac_hw_setup()", " after reset", " - bonding: use skb_cow_head() in bond_do_alb_xmit() and rlb_arp_xmit()", " - powerpc/kexec_file: Use inclusive range checks in add_usable_mem()", " - net/mlx5e: Fix setting RS FEC after remapping", " - net/mlx5e: Fix ETS zero BW reporting when one TC holds 100%", " - net_sched: sch_fq_pie: implement lockless fq_pie_dump()", " - net/sched: pie: clamp psched_mtu in pie_drop_early", " - ASoC: bcm: bcm63xx: Publish the OF module aliases", " - ASoC: Intel: SST: Publish the PCI module aliases", " - netfilter: ip6_tables: set F_PROTO when proto value is nonzero", " - ASoC: mt6351: Publish the OF module alias", " - virtio-console: call scheduler when we free unused buffs", " - vdpa_sim_blk: use dev_dbg() to print errors", " - vdpa_sim_blk: make vdpasim_blk_check_range usable by other requests", " - virtio-pci: return IRQ_HANDLED after non-zero ISR", " - net: ipv6: Clamp to IP6_MAX_MTU in ip6_dst_mtu_maybe_forward", " - net: ethernet: cortina: Finish RX updates before NAPI completion", " - net: ethernet: cortina: No mapping is a dropped rx", " - net: ethernet: cortina: Count RX drops once per frame", " - net: ethernet: cortina: Count RX descriptors for freeq refill", " - watchdog: fix hrtimer start when pretimeout is zero", " - hwmon: (gpio-fan) take fan_data->lock in gpio_fan_shutdown()", " - hwmon: (aspeed-pwm-tacho) Propagate reset deassert errors", " - net: stmmac: optimize locking around PTP clock reads", " - net: sun4i-emac: fix missing of_node_put() for phy_node", " - octeontx2-af: fix PF/CGX debugfs PCI bus lookup", " - net/rds: Pass a pointer to virt_to_page()", " - scsi: target: iscsi: Handle abort for WRITE_PENDING cmds", " - Revert \"scsi: smartpqi: Fix AIO retry marker cleared by SCSI core", " between dispatches.\"", " - Revert \"scsi: smartpqi: Fix BUILD_BUG_ON() statements\"", " - Revert \"scsi: core: Register sysfs attributes earlier\"", " - Revert \"scsi: smartpqi: Capture controller reason codes\"", " - ALSA: ctxfi: Fix CA20K2 S/PDIF passthrough", " - dm/amdgpu: fix malformed link_settings debugfs output", " - watchdog: sunxi_wdt: preserve boot-enabled watchdog", " - tunnels: Drop stale dst when building an ICMP error for PMTUD", " - exec: do_close_on_exec() before taking exec_update_lock", " - net: hso: fix TIOCMIWAIT race", " - netfilter: report NLM_F_DUMP_FILTERED when all is filtered out", " - KVM: PPC: Book3S HV: Set irqfd->producer only on success", " - s390/qeth: allow bridgeport queries despite OS_MISMATCH", " - hwmon: (applesmc) fix key backlight workqueue leak on register failure", " - hwmon: (pmbus) Clear generic status alarms with CLEAR_FAULTS", " - media: hevc: add bounded tile-count helpers", " - media: v4l2-h264: Fix memcmp() size in B1 reference list comparison", " - mptcp: options: handle MPC data + csum reqd + no csum", " - Revert \"perf tests: Fix flakiness in BPF counters test on hybrid", " systems\"", " - [Config] remove CRYPTO_DEV_SUN8I_CE_PRNG", " - [Config] remove CRYPTO_DEV_SUN8I_SS_PRNG", " - netfilter: nft_set_pipapo_avx2: add missing vzeroupper", " - ARM: fix hash_name() fault", " - ARM: fix branch predictor hardening", " - ARM: ensure interrupts are enabled in __do_user_fault()", " - Bluetooth: L2CAP: Fix deadlock", " - Revert \"alpha: don't leak hardware-fabricated FP exception bits to user", " space\"", " - Revert \"alpha: fix ieee_swcr_to_fpcr setting FPCR_DNOD unconditionally\"", " - selftests/landlock: Add tests for whiteout object creation", " - sunvdc: fix -EIO issue due to lack of retries", " - Revert \"perf cs-etm: Avoid truncating AUX buffer sizes to int\"", " - Revert \"perf cs-etm: Flush thread stacks after decoder reset\"", " - media: video-i2c: fix buffer queue ordering", " - ipv6: Select best matching nexthop object in fib6_table_lookup()", " - ipv6: Honor oif when choosing nexthop for locally generated traffic", " - xfrm: propagate extack to all netlink doit handlers", " - xfrm: add extack to verify_sec_ctx_len", " - xfrm: add extack support to verify_newsa_info", " - xfrm: add extack to verify_one_alg, verify_auth_trunc, verify_aead", " - xfrm: avoid RCU warnings around the per-netns netlink socket", " - xfrm: fix compat ALLOCSPI request use-after-free", " - xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for", " xfrm_trans_reinject()", " - ARM: socfpga: select the PL310 erratum 753970 workaround", " - RDMA/siw: Introduce siw_cep_set_free_and_put", " - RDMA/siw: Cleanup siw_accept", " - RDMA/siw: Clear association under lock if siw_qp_modify fails in", " siw_accept", " - firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS", " - clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate", " - IB/iser: Align coding style across driver", " - IB/iser: Remove iser_reg_data_sg helper function", " - IB/iser: Use iser_fr_desc as registration context", " - IB/iser: reject a remote invalidation of an unregistered direction", " - scsi: target: iscsi: Rename iscsi_cmd to iscsit_cmd", " - IB/isert: wait for deferred control PDU completions before releasing the", " connection", " - RDMA/mad: Fix receive buffer leak when PKey enforcement fails", " - RDMA/irdma: Enforce local fence for IB_WR_REG_MR", " - RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted", " - dmaengine: sprd: Fix runtime PM reference leak in probe", " - wifi: virt_wifi: free skb when disconnected", " - wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path", " - wifi: libipw: reject too-short beacon and probe responses", " - wifi: libipw: reject too-short association responses", " - IB/IPoIB: Avoid restoring OPER_UP after multicast flush", " - wifi: cfg80211: check IP header size in cfg80211_classify8021d()", " - soundwire: cadence_master: wait and cancel cdns->work before clock stop", " - MIPS: Octeon: apply USB FDT fixups also when USB is modular", " - dma-coherent: Warn if OF reserved memory is beyond current coherent DMA", " mask", " - dma-coherent: report a failed reserved memory assignment", " - dmaengine: Fix device kref underflow in dma_chan_put()", " - dmaengine: fix use-after-free in dma_chan_put() and", " dma_release_channel()", " - dmaengine: wait for RCU readers before releasing dma_device", " - wifi: cfg80211: only group hidden BSSes with beacon entries", " - wifi: cfg80211: don't filter by BSS type when removing stale entries", " - wifi: mac80211: suppress chanctx warning for debugfs reset", " - wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown", " - wifi: mac80211: don't RCU-dereference the mesh CSA settings we just set", " - wifi: mac80211: don't access the TSF of a down interface", " - dmaengine: xilinx_dma: Fix hardware buffer descriptor reuse order", " - dmaengine: xilinx_dma: Fix hardware buffer descriptor chain after cyclic", " DMA", " - RDMA/siw: Bound fragmented header copies by the remaining length", " - netfilter: nft_nat: fully initialise new_addr in netmap setup", " - netfilter: flowtable: hold reference on ct until flow is released", " - drm: Fix drm_pending_vblank_event leak in error path for out_fence_ptr", " - keys: fix lost wakeup when reaping a dead key type", " - ALSA: pcm: set timer->private_data before registering the PCM timer", " - Input: trackpoint - fix the inertia attribute name in the ABI document", " - wifi: virt_wifi: don't transfer operstate before register", " - ALSA: hda: trace PCM open only after assigning a stream", " - btrfs: tree-checker: print dev extent offset in error message", " - drm/msm/dsi: correct byte intf clock rate for 14nm DSI PHY", " - drm/msm/dsi: round the byte clock rate after reparenting to the PHY PLL", " - seg6: set IPSKB_L3SLAVE from IP6SKB_L3SLAVE on IPIP decapsulation", " - net: fddi: skfp: fix NULL deref when setting the MAC address while down", " - wifi: brcmfmac: fix lost 802.1x TX completion wakeup", " - tcp: Don't call skb_clone_and_charge_r() for close()d listener in", " tcp_v6_do_rcv().", " - tcp: do not let tcp_rmem be set below 4096", " - dmaengine: mmp_pdma: fix wrong sg length in mmp_pdma_prep_slave_sg()", " - Bluetooth: btmtksdio: Fix PM runtime reference leak in shutdown", " - Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup", " - pppoatm: ensure a writable skb header and linear data", " - drop_monitor: synchronize tracepoint unregistration on error path", " - drop_monitor: fix out-of-bounds write in reset_per_cpu_data()", " - KVM: PPC: Book3S HV: fix secure device page leak on uv_page_in() failure", " - powerpc/iommu: Fix the overflow validation in iommu_tce_check_ioba", " - ASoC: ux500: Parenthesize MSP_{RX,TX}_CLKPOL_BIT() arguments", " - ASoC: hdmi-codec: Report a change when the channel status moves", " - net: netsec: fix device_node reference leak on phy_np", " - net: lock the socket in sock_gettstamp()", " - net: ethernet: cortina: Ack RX overrun interrupt correctly", " - net: mvpp2: prevent buffer overflow in page_pool allocation", " - Input: eeti_ts - publish the OF module alias", " - Input: xpad - add support for Victrix Pro BFG Controller", " - Input: xpad - add support for Azeron devices", " - Input: xpad - fix PDP Marvel Xbox 360 controller", " - ata: libahci: clear PxCLBU and PxFBU for AHCI_HFLAG_32BIT_ONLY", " - rds: ib: use rds_conn_drop() on protocol version mismatch", " - tcp: exclude old ACKs from tcp fast path", " - RDMA/ucma: Serialize join and leave on copy_to_user failure", " - RDMA/core: fix refcount bug in iwpm_get_nlmsg_request()", " - openvswitch: avoid reallocating confirmed conntrack labels", " - net: xfrm: reject unrepresentable espintcp transport headers", " - kselftest/arm64: Fix size of thread_data values for pthread_join()", " - arm64: percpu: Fix this_cpu_write() casting", " - arm64: percpu: Fix this_cpu_and() mask generation", " - Bluetooth: btusb: fix NXP IW610 composite device handling", " - dmaengine: sun6i: fix non-atomic read of DMA position registers", " - dmaengine: sun6i: fix undefined behaviour in sun6i_dma_tx_status", " - dmaengine: ti: k3-udma-glue: fix NULL dereference in", " k3_udma_glue_release_rx_chn()", " - ipv6: xfrm: use full sockets in local error paths", " - net: wwan: mhi_wwan_mbim: guard against a cyclic NDP chain", " - net: wwan: mhi_wwan_mbim: check skb_copy_bits() return value", " - net/sched: hhf: cap hh_flows_limit at change time", " - net/packet: clear RX owner on VNET header error", " - net/packet: avoid truncating TPACKET_V3 private size", " - keys: translate request_key_auth pid for the reading procfs instance", " - KEYS: trusted: Fix tpm2_load_cmd() boundary check", " - i2c: at91: release DMA channels on remove and probe error", " - i2c: imx: release DMA channels on probe error", " - IB/mlx4: Fix use-after-free on pkey sysfs registration failure", " - selinux: always fill AVC decision in avc_has_perm_noaudit()", " - mmc: core: Fix OF node reference leak on card add failure", " - mmc: mxcmmc: cancel data work and watchdog on remove", " - mmc: rtsx_pci_sdmmc: ignore broken write-protect on ThinkPad X260", " - mmc: sdhci-of-aspeed: Remove children before releasing SDC resources", " - mmc: sdio_uart: fix xmit_fifo leak when the port table is full", " - mmc: sh_mmcif: initialize IRQ-thread mutex before requesting interrupt", " - mmc: spi: reset bytes_xfered before retrying CRC failures", " - mmc: sdhci_am654: Reset command and data lines on failed tuning", " - Input: atkbd - skip deactivate for Xiaomi Redmi Book Pro 16 2026", " - Input: evdev - zero absinfo before partial copy in EVIOCSABS", " - Input: i8042 - add quirk for Acer Aspire Go 15 AG15-42P", " - Input: rmi_smbus - fix out-of-bounds read in rmi_smb_write_block()", " - Input: soc_button_array - fix MS Surface Pro 11 probe failure", " - Input: soc_button_array - check btns_desc->package.count", " - Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722)", " - Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound", " - Input: zero ff_effect before compat copy in input_ff_effect_from_user", " - hwmon: (pmbus/core) increase number of phases and add new mask", " - hwmon: (pmbus/tps53679) Fix TPS53676 phase page decoding", " - hwmon: (pmbus/tps53679) Select page 0 for single-page TPS53676", " - hwmon: (w83791d) remove fan/pwm 4-5 sysfs group on remove", " - hwmon: (w83793) release probe data through kref", " - watchdog: digicolor: Avoid division by zero", " - watchdog: msc313e: Fix premature reset during timeout update", " - watchdog: sp5100_tco: Fix pci_dev reference leak in sp5100_tco_init()", " - wifi: brcmsmac: fix UAF in brcms_free_timer()", " - wifi: iwlegacy: fix broadcast stations deallocation", " - wifi: libertas_tf: fix UAF in lbtf_free_adapter()", " - wifi: rsi: fix heap OOB write on key removal", " - wifi: wlcore: release runtime PM ref on regdomain config failure", " - wifi: wilc1000: fix out-of-bounds read in P2P public action frames", " - wifi: wilc1000: fix RX buffer OOB-write in wilc_wlan_handle_isr_ext()", " - wifi: p54: validate curve data length in the calibration curve", " converters", " - wifi: p54: require a full exp_if record in PDR_INTERFACE_LIST", " - wifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length", " - wifi: mwifiex: validate scan response extents", " - wifi: mwifiex: validate action frame fixed fields", " - wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver", " - drm/gud: fix out-of-bounds write in gud_plane_atomic_check()", " - drm/msm/adreno: fix autosuspend cleanup during teardown", " - drm/msm/hdmi_phy: fix runtime PM cleanup on probe failure", " - HID: logitech-hidpp: fix race condition when accessing stale stack", " pointer", " - spi: spi-zynqmp-gqspi: stop the controller on shutdown", " - spi: zynqmp-gqspi: Use devm_spi_alloc_host()", " - erofs: fix atomic context detection when !CONFIG_DEBUG_LOCK_ALLOC", " - HID: hyperv: streamline driver probe to avoid devres issues", " - bpf: Fix bpf_skb_change_tail wrt csum partial skbs", " - bpf: Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL", " - bpf: support access variable length array of integer type", " - bpf: Fix divide-by-zero in btf_struct_walk()", " - HID: elecom: fix bus type for M-XGL20DLBK", " - bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch()", " - bpf: Fix out-of-bounds read of rtt_min in sock_ops", " - HID: amd_sfh: Move common macros and structures", " - HID: amd_sfh: Validate PCI BAR size before mapping", " - squashfs: Add dictionary size range check to prevent shift-out-of-bounds", " - Bluetooth: SMP: reject Security Request over BR/EDR", " - Documentation: s390: correct spelling", " - docs: s390/pci: Improve and update PCI documentation", " - s390/pci/docs: Fix sriov_numvfs attribute name", " - s390/cio: Fix cio_update_schib() to not cache invalid schib", " - s390/cio: Check pmcw.dnv before pmcw.ena in I/O entry points", " - xsk: Use a 32-bit compare in xsk_map_gen_lookup", " - libbpf: Fix an error in 64bit relocation value computation", " - bpf: Restrict CO-RE poisoning to relocatable instructions", " - netfilter: flowtable: allow unidirectional rules", " - netfilter: flowtable: publish HW_DEAD after worker is done", " - netfilter: nfnetlink_queue: nfqnl_instance GFP_ATOMIC ->", " GFP_KERNEL_ACCOUNT allocation", " - netfilter: nfnetlink_queue: hold nfnl mutex in event notifier", " - netfilter: nft_synproxy: use the family-aware checksum helper", " - ipvs: revalidate ihl before icmp_send", " - ocfs2: make ocfs2_calc_xattr_init() return void", " - drm/nouveau/clk: fix list cursor use after loop in", " nvkm_clk_ustate_update", " - drm/nouveau/clk: don't clobber reclock status when restoring volt/fan", " - net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure", " - net: gue: reject invalid REMCSUM offsets", " - ip6_gre: Call ip6erspan_tunnel_unlink_md() in ip6erspan_changelink().", " - sctp: avoid livelock while updating retransmit path", " - net: usb: catc: bound the RX packet length in catc_rx_done()", " - net/sched: sch_hfsc: bound the classify inner-filter walk with a drift", " budget", " - drm/virtio: fix object leak when drm_gem_handle_create() fails", " - drm/virtio: fix object leak in virtio_gpu_resource_create_ioctl()", " - drm/virtio: fix object leaks in virtio_gpu_resource_create_blob_ioctl()", " - drm/virtio: release the GEM object on virtio_gpu_vram_create() errors", " - Bluetooth: bnep: fix out-of-bounds reads on short RX/TX frames and", " control fallthrough", " - Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame()", " - net: usb: sr9700: include receive overhead in the length check", " - tg3: clean up PHYLIB resources on probe failure", " - s390/debug: Do not register views for failed static debug areas", " - s390/debug: Fix NULL pointer dereference in debug_info_copy()", " - net: ethernet: ti: netcp: fix pm_runtime usage counter leak on error", " - bpf: Fix bpf_sock context code generation", " - bpf, sockmap: Reject max_entries > INT_MAX in sock_map_alloc", " - sctp: hold asoc or transport before mod_timer() in timer handlers", " - net: stmmac: selftests: Support running selftests on DSA conduits", " - net: stmmac: selftests: Check the dev->features for S-TAG offload", " testing", " - net: stmmac: selftests: Capture all packets for vlan checks", " - net: stmmac: Remove some unnecessary void pointers", " - net: stmmac: dwmac4: Use the correct bufzise when the len is exactly 8K", " - nfc: nfcmrvl: validate helper command length before pull", " - nfc: st21nfca: remove redundant assignment to variable i", " - nfc: st21nfca: validate received frame size", " - nfc: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm()", " - selftests: nci: Correct pthread_create return value check", " - nfc: llcp: Fix race condition in accept_queue lifecycle", " - selftests: nci: Fix uninitialized family ID on missing attribute", " - selftests/nci: Fix out-of-bounds store on thread join", " - nfc: virtual_ncidev: Add missing ioctl compat handler", " - nfc: llcp: fix sdreq TLV list leak on parse/alloc/send failure", " - nfc: st21nfca: validate ISO15693 inventory length", " - nfc: llcp: fix -ENOMEM on connect with zero-length service name", " - nfc: llcp: fix WKS SAP hijacking via prefix match in nfc_llcp_wks_sap()", " - nfc: llcp: fix slab-out-of-bounds reads when logging service names", " - nfc: pn533: fix OOB read in pn533_acr122_is_rx_frame_valid()", " - veth: manage XDP program pointers during channel resize", " - net: skbuff: fix pull-bound underflow in skb_checksum_setup_ipv6()", " - vrf: Stop corrupting skb->csum when capturing CHECKSUM_COMPLETE packets", " - net: bcmgenet: validate Ethernet address in bcmgenet_set_mac_addr", " - ip_gre: Reject enabling collect metadata through changelink", " - net: xps: reject an out of range traffic class", " - tcp: fix use-after-free of retransmit_skb_hint in tcp_send_synack()", " - net/smc: fix UAF on lgr list traversal in smcr_port_err()", " - tipc: Fix a data race on mon->peer_cnt in mon_timeout()", " - llc: fix skb UAF and leaks on llc_mac_hdr_init() failure", " - bridge: check llc_mac_hdr_init() return value in br_send_bpdu()", " - net/sched: sch_teql: fix shadowed err in __teql_resolve()", " - vlan: ensure sufficient headroom in vlan_dev_hard_header()", " - autofs: fix sbi->pipe file reference leak in autofs_kill_sb()", " - rculist: add list_splice_rcu() for private lists", " - KVM: x86/mmu: Use a bool for direct", " - KVM: x86/mmu: Stop passing \"direct\" to mmu_alloc_root()", " - KVM: MMU: update comment on the number of page role combinations", " - KVM: X86: Remove useless code to set role.gpte_is_8_bytes when", " role.direct", " - KVM: X86: Calculate quadrant when !role.gpte_is_8_bytes", " - KVM: X86: Rename gpte_is_8_bytes to has_4_byte_gpte and invert the", " direction", " - KVM: x86/mmu: Derive shadow MMU page role from parent", " - KVM: x86/mmu: Always pass 0 for @quadrant when gptes are 8 bytes", " - SAUCE: Revert \"KVM: x86: Fix shadow paging use-after-free due to", " unexpected role\"", " - KVM: x86/mmu: pull call to drop_large_spte() into __link_shadow_page()", " - KVM: x86: Fix shadow paging use-after-free due to unexpected role", " - x86/PCI: Disable enhanced atomics on AMD NBIO 7.7 and 7.11", " - tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers", " underflow", " - sctp: discard the rest of the packet on a stale-cookie error", " - af_packet: fix integer overflow in prb_calc_retire_blk_tmo()", " - fou: reject omitted FOU_ATTR_IPPROTO on FOU_ENCAP_DIRECT", " - workqueue: Fix NULL current_pwq deref in flush dependency check", " - writeback: report a Tasks-RCU quiescent state per cgwb drain pass", " - fsl/fman: Fix clk reference leak in read_dts_node()", " - ipv6: do not let ipv6_find_hdr() return an offset past the packet end", " - ipv6: sr: enforce exact attribute length for SEG6_ATTR_DST", " - gpio: arizona: Fix runtime PM leak in arizona_gpio_direction_out()", " - gpio: zynq: fix runtime PM leak on request error path", " - llc: reserve device headroom for allocated frames", " - rds: ib: Clear the sg list when mapping an MR fails", " - drm/nouveau: fix autosuspend cleanup during teardown", " - drm/nouveau: Fix bridge reference leak in nv1a_ram_new()", " - drm/nouveau: fix double-free in nvif_vmm_dtor", " - drm/nouveau: Fix gem reference leak in validate_init()", " - drm/nouveau: don't bump pin count on failed re-pin in", " nouveau_bo_pin_locked()", " - HID: alps: fix use-after-free on input2 registration failure", " - HID: quirks: add ALWAYS_POLL quirk for SDINNOVATION gaming keyboard", " - HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()", " - net/mlx5: Fix rev_entry reference leak in", " mlx5_tc_ct_shared_counter_get()", " - net/sched: reject IDR error pointers when deleting actions", " - net: arp: terminate device name before lookup", " - net: atl1: fix soft lockup on out-of-range cmb_tpd_next_to_clean read", " - net: hisilicon: hns_dsaf_mac: fix mdio device leak in", " hns_mac_register_phy()", " - net: openvswitch: conntrack: avoid modifying shared unconfirmed ct entry", " - net: atl1c: fix soft lockup on out-of-range tpd_cons read", " - net: atl1e: fix soft lockup on out-of-range hw_next_to_clean read", " - net: usb: cdc_mbim: add MeiG Smart SRM821 to ZLP whitelist", " - netfilter: ip6t_rpfilter: reject routes without inet6_dev", " - netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds read", " - nfc: fix use-after-free in nfc_get_local_general_bytes", " - nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc()", " - nfc: port100: reject frames whose declared length exceeds the received", " data", " - scsi: libiscsi_tcp: Check the data direction of a Data-In PDU", " - pinctrl: single: free the IRQ on domain creation failure", " - s390/cio: Fix NULL pointer dereference in ccw_device_get_util_str()", " - Bluetooth: hci_sock: validate event length before filtering", " - Bluetooth: hci_sock: reject out-of-range OCF values", " - Bluetooth: L2CAP: validate frame length before control and FCS access", " - Bluetooth: RFCOMM: fix NULL dereference of dlc->session in", " RFCOMM_CONNINFO", " - xfs: fix blockgc group quota scanning when usrquota isn't enforced", " - net: tls: fix silent data drop under pipe back-pressure", " - file: add fput() cleanup helper", " - eventpoll: use hlist_is_singular_node() in __ep_remove()", " - eventpoll: split __ep_remove()", " - eventpoll: kill __ep_remove()", " - eventpoll: drop vestigial __ prefix from ep_remove_{file,epi}()", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: move epi_fget() up", " - perf test: Change all remaining #!/bin/sh to #!/bin/bash", " - tools/thermal/tmon: Fix compilation warning for wrong format", " - lan78xx: Enable 125 MHz CLK configuration for LAN7801 if NO EEPROM is", " detected", " - lan78xx: Enable Auto Speed and Auto Duplex configuration for LAN7801 if", " NO EEPROM is detected", " - Linux 5.15.222", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2025-68190", " - drm/amdgpu/atom: Check kcalloc() for WS buffer in", " amdgpu_atom_execute_table_locked()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-46242", " - eventpoll: fix ep_remove struct eventpoll / struct file UAF", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2025-38349", " - eventpoll: don't decrement ep refcount while still holding the ep mutex", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2025-37964 -- to the 6.1, 6.6 and 6.12 trees ended up with two", " - x86/mm: Fix check/use ordering in switch_mm_irqs_off()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-80726", " - KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow", " page", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-46113", " - KVM: x86: Fix shadow paging use-after-free due to unexpected GFN", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-52988", " - netfilter: nf_tables: join hook list via splice_list_rcu() in commit", " phase", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2023-53231", " - erofs: Fix detection of atomic context", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2023-53707", " - drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2024-49568", " - net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal", " msg", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-89560", " - landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2024-41062", " - bluetooth/l2cap: sync sock recv cb and release", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2022-50406", " - iomap: iomap: fix memory corruption when recording errors during", " writeback", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97523", " - mptcp: close race between scheduler and state change", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97524", " - mptcp: avoid unneeded actions on subflow reset", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-80833", " - crypto: sun8i-ss - Remove crypto_rng interface", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-80834", " - crypto: sun8i-ce - Remove crypto_rng interface", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-74496", " - fou: Fix use-after-free in fou_create()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93286", " - net: appletalk: fix NULL pointer dereference in aarp_send_ddp()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93287", " - i2c: smbus: reject oversized block transfers in the common path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97931", " - ALSA: us122l: Prevent write upgrades for read mappings", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97568", " - mptcp: syncookies: remember the request backup flag", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97572", " - bnxt_en: Propagate RX ring init failures in bnxt_init_nic()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97573", " - bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97576", " - media: v4l2-ctrls: validate HEVC tile counts", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97582", " - hwmon: (gpio-fan) Fix use-after-free in alarm work", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97592", " - s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm", " algorithm", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97596", " - ipvs: reject invalid states in connection template sync records", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97598", " - ipv4: fib: bound automatic table ID allocation", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97601", " - ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97604", " - fbdev: vfb: defer cleanup until the last reference", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97608", " - netfilter: nf_log: unregister loggers before per-net teardown", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97611", " - net: openvswitch: fix use-after-free of the flow table mask array", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97612", " - net: mpls: clear inner_protocol when the last label is popped", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97899", " - drm/i915: Fix memory leak in query_perf_config_list()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97904", " - cpufreq: initialize policy rwsem before sysfs publication", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97905", " - cpufreq: zero-initialize policy cpumask before sysfs publication", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97909", " - ASoC: sti: initialize IRQ lock before requesting IRQ", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97910", " - ASoC: sprd: validate compress buffer sizes against fixed allocations", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97923", " - tracing: Free histogram the var ref when its initialization fails", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97926", " - ufs: validate cylinder group metadata before caching it", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97927", " - ufs: create the root dentry after loading cylinder metadata", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97930", " - ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97940", " - ipv6: fix fib6 walker UAF on seq stop", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97948", " - powerpc/eeh: Fix recursive locking on devices without EEH sensitive", " driver", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-74743", " - macvlan: inherit needed_headroom and needed_tailroom from lowerdev", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-89792", " - ksmbd: prevent out-of-bounds reads in share config responses", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97951", " - scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97952", " - sunvdc: unmap LDC cookies when the descriptor send fails", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97954", " - net/rds: fix tcp stream corruption with large pages", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97957", " - net: hinic: fix mailbox segment buffer overflow", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97958", " - net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain().", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97959", " - net/sched: cls_route: free emptied bucket on filter move", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97963", " - net: stmmac: initialize ptp_lock at probe time", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97964", " - ppp_synctty: ensure a writeable skb header", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97969", " - watchdog: msc313e: Fix clock leak and spurious timer in settimeout()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97970", " - watchdog: msc313e: Avoid division by zero", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97981", " - net: ethernet: cortina: Count dropped frames as NAPI work", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97982", " - net: ethernet: cortina: Fix budget accounting", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97991", " - vdpa_sim_blk: reject out-of-range sector starts", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97993", " - vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97995", " - virtio_console: do not free control-out buffers on remove", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97998", " - netfilter: nfnetlink_log: cope with concurrent instance destruction", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98006", " - ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98009", " - net/sched: ets: clamp quantum in parse and fallback paths", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98010", " - net/sched: drr: clamp quantum in change class", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98011", " - net/sched: hhf: clamp quantum in change and init paths", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98012", " - net/sched: sfq: clamp quantum in change path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98013", " - net/sched: fq_pie: clamp quantum in change path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98014", " - net/mlx5: E-Switch, prevent mc_list repopulation during vport disable", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98015", " - net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98016", " - net/mlx5e: Fix use-after-free race in sample_restore_put()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98022", " - net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98023", " - vxlan: reject dynamic fdb entries that reference a nexthop id", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98025", " - net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent", " partial_data heap overflow", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98027", " - net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer", " size", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98030", " - net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98031", " - nexthop: Initialize extack in remove_nh_grp_entry()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98063", " - bpf: Fix NULL-ptr-deref in btf_var_show()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98064", " - bpf: Fix NULL-ptr-deref when showing a void BTF type", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98066", " - ALSA: caiaq: Fix potential double-free at error path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98068", " - net/rds: don't let rds_conn_shutdown() consume a concurrent drop", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98069", " - net/rds: acquire the fastpath locks in rds_conn_shutdown()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98070", " - net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98071", " - net/rds: clear cp_flags bits individually in rds_conn_path_reset()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98072", " - net/rds: use wq_has_sleeper() in release_in_xmit()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98074", " - bonding: do not clear curr_active_slave prematurely when releasing all", " slaves", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98075", " - bpf: reject BPF_PSEUDO_FUNC reference to the main program", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98076", " - tracing/probes: Fix use-after-free on field name/type of events with", " multiple probes", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98077", " - netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98078", " - ipvs: fix reversed sequence option serialization", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98080", " - btrfs: do not force reloc root creation during qgroup_account_snapshot()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98088", " - scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in", " _base_assign_reply_queues()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98090", " - btrfs: restore active device pointers after failed sprout", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98091", " - btrfs: detach failed sprout device from transaction update list", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98094", " - staging: fbtft: make dirty_lock IRQ-safe", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98095", " - af_packet: Don't cast tpacket_hdr.tp_len to int in", " tpacket_parse_header().", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98096", " - ipv6: sr: restore network header before routing and forwarding", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98098", " - tipc: fix NULL deref in tipc_named_node_up() on empty publication list", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98108", " - Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98113", " - ksmbd: rate limit unmapped SID errors", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98116", " - ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98121", " - watchdog: msc313e: Fix NULL pointer dereference in PM callbacks", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98123", " - sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98130", " - sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98154", " - nvme-rdma: fix -EIO cleanup order in queue_rq", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98157", " - EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-89796", " - mm/damon/core: avoid infinite kdamond_merge_regions() internal loop", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98158", " - ppp_async: drop the errored frame instead of resetting its headroom", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93288", " - netfilter: nfnetlink_log: wait for rcu grace period before freeing", " pernet state", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93782", " - vhost-scsi: flush backend after device ioctls", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93783", " - Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93784", " - wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93785", " - cifs: validate idmap key payload length", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93789", " - wifi: iwlwifi: bound aligned TLV advance in FW parser", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93795", " - blk-cgroup: fix leaks and online flag on radix_tree_insert failure", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93797", " - wifi: iwlwifi: mvm: fix an off-by-1 boundary check", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93798", " - btrfs: fix reloc root cleanup in merge_reloc_roots()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93800", " - btrfs: fix use-after-free on reloc root after error in", " insert_dirty_subvol()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93802", " - wifi: rsi: validate beacon length before fixed buffer copy", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93803", " - wifi: libipw: fix key index receive bound checks", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93805", " - wifi: cfg80211: validate rx/tx MLME callback frame lengths before access", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93807", " - wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93808", " - ALSA: usb-audio: caiaq: validate EP1 reply lengths", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93811", " - ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93812", " - ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93813", " - btrfs: tree-checker: validate INODE_REF's namelen", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93815", " - net: au1000: move free_irq out of the close-time spinlocked section", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93816", " - f2fs: validate inline dentry name lengths before conversion", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93819", " - PCI: mediatek: Protect root bus removal with rescan lock", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93820", " - PCI: rockchip: Protect root bus removal with rescan lock", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93821", " - PCI: altera: Protect root bus removal with rescan lock", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93822", " - PCI: iproc: Protect root bus removal with rescan lock", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93825", " - spi: Add NULL check for spi_get_device_id() in", " spi_get_device_match_data()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93830", " - net: stmmac: xgmac2: disable RBUE in default RX interrupt mask", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97407", " - ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in", " set_fmt", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97408", " - Bluetooth: L2CAP: validate connectionless PSM length", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97411", " - net: ibm: emac: mal: fix potential system hang in mal_remove()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97413", " - RDMA/rtrs-srv: Fix integer underflow in process_read and process_write", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97416", " - btrfs: balance: fix potential bg lookup failure in", " btrfs_may_alloc_data_chunk()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97417", " - netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97418", " - ALSA: es18xx: check control allocation before private data setup", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97419", " - hsr: broadcast netlink notifications in the device's net namespace", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97420", " - bpf: NUL-terminate replaced sysctl value", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97421", " - RDMA/umem: Be careful about boundary conditions in", " ib_umem_find_best_pgsz()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97430", " - xhci: Prevent queuing new commands if xhci is inaccessible", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97434", " - dpaa2-switch: fix handling of NAPI on the remove path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97435", " - net: dsa: sja1105: flower: reject cross-chip redirect", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97436", " - dpaa2-switch: rework FDB management on the bridge leave path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97437", " - ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97438", " - fs/ntfs3: validate index entry key bounds", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97439", " - fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97440", " - net: qrtr: fix node refcount leak on ctrl packet alloc failure", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97441", " - ata: ahci: fail probe if BAR too small for claimed ports", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97443", " - perf/ftrace: Fix WARNING in __unregister_ftrace_function", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97444", " - ACPICA: add boundary checks in two places", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97445", " - ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97446", " - ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97448", " - ACPICA: Add validation for node in acpi_ns_build_normalized_path()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97449", " - ACPICA: Add package limit checks in parser functions", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97450", " - ACPICA: validate handler object type in two places", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97451", " - ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op)", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97452", " - ACPICA: Prevent adding invalid references", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97453", " - ACPICA: validate byte_count in acpi_ps_get_next_package_length()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97454", " - ACPICA: add boundary checks in acpi_ps_get_next_field()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97455", " - ACPICA: Fix use-after-free in acpi_ds_terminate_control_method()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97456", " - ACPICA: Fix condition check in acpi_ps_parse_loop()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97472", " - ipv6: addrconf: fix temp address generation after prefix deprecation", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97475", " - thermal/drivers/tegra/soctherma: Switch to devm cooling device", " registration", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97476", " - rds: filter RDS_INFO_* getsockopt by caller's netns", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97481", " - serial: 8250: fix possible ISR soft lockup", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97482", " - usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET", " log", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97483", " - usb: core: hcd: fix possible deadlock in rh control transfers", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97484", " - usbip: vhci_hcd: fix NULL deref in status_show_vhci", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97485", " - omfs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97486", " - hpfs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97487", " - jfs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97488", " - qnx4: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97489", " - bfs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97490", " - affs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97491", " - net/rds: Don't sleep inside rds_ib_conn_path_shutdown", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97492", " - wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not", " needed", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97502", " - mmc: davinci: avoid NULL deref of host->data in IRQ handler", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97506", " - crypto: ixp4xx - fix buffer chain unwind on allocation failure", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97507", " - media: dm1105: fix missing error check for dma_alloc_coherent", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97508", " - thunderbolt: Set tb->root_switch to NULL when domain is stopped", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97510", " - thunderbolt: Release request if tb_cfg_request() fails in", " __tb_xdomain_response()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726)", " - alpha: fix ieee_swcr_to_fpcr setting FPCR_DNOD unconditionally", " - alpha: don't leak hardware-fabricated FP exception bits to user space", " - include/linux/list.h: mark list_add and __list_add as __always_inline", " - tools/compiler: match glibc 2.42 definition of __attribute_const__", " - x86/insn-eval: Move assign_register() out of KVM as insn_assign_reg()", " - powerpc/powermac: fix OF node refcount", " - staging: greybus: hid: fix SET_REPORT return value", " - usb: dwc2: gadget: Exit partial power down state when changing USB pull-", " up", " - USB: phy: fsl-usb: fix missing static keywords", " - usb: gadget: snps_udc_plat: clean up PHY on probe deferral", " - NFSD: Encode only the status in NFS-ACL v2 GETACL error replies", " - NFSD: Fix off-by-one in DRC bucket pruning limit", " - nfsd: return NFS4ERR_NOTSUPP for unsupported netloc4 types", " - nfsd: add filehandle match check to nfsd4_delegreturn()", " - nfsd: fix version mismatch loops in nfsd_acl_init_request()", " - nfsd: reject reclaim LOCK after RECLAIM_COMPLETE", " - eCryptfs: bound the packet-length peek to the user buffer", " - ecryptfs: fix tag 11 packet exact-fit size check", " - ecryptfs: show filename encryption options", " - fat: restore original value when fat_ent_write failed", " - fbdev: pvr2fb: correct user pointer annotation and sentinel initializer", " - fpga: stratix10-soc: Fix SVC mailbox handling during reconfiguration", " - alpha/PCI: Fix I/O port accessor argument order in pci_legacy_write()", " - alpha: marvel: Fix irq_set_status_flags to use correct IRQ number", " - alpha: marvel: Fix lock ordering in init_io7_irqs()", " - Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU", " - Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU", " - cpufreq: schedutil: Fix rate limit overflow", " - Bluetooth: hci_bcm: fix usage_count leak when autosuspend_delay is", " negative", " - Bluetooth: hci_uart: Fix false success return in hci_uart_setup()", " - Bluetooth: hci_event: clear HCI_LE_ADV only on a created connection", " - Bluetooth: hci_h5: fix usage_count leak when autosuspend_delay is", " negative", " - Bluetooth: hci_intel: fix usage_count leak when autosuspend_delay is", " negative", " - SUNRPC: Guard svcauth_gss_release() dispatch on rq_auth_stat", " - staging: media: tegra-video: vi: fix probe failure on skipped last port", " - rpmsg: glink: smem: order FIFO read after availability check", " - regulator: max8998_pmic_dt_parse_pdata: of_node_put on reg_np after", " ownership transferred to rdata", " - ocfs2: cluster: avoid lock order inversion in o2hb_region_pin() from", " drop_item", " - ocfs2: cluster: fix o2hb_dependent_users leak on pin failure", " - hwmon: (max6621) fix negative temperature offset and crit readings", " - hwmon: (max6621) fix temperature clamp range", " - nvme: nvme-fc: Fix nvme_fc_create_hw_io_queues() queue deletion in error", " path", " - sctp: distinguish sequence zero from wildcard in reconf lookup", " - PCI: Fix 32-bit config write in Intel PCH Root Port MPC ACS quirk", " - PCI: meson: Fix GPIO state while requesting PERST#", " - PCI/sysfs: Avoid spurious runtime PM wakeup on config space accesses", " - PCI/proc: Avoid spurious runtime PM wakeup on config space accesses", " - iommu/vt-d: Fix no_iommu to disable platform opt-in", " - net: usb: qmi_wwan: add Telit Cinterion FE990D50 composition", " - net: openvswitch: fix nf_connlabels leak in ovs_ct_init", " - NTB: ntb_transport: Recycle TX entries before client callbacks", " - net: ntb_netdev: Avoid double-accounting netif_rx() drops", " - net: ntb_netdev: Count packets dropped on RX refill failure", " - PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip", " - arch_numa: avoid false positive fortify warning in", " setup_node_to_cpumask_map()", " - dm-switch: use WRITE_ONCE() in switch_region_table_write()", " - wifi: rtl818x: initialize eeprom_93cx6 struct to zero", " - taskstats: fix cpumask parsing cutting off the last character", " - timer: Keep debugobjects state consistent in migrate_timer_list()", " - udf: Fix i_lenExtents truncation on 32-bit kernels", " - platform/chrome: sensorhub: Fix dropped timestamp events and log spam", " - net: openvswitch: fix kernel-doc warnings in internal headers", " - selinux: avoid implicit conversions in services code", " - ALSA: seq: Fix port lock leak in deliver_to_subscribers()", " - net: ntb_netdev: Fix TX busy and drop handling", " - tracing/mmiotrace: Remove reference to unused per CPU data pointer", " - clk: qcom: gcc-mdm9607: Increase delay for USB PHY reset", " - usb: f_mass_storage: Bump local buffer size in fsg_common_create_luns()", " - thermal/drivers/imx: Disable clock on runtime resume failure", " - thermal/drivers/qoriq: Disable clock on resume failure", " - dmaengine: dw-edma: Complete descriptors before pausing", " - block: flag zoned disks with GENHD_FL_NO_PART", " - ata: ahci: work around lost interrupts on Marvell 88SE61xx", " - Input: aiptek - validate raw macro indices before updating state", " - Input: aiptek - switch to using dev_groups for driver-specific", " attributes", " - Revert \"irqchip/mbigen: Fix mbigen node address layout\"", " - parisc: Fix alignment of asm statements in head.S", " - batman-adv: bla: prevent CRC corruptions after claim flush", " - clk: qcom: gcc-msm8916: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: qcom: gcc-msm8939: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: qcom: gcc-mdm9607: Drop incorrect apss_tcu_clk_src", " - clk: qcom: gcc-mdm9607: Drop incorrect system_noc_bfdcd_clk_src", " - clk: qcom: gcc-mdm9607: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: qcom: gcc-mdm9607: Fix halt_reg for gcc_apss_axi_clk", " - clk: qcom: gcc-mdm9607: Drop incorrect BIMC PLL and related clocks", " - i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure", " - ASoC: fsl: mpc5200-i2s: Free DMA resources on probe failure", " - AsoC: intel: sst: fix PCI device reference leak on probe failure", " - ASoC: samsung: aries_audio_probe: double of_node_put due to direct", " assignment without of_node_get", " - iio: gyro: mpu3050: fix sign of raw angular velocity readings", " - iio: light: cm32181: return zero after writing calibscale", " - iio: light: gp2ap002: Disable regulators on resume failure", " - iio: srf04: fix pm_runtime handling on probe error path", " - iio: temperature: hid-sensor-temperature: switch to non-devm", " iio_device_register()", " - KVM: s390: Zero initialize irq in reinject_machine_check", " - KVM: s390: Restore sigset on error path", " - media: cec: meson: ao-cec-g12a: name the CEC core regmap to avoid", " debugfs clash", " - media: v4l2-ctrls: Allow unknown HDR10 white point and luminance", " - media: venus: fix payload size returned by parse_caps() and", " parse_alloc_mode()", " - media: venus: fix payload size calculation in parse_raw_formats()", " - media: vimc: fix pixel format lookup in enum_framesizes", " - scsi: qla2xxx: Fix Name Server logout detection on FWI2 adapters", " - scsi: qla2xxx: Check entry_status in qla24xx_modify_vp_config()", " - scsi: qla2xxx: Drop vport reference under lock in report ID acquisition", " - scsi: qla2xxx: Use coherent DMA buffer for D_Port diagnostics", " - f2fs: return symlink writeback errors", " - f2fs: reject overlapping move range after len expansion", " - f2fs: return writeback error from collapse range", " - f2fs: fix i_size when pinned fallocate partially fails", " - drm/bridge: dw-hdmi: fix i2c adapter leak on probe failure", " - drm/sun4i: fix refcount leak in sun4i_backend_init_sat()", " - drm/hibmc: Fix list of formats on the primary plane", " - drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value", " - drm/amdgpu: use AMDGPU_GPU_PAGE_SHIFT instead of PAGE_SHIFT", " - drm/nouveau: Use write-combined maps for coherent", " - mm/damon/core-kunit: check region count before testing in split_at()", " - mm/damon/vaddr: drop last same folio access check optimization", " - mm/damon/vaddr-kunit: check region count in three_regions test", " - mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of()", " - firmware: stratix10-svc: Add mutex in stratix10 memory management", " - drm/bridge: cdns-mhdp8546: Return an error pointer on allocation failure", " - Smack: fix W=1 build warnings", " - smack: simplify write handlers of sysfs entries", " - smack: deduplicate smackfs/{direct,mapped} file_operations", " - smack: restrict smackfs/{direct,mapped} values to 0-255", " - soc: samsung: exynos-pmu: fix of_node refcount leak in", " exynos_get_pmu_regmap()", " - media: cec-pin: Fix event FIFO ordering", " - clk: moxart: remove unused variables, fix refcount leak", " - clk: hisilicon: reset: Use devm_kzalloc to initialize", " hisi_reset_controller", " - ARM: imx: fix device_node refcount leak in imx_src_init()", " - ARM: imx: fix device_node refcount leaks in imx7_src_init()", " - clk: imx: scu: drop redundant init.ops variable assignment", " - perf/x86/intel/uncore: Keep PCI PMUs working when MMIO/MSR setup fails", " - media: keymaps: Remove obsolete RC_MAP_RC5_TV keymap define", " - media: keymaps: Remove obsolete RC_MAP_HAUPPAUGE_NEW keymap define", " - perf tests stat_bpf_counters: Fix usage of '==' to address shellcheck", " warning", " - perf test: raise limit to 20 percent for perf_stat_--bpf-counters_test", " - perf test bpf-counters: Add test for BPF event modifier", " - perf test stat_bpf_counter.sh: Stabilize the test results", " - perf test: Use sqrtloop workload to test bperf event", " - perf test: Fix perf stat --bpf-counters on hybrid machines", " - perf tests: Fix flakiness in BPF counters test on hybrid systems", " - bpftool: Update btf_dump__new() and perf_buffer__new_raw() calls", " - bpftool: Use libbpf_get_error() to check error", " - bpftool: Fix pretty print dump for maps without BTF loaded", " - tools/bpf/bpftool: Reset vmlinux BTF after map commands", " - bpftool: remove duplicate free_btf_vmlinux() definition", " - dmaengine: mediatek: mtk-uart-apdma: Return -ENOMEM on memory allocation", " failure", " - dmaengine: hisilicon: Return -ENOMEM on dynamic memory allocation in", " probe", " - soundwire: qcom: Fix port exhaustion check in stream_alloc_ports", " - iio: orientation: hid-sensor-rotation: Avoid race between callback setup", " and device exposure", " - selftests/rseq: Replace glibc-specific __GNUC_PREREQ with portable check", " - crypto: atmel-ecc - replace min_t with min", " - crypto: atmel-ecc - clean up and improve ECDH comments", " - crypto: sa2ul - Use the defined variable to clean code", " - nvmet-rdma: avoid circular locking dependency on install_queue()", " - nvmet-rdma: use sbitmap to replace rsp free list", " - nvmet-rdma: factor out response resource cleanup", " - bus: ti-sysc: Fix /chosen node reference leak", " - PM: sleep: Fix off-by-one in wakelocks number limit check", " - staging: greybus: audio: correct sscanf() return value check", " - staging: sm750fb: gate dualview dataflow using g_dualview", " - staging: fbtft: Use sysfs_emit_at() to print to sysfs file", " - netdev: reshuffle netif_napi_add() APIs to allow dropping weight", " - staging: switch to netif_napi_add_weight()", " - staging: octeon: fix free_irq dev_id mismatch in cvm_oct_rx_shutdown", " - staging: octeon: ethernet-mem: replace pr_warn with dev_warn in free", " functions", " - staging: octeon: replace pr_warn with dev_warn in fill and rx paths", " - staging: rtl8723bs: fix mismatched free of HalData in", " rtw_sdio_if1_init()", " - ALSA: via82xx: Remove unreachable branch in snd_via686_pcm_pointer()", " - selftests/bpf: Fix memory leak in msg_alloc_iov error path", " - selftests/bpf: Fix memory leak in msg_alloc_iov", " - irqchip/gic-v3-its: Fix memleak in its_probe_one()", " - selftests: timers: leap-a-day: Fix -w option and update usage comment", " - clocksource: Unregister subsystem on device registration failure", " - y2038: uapi: Use 64-bit __kernel_old_timespec::tv_nsec on x32", " - timekeeping: Account for monotonicity adjustment in ntp_error", " - clk: qcom: gdsc: propagate gdsc_check_status() errors from", " gdsc_poll_status", " - clk: qcom: gdsc: propagate gdsc_enable() failure for ALWAYS_ON domains", " - clk: qcom: gdsc: enable optional power domain support", " - clk: qcom: gdsc: Release pm subdomains in reverse add order", " - clk: qcom: gdsc: Capture pm_genpd_add_subdomain result code", " - efi: fix stale reference to efi_recover_from_page_fault()", " - iommu/mediatek-v1: Fix off-by-one in MT2701_LARB_NR_MAX", " - iommu/msm: Return -ENOMEM on memory allocation failure in probe", " - iommu/amd: Prevent SB IOAPIC from overriding IVRS validation errors", " - iommu/amd: Add support for Hygon family 18h model 4h IOAPIC", " - iommu/amd: Fix false positive in SB IOAPIC IVRS validation", " - leds: pca9532: Fix inverted GPIO output polarity", " - hwspinlock: propagate errno when registering single lock", " - usb: mtu3: allow system suspend during active gadget connection", " - usb: renesas_usbhs: Fix power-off ordering on unbind", " - drm/panel: samsung-s6d16d0: Power off on prepare failure", " - iio: accel: dmard09: Implement IIO_CHAN_INFO_SCALE", " - RDMA/core: Avoid flush_workqueue(system_unbound_wq) usage", " - RDMA/mlx4: Avoid flush_scheduled_work() usage", " - RDMA/mlx: Calling qp event handler in workqueue context", " - hwrng: ks-sa - access private data via struct hwrng", " - hwrng: ks-sa - Fix runtime PM cleanup on registration failure", " - ALSA: hpi: Check transport errors during HPI6000 adapter initialization", " - pmdomain: bcm: bcm2835: handle genpd provider registration errors", " - misc: rtsx_usb: avoid USB I/O in runtime autosuspend", " - RDMA/hfi1: Remove redundant PCI device ID validation", " - RDMA/hfi1: Create workqueues before device initialization", " - RDMA/hfi1: Stop flushing the global IB workqueue", " - RDMA/hfi1: Initialize debugfs after probe completes", " - fs/isofs: replace kmap() with kmap_local_page()", " - rpmsg: glink: Remove the rpmsg dev in close_ack", " - rpmsg: glink: remove duplicate code for rpmsg device remove", " - libnvdimm/labels: Bound the on-media label size before the shift", " - cpufreq: spear: Fix an IS_ERR() vs NULL bug in spear1340_set_cpu_rate()", " - irqdomain: Introduce irq_domain_free()", " - irqdomain: Introduce irq_domain_instantiate()", " - irqdomain: Handle additional domain flags in irq_domain_instantiate()", " - genirq/generic_chip: Introduce irq_domain_{alloc,remove}_generic_chips()", " - cpufreq: intel_pstate: Fix setting minimum P-state at init time", " - cpufreq: schedutil: Fix self-contradictory comment in", " sugov_iowait_apply()", " - remoteproc: qcom: Fix glink->node reference leak in", " qcom_add_glink_subdev", " - arm64: dts: qcom: sm8250: Use QMP property to control load state", " - arm64: dts: qcom: sm8250: remove mmcx regulator", " - arm64: dts: qcom: sm8250: Add camcc DT node", " - gpu: host1x: Fix offset calculation in trace_write_gather", " - crypto: sl3516 - drop invalid sg_dma_len checks before DMA mapping", " - ACPI: move from strlcpy() with unused retval to strscpy()", " - ACPI: processor: idle: Expand _LPI package sanity checks", " - tty: hvc: restrict HVC_DCC to ARMv6+ and ARM64", " - accessibility: speakup: Fix incorrect string length computation in", " report_char_chartab_status()", " - misc: rtsx: add missing write register handling", " - misc: ad525x_dpot: Make ad_dpot_remove() return void", " - ppdev: prevent overflow when setting port timeout", " - char: xilinx_hwicap: unregister class on init errors", " - perf ui hists: Fix uninitialized stack memory free on pstack allocation", " failure", " - driver core: soc: remove layering violation for the soc_bus", " - driver core: soc: Unregister bus on early device registration failure", " - dmaengine: dw-edma: Clear stale requests on termination", " - arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for", " PCIe", " - RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters", " - RDMA/srpt: Pass the mapped task attribute to target_init_cmd()", " - RDMA/nldev: Split nldev_stat_set_mode_doit out of nldev_stat_set_doit", " - RDMA/restrack: Fix typos in the comments", " - RDMA/core: Add driver APIs pre_destroy_cq() and post_destroy_cq()", " - iommu/arm-smmu: Add missing pm_runtime_disable() in", " qcom_iommu_device_probe", " - iommu/qcom: Remove sysfs device on probe failure path", " - iommu/qcom: Fix inverted fault report check in qcom_iommu_fault()", " - thermal: int340x_thermal: Consolidate priv->data_vault checks", " - wifi: ath11k: Correctly copy the hint BSSID in WMI scan request", " - ath11k: add trace log support", " - ARM: dts: allwinner: a10: Fix PMU interrupt", " - perf cs-etm: Flush thread stacks after decoder reset", " - perf cs-etm: Avoid truncating AUX buffer sizes to int", " - leds: pca9532: Fix phantom device registration on missing hardware", " - drm/tve200: add OF module alias for autoloading", " - netfilter: nf_nat_sip: rewind offset when NAT shrinks the packet", " - arm64: dts: rockchip: Add gru-scarlet-dumo board", " - arm64: dts: rockchip: Fix PCI node addresses on rk3399-gru", " - arm64: dts: rockchip: Fix Gru WLAN sideband interrupt", " - ARM: lpc32xx: only run SoC init on LPC32xx hardware", " - power: supply: sbs-battery: Use a per-device serial number buffer", " - crypto: keembay - publish OF module alias for OCS AES/SM4", " - w1: ds2482: Fix signedness bug in ds2482_w1_triplet()", " - remoteproc: Use unbounded workqueue for recovery work", " - remoteproc: core: Attach rproc asynchronously in rproc_add() path via", " schedule_work()", " - staging: rtl8723bs: use kfree_sensitive() for key material", " - arm64: dts: allwinner: sun50i-a64-pinephone: Fix mpu6050 mount matrix", " - clk: tegra: tegra124-emc: put EMC node on register failure", " - clk: palmas: Manage external-control prepare with devm", " - clk/x86: pmc_atom: add kasprintf return value check", " - scsi: core: Register sysfs attributes earlier", " - scsi: smartpqi: Fix AIO retry marker cleared by SCSI core between", " dispatches.", " - RDMA/mlx5: Send cong param changes to the resolved port mdev", " - bus: mhi: host: Flush the posted write after writing to", " MHI_SOC_RESET_REQ_OFFSET", " - selftests/zram: fix kernel_gte() for POSIX sh", " - power: supply: sc2731_charger: Convert to platform remove callback", " returning void", " - clk: qcom: Return expected ENOMEM error on dynamic allocation failure", " - misc: vmc_vmci: Fix potential memory leak in vmci_event_subscribe()", " - fanotify: report full event length for FIONREAD", " - wifi: mt76: mt7915: use little-endian for bss_info_ra wire fields", " - perf: arm_spe: Make wakeup range check overflow safe", " - perf machine: Guard against NULL strlist in machines__findnew()", " - perf machine: Use snprintf() for guestmount path construction", " - perf machine: Check snprintf truncation in machines__findnew()", " - perf machine: Don't abort guest map creation on first inaccessible dir", " - perf machine: Reset errno before strtol in guest kernel map creation", " - perf machine: Free scandir entries in guest kernel map creation", " - perf machine: Check snprintf truncation for guest kallsyms path", " - iommu/arm-smmu-v3: Convert to use atomic poll timeout", " - wifi: mac80211: send TWT teardown to peer after setup TX failure", " - wifi: zd1211rw: reject secondary interfaces to prevent conflicts", " - wifi: mac80211: skip unused probe response countdown offsets", " - firmware: google: Add bounds checks in coreboot_table_populate()", " - powerpc/smp: add NULL guard for cause_ipi in smp_muxed_ipi_message_pass", " - MIPS: ptrace: Fix syscall skipping via PTRACE_SYSCALL", " - serial: amba-pl011: unprepare console clock on unregister", " - HID: split apart hid_device_probe to make logic more apparent", " - HID: ensure timely release of driver-allocated resources", " - HID: i2c-hid: Switch i2c_hid_parse() to goto style error handling", " - HID: i2c-hid: Fix \"(null)\" output when reading report descriptor fails", " - HID: lg4ff: validate report length before fixed offsets", " - perf thread-stack: Fix heap buffer overflow on branch stack wrap copy", " - perf auxtrace: Fix queue grow overflow and old array leak", " - perf intel-pt: Fix off-by-one in auxtrace_info minimum size check", " - perf intel-bts: Fix off-by-one in auxtrace_info minimum size check", " - iio: light: tsl2772: fix ALS calibscale readback", " - iio: light: isl29028: return zero in write_raw() on success", " - iio: light: tsl2583: return zero in write_raw() on success", " - block/blk-stat: drain per-cpu callback stats over possible CPUs", " - block/blk-iocost: collect per-cpu latency stats over possible CPUs", " - block/kyber-iosched: flush per-cpu latency buckets over possible CPUs", " - lib/string: fix memchr_inv() for large ranges", " - pps: don't try to wait for negative timeouts in PPS_FETCH", " - pps: clients: gpio: Bypass edge's direction check when not needed", " - pps: pps-gpio: split IRQ handler into hardirq timestamper + threaded", " handler", " - pps-gpio: remove dead capture_clear code", " - PCI/sysfs: Add static PCI resource attribute macros", " - remoteproc: Move resource table data structure to its own header", " - remoteproc: use rsc_table_for_each_entry() in rproc_handle_resources()", " - scripts/tags.sh: improve compiled sources generation", " - scripts/tags.sh: Prevent binary files appearing in cscope.files", " - ocfs2: use bitmap API in fill_node_map", " - drm/sun4i: vi scaler: Fix coefficient selection", " - of: property: add missing kerneldoc for of_graph_get_endpoint_count()", " - of: property: use unsigned int return on of_graph_get_endpoint_count()", " - bitfield: Add less-checking __FIELD_{GET,PREP}()", " - bitfield: Add non-constant field_{prep,get}() helpers", " - drm/sun4i: tcon: Drop remote endpoint reference", " - drm/sun4i: dw-hdmi: Drop TCON TOP port reference", " - drm/sun4i: hdmi-phy: Fix H6 8-bit MPLL config at 594 MHz", " - RDMA/siw: Introduce siw_free_cm_id", " - mfd: rave-sp: validate received frame payload lengths", " - mfd: iqs62x: Reject zero-length firmware records", " - drm/amdgpu/gfx6: Fixup emit_cntxcntl()", " - ext4: fix spurious message about orphan cleanup on RO fs", " - phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table", " - perf trace-event: Fix buffer overflow in read_string()", " - drm/amdgpu/gfx6: Fixup emitting SWITCH_BUFFER packets", " - firmware_loader: Check fw_state_is_done in loading_store", " - pinctrl: rockchip: Reset the pin count when recalculating SoC data", " - soc: fsl: qe: check platform_driver_register() in qe_ic_of_init()", " - coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()", " - coresight: etm4x: Cleanup TRCIDR2 register accesses", " - coresight: etm4x: Cleanup TRCIDR3 register accesses", " - coresight: etm4x: Cleanup TRCIDR4 register accesses", " - coresight: etm4x: Cleanup TRCIDR5 register accesses", " - coresight: Change syncfreq to be a u8", " - regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handling", " - sched/fair: Check CPU capacity before comparing group types during load", " balance", " - Bluetooth: btusb: Fix BD_ADDR byte order in btusb_set_bdaddr_wcn6855()", " - perf trace-event: Fix integer truncation in do_read() and skip()", " - scsi: sd: Fix sd_done() sense handling condition", " - iio: light: gp2ap002: re-enable irq if runtime suspend fails", " - flow_offload: rename offload functions with offload instead of flow", " - arm64: dts: turris-mox: fix usb3 phys", " - ARM: dts: helios4: add vcc-supply to EEPROM", " - ARM: dts: helios4: add vcc-supply to GPIO expander", " - ARM: dts: helios4: add SATA regulator supplies", " - perf stat: Clear screen only if output file is a tty", " - perf stat: Fix evsel_list leak in cmd_stat", " - perf synthetic-events: Fix uninitialized pthread_join", " - perf synthetic-events: Fix divide by zero in", " perf_event__synthesize_threads", " - iommu/vt-d: Fix UCTP context table slot when copying root entries", " - m68k: Fix backtraces for non-running tasks", " - powerpc/configs: enable CONFIG_RAS to fix EDAC support", " - spi: sprd-adi: Fix probe succeeding without registering the controller", " - nfc: digital: Do not dump a NULL response in command completion", " - dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal", " - ASoC: pxa: Use devm_clk_get_optional() for extclk clock", " - ASoC: fsl-asoc-card: defer probe when the CPU DAI device is not ready", " - ubi: Fix repeated words in comments", " - ubi: fastmap: Use the bitmap API to allocate bitmaps", " - ubi: fastmap: Fix missed ec updating after erasing old fastmap data", " block", " - ubi: fastmap: erase_block: Get erase counter from wl_entry rather than", " flash", " - ubi: fastmap: Allocate memory with GFP_NOFS in ubi_update_fastmap", " - ubi: Replace erase_block() with sync_erase()", " - UBI: Preserve torture flag when rescheduling failed erasures", " - UBI: fastmap: Pass to_be_tortured when reusing old fastmap PEBs", " - ubi: fastmap: Add fastmap control support for 'UBI_IOCATT' ioctl", " - ubi: fastmap: Add fastmap control support for module parameter", " - ubi: Simplify bool conversion", " - ubi: fastmap: Wait until there are enough free PEBs before filling pools", " - ubi: fastmap: Fix lapsed wear leveling for first 64 PEBs", " - ubi: fastmap: Add module parameter to control reserving filling pool", " PEBs", " - UBI: fix two issues in the ubi.mtd MODULE_PARM_DESC", " - selfetests/bpf: Update vmtest.sh defaults", " - selfetests/bpf: Adapt vmtest.sh to s390 libbpf CI changes", " - bpf/docs: Update list of architectures supported.", " - selftests/bpf: Fix vmtest.sh getopts optstring", " - selftests/bpf: Limit URLS parsing logic to actual scope in vmtest", " - selftests/bpf: Support local rootfs image for vmtest", " - selftests/bpf: Add description for running vmtest on RV64", " - selftests/bpf: vmtest.sh: Preserve command quoting when running in the", " VM", " - spi: img-spfi: don't disable runtime PM on DMA deferred probe", " - power: supply: bd99954: Drop bad register fields", " - power: supply: bq27xxx: bq27520g4: fix REG_TTES address", " - power: supply: bq27xxx: bq28z610: fix invalid AverageEnergy address", " - power: supply: bq27xxx: bq27z561: fix invalid AverageEnergy address", " - xenbus: Unregister reboot notifier on init failure", " - clocksource/drivers/clps711x: Do not unmap clocksource MMIO", " - clocksource/drivers/armada: Unwind timer clock on init failure", " - x86/pkeys: Fix pkey_alloc() return value when pkeys are not supported", " - bpftool: Fix double close in map dump", " - tracing: Remove \"__attribute__()\" from the type field of event format", " - tracing: Have trace_event_update_all() only handle module that is", " loading", " - bpf: Fix pending_pos walk on 32-bit ring position wrap", " - crypto: hisilicon/sec2 - fix CCM algorithm long packet failure", " - perf dso: Guard close() against invalid fd in", " dso__decompress_kmodule_path()", " - perf dso: Guard against cache underflow on short reads in", " dso_cache__memcpy()", " - mailbox: rockchip: disable pclk on probe failure and unbind", " - hwmon: (emc1403) Add support for EMC1442", " - smb/server: preserve error status in smb2_handle_negotiate()", " - nfs: replace atomic bitops sequence with clear_and_wake_up_bit helper", " - nfs: refactor pNFS functions using clear_and_wake_up_bit", " - pppox: drain queued packets on channel handoff", " - hsr: Use a single struct for self_node.", " - net: hsr: Use full string description when opening HSR network device", " - net: bridge: vlan: fix inverted default vlan notification", " - ALSA: hda: Fix connection list comparison in proc output", " - 8139cp: fix Rx and Tx not being disabled in cp_suspend", " - platform/x86: dell-wmi-sysman: Fix instance ID bounds", " - vsock: use sock_error() to consume sk_err after a failed connect", " - bonding: initialize err for empty target lists", " - i3c: mipi-i3c-hci: Fix DAT/DCT entry sizes", " - i3c: mipi-i3c-hci: Fix number of DAT/DCT entries for HCI versions < 1.1", " - i3c: mipi-i3c-hci: Quieten initialization messages", " - i3c: mipi-i3c-hci: Switch PIO data allocation to devm_kzalloc()", " - i3c: mipi-i3c-hci: Refactor PIO register initialization", " - i3c: mipi-i3c-hci: Fix missing STAT_IBI_STATUS_THLD in PIO mode", " - virtio_balloon: disable indirect descriptors", " - prctl: fix PR_SET_MM_AUXV losing the forced AT_NULL terminator", " - ALSA: control: Use automatic cleanup of kfree()", " - RDMA/ucma: Allow path records to exactly fit the output buffer", " - net: thunderbolt: Count delivered packets in rx_packets and rx_bytes", " - forcedeth: stop the tx_timeout register dump past the requested window", " - net: ipa: report when the driver has been removed", " - net: ipa: Convert to platform remove callback returning void", " - net: ipa: balance runtime PM reference on remove error", " - nfs: move the nfs4_data_server_cache into struct nfs_net", " - scsi: qla2xxx: Fix an loop timeout test", " - Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX", " - octeontx2-af: Fix TL3/TL2 link config ENA clearing", " - cifs: fix clearing stats for fastest execution of each smb2 command", " - net: ip6_gre: Remove the unused function ip6gre_tnl_addr_conflict()", " - net_sched: sch_fq: struct sched_data reorg", " - net_sched: sch_fq: change how @inactive is tracked", " - net_sched: export pfifo_fast prio2band[]", " - net/sched: sch_codel: clamp default mtu to avoid disabling CoDel", " - tpm: st33zp24: Validate locality read result", " - apparmor: Replace sprintf/strcpy with scnprintf/strscpy in", " aa_policy_init", " - net: ethernet: sun4i-emac: Fix IRQ error handling", " - net: stmmac: selftests: Pass the IP proto mask in the TC selftest", " - netfilter: xt_cgroup: Make it independent from net_cls", " - netfilter: xt_HL: add pr_fmt and checkentry validation", " - netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited()", " - selftests: arm64: add hugetlb mte tests", " - selftests/arm64: Print missing MTE TAP headers", " - selftests/arm64: Treat KSM merge_across_nodes as optional", " - net: stmmac: selftests: Check multiple MMC counters", " - net: stmmac: dwmac1000: Account for the primary MAC address for UC", " filtering", " - net: stmmac: dwmac4: Account for the primary MAC address for UC", " filtering", " - net: stmmac: dwxgmac: Account for the primary MAC address for UC", " filtering", " - net: stmmac: selftests: Account for the UC filter list for filtering", " tests", " - nvme: target: rdma: fix ndev refcount leak on queue connect", " - clk: qcom: Drop mmcx gdsc supply for dispcc and videocc", " - RDMA/nldev: Check stat attribute before accessing it", " - HID: fix an error code in hid_check_device_match()", " - ALSA: control: Fix unannotated kfree() cleanup", " - Bluetooth: L2CAP: Fix send LE flow credits in ACL link", " - kselftest/arm64: mte: Skip the hugetlb tests if MTE not supported on", " such mappings", " - kselftest/arm64: mte: Use the correct naming for tag check modes in", " check_hugetlb_options.c", " - nvmet-rdma: fix queue leak when connect backlog is exceeded", " - clk: qcom: gdsc: Bump parent usage count when GDSC is found enabled", " - Linux 5.15.221", " - SAUCE: Revert \"bpftool: Update btf_dump__new() and", " perf_buffer__new_raw() calls\"", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90053", " - net/sched: sch_htb: limit htb_classify inner-class filter hops", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90054", " - tcp: fix corruption of urgent data on multi-segment retransmit", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90055", " - usb: atm: usbatm: fix invalid ci_range initialization", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90056", " - net: fec: only stop PTP if it was initialized", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90058", " - net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90062", " - netfilter: nf_tables: move hardware offload step after building the", " chain blob", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90063", " - virtio-net: Ensure that TCP packets don't overflow gso_segs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90067", " - libceph: validate banner payload length", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90068", " - ASoC: dapm: Fix off-by-one check on the second enum channel", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93245", " - apparmor: policy_int make sure list heads are initialized before fail", " path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90070", " - tpm: st33zp24: Return zero on status read failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90071", " - net/sched: sch_teql: restore skb->dev on the slave failure path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90072", " - net/sched: sfq: clamp quantum to avoid signed overflow soft lockup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90073", " - net/sched: hhf: clamp quantum before hhf_change() to avoid overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90074", " - net/sched: fq_pie: clamp default quantum to avoid signed overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90075", " - net/sched: fq_codel: clamp default quantum and mtu", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90078", " - net/sched: act_skbmod: fix length calculations and avoid invalid header", " warnings", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90081", " - net/rds: use wq_has_sleeper() in rds_cong_map_updated()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89780", " - net: qualcomm: rmnet: restore skb->dev on deaggregated frames", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89789", " - gtp: add synchronize_net() in gtp_newlink() error path to prevent use-", " after-free", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90088", " - Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite", " loop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90102", " - NFSv4/pnfs: key the data server cache on the NFS version", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90103", " - NFSv4.2: fix LAYOUTSTATS send buffer exhaustion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90107", " - net/smc: free pending qentry in smc_llc_flow_stop() before memset", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90114", " - net: bridge: Reject descending VLAN tunnel ranges", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90126", " - rtc: pcf8563: fix clock provider leak on unbind", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90128", " - vdpa/mlx5: fix wrong list iterated in add_direct_chain error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89779", " - fs/ntfs3: validate ef->size covers the record's name and value", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89781", " - fs/ntfs3: fix out-of-bounds read in read_log_rec_buf()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90140", " - cuse: wait for pending RCU callbacks on module exit", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90141", " - ipvs: fix integer overflow in ftp helper port/address parsing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90143", " - net: kcm: Hold RCU read lock while running BPF parser", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90151", " - NFSv4: remove callback IDR entry on client allocation failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90157", " - bpf: Reject negative optlen in cgroup getsockopt hook", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90160", " - lwt_bpf: Restore reserved headroom after xmit program", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90198", " - ALSA: core: Fix use-after-free in snd_card_do_free()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90202", " - scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90203", " - Squashfs: check block offset is not negative", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93252", " - ocfs2: fix circular locking dependency in ocfs2_init_acl()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90209", " - s390/debug: Fix deadlock during unregister", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90214", " - ASoC: xilinx: formatter_pcm: fix stream_data leak on open error", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90216", " - ubi: Fix rollback for explicit UBI device numbers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90218", " - RDMA/cma: Fix WARNING in res_to_rt", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90219", " - RDMA/cxgb4: Free debugfs on registration failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90221", " - nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90222", " - nfc: pn533: hold a reference to the request skb during send_frame", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90223", " - nfc: llcp: bound SNL TLV parsing to the skb and add length checks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90224", " - nfc: nci: fix double completion race in nci_data_exchange_complete", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90225", " - nfc: llcp: read llcp_sock->local under the socket lock in getsockopt", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90226", " - nfc: llcp: avoid userspace overflow on invalid optlen", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90228", " - nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89784", " - SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90245", " - fbdev: kyro: Validate overlay viewport coordinates", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90248", " - net/sched: cls_api: fix teardown of an adopted proto on insert-race loss", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90249", " - iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90251", " - Bluetooth: MSFT: validate evt_prefix_len against the response length", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90257", " - Bluetooth: virtio_bt: avoid OOB read of build info string", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90274", " - coresight: etm4x: fix underflow for usage of (nrseqstate - 1)", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90281", " - phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime", " suspend", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90283", " - hugetlbfs: release subpool on fill_super failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90284", " - firmware_loader: do not queue completed sysfs fallback requests", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90285", " - scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90286", " - drm/amdgpu/gfx6: Use PFP on the compute queues too", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90290", " - arm64: hibernate: Restore DAIF state on error", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93256", " - arm64: hibernate: mask DAIF before restoring hibernated kernel", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90292", " - RDMA/siw: Fix use-after-free in siw_accept()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90293", " - IB/isert: post the full-feature receive buffers after session", " registration", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90294", " - IB/isert: delay the final Login Response until the session is registered", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90295", " - cpufreq: imx6q: fix out-of-bounds write when probed more than once", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90296", " - cpufreq: imx6q: fix devres accumulation across driver rebind", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90297", " - drm/sun4i: crtc: Propagate layer initialization error", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90298", " - drm/sun4i: tcon: Drop TCON TOP device reference", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90302", " - ocfs2: synchronize heartbeat callbacks with o2net teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90303", " - ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user", " faults", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90307", " - RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90314", " - remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90316", " - drm/omap: dsi: Do not copy isr table", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90318", " - fat: release buffer head after rebuilding parent", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90319", " - rapidio: clear mport->net when rio_add_net() fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90327", " - phonet: pep: do not write beyond optlen in getsockopt", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90329", " - HID: synchronize input before cleaning up a failed probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90334", " - tty: clear cdev pointer after cdev_add() failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90341", " - firmware: coreboot: Validate table bounds", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90348", " - wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90360", " - regulator: core: use system_freezable_wq for init complete work", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90361", " - wifi: ath11k: fix leak in ath11k_service_ready_ext_event()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90362", " - drm/msm/dsi: Drop dev_pm_opp_set_rate(0)", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90372", " - wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90378", " - wifi: mt76: mt792x: Fix memory leak in SDIO TX path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90382", " - wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93261", " - locking/lockdep: Fix NULL pointer dereference in __lock_set_class()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93283", " - i3c: master: Fix device_register() error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90386", " - i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90388", " - iommu/dma: Check atomic pool allocation result directly", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90391", " - lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90393", " - bpf: Fix potential UAF in bpf_netns_link_update_prog", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90394", " - power: supply: sc2731_charger: cancel work on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90395", " - power: supply: isp1704_charger: cancel work on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93262", " - md/raid5-ppl: fix use-after-free in ppl_do_flush()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90403", " - wifi: rtlwifi: pci: fix error path in rtl_pci_probe()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90411", " - nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90413", " - IB/isert: reject login PDUs declaring more data than was received", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90414", " - IB/isert: reject PDUs declaring more data than was received", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90415", " - RDMA/cxgb4: free STAG index when TPT entry write fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90416", " - RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90419", " - nilfs2: prevent out-of-bounds read in super root block parsing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90420", " - nilfs2: fix infinite loop in nilfs_clean_segments()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93264", " - RDMA/efa: Fix PBL chunk length computation", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89782", " - fs/ntfs3: reject restart table growth beyond U16_MAX entries", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90431", " - remoteproc: Prevent crash handling to race with rproc_del()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90434", " - isofs: release zisofs block pointer buffer head", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90435", " - RDMA/mlx5: Fix integer overflow of user QP buffer size", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92476", " - crypto: keembay - Initialize completion before requesting IRQ", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89785", " - fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89787", " - ext4: check dir entry fits before reading the hash trailer in", " ext4_search_dir()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92494", " - ext4: fix buffer_head leak in ext4_init_orphan_info", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92496", " - wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92498", " - wifi: ath6kl: avoid buffer overreads in WMI event handlers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92501", " - ext4: drain in-flight DIO before buffered write fallback", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92504", " - thermal: intel: int3400: clean up ODVP on probe failures", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92508", " - RDMA/core: Fix potential use after free in ib_free_cq()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93268", " - ext4: skip extra isize expansion during mount to prevent deadlock", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89786", " - ext4: fix out-of-bounds read in ext4_read_inline_dir()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92521", " - ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92522", " - ACPI: processor: validate MADT IOAPIC entry bounds", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92524", " - irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93037", " - RDMA/hfi1: Propagate sdma_txinit_ahg() errors", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93039", " - ASoC: meson: Keep link pointers valid on realloc failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93040", " - dmaengine: dw-edma: Serialize channel state checks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93041", " - dmaengine: dw-edma: Serialize abort state updates", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93046", " - software node: Fix software_node_get_reference_args() with index -1", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93048", " - mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93049", " - mtd: mtdswap: Avoid freeing registered blktrans device twice", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89777", " - vfio/pci: clear vdev->msi_perm after freeing it on init failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93051", " - misc: ad525x_dpot: use driver core groups for sysfs files", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93052", " - misc: bcm-vk: Use acquire/release for msgq_inited", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93053", " - speakup: keyhelp: guard letter_offsets possible out-of-range indexing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93054", " - uio: Fix stale info pointer in failed registration path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93055", " - UDF symlink pathComponent header OOB read", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93056", " - usb: gadget: f_uac1_legacy: remove broken string configfs attributes", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93061", " - gpu: host1x: Avoid stack over-read in debug output helpers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93067", " - drm/bridge: tc358767: clamp the reported AUX read size to the request", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93271", " - wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93095", " - hfsplus: validate thread record before delete key rebuild", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93098", " - rpmsg: glink: fix deadlock in endpoint destroy during driver detach", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89778", " - isofs: fix out-of-bounds page array access on empty zisofs block", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93102", " - RDMA/hfi1: Free RX data on late probe failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93103", " - RDMA/hfi1: Preserve unit 0 on allocation failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89783", " - xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is", " full", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93108", " - RDMA/ipoib: Drain RCU callbacks during module teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93109", " - RDMA/mlx5: Drain RCU callbacks during module teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93110", " - RDMA/core: Wait for RCU callbacks before unloading ib_core", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93114", " - platform/surface: acpi-notify: Check ACPI companion before use", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93115", " - platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93120", " - usb: gadget: configfs: fix out-of-bounds read of qw_sign", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93130", " - platform/x86: dell-wmi-base: Fix resource leak on module load failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93131", " - platform/x86: dell-privacy: Fix race condition", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93138", " - bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93140", " - udf: Mark LVID buffer as uptodate before marking it dirty", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93141", " - usb: gadget: r8a66597: avoid double free of ep0_req in probe error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93145", " - clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93278", " - staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93279", " - staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93280", " - greybus: audio: bound the topology section sizes against the fetched", " size", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93151", " - nvmet-rdma: fix response resource leak on queue teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93158", " - crypto: sa2ul - stop probe if context pool creation fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93159", " - crypto: atmel-sha204a - fix heap info leak on I2C transfer failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93160", " - crypto: atmel-ecc - reject hardware ECDH without a public key", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93161", " - crypto: qat - clear AES key schedule from stack", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93165", " - platform/chrome: sensorhub: Fix memory overread in ring handler", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93167", " - csky: Fix a4/a5 restoration in syscall trace path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93170", " - dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and", " MCDMA interrupt handlers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93177", " - drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93178", " - drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93274", " - pinctrl: bcm2835: Don't remove an unregistered GPIO chip", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93183", " - drm/lima: call drm_mm_init() with a valid allocation range", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93185", " - ASoC: rt700-sdw: always drain jack work on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93188", " - HID: roccat: bound device-supplied profile index", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93189", " - HID: core: quiesce input in hid_hw_stop() to prevent use-after-free", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93191", " - smack: fix incorrect task context in smack_msg_queue_msgrcv", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-40123", " - bpf: Enforce expected_attach_type for tailcall compatibility", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89947", " - clk: meson: align gxbb_32k_clk_sel number of parents with actual count", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80671", " - perf sched: Fix register_pid() overflow, strcpy, and BUG_ON", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93203", " - batman-adv: bla: avoid CRC corruption due to parallel claim add", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93204", " - batman-adv: dat: atomically update mac addresses", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-52944", " - ksmbd: fix FSCTL permission bypass by adding a permission check for", " FSCTL_SET_SPARSE", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-22039", " - ksmbd: fix overflow in dacloffset bounds check", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-21651", " - net: hns3: don't auto enable misc vector", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-53078", " - bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-43088", " - net: af_key: zero aligned sockaddr tail in PF_KEY exports", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-31420", " - bridge: mrp: reject zero test interval to avoid OOM panic", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-22103", " - net: fix NULL pointer dereference in l3mdev_l3_rcv", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-21649", " - net: hns3: fix kernel crash when 1588 is sent on HIP08 devices", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2023-52676", " - bpf: Guard stack limits against 32bit overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2024-50017", " - x86/mm/ident_map: Use gbpages only where full GB page should be mapped.", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-74268", " - tcp: clear sock_ops cb flags before force-closing a child socket", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90015", " - xhci: fix lost bounce buffers on TDs spanning several ring segments", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89816", " - drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93234", " - drm/gud: validate TV mode names before creating enum property", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89817", " - drm/gud: NUL-terminate TV mode names read from the device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89821", " - drm/amd/display: avoid divide-by-zero in __is_lut_linear()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89823", " - drm: fix race between partial drm_dev_register() failure and ioctl", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89843", " - scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89845", " - scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89846", " - scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89847", " - scsi: qla2xxx: Avoid double completion in async IOCB timeout", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93242", " - scsi: qla2xxx: Fix response queue over-consumption in", " __qla_consume_iocb()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89849", " - scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89850", " - scsi: qla2xxx: Don't query firmware state while chip is down", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89851", " - scsi: qla2xxx: Fix FCE trace enable parsing in debugfs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89852", " - scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89853", " - scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89854", " - scsi: qla2xxx: Fix cs84xx use-after-free on host teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89855", " - scsi: qla2xxx: Serialize flash version read in reset handler", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89856", " - scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89858", " - scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89861", " - scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89863", " - scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89864", " - scsi: qla2xxx: Bound i2c->length in I2C bsg handlers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89865", " - scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89871", " - media: video-i2c: fix kthread error pointer left in kthread_vid_cap on", " failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89872", " - media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89876", " - media: tda18250: fix possible integer overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89878", " - media: s2255: check firmware size before reading trailing marker", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89879", " - media: s2255: bound JPEG frame size before copying into the buffer", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89880", " - media: rtl2832_sdr: release URBs and stream buffers on start_streaming()", " failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89881", " - media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix", " DMA leak", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89883", " - media: rc: sunxi-cir: Unregister rc device on probe failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93236", " - media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89887", " - media: i2c: ov7740: fix use-after-destroy in remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89888", " - media: i2c: ov02a10: fix endpoint parsing use-after-free", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89890", " - media: go7007: defer the ALSA v4l2 put until card release", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89891", " - media: em28xx: fix use-after-free of dev_next->devlist on disconnect", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89892", " - media: em28xx: defer audio-only extension registration", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89893", " - media: cx23885: cancel NetUP CI work before teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89894", " - media: cx231xx: reject geometry changes while the VBI queue is busy", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89895", " - media: cobalt: Avoid freeing ALSA private data twice", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89896", " - media: cedrus: fix memory leak in cedrus_init_ctrls()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89897", " - media: cec: Serialize exclusive follower delivery", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89901", " - media: airspy: use vb2_video_unregister_device() on disconnect to fix", " NULL deref", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89923", " - KVM: s390: Free guest debug data on vcpu destroy", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89924", " - KVM: s390: Fix old_data leak in guest debug error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89925", " - KVM: s390: Fix memory leak in guest debug handling", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89926", " - KVM: s390: Fix length check __import_wp_info()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89927", " - KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89930", " - KVM: nVMX: Service local TLB flushes on failed nested VM-Enter", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89932", " - KVM: nVMX: Always flush vpid02 on first use", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89936", " - iio: dac: m62332: Fix regulator reference count imbalance", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89937", " - iio: chemical: sgp30: Handle IAQ thread creation failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89939", " - iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89945", " - ASoC: cs35l34: drain threaded IRQ before runtime suspend", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89946", " - ASoC: cs35l33: drain threaded IRQ before runtime suspend", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89948", " - batman-adv: bla: fix freeing of claims on meshif deletion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89949", " - batman-adv: dat: avoid unaligned fault in IP extraction", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89951", " - batman-adv: fix stale receive device on merged fragments", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89952", " - mtd: rawnand: validate ONFI extended parameter page sections", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89953", " - mtd: mtdoops: free page bitmap when the backing MTD is removed", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89954", " - mtd: afs: validate v2 image info bounds", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89964", " - parisc: eisa: Fix infinite loop when parsing invalid IRQ value", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89965", " - nvdimm/btt: reject an arena whose nfree is below the lane count", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89968", " - nvmet-tcp: reject unsolicited H2CData PDUs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89969", " - nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89973", " - nvme-tcp: check the data direction of a C2HData PDU", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89979", " - ALSA: pcm: Fix race between non-atomic ops and trigger-start", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89980", " - ALSA: harmony: initialize locks before requesting IRQ", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89982", " - i2c: mux: Fix channel node leak on adapter add failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89983", " - i2c: core: fix debugfs UAF on adapter removal", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89984", " - perf/x86/intel: Fix kernel address leakages in LBR stack", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89989", " - ima: Check for ERR_PTR from dentry_path() in validate_hash_algo()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89993", " - dmaengine: dw-edma: Initialize IRQ data before requesting IRQs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89997", " - dm: fix resume-vs-remove race", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89999", " - HID: wacom: validate report length in wacom_intuos_pro2_bt_irq", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90000", " - HID: rmi: fix OOB access with undersized RMI reports", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90007", " - scsi: pm8001: Use rollback index when freeing MSI-X vectors", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90011", " - scsi: target: iscsi: Reserve a terminator byte for the login payload", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90017", " - staging: rtl8723bs: fix OOB read in rtw_action_frame_parse()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90018", " - staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90019", " - usb: gadget: fix null pointer dereference in usb_put_function_instance()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90020", " - USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90025", " - usb: typec: ucsi: displayport: Fix OOB altmode array index", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90031", " - usb-storage: ene_ub6250: fix race between scan work and probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90032", " - media: usbtv: keep device alive while ALSA card exists", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90033", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90034", " - usb: image: mdc800: change kmalloc() to kzalloc()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-38097", " - espintcp: remove encap socket caching to avoid reference leak", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89515", " - scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80689", " - tracing/mmiotrace: Add NULL check for mmio_trace_array in logging", " functions", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80888", " - drm/vmwgfx: drop dma_buf reference on foreign-fd prime import", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80912", " - selinux: reject an unclaimed class value in security_get_classes()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89595", " - fsnotify: Fix stale object mask after concurrent mark updates", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89603", " - entry: Fix seccomp bypass after ptrace with TSYNC", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-74378", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89488", " - openvswitch: Fix CT limit teardown use-after-free", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90049", " - net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80977", " - net: skbuff: don't touch shared zerocopy state in skb_tx_error()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80928", " - smack: fix cred UAF in smack_file_send_sigiotask()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93222", " - signal: avoid shared siginfo namespace rewrites", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80930", " - tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80931", " - w1: ds28e17: reject an oversize length on an I2C block read", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80932", " - vsock/virtio: flush works in dependency order", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80938", " - wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80941", " - wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80944", " - wifi: mwifiex: Detach sync cmd buffer on interrupted wait", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80949", " - wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80951", " - i3c: master: svc: bound IBI payload to the requested max_payload_len", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80952", " - i3c: master: Fix info leak and UAF in device unregister path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80963", " - dm-stats: fix a crash if allocation of per-cpu data fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80964", " - ALSA: virmidi: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80965", " - ALSA: serial-u16550: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80966", " - ALSA: portman2x4: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80967", " - ALSA: pcxhr: initialize mutexes before requesting threaded IRQ", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80968", " - ALSA: mts64: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80969", " - ALSA: mpu401: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80971", " - ALSA: bcd2000: clear the URB pointers on disconnect", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80972", " - ALSA: aloop: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80973", " - ALSA: 6fire: bound the MIDI event length from the device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80976", " - seg6: reset IP6CB after IPv6 decapsulation", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80978", " - net: cap advertised IP tunnel headroom", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80983", " - net/smc: fix socket refcount leak in smc_switch_conns()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80987", " - NTB: ntb_transport: Reject oversized TX buffers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80988", " - NTB: ntb_transport: Fail TX enqueue when the QP link is down", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80994", " - net: openvswitch: fix flow mask use-after-free on flow deletion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81000", " - net: tun: bound receive headroom", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81001", " - slip: fix use-after-free in sl_sync()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81002", " - xdp: fix zero-copy frame layout", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81003", " - net/iucv: filter frames in afiucv_hs_rcv() by ingress device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81005", " - ipmi: si: Fix NULL pointer dereference after failed registration", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81007", " - ipmi: ipmb: validate write message length", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81008", " - interconnect: Fix use after free in icc_get() and of_icc_get_by_index()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81017", " - platform/chrome: sensorhub: Bound the EC-reported sensor number", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89440", " - mmc: via-sdmmc: stop card-detect handling on probe failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89444", " - platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93206", " - PCI/proc: Use file_ns_capable() when checking config space read access", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89456", " - s390/dasd: Propagate partial completion length across ERP recovery", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89457", " - s390/dasd: Guard sysfs discipline callbacks against unallocated private", " data", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89458", " - s390/dasd: Do not complete a failed ESE read as successful", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89461", " - power: supply: max17040: synchronize work cancellation on suspend", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89463", " - power: supply: ucs1002: fix use-after-free on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89464", " - power: supply: twl4030_charger: cancel workers via devm", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89469", " - power: supply: lp8727: fix use-after-free in lp8727_release_irq()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89470", " - power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89471", " - power: supply: cros_usbpd-charger: bound the EC-reported port count", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89474", " - power: supply: bq256xx: drain usb_work before freeing the charger", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89475", " - power: supply: bq24257: fix use-after-free on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89476", " - sctp: fix stream->outcnt underflow on duplicate RECONF responses", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89477", " - sctp: fix NULL deref on untransmitted RECONF completion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89478", " - sctp: drop a chunk if its transport was removed", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89479", " - sctp: stop processing a packet once its association is deleted", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89480", " - nvme-tcp: reject a read that transferred too few bytes", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89482", " - nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89483", " - nvme: zero the discard fallback page", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89485", " - lockd: pin next file across nlm_inspect_file lock-drop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89487", " - openvswitch: only skb_tx_error() a packet we are about to drop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89489", " - openrisc: fix arbitrary kernel memory access via or1k_atomic syscall", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89490", " - ocfs2: fix readdir position truncation on 32-bit kernels", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89491", " - ocfs2: cluster: don't sleep while holding o2hb_live_lock in", " o2hb_region_pin()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89493", " - ocfs2: validate rl_used against rl_count in refcount block validator", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89494", " - ocfs2: validate lengths in dlm_mig_lockres_handler", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89495", " - ocfs2: bound namelen in dlm_migrate_request_handler", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89496", " - ocfs2: always run deallocs on copy-on-write completion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89497", " - orangefs: skip leading spaces before parsing client debug masks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89498", " - orangefs: fix double-free of trailer_buf on readdir copy failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89504", " - regulator: as3722_get_regulator_dt_data: fix premature of_node_put", " leaving dangling of_node pointer", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89508", " - RDMA/ucma: Lock the handler in ucma_set_ib_path()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89510", " - RDMA/cxgb4: Cancel reg_work before freeing device on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89511", " - qede: Fix NULL pointer dereference in TPA fragment processing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89512", " - remoteproc: scp: Fix device reference leak on failed lookup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89524", " - wifi: ath6kl: clamp assoc request/response lengths before subtracting IE", " offsets", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89525", " - udf: reject VAT indexes equal to the entry count", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89532", " - svcrdma: Fix pcl_for_each_segment for empty chunks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89533", " - svcrdma: Fix offset arithmetic in read_chunk_range", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89538", " - SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89540", " - sunrpc: init gssp_lock before publishing proc entry", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89541", " - SUNRPC: harden gss_unwrap_resp_priv length checks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89542", " - SUNRPC: harden gss_krb5_unwrap_v2 against short tokens", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89548", " - SUNRPC: always drain cache_cleaner before destroying a cache_detail", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89549", " - sunrpc: route to a populated pool in svc_pool_for_cpu()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89551", " - SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89554", " - mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89555", " - mpls: reload header after pskb_may_pull()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89557", " - md: do overflow check for sb->bblog_shift in super_1_load()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89559", " - libnvdimm/labels: Prevent integer overflow in __nd_label_validate()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93226", " - ipv6: use RCU iterator to dump route exceptions", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89562", " - ip6_gre: fix hardware header length for NBMA tunnels", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89563", " - ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89569", " - Bluetooth: RFCOMM: serialize security confirmation handling", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89573", " - dm array: reject an array block whose value size is not the caller's", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89575", " - dm raid1: reserve space for NUL-terminator in build_constructor_string()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89576", " - dm-era: fix shadowed superblock leak on take-snap failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89582", " - bnx2x: fix double free in bnx2x_init_firmware() error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89585", " - auxdisplay: charlcd: cancel backlight work on registration failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89586", " - ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89594", " - hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89596", " - forcedeth: fix off-by-one when saving/restoring non-PCI config space", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89597", " - fbdev: uvesafb: unregister connector callback on init failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89599", " - fbdev: omapfb: panel-dsi-cm: initialize lock before registering display", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89605", " - ecryptfs: release message context on send failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89606", " - ecryptfs: reject too-small tag 70 packets", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89607", " - ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89608", " - ecryptfs: pass packet set buffer size to parser", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89609", " - ecryptfs: hold msg ctx list lock when cleaning daemon queue", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89615", " - fs/ntfs3: bound page_lcns[] index by the log record", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89616", " - fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89617", " - fs/ntfs3: validate dirty page table on log replay", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89621", " - HID: mcp2221: validate report size in mcp2221_raw_event()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89626", " - HID: sensor: custom: Fix field sysfs group cleanup on failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89627", " - HID: roccat: free buffered reports when destroying device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89628", " - HID: picolcd: clamp eeprom debugfs read to bytes actually received", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89643", " - audit: avoid dropping live tree ref on fsnotify rule autoremove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89649", " - ceph: bound xattr value length in __build_xattrs()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89650", " - ceph: bound num_export_targets array for mds info v2/v3", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89653", " - ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89655", " - ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89656", " - libceph: reject buckets with mismatched CRUSH ids", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89662", " - NFSD: Prevent lock owner use-after-free during client teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89663", " - nfsd: revoke copy-notify stateids before dropping their reference", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89665", " - nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89669", " - nfsd: initialize copy-notify stateid before publishing it", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89673", " - nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89674", " - nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89684", " - nfsd: fix cpntf publish race in nfs4_init_cp_state", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89694", " - nfsd: check client ownership when cancelling a copy-notify stateid", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89696", " - nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89697", " - nfsd: add fh_want_write() for early-verified SETATTR in", " nfsd_proc_setattr()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89699", " - nfsd: validate symlink target length in NFSv4 CREATE", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89704", " - nfsd: sample writeback error cursor before async COPY loop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89706", " - nfsd: Reset write verifier when async COPY writeback fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89710", " - NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget", " path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89711", " - NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89712", " - NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89720", " - ubifs: fix out-of-bounds read in signature length check", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93213", " - of: fix out-of-bounds read in of_alias_scan() stem parser", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89723", " - nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after", " truncation", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89724", " - media: vicodec: fix out-of-bounds write in FWHT encoder", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89725", " - media: cec: stm32: prevent out-of-bounds write on RX overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89726", " - lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89729", " - HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89730", " - fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89732", " - usb: gadget: f_fs: Prevent deadlock during ep0 read loop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89733", " - usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and", " uvc_function_unbind()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93214", " - usb: gadget: f_tcm: fix deadlock in usbg_make_tpg()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89736", " - usb: gadget: u_audio: Fix use-after-free on sound card disconnect", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89741", " - Revert \"media: v4l2-dev: fix error handling in", " __video_register_device()\"", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89742", " - rapidio: mport_cdev: fix use-after-free in dma_req_free()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89749", " - tracing: Fix crash passing ERR_PTR to kthread_stop()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89752", " - mm: memcg: stop reclaim when a limit update is superseded", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89753", " - mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89765", " - timers/itimer: Zero-init old itimerval before copy to userspace", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93219", " - clocksource/drivers/timer-sun4i: Advertise a real minimum delta", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-23191", " - ALSA: aloop: Fix racy access at PCM trigger", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586)", " - io_uring/io-wq: fix worker accounting when canceling creation callbacks", " - can: j1939: add missing calls in NETDEV_UNREGISTER notification handler", " - can: j1939: make j1939_sk_bind() fail if device is no longer registered", " - Revert \"PM: sleep: Use complete() in device_pm_sleep_init()\"", " - smc: Use __sk_dst_get() and dst_dev_rcu() in smc_vlan_by_tcpsk().", " - selinux: switch two allocations to use kzalloc_objs()", " - ALSA: pcm: fix wait_time calculations", " - ASoC: tegra: Fix Master Volume Control", " - ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked", " streams", " - kcov: replace local_irq_save() with a local_lock_t", " - ext4: propagate errors from fast commit range replay", " - nilfs2: correct return value kernel-doc descriptions for ioctl functions", " - nvme: rename CDR/MORE/DNR to NVME_STATUS_*", " - HID: ft260: fix i2c probing for hwmon devices", " - HID: ft260: improve i2c write performance", " - HID: ft260: improve i2c large reads performance", " - HID: ft260: skip unexpected HID input reports", " - HID: ft260: wake up device from power saving mode", " - HID: ft260: missed NACK from busy device", " - HID: ft260: validate i2c input report length", " - HID: input: read battery capacity from its actual report offset", " - fpga: dfl: fme: add error handling", " - accessibility: speakup: unregister tty ldisc on later init failures", " - xhci: dbgtty: Fix unregister on tty_alloc_driver() failure", " - usb: usbtest: disable dynamic ID support", " - mm/swap: reject swapon() on filesystem-level encrypted files", " - crypto: atmel-tdes - use scatterlist length before DMA mapping", " - crypto: qce - Remove unsafe/deprecated algorithms", " - usb: core: Strengthen error handling in hub_hub_status()", " - USB: serial: spcp8x5: drop broken carrier detect support", " - Linux 5.15.220", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80824", " - usb: usbfs: fix use-after-free of usb_device in usbdev_release()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80826", " - USB: c67x00: fix use-after-free in c67x00_add_iso_urb()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80827", " - USB: serial: option: fix slab OOB read in interrupt URB callback", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80828", " - ALSA: usb-audio: Complete cleanup after system-resume errors", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80829", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80830", " - usb: core: Add lock to usb_wakeup_notification()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80921", " - KVM: s390: vsie: zero stale crypto bits", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80831", " - crypto: mxs-dcp - fix source scatterlist length access", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80832", " - crypto: qce - fix CCM AAD buffer underallocation", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80840", " - ipv6: seg6: clear IPv4 control block on IPIP decapsulation", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80842", " - net: bridge: mcast: fix use-after-free of a master VLAN's multicast", " context", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80843", " - xfrm: fix xfrm_state_construct() auth-trunc leak", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80844", " - xfrm: ah6: validate routing header segments_left", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80846", " - xfrm: drop ESP-in-TCP packets with no ingress device", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80848", " - xfrm: espintcp: fix UAF during close", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80854", " - usb: gadget: f_tcm: keep port count until LUN teardown completes", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80855", " - fuse: fix invalidate lock leak on open O_TRUNC DAX failure", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80856", " - fuse: fix invalidate lock leak on setattr writeback failure", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80923", " - xhci: dbgtty: Fix unregister on tty_register_driver() failure", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80768", " - HID: ft260: fix stack-use-after-return write in I2C read race", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80766", " - HID: uclogic: fix use-after-free of inrange_timer on remove", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80789", " - nvmet-tcp: bound SGL data length before allocating command buffers", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80783", " - HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80796", " - nfc: nci: add data_len bound checks to activation parameter extractors", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80807", " - nilfs2: reject invalid block index in GC ioctl", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80916", " - kcov: fix data corruption and race conditions on PREEMPT_RT", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-72323", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-43437", " - ALSA: pcm: fix use-after-free on linked stream runtime in", " snd_pcm_drain()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-53089", " - bpf: Fix use-after-free in offloaded map/prog info fill", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2025-40102", " - KVM: arm64: Prevent access to vCPU events before init", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2025-39925", " - can: j1939: implement NETDEV_UNREGISTER notification handler", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2024-58095", " - jfs: add check read-only before txBeginAnon() call", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2024-58094", " - jfs: add check read-only before truncation in jfs_truncate_nolock()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2024-46754", " - bpf: Remove tst_run from lwt_seg6local_prog_ops.", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-68476", " - ipvs: reload ip header after head reallocation", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80806", " - ext4: don't enable DAX on new encrypted files", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80863", " - RDMA/rxe: Fix OOB in free_rd_atomic_resources()", " * Jammy update: v5.15.219 upstream stable release (LP: #2168549)", " - Linux 5.15.219", " * Jammy update: v5.15.219 upstream stable release (LP: #2168549) //", " CVE-2026-80590", " - inet: frags: strip GSO state from fragments before reassembly", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525)", " - null_blk: fix UBSAN shift-out-of-bounds when zone_size is 0 or overflows", " - ext4: clear error before retrying inode xattr space fallback", " - misc: fastrpc: separate fastrpc device from channel context", " - misc: fastrpc: Rework fastrpc_req_munmap", " - perf/core: Fix child_total_time_enabled accounting bug at task exit", " - perf: Fix cgroup state vs ERROR", " - perf: Fix dangling cgroup pointer in cpuctx", " - nfc: nci: free destination parameters when closing a connection", " - drm/amdgpu: check ASPM on the dGPU host link", " - KVM: x86/mmu: Retry page fault if root is invalidated by memslot update", " - KVM: x86/mmu: Directly \"destroy\" PTE list when recycling rmaps", " - KVM: x86/mmu: Rename pte_list_{destroy,remove}() to show they zap SPTEs", " - KVM: x86/mmu: Document the \"rules\" for using host_pfn_mapping_level()", " - KVM: Rename mmu_notifier_* to mmu_invalidate_*", " - KVM: x86/mmu: Split out TDP MMU page fault handling", " - KVM: x86/mmu: Rename __direct_map() to direct_map()", " - HID: magicmouse: Prevent out-of-bounds (OOB) read during", " DOUBLE_REPORT_ID", " - KVM: x86: Retry page fault if MMU reload is pending and root has no sp", " - Input: atkbd - skip deactivate for HONOR FMB-P's internal keyboard", " - Input: atkbd - skip deactivate for HONOR ZQC-P", " - mptcp: pm: ADD_ADDR rtx: allow ID 0", " - mptcp: pm: fix data race in add_addr timer callback", " - can: use skb hash instead of private variable in headroom", " - Revert \"ALSA: aoa: Use guard() for mutex locks\"", " - Linux 5.15.218", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80765", " - HID: hyperv: validate initial device info bounds", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80767", " - HID: sensor: custom: Fix use-after-free in enable_sensor", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80918", " - HID: core: fix number/pointer type confusion on long items", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80889", " - can: isotp: fix timer drain order, wakeup handling and tx_gen ordering", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-46170", " - mptcp: pm: ADD_ADDR rtx: free sk if last", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-46158", " - mptcp: pm: ADD_ADDR rtx: always decrease sk refcount", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80555", " - s390/vfio_ccw: Free all memory if cp_init() fails", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2025-68794", " - iomap: adjust read range correctly for non-block-aligned positions", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-64581", " - xfrm: fix sk_dst_cache double-free in xfrm_user_policy()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80781", " - HID: core: fix OOB read of field->usage in hid_set_field()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80782", " - HID: magicmouse: do not keep a stale msc->input if no input is claimed", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80583", " - ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80587", " - mptcp: avoid combining some incoming suboptions", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80547", " - s390/vfio_ccw: Implement a crw lock", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80548", " - s390/vfio_ccw: Selectively expand io_mutex", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80552", " - s390/vfio_ccw: Ensure index for read/write regions are within range", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80788", " - nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80790", " - nvmet-fc: fix invalid free in LS IOD error path", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80792", " - ipv6: fix use-after-free in ip6_finish_output2()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80793", " - ipv4: reject undersized MTUs in ip_do_fragment()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80557", " - libceph: fix OOB read in decode_watchers() via missing bounds check", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80794", " - nfc: nci: fix uninit-value in the RF discover/activated NTF handlers", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80795", " - nfc: nci: fix out-of-bounds write in nci_target_auto_activated()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80823", " - nfc: st21nfca: validate ATR_REQ length against the received frame", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80797", " - nfc: pn533: purge fragmented skbs during cleanup", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80798", " - nfc: llcp: reject PDUs shorter than the LLCP header", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80799", " - nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80800", " - nfc: llcp: bound the connect_sn TLV walk to the skb", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80801", " - nfc: microread: validate target discovery payload lengths", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80802", " - nfc: fdp: bound the device-reported read length and fix an skb leak", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80803", " - nfc: digital: clamp SENSF_RES length to the destination buffer", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80536", " - xfs: bounds-check buffer log item's dirty bitmap", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80553", " - s390/vfio_ccw: Cancel existing workqueues", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74662", " - inet: frags: publish queues before arming timer", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74666", " - packet: synchronize pressure clearing with ring reconfiguration", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74663", " - net/sched: reject overly deep qdisc hierarchies", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74668", " - packet: use consistent hard_header_len in TX_RING send path", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74582", " - packet: use consistent hard_header_len in non-ring send paths", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80737", " - serial: amba-pl011: synchronize DMA teardown", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74626", " - NTB: ntb_netdev: Preserve RX queue depth on allocation failure", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74637", " - perf/core: Fix group leader use-after-free after sibling detach", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74647", " - misc: fastrpc: Remove buffer from list prior to unmap operation", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74632", " - mm/huge_memory: fix huge_zero_pfn race", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80562", " - gpio: ml-ioh: use raw_spinlock_t for the register lock", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80805", " - xfs: validate attr entry pointer before field access", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80808", " - ext4: stop retrying saturated xattr cache entries", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80809", " - ocfs2: fix missing metadata reservation for large xattrs", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80812", " - ALSA: dummy: Check card index validity at probe", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80814", " - rndis_host: add overflow check in rndis_rx_fixup()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80819", " - Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80917", " - PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems", " * Jammy update: v5.15.217 upstream stable release (LP: #2168510)", " - f2fs: fix UAF issue in f2fs_merge_page_bio()", " - media: mediatek: vcodec: Fix a resource leak related to the scp device", " in FW initialization", " - fscrypt: use the mount idmap for the owner check in", " fscrypt_ioctl_set_policy()", " - ipvs: separate destination availability state", " - selinux: require every boolean value to be defined", " - selinux: reject a class permission count below its inherited common", " - selinux: do not cancel a policy conversion that never started", " - mptcp: options: reset DSS fields in case of unexpected size", " - s390/qeth: validate user buffer length in SNMP and ARP query ioctls", " - ASoC: cs4265: sort the register default table", " - ASoC: codecs: lpass-wsa-macro: Fix enum kcontrol accesses", " - powerpc/pseries: pci - logic bug", " - Input: synaptics-rmi4 - fix F55 transmitter electrode count typo", " - Input: focaltech - fix array out-of-bounds in", " focaltech_process_rel_packet", " - Input: psxpad-spi - set driver data before use", " - Input: atkbd - skip deactivate for Xiaomi Book Pro 14's internal", " keyboard", " - Input: iforce - validate input packet lengths", " - powerpc/pseries: lparcfg - fix kbuf[] underflow", " - Input: synaptics-rmi4 - zero report size on F54 work error", " - Input: synaptics-rmi4 - bound the F54 report size to the allocated", " buffer", " - Input: synaptics-rmi4 - block s_input when F54 queue is busy", " - Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue", " - crypto: qce - fix error path in devm_qce_register_algs", " - libceph: fix multiple unsafe decodes in decode_locker()", " - ftrace: Fix off-by-one fentry site disable in ftrace_free_mem()", " - openrisc: signal: do not restore privileged SR bits on sigreturn", " - Input: sur40 - fix input device registration ordering", " - Input: sur40 - fix V4L error path cleanup", " - libceph: Avoid using invalid osd indices from primary_temp", " - ceph: fix MDS random selection readiness predicate", " - libceph: tolerate addrvecs with multiple entries of the same type", " - mmc: omap_hsmmc: fix busy_timeout overflow in ns conversion on 32-bit", " - mmc: sdhci: unmap the bounce buffer before device release", " - mmc: sdhci: make tuning_err a signed int", " - drm/radeon: fix autosuspend cleanup during teardown", " - s390/vfio_ccw: Fix out of bounds check on CCW array", " - drm/amdgpu: Reject UVD message with invalid number of h265 refs", " - drm/amdgpu: validate GEM_CREATE domain combinations", " - drm/amdgpu: Reject UVD message with dimensions above 4096", " - drm/amdgpu: Implement insert_end for VCE 3", " - drm/amdgpu: Fix UVD decode image min size calculation", " - xfs: fix ilock leak on error in xfs_dq_get_next_id", " - xfs: check v5 superblock features early", " - net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot", " - mm: do file ownership checks with the proper mount idmap", " - iommu/amd: Don't split flush for amd_iommu_domain_flush_all()", " - bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is", " uninitialized", " - udmabuf: Do not create malformed scatterlists", " - dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning", " - fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region()", " - Input: mms114 - fix touch indexing for MMS134S and MMS136", " - i2c: davinci: Unregister cpufreq notifier on probe failure", " - Input: mms114 - reject an oversized device packet size", " - ALSA: hda: conexant: Remove mic bias threshold override", " - VFS/audit: introduce kern_path_parent() for audit", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - audit: fix recursive locking deadlock in audit_dupe_exe()", " - ALSA: hda: Fix cached processing coefficient verbs", " - serial: max310x: replace bare use of 'unsigned' with 'unsigned int'", " (checkpatch)", " - serial: max310x: implement gpio_chip::get_direction()", " - rxrpc: serialize kernel accept preallocation with socket teardown", " - fbcon: Rename struct fbcon_ops to struct fbcon_par", " - fbcon: Use correct type for vc_resize() return value", " - tipc: restrict socket queue dumps in enqueue tracepoints", " - mlxsw: spectrum: On port enslavement to a LAG, join upper's bridges", " - mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()", " - vduse: Use fixed 4KB bounce pages for non-4KB page size", " - vduse: remove unused vaddr parameter of vduse_domain_free_coherent", " - vduse: take out allocations from vduse_dev_alloc_coherent", " - VDUSE: avoid leaking information to userspace", " - octeontx2-af: Fix APR entry mapping based on APR_LMT_CFG", " - octeontx2: Annotate mmio regions as __iomem", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - tcp: convert to dev_net_rcu()", " - net: dst: annotate data-races around dst->input", " - net: dst: annotate data-races around dst->output", " - net: dst: add four helpers to annotate data-races around dst->dev", " - ipv4: adopt dst_dev, skb_dst_dev and skb_dst_dev_net[_rcu]", " - netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst", " - ASoC: mediatek: mt8192-afe-pcm: Convert to devm_pm_runtime_enable()", " - ASoC: mediatek: mt8192-afe-pcm: Simplify with dev_err_probe()", " - ASoC: mediatek: Use common mtk_afe_pcm_platform with common probe cb", " - ASoC: mediatek: mt8192-afe-pcm: Simplify probe() with local dev variable", " - ASoC: mediatek: mt8192: Check runtime resume during probe", " - netfilter: nft_set_pipapo: use GFP_KERNEL for insertions", " - netfilter: nft_set_pipapo: move prove_locking helper around", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", " - netfilter: nft_set_pipapo: make pipapo_clone helper return NULL", " - netfilter: nft_set_pipapo: prepare walk function for on-demand clone", " - netfilter: nft_set_pipapo: merge deactivate helper into caller", " - netfilter: nft_set_pipapo: prepare pipapo_get helper for on-demand clone", " - netfilter: nft_set_pipapo: move cloning of match info to insert/removal", " path", " - netfilter: nft_set_pipapo: don't leak bad clone into future transaction", " - remoteproc: qcom: replace kstrdup with kstrndup", " - remoteproc: qcom: fix sparse warnings", " - remoteproc: qcom: pas: Adjust the phys addr wrt the mem region", " - remoteproc: qcom: Fix leak when custom dump_segments addition fails", " - lsm: use default hook return value in call_int_hook()", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - fs/ntfs3: Make ntfs_update_mftmirr return void", " - fs/ntfs3: Undo critial modificatins to keep directory consistency", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - net: thunderbolt: Fix frags[] overflow by bounding frame_count", " - mtd: spi-nor: Fix spi_nor_try_unlock_all()", " - mtd: spi-nor: swp: Improve locking user experience", " - dmaengine: dw-edma: Remove unused irq field in struct dw_edma_chip", " - dmaengine: dw-edma: Detach the private data and chip info structures", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - taskstats: fill_stats_for_tgid: use for_each_thread()", " - taskstats: retain dead thread stats in TGID queries", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - ksmbd: fix integer overflow in set_file_allocation_info()", " - i2c: imx: separate atomic, dma and non-dma use case", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", " - can/esd_usb2: Rename esd_usb2.c to esd_usb.c", " - [Config] Set CONFIG_CAN_ESD_USB=m", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - thunderbolt: Remove usage of the deprecated ida_simple_xx() API", " - thunderbolt: Update property.c function documentation", " - thunderbolt: Keep XDomain reference during the lifetime of a service", " - thunderbolt: Remove service debugfs entries during unregister", " - thunderbolt: Remove XDomain from the bus without holding tb->lock", " - thunderbolt: Prevent XDomain delayed work use-after-free on disconnect", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - ovl: use linked upper dentry in copy-up tmpfile", " - scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: make error counter atomic", " - firmware_loader: introduce __free() cleanup hanler", " - Input: ims-pcu - fix firmware leak in async update", " - mmc: vub300: fix use-after-free on disconnect", " - mmc: vub300: rename probe error labels", " - mmc: vub300: fix use-after-free on probe failure", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", " - net: Add helper function to parse netlink msg of ip_tunnel_encap", " - net: ipip: require CAP_NET_ADMIN in the device netns for changelink", " - net: ixp4xx_hss: fix duplicate HDLC netdev allocation", " - net/sched: act_ct: preserve tc_skb_cb across defragmentation", " - net: mana: Validate the packet length reported by the NIC", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", " - treewide: rename pinctrl_gpio_direction_output_new()", " - gpio: tegra: do not call pinctrl for GPIO direction", " - net/sched: taprio: avoid calling child->ops->dequeue(child) twice", " - net/sched: sch_taprio: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - bootconfig: do not put quotes on cmdline items unless necessary", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - espintcp: use sk_msg_free_partial to fix partial send", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - octeontx2-pf: fix SQB pointer leak on init failure", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", " - usb: gadget: f_tcm: synchronize delayed set_alt with teardown", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", " - dma-buf/drivers: make reserving a shared slot mandatory v4", " - drm/virtio: use uninterruptible resv lock for plane updates", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/tegra: fbdev: Remove offset into framebuffer memory", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/virtio: Return proper error codes instead of -1", " - drm/virtio: bound EDID block reads to the response buffer", " - media: aspeed: fix missing of_reserved_mem_device_release() on probe", " failure", " - drm/i915/vrr: require valid min/max vfreq for VRR", " - drm/i915/hdcp: check streams[] bounds before overflow", " - drm/i915/hdcp: require monotonically increasing seq_num_v", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: i2c: imx219: Drop IMX219_VTS_* macros", " - media: i2c: imx219: Correct the minimum vblanking value", " - media: i2c: imx219: Rename VTS to FRM_LENGTH", " - media: imx219: Fix maximum frame length in lines", " - wifi: ath6kl: fix use-after-free in aggr_reset_state()", " - media: v4l: async: Set owner for async sub-devices", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", " - ALSA: seq: close a re-opened queue timer in the destructor", " - wifi: brcmfmac: drain bus_reset work on device removal", " - serial: 8250_mid: Remove unneeded test for ->setup() presence", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " - wifi: brcmfmac: fix 43752 SDIO FWVID incorrectly labelled as Cypress", " (CYW)", " - wifi: brcmfmac: set F2 blocksize to 256 for BCM43752", " - sc16is7xx: Properly resume TX after stop", " - serial: sc16is7xx: Fill in rs485_supported", " - serial: sc16is7xx: remove obsolete out_thread label", " - serial: sc16is7xx: fix regression with GPIO configuration", " - serial: sc16is7xx: implement gpio get_direction() callback", " - mptcp: cleanup MPJ subflow list handling", " - mptcp: fix subflow accounting on close", " - mptcp: decrement subflows counter on failed passive join", " - sctp: avoid auth_enable sysctl UAF during netns teardown", " - ceph: avoid fs reclaim while using current->journal_info", " - libceph: Amend checking to fix `make W=1` build breakage", " - libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE", " - libceph: add doutc and *_client debug macros support", " - ceph: rename _to_client() to _to_fs_client()", " - ceph: print cluster fsid and client global_id in all debug logs", " - ceph: fix hanging __ceph_get_caps() with stale mds_wanted", " - libceph: fix two unsafe bare decodes in decode_lockers()", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", " - net/sched: serialize qdisc_rtab_list against concurrent get/put", " - ftrace: Add global mutex to serialize trace_parser access", " - super: fix emergency thaw deadlock on frozen block devices", " - ksmbd: rename smb2_get_msg to smb_get_msg", " - smb/server: fix minimum SMB1 PDU size", " - smb/server: fix minimum SMB2 PDU size", " - ksmbd: validate minimum PDU size for transform requests", " - mm/vmstat: fold stranded per-cpu node stats when a node comes online", " - ksmbd: conn lock to serialize smb2 negotiate", " - ksmbd: reject repeated SMB2 NEGOTIATE requests", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", " - igc: remove napi_synchronize() in igc_down()", " - net: pktgen: fix code style (WARNING: Block comments)", " - net: pktgen: fix proc entry use-after-free", " - scsi: sd: sd_zbc: Improve source code documentation", " - scsi: sd: sd_zbc: Use logical blocks as unit when querying zones", " - scsi: sd: sd_zbc: Introduce struct zoned_disk_info", " - scsi: sd: sd_zbc: Return early in sd_zbc_check_zoned_characteristics()", " - scsi: scsi_debug: Rename zone type constants", " - scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write", " - ice: fix VF interrupts cleanup", " - ice: fix memory leak in ice_lbtest_prepare_rings()", " - fsnotify: opt-in for permission events at file open time", " - fs: don't block write during exec on pre-content watched files", " - binfmt_misc: restore write access when removing an entry", " - i2c: imx: Fix slave registration race and error handling", " - i2c: bcm-iproc: remove printout on handled timeouts", " - i2c: iproc: reset bus after timeout if START_BUSY is stuck", " - can: gs_usb: gs_usb_receive_bulk_callback(): resubmit URB on skb", " allocation failure", " - jiffies: Define secs_to_jiffies()", " - ice: wait for reset completion in ice_resume()", " - drm/amd/pm: fix torn gpu metrics reads", " - sched/psi: Shut down rtpoll_timer in psi_cgroup_free()", " - mm/ptdump: always stabilise against page table freeing using init_mm", " - net: add a couple of helpers for iph tot_len", " - openvswitch: use skb_ip_totlen in conntrack", " - net: sched: use skb_ip_totlen and iph_totlen", " - openvswitch: move key and ovs_cb update out of handle_fragments", " - net/sched: act_ct: fix sk_buff leak when the header checks reject a", " packet", " - net: atlantic: free stranded TX buffers on ring deinit", " - net/smc: rdma write inline if qp has sufficient inline space", " - net: smc: fix splice entry lifetime imbalance in smc_rx_splice", " - arm64: tegra: Add EL2 virtual timer interrupt for Tegra194", " - crypto: ccm - Set rfc4309 maxauthsize from child", " - netfilter: ipset: fix refcount race between list:set GC and swap", " - netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort", " path", " - netfilter: flowtable: publish GC-visible tuple last", " - netfilter: ipset: fix list type element drift bug", " - net: packet: fix wrong transport_header when sending VLAN-tagged frame", " - ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers", " - af_packet: Don't send zero-byte data in tpacket_snd().", " - net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG", " - net/x25: fix use-after-free of the socket by its timers", " - binfmt_misc: use exe_file_deny_write_access() for the interpreter clone", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - drm/vmwgfx: Reserve fence slots on buffer objects in cotables", " - drm/virtio: Unlock reservations on dma_resv_reserve_fences() error", " - jiffies: Cast to unsigned long in secs_to_jiffies() conversion", " - ring-buffer: Remove jump to out label in ring_buffer_swap_cpu()", " - ring-buffer: Use current_context for safe per-CPU buffer swap", " - Linux 5.15.217", "" ], "package": "linux-kvm", "version": "5.15.0-1111.116", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2170108, 2170970, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168549, 2168549, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168510 ], "author": "Alessio Faina ", "date": "Fri, 16 Oct 2026 09:22:17 +0200" }, { "cves": [ { "cve": "CVE-2022-1205", "url": "https://ubuntu.com/security/CVE-2022-1205", "cve_description": "A NULL pointer dereference flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system.", "cve_priority": "high", "cve_public_date": "2022-08-31 16:15:00 UTC" }, { "cve": "CVE-2022-50303", "url": "https://ubuntu.com/security/CVE-2022-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix double release compute pasid If kfd_process_device_init_vm returns failure after vm is converted to compute vm and vm->pasid set to compute pasid, KFD will not take pdd->drm_file reference. As a result, drm close file handler maybe called to release the compute pasid before KFD process destroy worker to release the same pasid and set vm->pasid to zero, this generates below WARNING backtrace and NULL pointer access. Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step of kfd_process_device_init_vm, to ensure vm pasid is the original pasid if acquiring vm failed or is the compute pasid with pdd->drm_file reference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10", "cve_priority": "medium", "cve_public_date": "2025-09-15 15:15:00 UTC" }, { "cve": "CVE-2023-53320", "url": "https://ubuntu.com/security/CVE-2023-53320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info() The function mpi3mr_get_all_tgt_info() has four issues: 1) It calculates valid entry length in alltgt_info assuming the header part of the struct mpi3mr_device_map_info would equal to sizeof(u32). The correct size is sizeof(u64). 2) When it calculates the valid entry length kern_entrylen, it excludes one entry by subtracting 1 from num_devices. 3) It copies num_device by calling memcpy(). Substitution is enough. 4) It does not specify the calculated length to sg_copy_from_buffer(). Instead, it specifies the payload length which is larger than the alltgt_info size. It causes \"BUG: KASAN: slab-out-of-bounds\". Fix the issues by using the correct header size, removing the subtraction from num_devices, replacing the memcpy() with substitution and specifying the correct length to sg_copy_from_buffer().", "cve_priority": "low", "cve_public_date": "2025-09-16 17:15:00 UTC" }, { "cve": "CVE-2025-39726", "url": "https://ubuntu.com/security/CVE-2025-39726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ism: fix concurrency management in ism_cmd() The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that. This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well. A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it. On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.", "cve_priority": "high", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39779", "url": "https://ubuntu.com/security/CVE-2025-39779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: subpage: keep TOWRITE tag until folio is cleaned btrfs_subpage_set_writeback() calls folio_start_writeback() the first time a folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tag even if there are still dirty blocks in the folio. This can break ordering guarantees, such as those required by btrfs_wait_ordered_extents(). That ordering breakage leads to a real failure. For example, running generic/464 on a zoned setup will hit the following ASSERT. This happens because the broken ordering fails to flush existing dirty pages before the file size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode or for compressed writes, it locks several folios for delalloc and starts writing them out. Let's call the last locked folio folio X. Suppose the write range only partially covers folio X, leaving some pages dirty. Process A calls btrfs_subpage_set_writeback() when building a bio. This function call clears the TOWRITE tag of folio X, whose size = 8K and the block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range. Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. It calls tag_pages_for_writeback() to tag dirty folios with PAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then, B collects tagged folios using filemap_get_folios_tag() and must wait for folio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE) However, between tagging and collecting, process A may call btrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY) As a result, process B won't see folio X in its batch, and returns without waiting for it. This breaks the WB_SYNC_ALL ordering requirement. Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retains the TOWRITE tag. We now manually clear the tag only after the folio becomes clean, via the xas operation.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39810", "url": "https://ubuntu.com/security/CVE-2025-39810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix memory corruption when FW resources change during ifdown bnxt_set_dflt_rings() assumes that it is always called before any TC has been created. So it doesn't take bp->num_tc into account and assumes that it is always 0 or 1. In the FW resource or capability change scenario, the FW will return flags in bnxt_hwrm_if_change() that will cause the driver to reinitialize and call bnxt_cancel_reservations(). This will lead to bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc may be greater than 1. This will cause bp->tx_ring[] to be sized too small and cause memory corruption in bnxt_alloc_cp_rings(). Fix it by properly scaling the TX rings by bp->num_tc in the code paths mentioned above. Add 2 helper functions to determine bp->tx_nr_rings and bp->tx_nr_rings_per_tc.", "cve_priority": "low", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-37861", "url": "https://ubuntu.com/security/CVE-2025-37861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.", "cve_priority": "low", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-38643", "url": "https://ubuntu.com/security/CVE-2025-38643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() Callers of wdev_chandef() must hold the wiphy mutex. But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes: WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985", "cve_priority": "low", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38615", "url": "https://ubuntu.com/security/CVE-2025-38615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: cancle set bad inode after removing name fails The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted. The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's \"icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier\". In some it's outright \"we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles\".", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38361", "url": "https://ubuntu.com/security/CVE-2025-38361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check dce_hwseq before dereferencing it [WHAT] hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used. (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)", "cve_priority": "low", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38259", "url": "https://ubuntu.com/security/CVE-2025-38259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd9335: Fix missing free of regulator supplies Driver gets and enables all regulator supplies in probe path (wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup in final error paths and in unbind (missing remove() callback). This leads to leaked memory and unbalanced regulator enable count during probe errors or unbind. Fix this by converting entire code into devm_regulator_bulk_get_enable() which also greatly simplifies the code.", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38239", "url": "https://ubuntu.com/security/CVE-2025-38239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix invalid node index On a system with DRAM interleave enabled, out-of-bound access is detected: megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it accordingly.", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2022-50071", "url": "https://ubuntu.com/security/CVE-2022-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: move subflow cleanup in mptcp_destroy_common() If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE eBPF program, the MPTCP protocol ends-up leaking all the subflows: the related cleanup happens in __mptcp_destroy_sock() that is not invoked in such code path. Address the issue moving the subflow sockets cleanup in the mptcp_destroy_common() helper, which is invoked in every msk cleanup path. Additionally get rid of the intermediate list_splice_init step, which is an unneeded relic from the past. The issue is present since before the reported root cause commit, but any attempt to backport the fix before that hash will require a complete rewrite.", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2025-37920", "url": "https://ubuntu.com/security/CVE-2025-37920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: Fix race condition in AF_XDP generic RX path Move rx_lock from xsk_socket to xsk_buff_pool. Fix synchronization for shared umem mode in generic RX path where multiple sockets share single xsk_buff_pool. RX queue is exclusive to xsk_socket, while FILL queue can be shared between multiple sockets. This could result in race condition where two CPU cores access RX path of two different sockets sharing the same umem. Protect both queues by acquiring spinlock in shared xsk_buff_pool. Lock contention may be minimized in the future by some per-thread FQ buffering. It's safe and necessary to move spin_lock_bh(rx_lock) after xsk_rcv_check(): * xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers. * xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-43456", "url": "https://ubuntu.com/security/CVE-2026-43456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix type confusion in bond_setup_by_slave() kernel BUG at net/core/skbuff.c:2306! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306 RSP: 0018:ffffc90004aff760 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900 RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780 R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0 Call Trace: ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900 dev_hard_header include/linux/netdevice.h:3439 [inline] packet_snd net/packet/af_packet.c:3028 [inline] packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592 ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646 __sys_sendmsg+0x170/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe1a0e6c1a9 When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond, bond_setup_by_slave() directly copies the slave's header_ops to the bond device: bond_dev->header_ops = slave_dev->header_ops; This causes a type confusion when dev_hard_header() is later called on the bond device. Functions like ipgre_header(), ip6gre_header(),all use netdev_priv(dev) to access their device-specific private data. When called with the bond device, netdev_priv() returns the bond's private data (struct bonding) instead of the expected type (e.g. struct ip_tunnel), leading to garbage values being read and kernel crashes. Fix this by introducing bond_header_ops with wrapper functions that delegate to the active slave's header_ops using the slave's own device. This ensures netdev_priv() in the slave's header functions always receives the correct device. The fix is placed in the bonding driver rather than individual device drivers, as the root cause is bond blindly inheriting header_ops from the slave without considering that these callbacks expect a specific netdev_priv() layout. The type confusion can be observed by adding a printk in ipgre_header() and running the following commands: ip link add dummy0 type dummy ip addr add 10.0.0.1/24 dev dummy0 ip link set dummy0 up ip link add gre1 type gre local 10.0.0.1 ip link add bond1 type bond mode active-backup ip link set gre1 master bond1 ip link set gre1 up ip link set bond1 up ip addr add fe80::1/64 dev bond1", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2022-49858", "url": "https://ubuntu.com/security/CVE-2022-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix SQE threshold checking Current way of checking available SQE count which is based on HW updated SQB count could result in driver submitting an SQE even before CQE for the previously transmitted SQE at the same index is processed in NAPI resulting losing SKB pointers, hence a leak. Fix this by checking a consumer index which is updated once CQE is processed.", "cve_priority": "medium", "cve_public_date": "2025-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-22057", "url": "https://ubuntu.com/security/CVE-2025-22057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: decrease cached dst counters in dst_release Upstream fix ac888d58869b (\"net: do not delay dst_entries_add() in dst_release()\") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30 Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-22083", "url": "https://ubuntu.com/security/CVE-2025-22083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang: 1. Use-after-free when no tpgs are found: This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If a scsi request is then sent we do: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend which sees the vs_tpg we just did a kfree on. 2. Tpg dir removal hang: This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1. The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg. Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir. 3. Tpg leak: This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names. The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs. Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2024-58096", "url": "https://ubuntu.com/security/CVE-2024-58096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode ath11k_hal_srng_* should be used with srng->lock to protect srng data. For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock. So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319 So add srng->lock for them to avoid such warnings. Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct hal_srng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_process_rx(). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-21947", "url": "https://ubuntu.com/security/CVE-2025-21947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix type confusion via race condition when using ipc_msg_send_request req->handle is allocated using ksmbd_acquire_id(&ipc_ida), based on ida_alloc. req->handle from ksmbd_ipc_login_request and FSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion between messages, resulting in access to unexpected parts of memory after an incorrect delivery. ksmbd check type of ipc response but missing add continue to check next ipc reponse.", "cve_priority": "high", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2022-49562", "url": "https://ubuntu.com/security/CVE-2022-49562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing \"random\" pfns for pretty much any other VM_PFNMAP case.", "cve_priority": "low", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2025-21812", "url": "https://ubuntu.com/security/CVE-2025-21812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: rcu protect dev->ax25_ptr syzbot found a lockdep issue [1]. We should remove ax25 RTNL dependency in ax25_setsockopt() This should also fix a variety of possible UAF in ax25. [1] WARNING: possible circular locking dependency detected 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted ------------------------------------------------------ syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated---", "cve_priority": "high", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21801", "url": "https://ubuntu.com/security/CVE-2025-21801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ravb: Fix missing rtnl lock in suspend/resume path Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations. Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down", "cve_priority": "low", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-54683", "url": "https://ubuntu.com/security/CVE-2024-54683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: IDLETIMER: Fix for possible ABBA deadlock Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs: | ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20 | | but task is already holding lock: | ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v] | | which lock already depends on the new lock. A simple reproducer is: | #!/bin/bash | | while true; do | iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\" | iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\" | done & | while true; do | cat /sys/class/xt_idletimer/timers/testme >/dev/null | done Avoid this by freeing list_mutex right after deleting the element from the list, then continuing with the teardown.", "cve_priority": "medium", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2024-53220", "url": "https://ubuntu.com/security/CVE-2024-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to account dirty data in __get_secs_required() It will trigger system panic w/ testcase in [1]: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2752! RIP: 0010:new_curseg+0xc81/0x2110 Call Trace: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is if checkpoint_disabling and lfs_mode are both on, it will trigger OPU for all overwritten data, it may cost more free segment than expected, so f2fs must account those data correctly to calculate cosumed free segments later, and return ENOSPC earlier to avoid run out of free segment during block allocation. [1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2025-21759", "url": "https://ubuntu.com/security/CVE-2025-21759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: extend RCU protection in igmp6_send() igmp6_send() can be called without RTNL or RCU being held. Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection.", "cve_priority": "high", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57999", "url": "https://ubuntu.com/security/CVE-2024-57999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing. These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range. The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries Workqueue: events work_for_cpu_fn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100 LR [c00000000005e830] iommu_init_table+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620 [c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 There are 2 issues in the code 1. The index is \"int\" while the address is \"unsigned long\". This results in negative value when setting the bitmap. 2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well.", "cve_priority": "low", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57982", "url": "https://ubuntu.com/security/CVE-2024-57982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: state: fix out-of-bounds read during lookup lookup and resize can run in parallel. The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array. rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask; While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) { This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again). Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent. The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side. xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2022-49651", "url": "https://ubuntu.com/security/CVE-2022-49651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: srcu: Tighten cleanup_srcu_struct() GP checks Currently, cleanup_srcu_struct() checks for a grace period in progress, but it does not check for a grace period that has not yet started but which might start at any time. Such a situation could result in a use-after-free bug, so this commit adds a check for a grace period that is needed but not yet started to cleanup_srcu_struct().", "cve_priority": "low", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2022-49359", "url": "https://ubuntu.com/security/CVE-2022-49359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Job should reference MMU not file_priv For a while now it's been allowed for a MMU context to outlive it's corresponding panfrost_priv, however the job structure still references panfrost_priv to get hold of the MMU context. If panfrost_priv has been freed this is a use-after-free which I've been able to trigger resulting in a splat. To fix this, drop the reference to panfrost_priv in the job structure and add a direct reference to the MMU structure which is what's actually needed.", "cve_priority": "high", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2022-49234", "url": "https://ubuntu.com/security/CVE-2022-49234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: Avoid cross-chip syncing of VLAN filtering Changes to VLAN filtering are not applicable to cross-chip notifications. On a system like this: .-----. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-' '-1-2-' '-1-2-' Before this change, upon sw1p1 leaving a bridge, a call to dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1. In this scenario: .---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-' When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be called for sw2 and sw3 with a non-existing port - leading to array out-of-bounds accesses and crashes on mv88e6xxx.", "cve_priority": "medium", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2024-57945", "url": "https://ubuntu.com/security/CVE-2024-57945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Fix the out of bound issue of vmemmap address In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)). However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page. For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END. This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base.", "cve_priority": "low", "cve_public_date": "2025-01-21 13:15:00 UTC" }, { "cve": "CVE-2024-53210", "url": "https://ubuntu.com/security/CVE-2024-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct() Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skb_queue_purge() and WARN_ON in iucv_sock_destruct() during socket close. To fix this decrease skb refcount by one if MSG_PEEK is set in order to prevent memory leak and WARN_ON. WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53187", "url": "https://ubuntu.com/security/CVE-2024-53187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check for overflows in io_pin_pages WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1110.115 -proposed tracker (LP: #2168199)", "", " [ Ubuntu: 5.15.0-199.209 ]", "", " * jammy/linux: 5.15.0-199.209 -proposed tracker (LP: #2168214)", " * [SRU] selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value", " (LP: #2107442)", " - selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value", " * CVE-2022-1205", " - ax25: Fix ax25 session cleanup problems", " * CVE-2022-50303", " - drm/amdkfd: Fix double release compute pasid", " * CVE-2023-53320", " - scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info()", " * CVE-2025-39726", " - s390/ism: fix concurrency management in ism_cmd()", " * CVE-2025-39779", " - btrfs: subpage: keep TOWRITE tag until folio is cleaned", " * CVE-2025-39810", " - bnxt_en: Fix memory corruption when FW resources change during ifdown", " * udpgro.sh from ubuntu_kselftests_net failed with J-5.15 (udpgso_bench_rx:", " recv: bad packet len) (LP: #2129861)", " - selftests: udpgro: no need to load xdp for gro", " * CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", " * CVE-2025-37861", " - scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue", " * CVE-2025-38643", " - wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()", " * CVE-2025-38615", " - fs/ntfs3: cancle set bad inode after removing name fails", " * CVE-2025-38361", " - drm/amd/display: Check dce_hwseq before dereferencing it", " * CVE-2025-38259", " - ASoC: codecs: wcd9335: Fix missing free of regulator supplies", " * CVE-2025-38239", " - scsi: megaraid_sas: Fix invalid node index", " * CVE-2025-38069", " - PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops", " * CVE-2022-50071", " - mptcp: move subflow cleanup in mptcp_destroy_common()", " * CVE-2025-37920", " - xsk: Fix race condition in AF_XDP generic RX path", " * CVE-2026-43456", " - bonding: fix type confusion in bond_setup_by_slave()", " - bonding: prevent potential infinite loop in bond_header_parse()", " * CVE-2022-49858", " - octeontx2-pf: Fix SQE threshold checking", " * CVE-2025-22057", " - net: decrease cached dst counters in dst_release", " * CVE-2025-22083", " - vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint", " * CVE-2024-58096", " - wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode", " * CVE-2025-21947", " - ksmbd: fix type confusion via race condition when using", " ipc_msg_send_request", " * CVE-2022-49562", " - KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits", " * CVE-2025-21812", " - ax25: rcu protect dev->ax25_ptr", " * CVE-2025-21801", " - net: ravb: Fix missing rtnl lock in suspend/resume path", " * CVE-2024-54683", " - netfilter: IDLETIMER: Fix for possible ABBA deadlock", " * CVE-2024-53220", " - f2fs: fix to account dirty data in __get_secs_required()", " * CVE-2025-21759", " - ipv6: mcast: extend RCU protection in igmp6_send()", " * CVE-2024-57999", " - powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW", " * CVE-2024-57982", " - xfrm: state: fix out-of-bounds read during lookup", " * CVE-2022-49651", " - srcu: Tighten cleanup_srcu_struct() GP checks", " * CVE-2022-49359", " - drm/panfrost: Job should reference MMU not file_priv", " * CVE-2022-49234", " - net: dsa: Avoid cross-chip syncing of VLAN filtering", " * CVE-2024-57945", " - riscv: mm: Fix the out of bound issue of vmemmap address", " * CVE-2024-53210", " - s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()", " * CVE-2024-53187", " - io_uring: check for overflows in io_pin_pages", "" ], "package": "linux-kvm", "version": "5.15.0-1110.115", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2168199, 2168214, 2107442, 2129861 ], "author": "Alessio Faina ", "date": "Mon, 28 Sep 2026 14:57:31 +0200" } ], "notes": "linux-headers-5.15.0-1111-kvm version '5.15.0-1111.116' (source package linux-kvm version '5.15.0-1111.116') was added. linux-headers-5.15.0-1111-kvm version '5.15.0-1111.116' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1109-kvm. As such we can use the source package version of the removed package, '5.15.0-1109.114', 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-1111-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1109.114", "version": null }, "to_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1111.116", "version": "5.15.0-1111.116" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 5.15.0-1111.116", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed-kvm", "version": "5.15.0-1111.116", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Alessio Faina ", "date": "Fri, 16 Oct 2026 10:17:57 +0200" }, { "cves": [], "log": [ "", " * Main version: 5.15.0-1110.115", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed-kvm", "version": "5.15.0-1110.115", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Alessio Faina ", "date": "Mon, 28 Sep 2026 15:12:15 +0200" } ], "notes": "linux-image-5.15.0-1111-kvm version '5.15.0-1111.116' (source package linux-signed-kvm version '5.15.0-1111.116') was added. linux-image-5.15.0-1111-kvm version '5.15.0-1111.116' has the same source package name, linux-signed-kvm, as removed package linux-image-5.15.0-1109-kvm. As such we can use the source package version of the removed package, '5.15.0-1109.114', 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-1111", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1109.114", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1111.116", "version": "5.15.0-1111.116" }, "cves": [ { "cve": "CVE-2025-68190", "url": "https://ubuntu.com/security/CVE-2025-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked() kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-46242", "url": "https://ubuntu.com/security/CVE-2026-46242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s \"*pprev = next\" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays.", "cve_priority": "high", "cve_public_date": "2026-05-30 13:16:00 UTC" }, { "cve": "CVE-2025-38349", "url": "https://ubuntu.com/security/CVE-2025-38349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: don't decrement ep refcount while still holding the ep mutex Jann Horn points out that epoll is decrementing the ep refcount and then doing a mutex_unlock(&ep->mtx); afterwards. That's very wrong, because it can lead to a use-after-free. That pattern is actually fine for the very last reference, because the code in question will delay the actual call to \"ep_free(ep)\" until after it has unlocked the mutex. But it's wrong for the much subtler \"next to last\" case when somebody *else* may also be dropping their reference and free the ep while we're still using the mutex. Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion. A mutex \"unlock\" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up. See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics: \t\"mutex_unlock() may access the mutex structure even after it has \t internally released the lock already - so it's not safe for \t another context to acquire the mutex and assume that the \t mutex_unlock() context is not using the structure anymore\" So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops _their_ reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it. Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole _point_ of refcounts: unlike mutexes, they are inherently about object lifetimes).", "cve_priority": "high", "cve_public_date": "2025-07-18 08:15:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-80726", "url": "https://ubuntu.com/security/CVE-2026-80726", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-46113", "url": "https://ubuntu.com/security/CVE-2026-46113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, \"KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE\", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the \"correct\" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the \"wrong\" shadow page. However, that was only an imprecision until 2032a93d66fa (\"KVM: MMU: Don't allocate gfns page for direct mmu pages\") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-52988", "url": "https://ubuntu.com/security/CVE-2026-52988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase Publish new hooks in the list into the basechain/flowtable using splice_list_rcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on.", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2023-53231", "url": "https://ubuntu.com/security/CVE-2023-53231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: Fix detection of atomic context Current check for atomic context is not sufficient as z_erofs_decompressqueue_endio can be called under rcu lock from blk_mq_flush_plug_list(). See the stacktrace [1] In such case we should hand off the decompression work for async processing rather than trying to do sync decompression in current context. Patch fixes the detection by checking for rcu_read_lock_any_held() and while at it use more appropriate !in_task() check than in_atomic(). Background: Historically erofs would always schedule a kworker for decompression which would incur the scheduling cost regardless of the context. But z_erofs_decompressqueue_endio() may not always be in atomic context and we could actually benefit from doing the decompression in z_erofs_decompressqueue_endio() if we are in thread context, for example when running with dm-verity. This optimization was later added in patch [2] which has shown improvement in performance benchmarks. ============================================== [1] Problem stacktrace [name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291 [name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi [name:core&]preempt_count: 0, expected: 0 [name:core&]RCU nest depth: 1, expected: 0 CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1 Hardware name: MT6897 (DT) Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4 [2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/", "cve_priority": "medium", "cve_public_date": "2025-09-15 15:15:00 UTC" }, { "cve": "CVE-2023-53707", "url": "https://ubuntu.com/security/CVE-2023-53707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1 The type of size is unsigned int, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later.", "cve_priority": "medium", "cve_public_date": "2025-10-22 14:15:00 UTC" }, { "cve": "CVE-2024-49568", "url": "https://ubuntu.com/security/CVE-2024-49568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg When receiving proposal msg in server, the fields v2_ext_offset/ eid_cnt/ism_gid_cnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2_ext_offset, once exceed the max value, there has the chance to access wrong address, and crash may happen. This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt before using them.", "cve_priority": "high", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2026-89560", "url": "https://ubuntu.com/security/CVE-2026-89560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation Whiteout objects are used in the upper layer of an OverlayFS to indicate that the file with this name does not exist in the unified view, even if it is present in one of the lower layer file systems. For the userspace implementations of OverlayFS (fuse-overlayfs), whiteout objects can be created from userspace as well: * mknod(2) with S_IFCHR and makedev(0, 0) * renameat2(2) with RENAME_WHITEOUT, creating the whiteout in the old place of the moved file. This commit guards whiteout creation in both of these cases with LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered character devices and are not bound to a driver. LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a whiteout object: creating one is the only S_IFCHR creation that the VFS exempts from CAP_MKNOD, so it is as unprivileged as creating a regular file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that expose a kernel interface [1]. For the mknod(2) case, introduce a Landlock erratum. The creation of whiteout objects through mknod(2) was previously guarded using LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using LANDLOCK_ACCESS_FS_MAKE_REG. For the renameat2(2) case, fix a bug: Before this commit, renameat2(2) with RENAME_WHITEOUT would create a directory entry even when all LANDLOCK_ACCESS_FS_MAKE_* rights were denied. This does not affect normal renames within layered OverlayFS mounts: When doing a regular rename() on a mounted fuse-overlayfs, it is the fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT, and only the Landlock domain of that daemon is checked there. Depends-on: 49c9e09d9610 (\"landlock: Fix handling of disconnected directories\") Depends-on: fe72ce6710cb (\"landlock: Add errata documentation section\") [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and add link(2) to the user doc]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2024-41062", "url": "https://ubuntu.com/security/CVE-2024-41062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bluetooth/l2cap: sync sock recv cb and release The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work \t l2cap_sock_release hci_acldata_packet \t l2cap_sock_kill l2cap_recv_frame \t sk_free l2cap_conless_channel \t l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.", "cve_priority": "high", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2022-50406", "url": "https://ubuntu.com/security/CVE-2022-50406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: iomap: fix memory corruption when recording errors during writeback Every now and then I see this crash on arm64: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dm_thin_pool dm_persistent_data XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296). dm_bio_prison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0 dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECT potentially unexpected fatal signal 6. nf_reject_ipv6 potentially unexpected fatal signal 6. ipt_REJECT nf_reject_ipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) ip_tables pc : 000003fd6d7df200 x_tables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wb_workfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseq_set+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : __filemap_set_wb_err+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseq_set+0x1c/0x100 __filemap_set_wb_err+0x24/0xe0 iomap_do_writepage+0x5e4/0xd5c write_cache_pages+0x208/0x674 iomap_writepages+0x34/0x60 xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: ---truncated---", "cve_priority": "low", "cve_public_date": "2025-09-18 16:15:00 UTC" }, { "cve": "CVE-2026-97523", "url": "https://ubuntu.com/security/CVE-2026-97523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close race between scheduler and state change The mptcp scheduler may race with subflow sockets state change: data transmission on the selected socket may fail and a later release could try to use mss_now reset to 0 for a divide operation. Address the issue by explicitly checking for the critical scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97524", "url": "https://ubuntu.com/security/CVE-2026-97524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid unneeded actions on subflow reset Once in a blue moon, the mptcp receive path can recursively call mptcp_data_ready() via state change under unlucky error conditions, and then try to hold the data lock again. Break the recursion loop explicitly checking for the exceptional condition. Add a new flag instead of using an existing one like 'closing', to exit early in subflow_state_change(), and explicitly flush the RX queue at reset time. This avoids unneeded processing to check for available data -- calling get_mapping_status() and more on a dying subflow -- but also in error reporting and worker scheduling. Note that we must consume the currently peeked skb before invoking mptcp_dss_corruption to avoid consuming it again after the eventual reset has freed it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-80833", "url": "https://ubuntu.com/security/CVE-2026-80833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ss support which is one of the only remaining ones. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. Also, it had a buffer overread bug in the line 'memcpy(ctx->seed, d + dlen, ctx->slen);'. There's no point in fixing these bugs separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80834", "url": "https://ubuntu.com/security/CVE-2026-80834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ce support which is one of the only remaining ones. Note that the sun8i-ce support for hwrng remains in place. That is the interface that actually matters. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. There's no point in fixing this separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-74496", "url": "https://ubuntu.com/security/CVE-2026-74496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Fix use-after-free in fou_create() fou_create() publishes struct fou through sk_user_data before adding the new FOU port to the per-netns list. If fou_add_to_port_list() fails, the error path frees fou while it is still reachable through sk_user_data. A concurrent receive can then dereference the freed object in fou_from_sock(). This ordering issue was previously noted in the linked discussion. The failure is reachable when local port 0 is requested. Each socket binds to a different ephemeral port, but fou_cfg_cmp() compares the requested port 0 and reports -EALREADY once an entry already exists. Release the tunnel socket before freeing fou so sk_user_data is cleared first, and defer reclamation with kfree_rcu() to protect concurrent RCU readers. This matches the lifetime handling in fou_release().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-93286", "url": "https://ubuntu.com/security/CVE-2026-93286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: appletalk: fix NULL pointer dereference in aarp_send_ddp() aarp_send_ddp() calls atalk_find_dev_addr(dev) in the LocalTalk fast path without checking for NULL. When the device has no AppleTalk interface configured (dev->atalk_ptr == NULL), this leads to a NULL pointer dereference at the at->s_net access. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:aarp_send_ddp (net/appletalk/aarp.c:552 (discriminator 2)) Call Trace: atalk_sendmsg (net/appletalk/ddp.c:1715) __sys_sendto (net/socket.c:2265 (discriminator 1)) __x64_sys_sendto (net/socket.c:2272) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Add a NULL check consistent with the other callers of atalk_find_dev_addr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93287", "url": "https://ubuntu.com/security/CVE-2026-93287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: reject oversized block transfers in the common path The SMBus block transfer length data->block[0] is validated in i2c_smbus_xfer_emulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbus_xfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked. Add an early validation in __i2c_smbus_xfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback runs. data->block[0] is filled in by the device on SMBus block reads, so the check is scoped to operations where the length is actually supplied by the caller. This is consistent with the existing -EINVAL convention in the emulated path and protects all downstream consumers at once: the smbus_write tracepoint, all native smbus_xfer driver implementations, and the emulated path. Two distinct bugs are fixed by this change: Bug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h) trace_smbus_write() fires before any validation and copies data->block[0]+1 bytes into a 34-byte event buffer. With block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221. BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91 Call Trace: __asan_memcpy+0x23/0x80 trace_event_raw_event_smbus_write+0x27c/0x530 __i2c_smbus_xfer+0x43a/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c) stub_xfer() implements .smbus_xfer directly and only clamps block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With block[0]=0xff and command=0 the loop accesses block[1+i] for i up to 254, far past the 34-byte union. UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44 index 34 is out of range for type '__u8 [34]' Call Trace: __ubsan_handle_out_of_bounds+0xd7/0x120 stub_xfer+0x1971/0x198f [i2c_stub] __i2c_smbus_xfer+0x306/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97931", "url": "https://ubuntu.com/security/CVE-2026-97931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: us122l: Prevent write upgrades for read mappings The hwdep mmap callback rejects read-buffer mappings that are initially writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ. A process that can open the hwdep node O_RDWR can later use mprotect() to make the mapping writable. The read allocation begins with struct usb_stream. Its read_size member is used by the fault handler to decide which pages belong to the read buffer. The read VMA intentionally remains expandable because pcm_usb_stream uses mremap() after reading that size. Changing read_size first can therefore map and access pages beyond the allocation. The same member is also consumed by usb_stream_free(), where changing it can make free_pages_exact() release pages outside the allocation. Clear VM_MAYWRITE for read-buffer mappings after rejecting an initially writable VMA. This keeps the separate output-buffer mapping writable while preventing later permission upgrades.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97568", "url": "https://ubuntu.com/security/CVE-2026-97568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: syncookies: remember the request backup flag Instead of using an uninitialised bit when copying the info in subflow_ulp_clone(). To fix this, no need to extend the join_entry structure: backup is coming from struct mptcp_subflow_request_sock, only one bit. Do the same here by using one bit for both.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97572", "url": "https://ubuntu.com/security/CVE-2026-97572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Propagate RX ring init failures in bnxt_init_nic() bnxt_init_rx_rings() returns an error when bnxt_alloc_one_rx_ring() fails, but bnxt_init_nic() discards that return value and calls bnxt_init_chip(), which enables TPA. If an allocation fails, this could leave rxr->rx_tpa[] partially zeroed and TPA would be enabled over an array with zeroed entries. This would lead to a zeroed DMA address being handed out if the agg_idx is translated to a SW index at a zeroed entry. Fix this by propagating the error out of bnxt_init_nic(). Both callers already check its return value and unwind with bnxt_free_skbs() and bnxt_free_mem(), which tolerate a partially initialized RX ring.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97573", "url": "https://ubuntu.com/security/CVE-2026-97573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset() bnxt_rx_ring_reset() frees the ring buffers and then reallocates them, ignoring the result. bnxt_alloc_one_rx_ring() can fail in bnxt_alloc_one_tpa_info_data(), which returns -ENOMEM on the first failed allocation and leaves the remaining rxr->rx_tpa[] entries zeroed. The error isn't propagated up, so the loop in bnxt_rx_ring_reset continues and at the end the code re-enables TPA with partially unallocated rx_tpa array. This means that when the agg_id from hardware is mapped to a SW index in rxr->rx_tpa[], an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by falling back to a global reset, which is what the existing code already does when other functions fail, but unlike the other failure cases this particular failure has to return because TPA can't be re-enabled since the allocation failed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97576", "url": "https://ubuntu.com/security/CVE-2026-97576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC tile counts The stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from column_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[] and use them as tile-loop bounds, but std_validate_compound() does not bound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling enabled whose tile counts exceed the uAPI array capacity, mirroring the existing compound-control range checks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97582", "url": "https://ubuntu.com/security/CVE-2026-97582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gpio-fan) Fix use-after-free in alarm work fan_alarm_irq_handler() queues fan_data->alarm_work, but nothing cancels it. fan_alarm_notify() dereferences fan_data and its hwmon device. On unbind, devres frees the interrupt, which only waits for the handler itself, and then releases the hwmon device and fan_data, so a pending fan_alarm_notify() can run after those frees. Replace INIT_WORK() with devm_work_autocancel(), registered before devm_request_irq(). The devres cleanup then frees the interrupt first, so no new work can be queued, and cancels the work while fan_data and the hwmon device are still alive. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97592", "url": "https://ubuntu.com/security/CVE-2026-97592", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done. Similar with the buffers which are part of the gcm_sg_walk structs from the variables gw_in and gw_out.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97596", "url": "https://ubuntu.com/security/CVE-2026-97596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reject invalid states in connection template sync records IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6 records.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97598", "url": "https://ubuntu.com/security/CVE-2026-97598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: bound automatic table ID allocation fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment (\"ip rule ... table 0\") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TABLE_MAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable. The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97601", "url": "https://ubuntu.com/security/CVE-2026-97601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97604", "url": "https://ubuntu.com/security/CVE-2026-97604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vfb: defer cleanup until the last reference FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114) Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489) unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97608", "url": "https://ubuntu.com/security/CVE-2026-97608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: unregister loggers before per-net teardown nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL lock nf_log_mutex find logger in loggers[][] net->nf.nf_loggers[pf] = logger unlock nf_log_mutex nf_log_unregister(logger) lock nf_log_mutex loggers[pf][type] = NULL unlock nf_log_mutex synchronize_rcu() module exit returns module core frees backend memory Later, a sysctl read or packet logging operation can dereference the stale per-net logger pointer. Fix this by unregistering the global logger backends before tearing down per-net state. Once the global registrations are gone, later writers can no longer rebind the logger. unregister_pernet_subsys() already waits for an RCU grace period after the pre-exit callback clears the per-net selection, while nf_log_unregister() continues to cover readers of the global logger table. Apply this ordering fix to both nf_log backends that combine per-net teardown with global logger registration.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97611", "url": "https://ubuntu.com/security/CVE-2026-97611", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix use-after-free of the flow table mask array tbl_mask_array_realloc() retires the old mask_array before it stops being reachable: \told = ovsl_dereference(tbl->mask_array); \tif (old) { \t\t... \t\tcall_rcu(&old->rcu, mask_array_rcu_cb); \t} \trcu_assign_pointer(tbl->mask_array, new); call_rcu() only waits for read-side critical sections already in flight. tbl->mask_array still points at old between the call_rcu() and the rcu_assign_pointer(), so a reader entering ovs_flow_tbl_lookup_stats() in that window picks up old in a fresh critical section that the pending grace period does not cover. tbl_mask_array_realloc() runs in process context under ovs_mutex, so the window is preemptible and can outlast the grace period. Then mask_array_rcu_cb() frees old before the swap runs: BUG: KASAN: slab-use-after-free in flow_lookup.constprop.0+0x2bf/0x2f0 Read of size 8 at addr ffff888020b3e018 by task poc/741 flow_lookup.constprop.0+0x2bf/0x2f0 ovs_flow_tbl_lookup_stats+0x4a3/0x5c0 ovs_dp_process_packet+0x19c/0x710 ovs_vport_receive+0x243/0x390 internal_dev_xmit+0x81/0x170 Freed by task 728: kfree+0x16a/0x4e0 rcu_core+0x853/0x1030 Publish the new array before retiring the old one. The kfree_rcu() that call_rcu() replaced ran after the swap.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97612", "url": "https://ubuntu.com/security/CVE-2026-97612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: clear inner_protocol when the last label is popped skb_mpls_push() records the pre-encapsulation network header once, gated on !skb->inner_protocol. skb_mpls_pop() never clears that record, so it outlives the encapsulation it describes. Open vSwitch can then re-push MPLS onto a packet whose inner_network_header still points at the older, deeper offset: push a label, pop every label, recirculate (ovs_flow_key_update() re-derives key->eth.type and resets network_header, but leaves inner_*), then push again. ovs_fragment() trusts the record: \tskb->network_header = skb->inner_network_header; so skb_network_offset() goes negative. The bound check is signed: \tif (skb_network_offset(skb) > MAX_L2_LEN) a negative offset passes it, and prepare_frag() widens the value: \tunsigned int hlen = skb_network_offset(skb); \tmemcpy(&data->l2_data, skb->data, hlen); which is a ~4GiB memcpy out of a 30-byte per-CPU buffer. Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8): BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 prepare_frag+0x3df/0x4e0 ovs_fragment+0x589/0x7e0 do_output+0x4ce/0x5e0 do_execute_actions+0x55d2/0x7b30 ovs_execute_actions+0xea/0x450 Same root-cause shape as commit 975b5b067f52 (\"ipv6: sr: restore network header before routing and forwarding\"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path. Clear inner_protocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/act_mpls.c is the only other skb_mpls_pop() caller and gets the same fix; sch_frag.c saves and restores inner_protocol around fragmentation in the same way OVS does.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97899", "url": "https://ubuntu.com/security/CVE-2026-97899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix memory leak in query_perf_config_list() When krealloc() fails, free the original oa_config_ids before returning to avoid a memory leak. (cherry picked from commit 9977e9d84f46d4f12ad35fbbc0ec4638554bce87)", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97904", "url": "https://ubuntu.com/security/CVE-2026-97904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: initialize policy rwsem before sysfs publication cpufreq_policy_alloc() initializes policy->rwsem after kobject_init_and_add() has created the policy sysfs directory and its default attributes. A sysfs access can therefore reach a policy callback before the semaphore has been initialized. Initialize policy->rwsem before publishing the policy kobject so sysfs callbacks always see an initialized semaphore.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97905", "url": "https://ubuntu.com/security/CVE-2026-97905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: zero-initialize policy cpumask before sysfs publication cpufreq_policy_alloc() allocates policy->cpus with alloc_cpumask_var(), i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate kmalloc_node() allocation, so its bitmap holds whatever the slab allocator left behind: cpufreq_online() cpufreq_policy_alloc() alloc_cpumask_var(&policy->cpus) /* bitmap is uninitialized */ kobject_init_and_add() /* policy%u/ appears in sysfs */ cpufreq_policy_online() cpumask_copy(policy->cpus, cpumask_of(cpu)) /* first valid value */ This leaves a window in which the sysfs attributes are already reachable while policy->cpus is still garbage. show()/store() gate on policy_is_inactive(), i.e. cpumask_empty(policy->cpus), so a non-zero bitmap makes them run the attribute callbacks on a policy that is not initialized yet. Fix this by using zalloc_cpumask_var() for policy->cpus.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97909", "url": "https://ubuntu.com/security/CVE-2026-97909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: initialize IRQ lock before requesting IRQ uni_reader_init() registers the shared IRQ before initializing reader->irq_lock. A pending interrupt can invoke the handler while the lock is still uninitialized. Initialize the lock before registering the IRQ so the interrupt path always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97910", "url": "https://ubuntu.com/security/CVE-2026-97910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sprd: validate compress buffer sizes against fixed allocations sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the fixed allocations. A fragment_size larger than the 32K IRAM data area makes the stage 0 copy_from_user() overflow past the IRAM allocation, and a buffer_size larger than the 2M DDR buffer makes the wrapping copy at the end of sprd_platform_compr_copy() write fully user controlled data past the buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP state reaches the copy callback directly. Reject parameters that do not fit into the fixed buffers in set_params(), and fix the advertised max fragment size: 128K never fitted into the 32K IRAM buffer. The caps values may have been carried over from the qdsp6 driver, which allocates its buffers according to the advertised maxima, unlike this driver. With 32K as max fragment size the advertised limits are self-consistent: 32K * 64 = 2M equals the DDR buffer size. Discovered by Atuin - Automated Vulnerability Discovery Engine.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97923", "url": "https://ubuntu.com/security/CVE-2026-97923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the var ref when its initialization fails create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 (\"tracing: Use hist trigger's var_ref array to destroy var_refs\") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it. The call was correct when it was written, before var refs were taken out of destroy_hist_field(). init_var_ref() cannot free it either. The caller owns the field, so init_var_ref() undoes only its own string allocations and leaves the field alone. Freeing it there would leave create_var_ref() passing freed memory to destroy_hist_field(), which reads its flags. Call __destroy_hist_field(), which frees the field without consulting the flag.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97926", "url": "https://ubuntu.com/security/CVE-2026-97926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: validate cylinder group metadata before caching it ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: \tucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); \tucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); \tucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); \tucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: - c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32 bit count outside the s_csp allocation. - c_frotor becomes a bitmap scan start, start = c_frotor >> 3, and then length = ((s_fpg + 7) >> 3) - start. A start beyond the block bitmap wraps the unsigned length to a huge value, so ubh_scanc() walks far past the cylinder group buffers. c_irotor drives the inode bitmap the same way. A crafted image can set any of these freely, turning an ordinary allocation into an out of bounds access. Reject a cylinder group whose recorded index does not match the group being read, or whose rotors fall outside the group, before the metadata is cached. Valid filesystems keep cg_cgx equal to the group number and the rotors within the group, so only malformed images are rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97927", "url": "https://ubuntu.com/security/CVE-2026-97927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: create the root dentry after loading cylinder metadata ufs_fill_super() installed sb->s_root before it loaded the cylinder group structures for a writable mount: \tsb->s_root = d_make_root(inode); \t... \tif (!sb_rdonly(sb)) \t\tif (!ufs_read_cylinder_structures(sb)) \t\t\tgoto failed; When ufs_read_cylinder_structures() failed, the error path freed the in-core superblock information and set sb->s_fs_info to NULL while sb->s_root stayed installed. get_tree_bdev() then reached deactivate_locked_super(), and because s_root was present, generic_shutdown_super() called sync_filesystem() and the put_super operation. Both dereference UFS_SB(sb), which is now NULL, so a mount that fails only while reading the cylinder groups oopses during teardown. A crafted image whose first cylinder group cannot be read reaches this path. Load the cylinder group metadata first and create the root dentry last, so the superblock is published to the VFS only once it is fully set up. ufs_setup_cstotal() and ufs_read_cylinder_structures() take only the super_block and do not use the root inode, so the reordering is safe.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97930", "url": "https://ubuntu.com/security/CVE-2026-97930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf The in04_last array in struct usx2ydev is declared as char[24], but in04_buf is allocated as sizeof(struct us428_ctls) which is 21 bytes. In i_usx2y_in04_int(), when ctl_snapshot_last == -2 (initialization path): memcpy(usx2y->in04_last, usx2y->in04_buf, sizeof(usx2y->in04_last)); This copies 24 bytes from a 21-byte slab allocation, reading 3 bytes past the end of the source object. Introduce a USX2Y_IN04_SIZE constant defined as sizeof(struct us428_ctls) and use it consistently for the in04_last array, the in04_buf allocation, the URB transfer length, and the comparison loop, replacing the bare 24 and 21 literals throughout.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97940", "url": "https://ubuntu.com/security/CVE-2026-97940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix fib6 walker UAF on seq stop ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a never-started iterator with a zeroed private object is not treated as linked. The same stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only widens the race.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97948", "url": "https://ubuntu.com/security/CVE-2026-97948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver The commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") refactored the EEH code such that the pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken. [<0>] 0xc00000011c78f870 [<0>] __switch_to+0xfc/0x1a0 [<0>] pci_lock_rescan_remove+0x30/0x44 [<0>] eeh_rmv_device+0x290/0x2e0 [<0>] eeh_pe_dev_traverse+0x80/0x130 [<0>] eeh_reset_device+0xcc/0x23c [<0>] eeh_handle_normal_event+0x830/0xa80 [<0>] eeh_event_handler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] start_kernel_thread+0x14/0x18 The issue is seen for cases where the errors are detected on the PHB directly AND|OR for devices where the driver error_detected() returns PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no error handlers like slot_reset(), resume() etc defined).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-74743", "url": "https://ubuntu.com/security/CVE-2026-74743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: inherit needed_headroom and needed_tailroom from lowerdev macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-89792", "url": "https://ubuntu.com/security/CVE-2026-89792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds reads in share config responses Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-97951", "url": "https://ubuntu.com/security/CVE-2026-97951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands When a LUN_RESET aborts a WRITE command that is in the TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and waits for the frontend to finish processing. If the initiator subsequently sends the remaining dataout PDUs, __iscsit_check_dataout_hdr() catches the payload, stops the dataout timer if the sequence is final and finally dumps the data. However, the iSCSI target doesn't trigger the completion process for these aborted commands. Because of this, the abort path hangs indefinitely in target_put_cmd_and_wait(), leading to a deadlocked target worker thread. Fix this by explicitly calling target_complete_cmd() when the final dataout PDU is received for an aborted WRITE command. target_complete_cmd() detects the CMD_T_ABORTED flag and cleanly routes the command into target_abort_work, allowing the abort completion to successfully unblock.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-97952", "url": "https://ubuntu.com/security/CVE-2026-97952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunvdc: unmap LDC cookies when the descriptor send fails __send_request() maps the request's pages into the LDC channel's map table (ldc_map_sg()), fills in the descriptor and marks it VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger(). When the trigger fails, the error path only prints a message: the descriptor stays READY and the cookies are never unmapped. The mapping is normally released in vdc_end_one() when the peer completes the descriptor - but a descriptor whose doorbell was never sent will never complete, and since dr->prod is not advanced on failure, the reset path (vdc_requeue_inflight(), which walks [cons, prod)) never visits it either. The map table entries are leaked permanently. Since commit a11f6ca9aef9 (\"sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN\") trigger failures occur in practice under load, so every resulting I/O error also leaks one request's worth of entries from the fixed-size (8192 entries per channel) map table. Because the allocator hands out contiguous ranges, fragmentation makes large multi-segment requests fail first as the table drains, until ldc_map_sg() fails permanently and the disk is dead until reboot. It also makes any retry-based recovery unusable: requeuing the request on -EAGAIN remaps the pages on every attempt, overwriting desc->cookies and orphaning the previous mapping, so the table drains at the retry rate. This is the memory exhaustion observed when the requeue approach was first tested in October 2025. Roll back on failure: unmap the cookies, mark the descriptor FREE again and clear the request entry. If the trigger failed with -ENOTCONN, __vdc_tx_trigger() has already reset the port, which tears down and reallocates both the dring and the LDC channel including its map table - nothing to roll back, and the stale descriptor must not be touched.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97954", "url": "https://ubuntu.com/security/CVE-2026-97954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix tcp stream corruption with large pages rds_message_map_pages() assigns PAGE_SIZE bytes to every scatterlist entry, even when total_len ends in a partial page. The RDS congestion map is defined as 8192 bytes, so on systems with PAGE_SIZE greater than 8192 the scatterlist maps bytes beyond the end of the congestion map. RDS-TCP transmits the SG contents according to those lengths, so the extra bytes become part of the TCP RDS stream and are interpreted as subsequent RDS message headers, corrupting the stream. Limit the final scatterlist mapping to the number of bytes remaining. This has no effect on systems with a 4K page size and allows RDS-TCP to be used on systems with 16K and larger page sizes. The RDS selftest, which previously hung on 16K pages, now passes.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97957", "url": "https://ubuntu.com/security/CVE-2026-97957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix mailbox segment buffer overflow check_mbox_seq_id_and_seg_len() validates that seq_id does not exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed MBOX_SEG_LEN (48). However, this allows the last segment (seq_id=42) to carry a full 48-byte payload, writing to offset 42*48=2016 for 48 bytes (ending at byte 2064). The receive buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a 16-byte heap buffer overflow. The hinic3 driver already handles this correctly by defining MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it exceeds the remaining buffer space. Apply the same fix to the hinic driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97958", "url": "https://ubuntu.com/security/CVE-2026-97958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain(). If a netlink socket sends RTM_GETCHAIN requests repeatedly without recv()ing the responses, tc_ctl_chain() hogs CPU and triggers Hung Task splat. [0] As caught in the stack trace, netlink_attachskb() could confuse tc_ctl_chain() by returning -EAGAIN when the userspace netlink socket's receive buffer is full. The replay: label exists since commit 32a4f5ecd738 (\"net: sched: introduce chain object to uapi\") but was not used initially. Since commit 9f407f1768d3 (\"net: sched: introduce chain templates\"), the label is needed for RTM_NEWCHAIN because tcf_proto_lookup_ops() may release RTNL to call request_module(). However, the replay logic is unnecessary for RTM_GETCHAIN. Let's apply the replay logic only for RTM_NEWCHAIN. [0]: INFO: task repro:1018 is blocked on a mutex likely owned by task repro:1022. task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 task_flags:0x400040 flags:0x00080000 Call Trace: ? clockevents_program_event (kernel/time/clockevents.c:372) ? pskb_expand_head (net/core/skbuff.c:615) ? skb_release_data (net/core/skbuff.c:1122) ? netlink_attachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/af_netlink.c:1232) ? __netlink_lookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/af_netlink.c:499) ? tc_chain_notify (net/sched/cls_api.c:3045) ? tc_chain_notify (./include/linux/skbuff.h:1384 net/sched/cls_api.c:3041) ? netlink_unicast (net/netlink/af_netlink.c:1335) ? rtnl_unicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985) ? tc_ctl_chain (net/sched/cls_api.c:3242) ? rtnetlink_rcv_msg (net/core/rtnetlink.c:7146) ? netlink_unicast (net/netlink/af_netlink.c:1354) ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:7177) ? netlink_rcv_skb (net/netlink/af_netlink.c:2556) ? netlink_unicast (net/netlink/af_netlink.c:1319) ? netlink_sendmsg (net/netlink/af_netlink.c:1900) ? __sock_sendmsg (net/socket.c:800) ? __sys_sendto (net/socket.c:2281) ? __x64_sys_sendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284) ? do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97959", "url": "https://ubuntu.com/security/CVE-2026-97959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_route: free emptied bucket on filter move route4_change can move an existing filter to a different top-level bucket: route4_set_parms recomputes the handle from TCA_ROUTE4_TO/ FROM/IIF, and the handle-mismatch check is gated on the 'new' flag, so for an existing filter the new handle may differ from the old one and land in a different bucket. When this happens, the filter is unlinked from the old bucket, but the bucket itself is never freed once it goes empty. The stale empty bucket remains in head->table[], causing route4_delete to report *last=false even after the last live filter is gone. That pins the empty tcf_proto and causes a leak. Fix this by refcounting the filters linked to a bucket and freeing the bucket when the count drops to zero. The existing scan in route4_delete goes away with it. The count is updated at all sites that link or unlink a filter during add, change and delete, and the bucket is dropped from head->table[] as soon as it reaches zero. Conditions to recreate the bug: CONFIG_NET_CLS_ROUTE4=y, CONFIG_NET_SCH_INGRESS=y, CONFIG_NET_CLS_ACT=y. tc qdisc replace dev lo clsact tc filter add dev lo ingress protocol ip pref 100 route from 1 to 1 tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \\ route from 1 to 2 tc filter del dev lo ingress protocol ip pref 100 handle 0x10002 \\ route from 1 to 2 tc filter show dev lo ingress | grep -c 'pref 100 route chain 0 '", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97963", "url": "https://ubuntu.com/security/CVE-2026-97963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: initialize ptp_lock at probe time priv->ptp_lock is only initialized in stmmac_ptp_register(), which runs during __stmmac_open(). However, the lock is also used while the interface is down and has never been opened: tc_taprio_configure() invokes the PTP gettime64() callback to compute the EST base time when offloading a TAPRIO schedule, and stmmac_get_time() takes priv->ptp_lock. Using an uninitialized rwlock is undefined behaviour. Move the rwlock_init() to __stmmac_dvr_probe(), together with the other private locks, so that ptp_lock is always valid regardless of the interface state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97964", "url": "https://ubuntu.com/security/CVE-2026-97964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_synctty: ensure a writeable skb header ppp_sync_txmunge() checks headroom before prepending the address and control bytes, but does not ensure that the skb header is writable. A received skb can reach this function through PPP channel bridging without passing through ppp_start_xmit(), which calls skb_cow_head(). For example, a PPPoE frame may share its buffer with a clone queued to an AF_PACKET socket. If it is bridged to a synchronous tty channel, the address/control bytes can overwrite data still visible to that socket. Use skb_cow_head() to ensure both sufficient headroom and a writable header.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97969", "url": "https://ubuntu.com/security/CVE-2026-97969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix clock leak and spurious timer in settimeout() msc313e_wdt_settimeout() unconditionally calls msc313e_wdt_start() which introduces two severe bugs: 1. If the watchdog is already active, calling start() again will increase the reference count of the clock again. However stop() is only called once, the reference count is unbalance. 2. If the watchdog is stopped, calling settimeout() will start the hardware timer accidentally. Factor out the register-writing logic into a helper function. Only call it in settimeout() if the watchdog is running. Otherwise, simply update `wdev->timeout`.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97970", "url": "https://ubuntu.com/security/CVE-2026-97970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Avoid division by zero clk_get_rate() could return 0. Avoid a division by zero panic.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97981", "url": "https://ubuntu.com/security/CVE-2026-97981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Count dropped frames as NAPI work The RX loop only consumes budget when it successfully delivers a frame. Error paths keep consuming descriptors without reducing the budget, so a stream of bad frames can process the entire receive ring in one poll. Move the budget accounting to a common end-of-frame path. This counts each completed frame as NAPI work whether it was delivered or dropped, matching the behavior of the vendor driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97982", "url": "https://ubuntu.com/security/CVE-2026-97982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Fix budget accounting The gmac_rx() function returns the remaining NAPI budget, but its caller treats the return value as the number of packets received. An idle poll therefore reports a full budget and remains scheduled. Return the number of received packets instead. Preserve the existing free queue refill accounting by adding that count directly; continuing to subtract it from the budget would invert the refill behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97991", "url": "https://ubuntu.com/security/CVE-2026-97991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim_blk: reject out-of-range sector starts vdpasim_blk_check_range() logs an invalid start sector but continues validating the request. The subsequent unsigned capacity subtraction can underflow and let an out-of-range buffer offset reach the data path. The invalid offset is used by three request paths. VIRTIO_BLK_T_OUT copies guest data to blk->buffer + offset through vringh_iov_pull_iotlb(), causing an out-of-bounds write in _copy_from_iter() or memcpy(). VIRTIO_BLK_T_IN copies from blk->buffer + offset to the guest through vringh_iov_push_iotlb(), causing an out-of-bounds read in _copy_to_iter(). VIRTIO_BLK_T_WRITE_ZEROES passes blk->buffer + offset to memset(), causing an out-of-bounds write. Reject starts at or beyond the capacity before the subtraction. Treat the capacity boundary as invalid because the IN and OUT paths round byte counts down to sectors for validation but later copy the original byte counts. A sub-sector request at the capacity boundary would otherwise still access past the end of the buffer. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97993", "url": "https://ubuntu.com/security/CVE-2026-97993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx vhost_vdpa_set_config_call() swaps the eventfd_ctx_fdget() return value into v->config_ctx before checking it, so on failure the field briefly holds an ERR_PTR: \tctx = fd == VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd); \tswap(ctx, v->config_ctx); \tif (!IS_ERR_OR_NULL(ctx)) \t\teventfd_ctx_put(ctx); \tif (IS_ERR(v->config_ctx)) { \t\tlong ret = PTR_ERR(v->config_ctx); \t\tv->config_ctx = NULL; \t\treturn ret; \t} Commit 0bde59c1723a (\"vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails\") added that clearing, and spelled out the invariant the rest of the file relies on: \"we consider 'v->config_ctx' valid if it is not NULL\". The window between the swap and the clearing still breaks it. vhost_vdpa_config_cb() only tests for NULL, so a config interrupt delivered inside the window hands the ERR_PTR to eventfd_signal(). Check the fd before installing it instead. That closes the window and matches how vhost_vring_ioctl() handles the same failure for the vq call fd. It also stops a rejected fd from tearing down a config interrupt that was working: until now the swap replaced the live context and put it, so after an EBADF the device silently stopped delivering config interrupts until userspace installed a new fd.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97995", "url": "https://ubuntu.com/security/CVE-2026-97995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_console: do not free control-out buffers on remove __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): \tfree_buf \tremove_vqs \tvirtcons_remove \tunbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97998", "url": "https://ubuntu.com/security/CVE-2026-97998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: cope with concurrent instance destruction Instances are refcounted. However, only memory release happens on the 1 -> 0 transition; the unlink from hashes can occur with any refcount. Uncooperative userspace can force a situation where a queue is pending for destruction from netlink event while a different socket with same portid processes an UNBIND request. With right timing, this will unhash the instance again: Oops: general protection fault, [..] Call Trace: nfulnl_recv_config+0x31a/0xd50 nfnetlink_rcv_msg+0x7c2/0xeb0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98006", "url": "https://ubuntu.com/security/CVE-2026-98006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev The epq_in_urb object belonging to the caiaq device is coupled within the struct snd_usb_caiaqdev. After usb_submit_urb(epq_in_urb, GFP_KERNEL) executes successfully, epq_in_urb is successfully added to the urbp_list queue of the dummy HCD driver (userspace specifies dummy_hcd as the HCD layer driver for the caiaq USB device). When init_card() calls snd_usb_caiaq_send_command() which subsequently fails due to a timeout, and proceeds to call snd_card_free() to release the card, the embedded ep1_in_urb object is also freed. When the dummy HCD driver detects that the URB has been unlinked, it returns the URB (by usb_hcd_giveback_urb()), which triggers [1]. Decouple the ep1_in_urb object from the struct snd_usb_caiaqdev and switch to using a pointer instead. Separately allocate and manage the memory for ep1_in_urb to prevent the release of the snd_card memory object from interfering with it. midi_out_urb has the same issue as ep1_in_urb and is handled in the same way. [1] BUG: KASAN: slab-use-after-free in usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 Write of size 4 at addr ffff88803cee1050 by task ktimers/1/29 Call Trace: usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 dummy_timer+0xaac/0x4d50 drivers/usb/gadget/udc/dummy_hcd.c:2019 __run_hrtimer kernel/time/hrtimer.c:2067 [inline] __hrtimer_run_queues+0x3eb/0xaf0 kernel/time/hrtimer.c:2124 hrtimer_run_softirq+0x1e1/0x2e0 kernel/time/hrtimer.c:2141 Allocated by task 36: snd_card_new+0x7b/0x110 sound/core/init.c:184 create_card sound/usb/caiaq/device.c:429 [inline] snd_probe+0x236/0x1af0 sound/usb/caiaq/device.c:544 Freed by task 36: snd_card_free_when_closed sound/core/init.c:630 [inline] snd_card_free+0x138/0x1d0 sound/core/init.c:662 snd_probe+0x162b/0x1af0 sound/usb/caiaq/device.c:553", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98009", "url": "https://ubuntu.com/security/CVE-2026-98009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: clamp quantum in parse and fallback paths ets_qdisc_change() falls back to psched_mtu() with no floor for bands without an explicit quantum. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so a zero psched_mtu on a headerless device makes the deficit-refill loop spin under the qdisc lock. Move the floor into ets_quantum_parse() so explicitly configured quanta are also clamped to [256, 1<<20], not just the fallback path. Conditions to recreate the bug: CONFIG_NET_SCH_ETS=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root ets bands 3 strict 2 quanta 1 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98010", "url": "https://ubuntu.com/security/CVE-2026-98010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: drr: clamp quantum in change class drr_change_class() rejects explicit quantum==0 but falls back to psched_mtu() with no floor. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 (or a zero psched_mtu on a headerless device) makes the deficit-refill loop spin under the qdisc lock. Add clamp_t(u32, quantum, 256, 1<<20) after the zero reject and on the fallback path. The explicit-zero reject is preserved. Conditions to recreate the bug: CONFIG_NET_SCH_DRR=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root drr tc class add dev dummy0 parent 1: classid 1:1 drr quantum 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98011", "url": "https://ubuntu.com/security/CVE-2026-98011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum in change and init paths hhf_change() accepts any quantum from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) in hhf_change() matching fq_codel_change(). Clamp hhf_init() to [256, 1<<20] matching the siblings, and remove the old fallback that only set quantum=256 on overflow. Conditions to recreate the bug: CONFIG_NET_SCH_HHF=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root hhf tc qdisc change dev dummy0 root hhf quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98012", "url": "https://ubuntu.com/security/CVE-2026-98012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum in change path sfq_change() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and the init clamp. Conditions to recreate the bug: CONFIG_NET_SCH_SFQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root sfq tc qdisc change dev dummy0 root sfq quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98013", "url": "https://ubuntu.com/security/CVE-2026-98013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp quantum in change path fq_pie_change() accepts any quantum value from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Conditions to recreate the bug: CONFIG_NET_SCH_FQ_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq_pie tc qdisc change dev dummy0 root fq_pie quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98014", "url": "https://ubuntu.com/security/CVE-2026-98014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch, prevent mc_list repopulation during vport disable In mlx5_esw_vport_disable(), move esw_apply_vport_rx_mode() ahead of esw_vport_change_handle_locked() so vport->allmulti_rule is NULL before the change handler observes it. During FW-fatal recovery the disable runs while dev->state == INTERNAL_ERROR. The promisc query inside esw_update_vport_rx_mode() fails and returns early, leaving vport->allmulti_rule intact, so esw_update_vport_mc_promisc() runs and adds MLX5_ACTION_ADD entries to vport->mc_list whose flow rules are then installed in the FDB by esw_add_mc_addr(). esw_destroy_legacy_table() tears down the FDB with those refs still held, corrupting the sub-tree and leaving dangling flow_rule pointers in vport->mc_list. Two-stage failure on `echo 1 > /sys/bus/pci/devices//reset`: refcount_t: underflow; use-after-free. tree_put_node+0xef/0x110 [mlx5_core] clean_tree+0x44/0xd0 [mlx5_core] (x5) mlx5_fs_core_cleanup+0x57/0x1c0 [mlx5_core] mlx5_unload+0x65/0xd0 [mlx5_core] ... mlx5_health_try_recover BUG: unable to handle page fault for address: 0000000003000055 down_write+0x1c/0x60 mlx5_del_flow_rules+0x33/0x1f0 [mlx5_core] esw_del_mc_addr+0x7b/0x170 [mlx5_core] esw_apply_vport_addr_list+0x56/0xf0 [mlx5_core] esw_vport_change_handle_locked+0x28b/0x310 [mlx5_core] mlx5_esw_vport_enable+0x270/0x4a0 [mlx5_core] ... mlx5_load ... mlx5_health_try_recover esw_apply_vport_rx_mode(false, false) clears vport->allmulti_rule via its local state machine even when the FW del fails. With the rule NULL the !IS_ERR_OR_NULL(allmulti_rule) gate in the change handler closes, no rules are installed during disable, and the reload starts with a clean mc_list.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98015", "url": "https://ubuntu.com/security/CVE-2026-98015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put In mlx5_eswitch_termtbl_put(), the zero-ref cleanup check reads tt->ref_count after termtbl_mutex has been released. Two concurrent callers on the same mlx5_termtbl_handle race: one decrements ref_count to zero, removes the hash entry, and calls kfree(tt) while the other has already dropped the mutex and is about to evaluate if (!tt->ref_count), producing a use-after-free. Fix this by capturing the result of the decrement into a stack-local last variable before dropping the mutex. The cleanup decision is now made entirely under termtbl_mutex, and tt is not touched after kfree.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98016", "url": "https://ubuntu.com/security/CVE-2026-98016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free race in sample_restore_put() Concurrent teardown of TC sample rules sharing the same restore context may re-read restore->count after dropping restore_lock. At that point another thread may already have completed cleanup and freed the restore object. Use the result of the refcount decrement while holding restore_lock to determine whether cleanup is needed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98022", "url": "https://ubuntu.com/security/CVE-2026-98022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations Several subsystems allocate ring buffers sized by dev->tx_queue_len with no upper bound. An unprivileged user (via unshare -Urn) can set a huge tx_queue_len and exhaust global memory with ring allocations: - pfifo_fast: pfifo_fast_init() and pfifo_fast_change_tx_queue_len() allocate 3 skb_array rings of tx_queue_len entries each. - tun: tun_queue_resize() and the queue-attach path resize ptr_rings to tx_queue_len on the NETDEV_CHANGE_TX_QUEUE_LEN notifier. - tap (macvtap/ipvtap): tap_queue_resize() and tap_init() resize/init ptr_rings to tx_queue_len on the same notifier. netif_change_tx_queue_len() is the single entry point for IFLA_TXQLEN, sysfs, and the SIOCSIFTXQLEN ioctl. Cap new_len at S16_MAX (32767) there so the oversized value is rejected at set time. This takes effect whether the device is up or down, before dev->tx_queue_len is written, before any notifier fires, and before any ring is allocated. The \"> S16_MAX\" check also subsumes the previous unsigned-long truncation test, and a negative ifr_qlen from the ioctl lands far above the cap after conversion, so both old failure modes are covered by the one comparison. tx_queue_len is ambigious: both a per-ring sizing multiplier and a default queue-length/limit knob for consumers that allocate nothing at set time (pfifo/bfifo/gred/plug/sfb limits, htb direct_qlen, qfq max_classes, teql). 32767 is chosen as the largest value NLA_POLICY_FULL_RANGE can express for the u32 IFLA_TXQLEN policy in patch 2/3 while staying a legitimate queue length on high-BDP paths; the ring-memory trade-off of a shared knob is disclosed below. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn). - pfifo_fast: create veth pairs, set tx_queue_len to 500000, attach mq+pfifo_fast. ~28 iterations OOMs a 2GB guest. - tun: create 50 tun devices with IFF_MULTI_QUEUE, set tx_queue_len to 500000, open 8 queues each. ~1.6GB of ptr_ring allocations OOMs a 512MB guest. - tap: same as tun with IFF_TAP. ~960MB OOMs a 512MB guest. - On the fixed kernel the oversized tx_queue_len is rejected with -ERANGE at set time (all four paths: RTM_SETLINK, RTM_NEWLINK create, sysfs, ioctl - the latter two via this check, the former two via this check and the 2/3 parse policy respectively).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98023", "url": "https://ubuntu.com/security/CVE-2026-98023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: reject dynamic fdb entries that reference a nexthop id The commit cited in the Fixes tag allowed VXLAN FDB entries to point to FDB nexthops so that overlay traffic could be load balanced across multiple VTEPs. Such entries can only be configured from user space, cannot be learned and cannot roam. They only make sense with a user space control plane such as E-VPN where data plane learning is disabled. Despite that, the VXLAN driver does not currently prevent such entries from being configured with the \"dynamic\" flag. The per-nexthop FDB list is only protected by the per-device hash lock, which is not sufficient when two VXLAN devices point to the same FDB nexthop and therefore share the list. Aging runs in softirq context without RTNL, so an entry deleted by one device can race with an addition or deletion from the other, leading to list corruption: list_del corruption. next->prev should be ffff8881069d9548, but was dead000000000122. (next=ffff8881069d9448) WARNING: CPU: 0 PID: 90 at lib/list_debug.c:65 __list_del_entry_valid_or_report+0x1aa/0x210 ... vxlan_fdb_destroy+0x5b8/0xad0 vxlan_cleanup+0x328/0x450 call_timer_fn+0x2a/0x1c0 run_timer_softirq+0x18c/0x210 BUG: KASAN: slab-use-after-free in vxlan_fdb_destroy Fix this by rejecting the bogus configuration of dynamic FDB entries that point to FDB nexthops, both when created and when an existing entry is updated. As such, the per-nexthop FDB list is only ever mutated under the RTNL lock. Add test cases to make sure that this does not regress in the future.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98025", "url": "https://ubuntu.com/security/CVE-2026-98025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is \t} else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB \"frame\" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98027", "url": "https://ubuntu.com/security/CVE-2026-98027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer size mv88e6xxx_get_rxnfc() uses rxnfc->rule_cnt as the write index while dumping the policy IDR, clobbering the input value before it has been looked at. That input is the number of entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed policy rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Count into a local so the caller's limit survives the walk, and stop with -EMSGSIZE once it is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98030", "url": "https://ubuntu.com/security/CVE-2026-98030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size bcm_sf2_cfp_rule_get_all() walks the whole cfp.unique bitmap into rule_locs[] without consulting nfc->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed CFP rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98031", "url": "https://ubuntu.com/security/CVE-2026-98031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: Initialize extack in remove_nh_grp_entry() remove_nh_grp_entry() prints the extack message when a listener fails to replace the reduced nexthop group. However, extack is not initialized and listeners are not required to set a message when returning an error. Neither netdevsim nor mlxsw do so when an allocation fails, resulting in the dereference of an uninitialized stack pointer. Fix by zero-initializing extack, as was done in commit 6347c5314cee (\"nexthop: initialize extack in nh_res_bucket_migrate()\").", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98063", "url": "https://ubuntu.com/security/CVE-2026-98063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref in btf_var_show() btf_var_show() calls btf_type_id_resolve() unconditionally, which dereferences btf->resolved_ids. That is NULL for a base BTF - e.g. the vmlinux BTF that bpf_snprintf_btf() renders against - since base BTF is not resolved during parsing. btf_modifier_show() guards this with 'if (btf->resolved_ids)', but btf_var_show() does not. A BPF program that passes the type_id of a BTF_KIND_VAR from the vmlinux BTF to bpf_snprintf_btf() thus NULL-derefs: KASAN: probably user-memory-access in range [0x46638-0x4663f] RIP: 0010:btf_var_show (kernel/bpf/btf.c:2929) Call Trace: btf_type_show (kernel/bpf/btf.c:8259) btf_type_snprintf_show (kernel/bpf/btf.c:8329) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Resolve the var's type directly with btf_type_skip_modifiers() when resolved_ids is NULL, mirroring btf_modifier_show().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98064", "url": "https://ubuntu.com/security/CVE-2026-98064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref when showing a void BTF type btf_modifier_show() resolves the modifier and then calls btf_type_ops(t)->show() unconditionally. For the void type (type_id 0, BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL. A \"const void\" (a modifier resolving to void) cannot be a map key or value - map_check_btf() rejects it because void has no size - so the map dump path does not reach it. But bpf_snprintf_btf() takes a type_id straight from the BPF program, and passing such a \"const void\" from the vmlinux BTF NULL-derefs: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:btf_modifier_show (kernel/bpf/btf.c:2914) Call Trace: btf_type_show (kernel/bpf/btf.c:8251) btf_type_snprintf_show (kernel/bpf/btf.c:8321) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fall back to btf_df_show() when the resolved type has no show op; it emits the \"\" placeholder already used for kinds like FWD and FUNC. bpf_snprintf_btf() then returns the length as usual.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98066", "url": "https://ubuntu.com/security/CVE-2026-98066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Fix potential double-free at error path The fix for caiaq driver's resource management to handle the errors tries to release the resources in a common destructor call, but as a sashiko review for another patch suggested, some of the audio resources such as URBs have been already freed, and this may lead to a double-free. For addressing the double-free, call the common destructor function from each place, and assure that the resource pointers get cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98068", "url": "https://ubuntu.com/security/CVE-2026-98068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: don't let rds_conn_shutdown() consume a concurrent drop rds_conn_shutdown() finishes by moving the path from RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts RDS_CONN_ERROR as the starting state of that final transition, so that a FIN processed in softirq context during the teardown does not derail the shutdown into a noisy error path. But consuming that RDS_CONN_ERROR also consumes the shutdown pass that came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN is a no-op. For the FIN case that is harmless - the socket the FIN arrived on is the very socket the teardown just released. It is not harmless for a dropper that attached something to the path first. rds_tcp_accept_one() is such a dropper. Its path claim in rds_tcp_accept_one_path() transitions RDS_CONN_DOWN -> RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous socket in softirq context, an administrative reset - can put the path into RDS_CONN_ERROR between that claim and the state check that follows, which accepts RDS_CONN_ERROR. The accept then installs the freshly accepted socket with rds_tcp_set_callbacks() while the queued teardown - which sampled tc->t_sock before this socket existed - is still running. rds_connect_path_complete() fails its transition to RDS_CONN_UP and drops the path again, queueing the pass that should reap the socket it just installed. If the in-flight shutdown's final transition consumes that drop's RDS_CONN_ERROR, the queued pass finds the path in RDS_CONN_DOWN and does nothing. The installed socket is never torn down: it sits established with its callbacks armed and its rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some later event drops it again. Reproduced with widened race windows as an ever-growing receive queue on a socket owned by a path stuck in RDS_CONN_DOWN, with the peer's send path wedged behind it. Make the final transition only DISCONNECTING -> DOWN. If it fails because the path is in RDS_CONN_ERROR, a drop raced the teardown: cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one piece of the skipped tail that must not be left behind - and return, letting the pass the drop queued finish the job: it tears down whatever attached to the path in the meantime, completes the transition to RDS_CONN_DOWN, and re-arms the reconnect from its own tail. The timer quiesce in that branch matters because the racing drop does not always queue that pass: rds_conn_path_drop() returns without queueing when a destroy is pending - exactly the situation during a netns teardown or module unload, when a FIN on the dying socket is processed while rds_conn_path_destroy() flushes cp_down_w. If the flushed pass is the one that takes this return, no later pass exists, and rds_conn_path_destroy() would find cp_conn_w still armed (WARN_ON) and then free a path whose reconnect timer can still fire. With the cancel in the branch, every exit of a shutdown pass leaves the timer quiesced no matter which pass completes the transition. The FIN case keeps making progress, one pass later and still without noisy logging. Any other state keeps today's rds_conn_path_error() handling; no current cp_state writer can leave a DISCONNECTING path in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from a non-DISCONNECTING state), so that branch is defensive. On kernels without the preceding patches the same hazard exists with the sample-based quiesce; the fix applies there equally.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98069", "url": "https://ubuntu.com/security/CVE-2026-98069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire the fastpath locks in rds_conn_shutdown() rds_conn_shutdown() quiesces the transmit and receive-refill paths by waiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and then runs the transport shutdown and rds_conn_path_reset(). Sampling the bits clear is not the same as owning them: the moment after the wait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or rds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run concurrently with the teardown. The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the transmit state under it. Oracle UEK fixed the same class of crashes - a 14-year tail of BUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL dereferences in rds_ib_send_cqe_handler() during failover testing - by making the teardown path *acquire* the fastpath bit locks instead of testing them (\"rds: Make sure transmit path and connection tear-down does not run concurrently\"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed. Do the same here: take both locks before calling the transport shutdown, hold them across rds_conn_path_reset(), and release them explicitly with a wake-up afterwards. Both are released with clear_bit_unlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rds_send_path_reset() are ordered before either bit is seen clear by the next acquire_in_xmit() or acquire_refill(). The fastpath users of these bits - rds_send_xmit() and rds_ib_recv_refill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rds_tcp_reset_callbacks() is different: since the previous patch it acquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rds_tcp_accept_one() on the single-threaded krdsd workqueue and holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown(). An IB path's drain in rds_ib_conn_path_shutdown() has no round cap, but no blocking waiter either: rds_tcp_reset_callbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDS_CONN_DISCONNECTING. Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on the path's ordered cp_wq, whose only execution slot is occupied by the blocked cp_down_w itself, so they are pending at most and cancel without flushing - a reliance on cp_wq being ordered that is now noted next to those cancels (on ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98070", "url": "https://ubuntu.com/security/CVE-2026-98070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks() rds_tcp_reset_callbacks() quiesces the transmit path by setting the path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to be sampled clear before swapping the underlying socket and calling rds_send_path_reset(). Sampling the bit clear is not the same as owning it: rds_send_xmit() can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its state recheck after taking the lock is a store-buffering pattern (the resetter writes the state and reads the bit, the sender writes the bit and reads the state) and acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write and the transmit path then runs concurrently with rds_send_path_reset() rewriting cp_xmit_* state - which is exactly what the comment above rds_send_path_reset() tells its callers to prevent. Take the lock instead, hold it across the socket swap and rds_send_path_reset(), and release it with a wake-up at the end. The lock-ordering constraint documented above the wait still holds: the lock is acquired before lock_sock(), so a sender inside tcp_sendmsg() can never be waited on while we hold the socket lock. Two details of the old code go away with the same change: - t_sock is now read only after the lock is acquired. The old code cached it before waiting; the teardown in rds_conn_shutdown() releases that socket and clears t_sock, so a pointer cached before the wait can be stale by the time the accept path resumes. Reading it under RDS_IN_XMIT is what makes the exclusion complete once the teardown owns the same lock, which the next patch arranges; until then the teardown still only samples the bit, and the two paths remain as exposed to each other as they are today. - The old !osock early path called rds_send_path_reset() with no serialization at all. It now runs under the lock like the normal path. The conditional RDS_CONN_RESETTING transition of the previous patch happens before the socket check either way: a path found without a socket is either still connecting (its reconnect worker blocked on t_conn_path_lock) and legitimately goes RESETTING -> UP on the new socket, or it has been torn down meanwhile and is dropped. The in-function comment describing the old wait-based quiesce is rewritten to describe the lock-based one, and the stale block comment above the function (which still described a return value and an incomplete list of t_sock writers) is refreshed to name all four writers - the connect, accept, teardown and swap paths - and what serializes each of them.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98071", "url": "https://ubuntu.com/security/CVE-2026-98071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: clear cp_flags bits individually in rds_conn_path_reset() rds_conn_path_reset() wipes the whole flag word with a plain cp->cp_flags = 0 store. Every other accessor of that word uses atomic bitops, and some of them can run concurrently with the reset: RDS_LL_SEND_FULL is set from rds_send_xmit() and cleared from the transport completion paths, neither of which holds anything that excludes the shutdown worker. A plain store racing an atomic read-modify-write on the same word is a data race, and whichever side loses has its update silently discarded. Clear the two bits the reset is actually responsible for instead. RDS_IN_XMIT and RDS_RECV_REFILL need no store at all here: they belong to the caller, rds_conn_shutdown(), which waits for both to be clear before calling the transport shutdown and this reset. This also gives every bit in cp_flags a single well-defined writer discipline, which the following patches rely on when they turn RDS_IN_XMIT and RDS_RECV_REFILL into bit locks held across the teardown: a blanket store mid-teardown would destroy lock ownership that an atomic clear preserves. Oracle UEK carries the same conversion (\"net/rds: Preserve essential connection state flags\"), motivated by its asynchronous shutdown state machine, whose progress and destroy flags must survive the reset. UEK's variant also clears RDS_IN_XMIT and RDS_RECV_REFILL because there the reset runs as the final step of a teardown that owns both bits, making those clears its unlock. Upstream that release belongs in rds_conn_shutdown(): once a later patch in this series turns the two bits into locks held across the teardown, ending ownership needs release semantics and a wake-up that a plain clear inside the reset would not provide. Based on Oracle UEK commit \"net/rds: Preserve essential connection state flags\" by Gerd Rausch.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98072", "url": "https://ubuntu.com/security/CVE-2026-98072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in release_in_xmit() release_in_xmit() clears RDS_IN_XMIT with clear_bit_unlock() and then checks waitqueue_active() to decide whether anyone needs waking. clear_bit_unlock() is only a release operation: it orders the critical section before the bit clear, but does not order the subsequent plain load of the wait queue head after it. The waiter side does the mirror image - it adds itself to the wait queue and then tests the bit. That is the classic store-buffering pattern: the releasing CPU can read the wait queue as empty while the waiting CPU still reads the bit as set, so the sleeper is never woken. The waiters are rds_conn_shutdown() and rds_tcp_reset_callbacks(), both in uninterruptible wait_event() with no timeout. A lost wake-up strands the shutdown worker on its single-threaded workqueue until some other sender releases the bit again - and on a connection that is being torn down precisely because it failed, there may never be another sender. The barrier used to be there: release_in_xmit() did clear_bit() followed by smp_mb__after_atomic() until commit 1422f28826d2 (\"rds: introduce acquire/release ordering in acquire/release_in_xmit()\") folded both into clear_bit_unlock(), which strengthened the lock hand-off but silently dropped the full barrier the wake-up check depends on. The refill counterpart, release_refill() in net/rds/ib_recv.c, still carries its smp_mb__after_atomic() for exactly this reason. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98074", "url": "https://ubuntu.com/security/CVE-2026-98074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: do not clear curr_active_slave prematurely when releasing all slaves When releasing all slaves during bond destruction (all == true), __bond_release_one() unconditionally clears bond->curr_active_slave to NULL in every iteration. If a backup slave is released before the active slave, bond_alb_deinit_slave() triggers rlb_teach_disabled_mac_on_primary(), which increments the active slave dev promiscuity counter and sets bond_info->primary_is_promisc = 1. Because bond->curr_active_slave was prematurely cleared to NULL when releasing the backup slave, the subsequent iteration releasing the active slave evaluates oldcurrent as NULL, so bond_change_active_slave(bond, NULL) is skipped. Consequently, bond_alb_handle_active_change() is never called to decrement the promiscuity counter, permanently leaking promiscuous mode on the physical device after bond teardown. When oldcurrent == slave, bond_change_active_slave(bond, NULL) already sets bond->curr_active_slave to NULL. We only need to avoid selecting a new active slave when all == true. Replace the if (all) branch with if (!all && oldcurrent == slave).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98075", "url": "https://ubuntu.com/security/CVE-2026-98075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject BPF_PSEUDO_FUNC reference to the main program fixups.c:jit_subprogs() rewrites BPF_PSEUDO_FUNC loads to contain real function addresses. This function is invoked from bpf_jit_subprogs() only when env->subprog_cnt > 1. Meaning that for any program like below: int main(void *ctx) { void *ptr = main; ... bpf_timer_set_callback(..., ptr); ... } The 'ptr' won't be ever converted to contain an address. In combination with e.g. bpf_timer_set_callback() this would lead to a function call at a bogus address. Instead of complicating the implementation, just assume that no useful program needs main to be a sync or async callback and reject BPF_PSEUDO_FUNC loads for the main subprogram.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98076", "url": "https://ubuntu.com/security/CVE-2026-98076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/probes: Fix use-after-free on field name/type of events with multiple probes The fields of a probe-based dynamic event (kprobe, uprobe, eprobe and fprobe events) are created in traceprobe_define_arg_fields() by handing the probe_arg name/type strings to trace_define_field(), which only stores the pointers without copying. Those strings are owned by the trace_probe and are freed when that probe is removed. An event can have several probes attached. The field list is defined only once, by the first probe that registers the event, but it is kept alive by any surviving sibling probe. Deleting just that first probe by symbol - # primary A: fields are defined from A's args echo 'p:kprobes/ev vfs_read a1=$arg1' > kprobe_events # append B: shares A's event call echo 'p:kprobes/ev vfs_write a1=$arg1' >> kprobe_events # delete only A (matched by symbol), B survives echo '-:kprobes/ev vfs_read' >> kprobe_events frees A's args (trace_probe_cleanup() -> traceprobe_free_probe_arg()), but trace_probe_unlink() keeps the trace_probe_event because the probe list is not empty. The event call stays registered via B while its fields now reference freed memory. Any field lookup then reads it, e.g. echo 'a1 == 1' > events/kprobes/ev/filter BUG: KASAN: slab-use-after-free in strcmp+0xa7/0xb0 Call Trace: strcmp trace_find_event_field parse_pred process_preds create_filter apply_event_filter event_filter_write field->name references parg->name (kstrdup'd, freed with the probe) and, for array arguments, field->type references parg->fmt (kmalloc'd, freed with the probe) - the scalar type otherwise points at the static fmttype rodata, which is safe. Have traceprobe_define_arg_fields() duplicate the name and type strings and anchor the copies on the trace_probe_event, which embeds the event call and outlives every individual probe; trace_probe_event_free() releases them. The reproducer above triggers reliably; the field lookup and the delete both run under event_mutex, so this is a dangling reference after removal rather than a race. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98077", "url": "https://ubuntu.com/security/CVE-2026-98077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace() sip_skip_whitespace() returns dptr unchanged when its own loop exhausts the buffer (dptr == limit), instead of NULL like its sibling sip_follow_continuation() returns on its own \"no more data\" path. ct_sip_get_header() only checks for NULL after calling it: dptr = sip_skip_whitespace(dptr, limit); if (dptr == NULL) break; if (*dptr != ':' || ++dptr >= limit) break; so a recognized header name followed only by spaces/tabs running to the exact end of the SIP payload, with no colon, makes the very next statement read one byte past the buffer. Make both \"no more data\" outcomes return NULL, matching the convention sip_follow_continuation() already uses and that both existing callers already check for.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98078", "url": "https://ubuntu.com/security/CVE-2026-98078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix reversed sequence option serialization hton_seq() expects the host-order source first and the unaligned network-order destination second. The version 1 sync sender passes these arguments in reverse for both sequence blocks. This leaves 24 bytes of the kmalloc-backed message unwritten. It may disclose stale heap data and replace the live connection sequence state with values read from the buffer. Pass the connection sequence state as the source and the message payload as the destination for both blocks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98080", "url": "https://ubuntu.com/security/CVE-2026-98080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not force reloc root creation during qgroup_account_snapshot() [BUG] When running btrfs/252 with quota enabled through MKFS_OPTIONS=\"-O quota\", it has a high chance to trigger the following kernel warning and flips the fs RO: BTRFS info (device dm-2): relocating block group 30408704 flags metadata|dup ------------[ cut here ]------------ WARNING: fs/btrfs/extent-tree.c:879 at lookup_inline_extent_backref+0x74b/0x960 [btrfs], CPU#4: btrfs/2173 CPU: 4 UID: 0 PID: 2173 Comm: btrfs Not tainted 7.2.0-rc6-custom+ #457 PREEMPT(full) 3adc6528fb66f7a55fe1095385818e742f200aab Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:lookup_inline_extent_backref+0x74b/0x960 [btrfs] Call Trace: insert_inline_extent_backref+0x7c/0x160 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_inc_extent_ref+0xa9/0x270 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_run_delayed_refs+0x4af/0x11c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_run_delayed_refs+0x9d/0xf0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshot+0x39d/0xf00 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshots+0x9b/0xc0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_commit_transaction+0x280/0xeb0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] prepare_to_relocate+0x147/0x200 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] relocate_block_group+0x6b/0x5e0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_block_group+0x92c/0x2380 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_balance+0xa2c/0x19c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_ioctl+0x2839/0x2d30 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS info (device dm-2): leaf 4593991680 gen 233 total ptrs 175 free space 5953 owner 2 BTRFS info (device dm-2): refs 3 lock_owner 2173 current 2173 \titem 0 key (166772736 METADATA_ITEM 1) itemoff 16250 itemsize 33 \t\textent refs 1 gen 222 flags 2 \t\tref#0: tree block backref root 266 [ Skip the tree dump ] \titem 174 key (263225344 METADATA_ITEM 0) itemoff 10328 itemsize 33 \t\textent refs 1 gen 162 flags 258 \t\tref#0: tree block backref root 267 BTRFS error (device dm-2): extent item not found for insert, bytenr 179847168 num_bytes 16384 parent 4594335744 root_objectid 273 owner 0 offset 0 BTRFS error (device dm-2): failed to run delayed ref for logical 179847168 num_bytes 16384 type 182 action 1 ref_mod 1: -117 [CAUSE] The above error is showing that there is a tree reference to a metadata extent that is no longer there. With \"ref_verify\" mount option (requires CONFIG_BTRFS_DEBUG), there is some extra debug output: BTRFS error (device dm-2): dumping block entry [180961280 16384], num_refs 0, metadata 1, from disk 0 BTRFS error (device dm-2): root entry 256, num_refs 18446744073709551615 BTRFS error (device dm-2): root entry 273, num_refs 18446744073709551615 BTRFS error (device dm-2): Ref action 3, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 1 btrfs_force_cow_block+0x129/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_insert_empty_items+0x3a/0x70 [btrfs] insert_with_overflow+0x53/0x130 [btrfs] btrfs_insert_dir_item+0x125/0x290 [btrfs] btrfs_add_link+0xaa/0x410 [btrfs] btrfs_rename+0x5ea/0xcd0 [btrfs] btrfs_rename2+0x28/0x60 [btrfs] vfs_rename+0x5b2/0xe10 filename_renameat2+0x244/0x430 __x64_sys_rename+0x48/0x70 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98088", "url": "https://ubuntu.com/security/CVE-2026-98088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() dev_to_node() can return NUMA_NO_NODE (-1) on systems without NUMA topology information for the PCI device, such as single-socket boards that don't expose device-to-node affinity. Passing -1 directly into cpumask_of_node() indexes node_to_cpumask_map[-1], an out-of-bounds array read caught by UBSAN: UBSAN: array-index-out-of-bounds in arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' Fall back to cpu_online_mask when no NUMA node is available, rather than assuming dev_to_node() always returns a valid node index.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98090", "url": "https://ubuntu.com/security/CVE-2026-98090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: restore active device pointers after failed sprout btrfs_init_new_device() switches latest_dev and possibly s_bdev from the seed device to the new sprout device before creating the first writable chunks. If chunk creation or the subsequent sprout setup fails, the error path releases the new device without switching those pointers back. btrfs_show_devname() can then dereference the freed latest_dev and crash. Restore the active device pointers to the latest seed device before removing and releasing the failed sprout device.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98091", "url": "https://ubuntu.com/security/CVE-2026-98091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: detach failed sprout device from transaction update list When creating the first metadata chunk for a sprout filesystem, create_chunk() adds the new device to the transaction dev_update_list through device->post_commit_list. If the subsequent system chunk creation fails, btrfs_init_new_device() aborts the transaction and releases the device while post_commit_list is still linked. This triggers a warning in btrfs_free_device() and leaves the transaction list referencing freed memory. Detach the device while holding chunk_mutex before releasing it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98094", "url": "https://ubuntu.com/security/CVE-2026-98094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: fbtft: make dirty_lock IRQ-safe fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled. Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again. The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled: WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2} CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); lock(console_owner); *** DEADLOCK *** Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98095", "url": "https://ubuntu.com/security/CVE-2026-98095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_packet: Don't cast tpacket_hdr.tp_len to int in tpacket_parse_header(). syzbot reported BUG() in sock_sendmsg_nosec(). [0] The problem is that tpacket_parse_header() casts user-provided tpacket_hdr.tp_len, which is u32, to int. If the length is larger than INT_MAX, the following condition in tpacket_parse_header() passes, if (unlikely(tp_len > size_max)) and any negative value can be returned to the caller, up to sock_sendmsg_nosec(). The repro set tpacket_hdr.tp_len to 0xfffffdef, which is cast to -EIOCBQUEUED (-529), triggering BUG() in sock_sendmsg_nosec(). *(uint64_t*)0x200000000008 = 0xfffffdef; ... syscall(__NR_write, /*fd=*/r[0], /*buf=*/0x200000000000ul, /*count=*/1ul); Let's define the local tp_len as u32 in tpacket_parse_header(). [0]: kernel BUG at net/socket.c:803! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 5628 Comm: syz-executor176 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 RIP: 0010:sock_sendmsg_nosec+0x145/0x180 net/socket.c:803 Code: 06 67 48 0f b9 3a eb 95 e8 e8 3a 22 f8 48 89 df 4c 89 f6 4c 89 e2 4d 89 fb 2e e8 32 a5 5c 16 e9 51 ff ff ff e8 cc 3a 22 f8 90 <0f> 0b e8 c4 3a 22 f8 48 83 c3 18 48 89 d8 48 c1 e8 03 42 80 3c 28 RSP: 0018:ffffc90003aefb48 EFLAGS: 00010293 RAX: ffffffff89a578d4 RBX: ffff8880764c67c0 RCX: ffff88807fb23e80 RDX: 0000000000000000 RSI: 00000000fffffdef RDI: 00000000fffffdef RBP: 00000000fffffdef R08: ffffc90003aef747 R09: 1ffff9200075dee8 R10: dffffc0000000000 R11: fffff5200075dee9 R12: 0000000000000001 R13: dffffc0000000000 R14: ffffc90003aefbc0 R15: ffffffff8aac4310 FS: 000055559101b400(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000210 CR3: 0000000073dca000 CR4: 00000000003526f0 Call Trace: __sock_sendmsg net/socket.c:815 [inline] sock_write_iter+0x2de/0x3e0 net/socket.c:1266 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x612/0xba0 fs/read_write.c:687 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f173130ecb9 Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 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 d8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd67e44248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f173130ecb9 RDX: 0000000000000001 RSI: 0000200000000000 RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd67e44388 R13: 0000000000000002 R14: 00002000000000c0 R15: 0000000000000002 ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98096", "url": "https://ubuntu.com/security/CVE-2026-98096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: restore network header before routing and forwarding ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative. This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows. Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98098", "url": "https://ubuntu.com/security/CVE-2026-98098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL deref in tipc_named_node_up() on empty publication list User-space applications can bind a large number of service addresses to one or more sockets. Each binding of a local-scope service address inserts one entry (publication) into the TIPC name table. If the number of these publications exceeds TIPC_MAX_PUBL (65535), protocol service types (such as node state and link state) are no longer inserted into the name table. This causes two issues: 1. User-space applications subscribing to node or link up/down events stop receiving notifications. 2. A NULL pointer dereference can occur: BUG: kernel NULL pointer dereference, address: 00000000000000d0 ... CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full) ... RIP: 0010:tipc_named_node_up (./include/linux/skbuff.h:2251 net/tipc/name_distr.c:195 net/tipc/name_distr.c:221) ... Call Trace: tipc_node_write_unlock (net/tipc/node.c:428) tipc_rcv (net/tipc/node.c:934 net/tipc/node.c:2189) tipc_udp_recv (net/tipc/udp_media.c:389) Thread 1 (tipc_net_finalize) | Thread 2 (named_distribute) -----------------------------|----------------------------- | ... | list_for_each_entry(publ, pls, binding_node) { | ... | __skb_queue_tail(list, skb); | ... | } | ... | hdr = buf_msg(skb_peek_tail(list)); ... | tipc_nametbl_publish(); | If 'tipc_nametbl_publish()' (Thread 1) fails because the number of local publications reaches TIPC_MAX_PUBL, list (Thread 2) will be empty. As a result, NULL is passed to 'buf_msg()', leading to a NULL pointer dereference. Fix these issues by allowing protocol service types (node state, link state, and topology server) to be inserted into the name table unconditionally. This ensures that users subscribing to these types always receive notifications. In addition, the maximum number of local user publications is reduced to (TIPC_MAX_PUBL - 1). This ensures that the maximum bulk size calculated in tipc_link_set_queue_limits() remains valid.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98108", "url": "https://ubuntu.com/security/CVE-2026-98108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan l2cap_new_connection() sets default value of channel mode to match the parent channel. l2cap_le_connect_req() left this at the default, and created L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that mode. This causes FLAG_DEFER_SETUP channels to reply to L2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect. It can also result to stack OOB write (of l2cap_alloc_cid determined values) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not limit maximum number of deferred channels or check for duplicate ident. Fix by setting chan->mode correctly in l2cap_le_connect_req(). Also check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE instead of OOB write to make it less brittle.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98113", "url": "https://ubuntu.com/security/CVE-2026-98113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: rate limit unmapped SID errors A client can include many structurally valid but unmapped SIDs in a DACL. Logging every mapping failure lets one request generate hundreds of kernel error messages. Rate limit the message to prevent an authenticated client from flooding the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98116", "url": "https://ubuntu.com/security/CVE-2026-98116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation with an mmap_count check performed under the PCM stream lock, but the lock is released long before the buffer is actually freed: snd_pcm_sync_stop(), constraint refinement and do_free_pages() all happen in between. snd_pcm_mmap_data(), on the other hand, takes no lock at all: it validates against the old buffer's state and dma_bytes, remaps its pages into the VMA, and only then increments mmap_count. A concurrent mmap() can therefore slip in between the check and the free. remap_pfn_range() installs writable PTEs for the old buffer's pages without taking page references, and the subsequent do_free_pages() returns those pages to the page allocator while the VMA still maps them. This leaves a stale, writable mapping of freed pages: a page-level use-after-free that can be leveraged for local privilege escalation. Make snd_pcm_mmap_data() participate in the buffer-access scheme introduced for hw_params/hw_free: acquire runtime->buffer_accessing before validating and remapping, and release it afterwards. Buffer reallocation already fails with -EBUSY while accessors are active, and the mmap side now fails with -EBUSY while a reallocation is in progress, so the validate/remap sequence and the check/free sequence can no longer interleave. A reproducer that turns this race into a stale writable mapping of the freed DMA buffer pages is available on request.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98121", "url": "https://ubuntu.com/security/CVE-2026-98121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix NULL pointer dereference in PM callbacks msc313e_wdt_probe() doesn't set the driver data for the platform device. As a result, dev_get_drvdata() in msc313e_wdt_suspend() and msc313e_wdt_resume() will return NULL, leading to a NULL pointer dereference afterward. Set the platform device driver data in msc313e_wdt_probe().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98123", "url": "https://ubuntu.com/security/CVE-2026-98123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration sctp_verify_asconf() walks ASCONF-ACK parameters with sctp_walk_params(), which advances by SCTP_PAD4(length), while the consumer sctp_get_asconf_response() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset. When those bytes yield a length of zero, the while loop over asconf_ack_len makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help). The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read. Reject SCTP_PARAM_ERR_CAUSE parameters shorter than sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERR_CAUSE parameter the consumer can see, so the consumer's asconf_ack_len check is dropped and it returns err_param->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTP_PARAM_ERR_CAUSE per RFC 5061. The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98130", "url": "https://ubuntu.com/security/CVE-2026-98130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START The SCTP_CMD_TIMER_START handler checks timer_pending() before calling timer_reduce(). The timer can expire and detach between these operations, causing timer_reduce() to rearm the timer without taking the association reference required for the newly armed timer. The timer callback later unconditionally drops its association reference, which can leave the association reference count unbalanced and result in use-after-free during association teardown. Use the return value of timer_reduce() to determine whether the timer was actually armed. Take the association reference only when timer_reduce() successfully starts a new timer, closing the race between checking the timer state and rearming it. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98154", "url": "https://ubuntu.com/security/CVE-2026-98154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix -EIO cleanup order in queue_rq On -EIO, the RDMA queue_rq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete. Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98157", "url": "https://ubuntu.com/security/CVE-2026-98157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation The poll_msec sysfs store file uses simple_strtoul() which accepts an unsigned long, but the target field (poll_msec) is unsigned int. On 64-bit systems, a value > UINT_MAX is silently truncated when stored. Fix the mismatch by using kstrtouint() instead. This rejects values larger than UINT_MAX at parse time, making truncation impossible. Also add a check for value < 1 to reject the 0-delay case, which would cause the poll work to spin without delay and consume 100% CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89796", "url": "https://ubuntu.com/security/CVE-2026-89796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid infinite kdamond_merge_regions() internal loop Patch series \"mm/damon: unurgent fixes for infinite loop, NULL de-ref and races\", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-98158", "url": "https://ubuntu.com/security/CVE-2026-98158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_async: drop the errored frame instead of resetting its headroom ppp_receive_nonmp_frame() prepends a two-byte direction tag before running the pass/active BPF filters: \t*(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG); Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in ppp_async's process_input_packet() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD: \terr: \t\tif (skb) { \t\t\t/* make skb appear as freshly allocated */ \t\t\tskb_trim(skb, 0); \t\t\tskb_reserve(skb, - skb_headroom(skb)); \t\t} ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head: skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev: kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled ppp_decompress_frame() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason. Rather than restore the headroom, drop the errored frame - as ppp_synctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read. The original V1 of this patch made room in ppp_receive_nonmp_frame() with skb_cow_head(); Eric pointed out that fixing the root cause in the transport is the right approach. Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-93288", "url": "https://ubuntu.com/security/CVE-2026-93288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state sashiko reports: \"nfnl_log_net_exit() calls nf_log_unset(), which clears the logger pointer without an RCU grace period. Immediately after, ops_free_list() frees the per-net state while concurrent packets might still be executing nf_log_packet() under rcu_read_lock().\" Clear the pointer via .pre_exit to make sure rcu readers have completed before pernet storage is free'd. The change in nf_log_syslog.c is only done for consistency: it doesn't use pernet data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93782", "url": "https://ubuntu.com/security/CVE-2026-93782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: flush backend after device ioctls vhost-scsi translates guest response descriptors into userspace iovecs when commands are submitted. Target-core completes those commands asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while an in-flight command still retains response iovecs translated through the old table. If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command completion can write the response to an unrelated userspace object. Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device ioctl. This waits for in-flight commands that can still use the old response iovecs before the ioctl returns.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93783", "url": "https://ubuntu.com/security/CVE-2026-93783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr and dereferences hdr->addr and hdr->ctrl without validating skb->len first. A truncated frame with skb->len less than the minimum header size causes an out-of-bounds read of uninitialized memory. Additionally, a zero-length frame causes skb->len-- to underflow to UINT_MAX, making skb_tail_pointer() read far past the buffer. Commit 23882b828c3c (\"Bluetooth: RFCOMM: validate skb length in MCC handlers\") fixed the same class of missing-length-check bugs in the MCC sub-handlers, but the top-level rfcomm_recv_frame() was left unfixed. KMSAN reports: BUG: KMSAN: uninit-value in rfcomm_run ... Uninit was created at: __alloc_skb+0x474/0xb60 vhci_write+0xe9/0x870 Fix this by rejecting frames smaller than sizeof(struct rfcomm_hdr) + 1 (the minimum frame must have a 3-byte header and a 1-byte FCS).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93784", "url": "https://ubuntu.com/security/CVE-2026-93784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie() The KASAN allocation trace shows that a malformed IE buffer is stored via SIOCSIWGENIE (cfg80211_wext_siwgenie()) without any validation. The crash trace shows that a subsequent SIOCSIWESSID triggers a connection attempt which calls cfg80211_sme_get_conn_ies() to process the stored IE buffer, causing: - An out-of-bounds read in skip_ie() which reads ies[pos+1] (the length byte) past the end of the 1-byte buffer. - An integer underflow in the memcpy size argument when offs returned by ieee80211_ie_split() exceeds ies_len, causing unsigned subtraction to wrap to SIZE_MAX and triggering a fortify panic. Fix this by validating the IE buffer in cfg80211_wext_siwgenie() before storing it. [drop unnecessary ie_len check, update commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93785", "url": "https://ubuntu.com/security/CVE-2026-93785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate idmap key payload length The cifs.idmap key type stores its payload length in key->datalen, which is limited to U16_MAX. Accepting a larger key payload truncates the recorded length and can make later users interpret the payload using inconsistent bounds. Reject oversized preparsed payloads before allocating or copying them. This keeps key->datalen consistent with the stored data for both inline and separately allocated idmap payloads.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93789", "url": "https://ubuntu.com/security/CVE-2026-93789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: bound aligned TLV advance in FW parser Validate ALIGN(tlv_len, 4) against remaining parser length before consuming bytes from the firmware image. This avoids length underflow on malformed TLVs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93795", "url": "https://ubuntu.com/security/CVE-2026-93795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix leaks and online flag on radix_tree_insert failure When radix_tree_insert() fails in blkg_create(), the error path has two issues: 1. blkg->online is set to true unconditionally, even when the blkg was never fully inserted. Move the assignment inside the success block. 2. The error path calls blkg_put() without first calling percpu_ref_kill(). Because the refcount is still in percpu mode, percpu_ref_put() only does this_cpu_sub() without checking for zero, so blkg_release() is never triggered. This permanently leaks the blkg memory, its percpu iostat, policy data, the parent blkg reference, and the cgroup css reference — the latter preventing the cgroup from ever being destroyed. Fix by replacing blkg_put() with percpu_ref_kill(), matching the pattern used in blkg_destroy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93797", "url": "https://ubuntu.com/security/CVE-2026-93797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix an off-by-1 boundary check Before looking at the 11th byte, check the length is big enough.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93798", "url": "https://ubuntu.com/security/CVE-2026-93798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix reloc root cleanup in merge_reloc_roots() If the root we got has zero root refs in its root item, we are resetting the root's ->reloc_root without using barriers like we do everywhere else. Sashiko complained about this while reviewing another patch, and it's correct (see the Link tag below). Also, we should not clear BTRFS_ROOT_DEAD_RELOC_TREE from the root unless the root points to the reloc root we have. Fix this by using clear_reloc_root(), which issues the memory barrier after setting the root's ->reloc_root to NULL and before clearing the bit BTRFS_ROOT_DEAD_RELOC_TREE from the root.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93800", "url": "https://ubuntu.com/security/CVE-2026-93800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol() If during relocation we fail in insert_dirty_subvol() because btrfs_update_reloc_root() returned an error, we will leave a root's reloc_root field pointing to a reloc root that was freed instead of NULL, resulting later in a use-after-free, or double free attempt during unmount. The sequence of steps is this: 1) During relocation the call to btrfs_update_reloc_root() in insert_dirty_subvol() fails, so insert_dirty_subvol() returns the error to merge_reloc_root() without adding the root to the list rc->dirty_subvol_roots; 2) Then merge_reloc_root() aborts the current transaction because insert_dirty_subvol() returned an error; 3) Up the call chain, merge_reloc_roots() gets the error, adds the reloc root for root X to the local reloc_roots list and jumps to the 'out' label, where it calls free_reloc_roots() to free all the reloc roots in the local reloc_roots list. This frees the reloc root for root X; 4) We go up the call chain to relocate_block_group() which calls clean_dirty_subvols() to go over dirty roots and set their ->reloc_root field to NULL, but root X is not in the dirty_subvol_roots list, so its ->reloc_root still points to a reloc root; 5) Relocation finishes, with an error and a transaction abort, but the ->reloc_root field for root X still points to the reloc root that was freed in step 3; 6) When unmounting the fs we end up calling: btrfs_free_fs_roots() btrfs_drop_and_free_fs_root() --> calls btrfs_put_root() against root X's ->reloc_root which is not NULL and points to the already freed reloc root in step 4 above Resulting in a use-after-free to a double free attempt. Syzbot reported this with the following dmesg/syslog: [ 106.004389][ T5339] BTRFS error (device loop0 state A): Transaction aborted (error -5) [ 106.014266][ T5339] BTRFS: error (device loop0 state A) in merge_reloc_root:1655: errno=-5 IO failure [ 106.021891][ T1061] BTRFS error (device loop0 state A): error while writing out transaction: -5 [ 106.026964][ T1061] BTRFS warning (device loop0 state A): Skipping commit of aborted transaction. [ 106.033807][ T5340] BTRFS error (device loop0 state A): bdev /dev/loop0 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 [ 106.039265][ T1061] BTRFS: error (device loop0 state A) in cleanup_transaction:2067: errno=-5 IO failure [ 106.044382][ T5339] BTRFS info (device loop0 state EA): forced readonly [ 106.074329][ T5339] BTRFS: error (device loop0 state EA) in merge_reloc_roots:1887: errno=-5 IO failure [ 106.081004][ T5356] BTRFS info (device loop0 state EA): scrub: started on devid 1 [ 106.085611][ T5339] BTRFS info (device loop0 state EA): balance: ended with status: -30 [ 106.089517][ T5356] BTRFS info (device loop0 state EA): scrub: not finished on devid 1 with status: -30 [ 106.662365][ T5338] BTRFS info (device loop0 state EA): last unmount of filesystem 3a375e4e-b156-4d76-a2ad-16e198ce1409 [ 106.682946][ T5338] ================================================================== [ 106.686574][ T5338] BUG: KASAN: slab-use-after-free in btrfs_put_root+0x2f/0x250 [ 106.690090][ T5338] Write of size 4 at addr ffff88803f978630 by task syz.0.0/5338 [ 106.693173][ T5338] [ 106.694279][ T5338] CPU: 0 UID: 0 PID: 5338 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) [ 106.694293][ T5338] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 106.694300][ T5338] Call Trace: [ 106.694308][ T5338] [ 106.694314][ T5338] dump_stack_lvl+0xe8/0x150 [ 106.694331][ T5338] print_address_description+0x55/0x1e0 [ 106.694343][ T5338] ? btrfs_put_root+0x2f/0x250 [ 106.694358][ T5338] print_report+0x58/0x70 [ 106. ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93802", "url": "https://ubuntu.com/security/CVE-2026-93802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: validate beacon length before fixed buffer copy rsi_prepare_beacon() copies the mac80211 beacon frame after FRAME_DESC_SZ into a management skb whose usable tailroom may be smaller than MAX_MGMT_PKT_SIZE after alignment. Validate the beacon length against the actual tailroom before the copy and skb_put(). Leave ownership of the management skb with the caller on error, matching the existing rsi_send_beacon() cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93803", "url": "https://ubuntu.com/security/CVE-2026-93803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libipw: fix key index receive bound checks libipw_rx() reads skb->data[hdrlen + 3] to extract the WEP key index in both the software-decrypt key selection path and the hardware-decrypted IV/ICV strip path. In both places the existing guard only checks skb->len >= hdrlen + 3, which proves bytes up to hdrlen + 2 but not the byte at hdrlen + 3. Require hdrlen + 4 bytes before reading that item in both paths. This is a local source-boundary check only; it does not change the key index semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93805", "url": "https://ubuntu.com/security/CVE-2026-93805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate rx/tx MLME callback frame lengths before access cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints before rejecting frames shorter than the frame-control field. After that, they only require len >= 2 before dispatching into subtype handlers that assume their fixed fields are present. The frames that trip this are not shorter than 2 bytes; they are short relative to their subtype. mwifiex is a concrete in-tree example on the length side: mwifiex_process_mgmt_packet() only requires a 4-address ieee80211_hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and removing addr4, pkt_len can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARN_ON(len < 2) does not fire on such a frame, and cfg80211_process_deauth() then reads u.deauth.reason_code as a two-byte access starting at offset 24, immediately past the 24-byte buffer. Add a frame-control length gate, then validate each subtype's minimum frame size in an if/else-if chain that mirrors the dispatch logic. Trace only after the frame is known to be well-formed. Side effects of this change: - The WARN_ON(len < 2) is dropped. It only guarded the frame_control read, never the subtype fixed fields, and it does not fire on the frames that actually trigger the out-of-bounds read (which are >= 2). The len >= 2 check is kept as the guard before dereferencing frame_control, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93807", "url": "https://ubuntu.com/security/CVE-2026-93807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers rsi_hal_load_key() copies tx_mic_key and rx_mic_key from data[16] and data[24] whenever key data is present. Those offsets are only part of the 32-byte TKIP key layout. Shorter keys used by other ciphers, such as CCMP, do not provide those bytes, so the unconditional copies can read past the supplied key buffer. Only copy the MIC keys for TKIP, and reject malformed TKIP keys that are shorter than the expected 32-byte layout. [drop useless length check]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93808", "url": "https://ubuntu.com/security/CVE-2026-93808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: caiaq: validate EP1 reply lengths usb_ep1_command_reply_dispatch() uses buf[0] as a command byte and then reads command-specific fixed items from the same URB buffer. Several paths use buf + 1, buf[1], buf[2], or buf + 3 without first proving that urb->actual_length contains those bytes. Add per-command length checks, use a payload length derived from the bytes after the command byte for the control-state copy, and reject short analog input payloads before the input helper reads fixed offsets from the EP1 reply.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93811", "url": "https://ubuntu.com/security/CVE-2026-93811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling 1. When ndr_decode_v4_ntacl() fails, the code jumped to free_n_data which only freed n.data, skipping kfree(acl.sd_buf) and leaking the buffer. Zero-initialize struct xattr_ntacl acl, reorder error labels to out_free to release acl.sd_buf on all error paths. 2. if (acl.sd_size < sizeof(struct smb_ntsd)) is true, original code returned success without freeing sd_buf and left stale *pntsd. Set rc = -EINVAL before jumping to out_free to return error code and free buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93812", "url": "https://ubuntu.com/security/CVE-2026-93812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr ndr_encode_v4_ntacl() allocates sd_ndr.data via kzalloc() at entry. If any subsequent ndr_write_*() call returns error during encoding, the allocated sd_ndr.data won't be freed and causes memory leak. Move kfree(sd_ndr.data) into out label to ensure the buffer gets released on all success and error return paths.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93813", "url": "https://ubuntu.com/security/CVE-2026-93813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tree-checker: validate INODE_REF's namelen [BUG] A crafted btrfs image can trigger the following crash: BUG: unable to handle page fault for address: ffffd1dc42884000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page CPU: 9 UID: 0 PID: 1034 Comm: poc Not tainted 7.1.0-rc4-custom+ #383 PREEMPT(full) 46af0a92938a63be7132e0dfd71e62327c51d5c2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:memcpy+0xc/0x10 Call Trace: read_extent_buffer+0xe4/0x100 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] btrfs_get_name+0x15e/0x1e0 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] reconnect_path+0x165/0x390 exportfs_decode_fh_raw+0x337/0x400 ? drop_caches_sysctl_handler+0xb0/0xb0 ---[ end trace 0000000000000000 ]--- RIP: 0010:memcpy+0xc/0x10 Kernel panic - not syncing: Fatal exception [CAUSE] TThe crafted image has the following corrupted INODE_REF item: item 9 key (258 INODE_REF 257) itemoff 11544 itemsize 4106 \tindex 2 namelen 4096 name: d\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000 The itemsize matches the namelen, but the namelen is 4096, way larger than normal name length limit (BTRFS_NAME_LEN, 255). Meanwhile the memory of the @name is only 255 byte sized, this will cause out-of-boundary access, and cause the above crash. [FIX] Add extra namelen verification for INODE_REF, just like what we have done in ROOT_REF checks. Now the crafted image can be rejected gracefully: BTRFS critical (device dm-2): corrupt leaf: root=5 block=30572544 slot=14 ino=259, invalid inode ref name length, has 4096 expect [1, 255] BTRFS error (device dm-2): read time tree block corruption detected on logical 30572544 mirror 2 [ Rebase, add a Link: tag, add an simple cause analyze ]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93815", "url": "https://ubuntu.com/security/CVE-2026-93815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: au1000: move free_irq out of the close-time spinlocked section au1000_close() calls free_irq() while aup->lock is still held with spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ descriptor request mutex, so it does not belong inside the close-time spinlocked section. This was found by our static analysis tool and then confirmed by manual review of the in-tree au1000_close() .ndo_stop path. The reviewed path keeps aup->lock held across the MAC reset, queue stop and free_irq(dev->irq, dev). A directed runtime validation kept that ndo_stop carrier and the same free_irq(dev->irq, dev) operation under the driver lock. Lockdep reported \"BUG: sleeping function called from invalid context\" and \"Invalid wait context\" while free_irq() was taking desc->request_mutex, with au1000_close() and free_irq() on the stack. Drop aup->lock before freeing the IRQ. The protected close-time work still stops the device and queue before IRQ teardown, but the sleepable IRQ core path now runs outside the spinlocked section.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93816", "url": "https://ubuntu.com/security/CVE-2026-93816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate inline dentry name lengths before conversion Inline dentry conversion copies names out of the inline dentry area before checking that each recorded name length fits in the available filename slots. A corrupted image can therefore make the conversion path read past the inline filename storage while building the regular dentry block. Validate each inline dentry name length against the inline filename area before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93819", "url": "https://ubuntu.com/security/CVE-2026-93819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93820", "url": "https://ubuntu.com/security/CVE-2026-93820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rockchip: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93821", "url": "https://ubuntu.com/security/CVE-2026-93821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93822", "url": "https://ubuntu.com/security/CVE-2026-93822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: iproc: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93825", "url": "https://ubuntu.com/security/CVE-2026-93825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: Add NULL check for spi_get_device_id() in spi_get_device_match_data() Prevent NULL pointer dereference when spi_get_device_id() returns NULL, which can happen when using driver_override without matching SPI ID entry.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93830", "url": "https://ubuntu.com/security/CVE-2026-93830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac2: disable RBUE in default RX interrupt mask Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97407", "url": "https://ubuntu.com/security/CVE-2026-97407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in set_fmt rockchip_pdm_set_fmt() calls pm_runtime_get_sync() before accessing hardware registers, but ignores its return value. If the runtime resume fails, the function continues to perform register accesses while the device state is undefined. Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() and return early on failure to avoid unpowered register accesses.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97408", "url": "https://ubuntu.com/security/CVE-2026-97408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate connectionless PSM length Connectionless L2CAP frames carry a two-byte PSM at the start of the payload. l2cap_recv_frame() currently reads that PSM unconditionally after validating only the outer L2CAP length. A malformed connectionless frame with a zero- or one-byte payload can therefore make the parser read beyond the advertised skb payload and use tailroom bytes as part of the PSM. A VHCI-backed QEMU reproducer injected a one-byte connectionless payload and reached the unchecked read. Reject connectionless frames that cannot contain the PSM before reading or pulling it. This preserves all valid connectionless frames while dropping only structurally incomplete packets.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97411", "url": "https://ubuntu.com/security/CVE-2026-97411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ibm: emac: mal: fix potential system hang in mal_remove() napi_disable() is not idempotent and calling it on an already-disabled or unenabled NAPI context will cause the kernel to spin indefinitely waiting for the NAPI_STATE_SCHED bit to clear. In mal_remove(), napi_disable() is called unconditionally. If no MACs were registered, NAPI was never enabled. Also, if they were registered but subsequently unregistered, NAPI was already disabled in mal_unregister_commac(). In either case, calling napi_disable() causes the kernel to hang upon module removal. Fix this by only calling napi_disable() in mal_remove() if the commac list is not empty (which implies NAPI is enabled).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97413", "url": "https://ubuntu.com/security/CVE-2026-97413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Fix integer underflow in process_read and process_write usr_len is read from a network-supplied message field (le16_to_cpu) and used to compute data_len = off - usr_len without validating that usr_len <= off. A malicious RDMA client can send usr_len > off causing an integer underflow, resulting in data_len wrapping to a huge size_t value which is then passed to the rdma_ev callback as a memory length, leading to out-of-bounds memory access. Fix by reading and validating usr_len <= off before rtrs_srv_get_ops_ids() in both process_read() and process_write(), ensuring the early return path acquires no reference and has no resource leak.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97416", "url": "https://ubuntu.com/security/CVE-2026-97416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: balance: fix potential bg lookup failure in btrfs_may_alloc_data_chunk() [BUG] Running btrfs balance can trigger a null-ptr-deref before relocating a data chunk when metadata corruption leaves a chunk in the chunk tree without a corresponding block group in the in-memory cache: KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] RIP: 0010:btrfs_may_alloc_data_chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601 Call Trace: __btrfs_balance fs/btrfs/volumes.c:4217 [inline] btrfs_balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604 btrfs_ioctl_balance fs/btrfs/ioctl.c:3577 [inline] btrfs_ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313 ... [CAUSE] __btrfs_balance() iterates the on-disk chunk tree and passes the chunk logical bytenr to btrfs_may_alloc_data_chunk() before relocating a data chunk. That helper then queries the in-memory block group cache: cache = btrfs_lookup_block_group(fs_info, chunk_offset); chunk_type = cache->flags; /* cache may be NULL */ A corrupt image can contain a chunk item whose matching block group item is missing, so no block group is ever inserted into the cache. In that case btrfs_lookup_block_group() returns NULL. The code only guards this with ASSERT(cache), which becomes a no-op when CONFIG_BTRFS_ASSERT is disabled. The subsequent dereference of cache->flags therefore crashes the kernel. [FIX] Add a NULL check after btrfs_lookup_block_group() in btrfs_may_alloc_data_chunk() and print and error message for clarity.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97417", "url": "https://ubuntu.com/security/CVE-2026-97417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack() The timestamp-only fast path dereferences the option stream as *(__be32 *)ptr, which assumes 4-byte alignment that the TCP option stream does not guarantee. Use get_unaligned_be32() instead, which reads the value safely and already returns host byte order, so the htonl() on the comparison constant can be dropped. This matches the existing get_unaligned_be32() use later in the same function.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97418", "url": "https://ubuntu.com/security/CVE-2026-97418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es18xx: check control allocation before private data setup snd_es18xx_mixer() creates controls with snd_ctl_new1() and then stores bookkeeping pointers or sets private_free before calling snd_ctl_add(). snd_ctl_new1() can return NULL on allocation failure, so those writes can dereference a NULL control pointer. Check the returned control pointers before using them and return -ENOMEM on allocation failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97419", "url": "https://ubuntu.com/security/CVE-2026-97419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: broadcast netlink notifications in the device's net namespace The HSR generic netlink family sets .netnsok = true. HSR devices can live in network namespaces other than init_net. Two async notifiers broadcast events with genlmsg_multicast(). They are hsr_nl_ringerror() and hsr_nl_nodedown(). That helper delivers only on the default genl socket in init_net. So the events always land in init_net. The network namespace of the device does not matter. This has two effects. A listener in the device's own namespace never sees its own ring error and node down events. A privileged listener in init_net receives events from HSR devices in other namespaces. The payload carries the peer node MAC (HSR_A_NODE_ADDR) and the slave port ifindex (HSR_A_IFINDEX). Switch both callers to genlmsg_multicast_netns(). Other families with .netnsok = true already do this. Examples are gtp, ovpn, team, batman-adv, netdev-genl, ethtool and handshake. hsr_nl_ringerror() already has the slave port. It uses dev_net(port->dev). hsr_nl_nodedown() takes the namespace from the master port via hsr_port_get_hsr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97420", "url": "https://ubuntu.com/security/CVE-2026-97420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: NUL-terminate replaced sysctl value When writing to sysctls, proc_sys_call_handler() guarantees that the buffer passed to proc handlers is NUL-terminated. If bpf_sysctl_set_new_value() replaces the pending sysctl value, it can hand a replacement buffer directly to proc handlers. However, the helper currently copies only buf_len bytes into that buffer without appending a NUL terminator, leaving downstream parsers vulnerable to out-of-bounds access. Fix this by appending a '\\0' after the replaced value to restore the expected sysctl semantics. Since the helper already rejects buf_len greater than PAGE_SIZE - 1, there is always room for the extra byte. Reproduced in a QEMU x86_64 guest booted with KASAN while exercising the sysctl replacement path with a cgroup/sysctl BPF program. The reproducer targets `/proc/sys/net/core/flow_limit_cpu_bitmap`, fills the original user write buffer with non-zero bytes, and overrides the sysctl value so the replacement buffer lacks a terminating NUL. Under that setup, the pre-fix kernel reported: BUG: KASAN: slab-out-of-bounds in strnchrnul+0x72/0x90 Read of size 1 at addr ffff88800de57000 by task repro_patch3/66 CPU: 0 UID: 0 PID: 66 Comm: repro_patch3 Not tainted 7.1.0-rc3-00269-g8370ca1f87cc #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? strnchrnul+0x72/0x90 ? strnchrnul+0x72/0x90 kasan_report+0xca/0x100 ? strnchrnul+0x72/0x90 strnchrnul+0x72/0x90 bitmap_parse+0x37/0x2e0 flow_limit_cpu_sysctl+0xc6/0x840 ? __pfx_flow_limit_cpu_sysctl+0x10/0x10 ? __kvmalloc_node_noprof+0x5ba/0x870 proc_sys_call_handler+0x31d/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? selinux_file_permission+0x39f/0x500 ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... The buggy address is located 0 bytes to the right of allocated 4096-byte region [ffff88800de56000, ffff88800de57000) With this fix applied, rerunning the same sysctl-targeted path yields no corresponding KASAN reports.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97421", "url": "https://ubuntu.com/security/CVE-2026-97421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz() Several corner cases, especially important on 32 bits: - umem->iova is u64, the function argument should pass in u64 or iova will be truncated - Check that the length is not too large for the iova - Check that lengths > 4G don't overflow the GENMASK", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97430", "url": "https://ubuntu.com/security/CVE-2026-97430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: Prevent queuing new commands if xhci is inaccessible Refuse to queue a new command on the command ring if xHC is marked inaccessible with the HCD_FLAG_HW_ACCESSIBLE. HCD_FLAG_HW_ACCESSIBLE is set and cleared in suspend and resume. Also print a warning if xhci is being suspended with commands still pending on the command ring.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97434", "url": "https://ubuntu.com/security/CVE-2026-97434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: fix handling of NAPI on the remove path All the NAPI instances for a DPSW device are attached to the first switch port's net_device but shared by all ports. The NAPI instances get disabled only once the last port goes down. This causes an issue on the .remove() path where each port is unregistered and freed one at a time, causing the NAPI instances to be deleted even though they are not disabled. In order to avoid this, split up the unregister_netdev() calls from the free_netdev() so that we make sure all ports go down before we attempt a deletion of NAPI instances. Also, make the netif_napi_del() explicit as it is on the .probe() path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97435", "url": "https://ubuntu.com/security/CVE-2026-97435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: flower: reject cross-chip redirect dsa_port_from_netdev() may return a valid port from a different switch chip. Programming another chip's port index into the local hardware causes redirection to the wrong port, or an out-of-bounds access if the index exceeds the local chip's port count. Apply a minimal fix that adds a check to catch this case and adjusts the extack message. When cls->common.skip_sw is not set, the operation could instead redirect to the upstream port and let the software or upstream switch(es) handle the forward, but that is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97436", "url": "https://ubuntu.com/security/CVE-2026-97436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: rework FDB management on the bridge leave path On bridge leave, the dpaa2_switch_port_set_fdb() function always allocates a new FDB for the port which is becoming standalone. In case no FDB is found, then the port leaving a bridge will continue to use the current one. The above logic does not cover the case in which there are multiple bridges which have ports from the same DPSW instance. In this case, when the last port leaves bridge #1, it finds an unused FDB to switch to, but the old FDB is not marked as unused. Since the number of FDBs is equal to the number of DPSW interfaces, this will eventually lead to multiple ports sharing the same FDB. Fix this by changing how we are managing the FDBs on the leave path. Instead of directly allocating a new FDB, first verify if the current port is the last one to leave a bridge. If this is the case, then continue to use the current FDB and only allocate another FDB if there are other ports remaining in the bridge.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97437", "url": "https://ubuntu.com/security/CVE-2026-97437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e() The bounds check in ntfs_dir_emit() compares fname->name_len (a character count) against e->size (a byte count) without accounting for the 2-byte-per-character UTF-16LE encoding or the ATTR_FILE_NAME header size: if (fname->name_len + sizeof(struct NTFS_DE) > le16_to_cpu(e->size)) This computes: name_len + 16 > e_size The correct check must account for the ATTR_FILE_NAME header (66 bytes before the name) and the UTF-16LE character size (2 bytes each): sizeof(NTFS_DE) + offsetof(ATTR_FILE_NAME, name) + name_len * sizeof(short) > e_size Which computes: 16 + 66 + name_len * 2 > e_size The correct calculation already exists as fname_full_size() in ntfs.h and is used in cmp_fnames(), namei.c, and fslog.c, but was not used in the readdir path. A crafted NTFS image with an index entry containing a small e->size but large fname->name_len bypasses the current check, causing ntfs_utf16_to_nls() to read past the entry boundary. Additionally, add a key_size validation in hdr_find_e() to ensure the declared key_size does not exceed the available entry data, preventing comparison functions from reading past entry boundaries on the lookup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97438", "url": "https://ubuntu.com/security/CVE-2026-97438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate index entry key bounds [BUG] A malformed NTFS directory index entry can advertise a key_size larger than the bytes actually present in its NTFS_DE payload. Directory lookup then passes that malformed key to cmp_fnames(), which can read past the end of the kmalloc'ed index buffer. BUG: KASAN: slab-out-of-bounds in fname_full_size fs/ntfs3/ntfs.h:590 [inline] BUG: KASAN: slab-out-of-bounds in cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 Read of size 1 at addr ffff88801c313018 by task syz.6.3365/9279 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 __asan_report_load1_noabort+0x14/0x30 mm/kasan/report_generic.c:378 fname_full_size fs/ntfs3/ntfs.h:590 [inline] cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 hdr_find_e.isra.0+0x3ed/0x670 fs/ntfs3/index.c:762 indx_find+0x4b5/0x900 fs/ntfs3/index.c:1186 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... Allocated by task 9279: kasan_save_stack+0x39/0x70 mm/kasan/common.c:56 kasan_save_track+0x14/0x40 mm/kasan/common.c:77 kasan_save_alloc_info+0x37/0x60 mm/kasan/generic.c:573 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0xc3/0xd0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __do_kmalloc_node mm/slub.c:5650 [inline] __kmalloc_noprof+0x2bd/0x900 mm/slub.c:5662 kmalloc_noprof include/linux/slab.h:961 [inline] indx_read+0x41d/0xad0 fs/ntfs3/index.c:1059 indx_find+0x447/0x900 fs/ntfs3/index.c:1179 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... [CAUSE] The index-header validators only validated INDEX_HDR-level geometry. They did not walk each NTFS_DE to verify entry alignment, subnode layout, or that key_size fit inside the entry payload. They also allowed a last sentinel entry to carry a non-zero key_size. [FIX] Walk every NTFS_DE in ntfs3's index-header validators and reject entries with invalid layout, mismatched subnode state, oversized key_size, or non-zero sentinel keys before lookup or log replay can consume them.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97439", "url": "https://ubuntu.com/security/CVE-2026-97439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib [BUG] A corrupted ntfs3 image can hit a NULL function pointer call in generic_perform_write() after toggling system.ntfs_attrib and then overwriting system.dos_attrib on the same file. BUG: kernel NULL pointer dereference, address: 0000000000000000 \\#PF: supervisor instruction fetch in kernel mode \\#PF: error_code(0x0010) - not-present page PGD bed5067 P4D bed5067 PUD 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffff88801025f988 EFLAGS: 00010246 Call Trace: generic_perform_write+0x409/0x8c0 mm/filemap.c:4255 __generic_file_write_iter+0x1bb/0x200 mm/filemap.c:4372 ntfs_file_write_iter+0xcd9/0x1c20 fs/ntfs3/file.c:1253 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x63b/0xf70 fs/read_write.c:686 ksys_write+0x133/0x250 fs/read_write.c:738 __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x77/0xc0 fs/read_write.c:746 ... [CAUSE] system.ntfs_attrib updates ATTR_DATA flags via ni_new_attr_flags() and switches i_mapping->a_ops to ntfs_aops_cmpr when FILE_ATTRIBUTE_COMPRESSED is set. system.dos_attrib then overwrites ni->std_fa from a one-byte DOS attribute value, clearing the compression bit without updating ATTR_DATA or the mapping operations. Old buffered writes use is_compressed(ni) to choose __generic_file_write_iter(). That leaves generic_perform_write() calling a NULL write_begin callback from ntfs_aops_cmpr. [FIX] Treat system.dos_attrib as a low-byte DOS attribute update and preserve the existing non-DOS attribute bits in ni->std_fa. This keeps compressed and sparse state consistent with ATTR_DATA and the mapping operations while keeping the existing DOS attribute semantics intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97440", "url": "https://ubuntu.com/security/CVE-2026-97440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix node refcount leak on ctrl packet alloc failure qrtr_send_resume_tx() calls qrtr_node_lookup() which takes a reference on the returned node. If the subsequent call to qrtr_alloc_ctrl_packet() fails due to memory allocation failure, the function returns -ENOMEM without calling qrtr_node_release() to release the node reference. Add qrtr_node_release(node) before returning on the allocation failure path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97441", "url": "https://ubuntu.com/security/CVE-2026-97441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: ahci: fail probe if BAR too small for claimed ports When an AHCI controller is disabled in BIOS, its HOST_CAP register may contain a bogus value, e.g. 0xFFFFFFFF. Since CAP.NP (Number of Ports) is a zeroes based 5-bit register field, a value of 0x1f means 32 ports. If CAP.NP claims more ports than can physically fit within the mapped BAR region, accessing port registers beyond the BAR boundary causes a kernel panic. Add validation in ahci_init_one() to check that the BAR size is sufficient for the number of ports claimed in CAP.NP. The check calculates the required MMIO size as: required_size = 0x100 (global registers) + max_ports * 0x80 If required_size exceeds the actual BAR size, the probe fails with -ENODEV, preventing the panic and providing a clear error message. [cassel: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97443", "url": "https://ubuntu.com/security/CVE-2026-97443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/ftrace: Fix WARNING in __unregister_ftrace_function perf_ftrace_function_unregister() unconditionally calls unregister_ftrace_function() without checking whether the ftrace_ops was ever successfully registered. This triggers a WARN_ON in __unregister_ftrace_function() when the ops doesn't have FTRACE_OPS_FL_ENABLED set. This can happen during perf_event_alloc() error cleanup when perf_trace_destroy() is called via __free_event() on an event whose ftrace_ops registration failed or was already torn down by perf_try_init_event()'s err_destroy path. The call path is: perf_event_alloc() error cleanup -> __free_event() -> event->destroy() [tp_perf_event_destroy] -> perf_trace_destroy() -> perf_trace_event_close() -> TRACE_REG_PERF_CLOSE -> perf_ftrace_function_unregister() -> unregister_ftrace_function() -> __unregister_ftrace_function() -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to unregister. If the ops is not enabled, just free the filter and return success.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97444", "url": "https://ubuntu.com/security/CVE-2026-97444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in two places Add boundary checks in acpi_ps_get_next_namestring() and acpi_ps_peek_opcode() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97445", "url": "https://ubuntu.com/security/CVE-2026-97445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources() Enhance buffer validation in acpi_ut_walk_aml_resources() to prevent buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97446", "url": "https://ubuntu.com/security/CVE-2026-97446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package() acpi_ns_custom_package() unconditionally dereferences the first element of the package to read the _BIX version number, without checking for NULL: if ((*Elements)->Common.Type != ACPI_TYPE_INTEGER) When firmware returns a _BIX package whose first element is an unresolvable reference, ACPICA evaluates that entry to NULL. acpi_ns_remove_null_elements() does not strip NULL entries for ACPI_PTYPE_CUSTOM packages (fixed-position format would break if elements were shifted), so acpi_ns_custom_package() sees the NULL and causes a crash. Add a NULL check for the first element (version field) before dereferencing it. The caller then receives AE_AML_OPERAND_TYPE instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97448", "url": "https://ubuntu.com/security/CVE-2026-97448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add validation for node in acpi_ns_build_normalized_path() Add validation for node in acpi_ns_build_normalized_path() to prevent use-after-free vulnerabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97449", "url": "https://ubuntu.com/security/CVE-2026-97449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add package limit checks in parser functions Add package limit checks in parser functions to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97450", "url": "https://ubuntu.com/security/CVE-2026-97450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate handler object type in two places ACPICA: validate handler object type in acpi_ev_has_default_handler() and acpi_ev_find_region_handler().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97451", "url": "https://ubuntu.com/security/CVE-2026-97451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op) Add overflow check for Index + Length to prevent integer overflow when calculating the truncation length. This prevents negative size parameter being passed to memcpy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97452", "url": "https://ubuntu.com/security/CVE-2026-97452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Prevent adding invalid references Prevent adding references for local, argument, and debug objects in acpi_ut_copy_simple_object().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97453", "url": "https://ubuntu.com/security/CVE-2026-97453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate byte_count in acpi_ps_get_next_package_length() Validate package length reading in acpi_ps_get_next_package_length().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97454", "url": "https://ubuntu.com/security/CVE-2026-97454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in acpi_ps_get_next_field() Add boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97455", "url": "https://ubuntu.com/security/CVE-2026-97455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix use-after-free in acpi_ds_terminate_control_method() Fix use-after-free issue in acpi_ds_terminate_control_method() by clearing references to method locals and arguments.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97456", "url": "https://ubuntu.com/security/CVE-2026-97456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix condition check in acpi_ps_parse_loop() Fix condition check for AML_ELSE_OP in acpi_ps_parse_loop() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97472", "url": "https://ubuntu.com/security/CVE-2026-97472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: fix temp address generation after prefix deprecation When a router temporarily deprecates an IPv6 prefix (either by sending a Router Advertisement with Preferred Lifetime = 0 or by letting the lifetime expire) and later restores it, the kernel permanently loses its ability to generate temporary privacy addresses (RFC 8981) for that prefix. This happens because the address worker attempts to generate a replacement temporary address when the current one nears expiration. As the base prefix is deprecated already, the generation fails after marking the temporary address as already having spawned a replacement (ifp->regen_count++). When the router eventually restores the prefix, the temporary address becomes active again. However, once it naturally expires, the address worker sees this temporary address already tried to generate one and skips the regeneration. Fix the issue by resetting the regen_count check of the latest temp address generated for the prefix updated by the incoming RA.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97475", "url": "https://ubuntu.com/security/CVE-2026-97475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tegra/soctherma: Switch to devm cooling device registration Use devm_thermal_of_cooling_device_register() to simplify resource management and avoid manual cleanup in error paths. As a side effect this change has the benefit of solving an existing issue. Before, the function tegra_soctherm_remove() only called debugfs_remove_recursive() and never called thermal_cooling_device_unregister() for any of the cooling devices registered here. After the driver removal, the thermal framework's cdev list would still hold references to thermal_cooling_device objects whose devdata pointer (ts) pointed to memory already freed by the platform device's devm cleanup. With this change, the cooling device is unregistered when the driver is removed, thus fixing the issue above.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97476", "url": "https://ubuntu.com/security/CVE-2026-97476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: filter RDS_INFO_* getsockopt by caller's netns The RDS_INFO_* family of getsockopt(2) options reads several file-scope global lists that are not per-netns: rds_sock_info / rds6_sock_info, rds_sock_inc_info / rds6_sock_inc_info -> rds_sock_list rds_tcp_tc_info / rds6_tcp_tc_info -> rds_tcp_tc_list rds_conn_info / rds6_conn_info, rds_conn_message_info_cmn (for the *_SEND_MESSAGES and *_RETRANS_MESSAGES variants), rds_for_each_conn_info (for RDS_INFO_IB_CONNECTIONS) -> rds_conn_hash[] The handlers do not filter by the caller's network namespace. rds_info_getsockopt() has no netns or capable() check, and rds_create() has no capable() check, so AF_RDS is reachable from an unprivileged user namespace. As a result, an unprivileged caller in a fresh user_ns plus netns can read the bound address and sock inode of every RDS socket on the host, the peer address of incoming messages on every RDS socket on the host, the peer address and TCP sequence numbers of every rds-tcp connection on the host, and the peer address and RDS sequence numbers of every RDS connection on the host. The rds-tcp transport is reachable from a non-initial netns (see rds_set_transport()), so a one-shot init_net gate at rds_info_getsockopt() would deny legitimate per-netns visibility to rds-tcp callers. Instead, filter at each handler by comparing the netns of the caller's socket to the netns of the list entry, or to rds_conn_net(conn) for connection paths. Only copy entries whose netns matches the caller. Counters (RDS_INFO_COUNTERS) are aggregate statistics and remain global. Reproducer (KASAN VM, rds and rds_tcp loaded): an AF_RDS socket binds 127.0.0.1:4242 in init_net as root. A child process enters a fresh user_ns plus netns and opens AF_RDS there, then calls getsockopt(SOL_RDS, RDS_INFO_SOCKETS). Before this change, the child sees the init_net socket. After this change, the child sees zero entries. Drop the rds_sock_count, rds_tcp_tc_count, and rds6_tcp_tc_count globals. v2 used them for the size precheck and lens->nr; v3 replaced the precheck with a per-ns count from a first pass over the list, so the globals have no remaining readers. The matching increments and decrements in rds_create()/rds_destroy_sock() and rds_tcp_set_callbacks()/rds_tcp_restore_callbacks() go away with them. Reported by the kernel test robot under clang W=1.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97481", "url": "https://ubuntu.com/security/CVE-2026-97481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix possible ISR soft lockup There are rare cases in which the host gets stuck in the ISR because it is flooded with messages during the startup phase. The reason for the soft lockup in the ISR is the missing FIFO error IRQ (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers the IRQ immediately again. Fix this by adding a check for the FIFOE status and clearing the FIFO if no data is ready (DR). This behavior was observed on an AM62L device which uses the OMAP 8250 driver. Fix it for all 8250 drivers, since the OMAP driver's special IRQ setup handling may trigger this behavior more frequently, but it is not ensured that other 8250 drivers aren't affected.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97482", "url": "https://ubuntu.com/security/CVE-2026-97482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET log goku_irq() handles a number of bus events under a single ep0 path. It already guards the gadget driver suspend/resume callbacks against a NULL ->driver: \tif (dev->gadget.speed != USB_SPEED_UNKNOWN \t\t\t&& dev->driver \t\t\t&& dev->driver->resume) { \t\tspin_unlock(&dev->lock); \t\tdev->driver->resume(&dev->gadget); \t\t... \t} but the very next branch unconditionally dereferences dev->driver when an INT_USBRESET arrives: \tif (stat & INT_USBRESET) { \t\tACK(INT_USBRESET); \t\tINFO(dev, \"USB reset done, gadget %s\\n\", \t\t\tdev->driver->driver.name); \t} If the controller raises INT_USBRESET before any gadget driver has been bound (or after one has been unbound), dev->driver is NULL and the printk dereferences NULL. smatch flags the inconsistency: drivers/usb/gadget/udc/goku_udc.c:1618 goku_irq() error: we previously assumed 'dev->driver' could be null (see line 1607) Fall back to a placeholder when the gadget driver is not bound. No functional change while a gadget driver is bound.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97483", "url": "https://ubuntu.com/security/CVE-2026-97483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: hcd: fix possible deadlock in rh control transfers >From within the SCSI error handler memory allocations must not trigger IO. Handling errors in UAS and the storage driver may involve resetting a device. The thread doing the reset itself relies on VM magic. However, that is insufficient, as resetting a device involves resuming it. Resumption as well as resetting involves conrol transfers to the parent of the device to be reset. That may be a root hub. Hence usbcore must heed the flags passed to usb_submit_urb() processing control transfers to root hubs. The problem exist since the storage driver has been merged.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97484", "url": "https://ubuntu.com/security/CVE-2026-97484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vhci_hcd: fix NULL deref in status_show_vhci platform_get_drvdata() can return NULL if a VHCI host controller's probe failed (e.g. due to USB bus number exhaustion). status_show_vhci() checked for a NULL pdev but not for a NULL hcd returned by platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not return NULL - it returns a pointer offset of 0x260, causing a NULL pointer dereference when that value is subsequently dereferenced. Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move status_show_not_ready() above status_show_vhci() to make it callable from the new error path without a forward declaration.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97485", "url": "https://ubuntu.com/security/CVE-2026-97485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: omfs: handle set_blocksize failures omfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97486", "url": "https://ubuntu.com/security/CVE-2026-97486", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hpfs: handle set_blocksize failures hpfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97487", "url": "https://ubuntu.com/security/CVE-2026-97487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: handle set_blocksize failures jfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97488", "url": "https://ubuntu.com/security/CVE-2026-97488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qnx4: handle set_blocksize failures qnx4 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97489", "url": "https://ubuntu.com/security/CVE-2026-97489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bfs: handle set_blocksize failures bfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the \tBUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97490", "url": "https://ubuntu.com/security/CVE-2026-97490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: affs: handle set_blocksize failures affs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97491", "url": "https://ubuntu.com/security/CVE-2026-97491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Don't sleep inside rds_ib_conn_path_shutdown New rds rdma self tests exposed a hang when tearing down the ib network configs. This is caused by the shutdown worker thread sleeping on the wait_event call, which blocks other work items in the queue. Fix this by changing wait_event to wait_event timeout, and looping until the wait check succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97492", "url": "https://ubuntu.com/security/CVE-2026-97492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed In case reconfiguration of NAN fails, we call ieee80211_handle_reconfig_failure, that marks all interfaces as not in the driver. Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces is called to destroy all the interfaces. If we have any other interface but the NAN one, for example a BSS station, then when its state (links, stations) will be removed, we won't tell the driver about this, because we will think that the interfaces are not in the driver, and then drivers might remain with dangling pointers to objects like stations and links (at least for iwlwifi this is the case). ieee80211_handle_reconfig_failure is meant to be called after we cleaned up the state in the driver, there is no reason to call it for NAN reconfiguration failure. Fix the code to just warn in such a case, as we do in other error paths in reconfig where it is too complicated to rewind.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97502", "url": "https://ubuntu.com/security/CVE-2026-97502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: avoid NULL deref of host->data in IRQ handler mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL: if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; } So we may legitimately reach the rest of the handler with host->data == NULL (and therefore data == NULL). The DATDNE branch already guards against this with an explicit \"if (data != NULL)\" check, but the subsequent TOUTRD (\"read data timeout\") and CRCWR/CRCRD (\"data CRC error\") branches dereference data unconditionally: if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); } if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... } If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this: drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914) Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch. No functional change for callers where data is non-NULL, which is the only case in which these branches did meaningful work before this change.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97506", "url": "https://ubuntu.com/security/CVE-2026-97506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ixp4xx - fix buffer chain unwind on allocation failure chainup_buffers() builds a linked list of buffer descriptors for a scatterlist. If dma_pool_alloc() fails while constructing the list, the current code sets buf to NULL and later dereferences it unconditionally at the end of the function: buf->next = NULL; buf->phys_next = 0; This can lead to a null-pointer dereference on allocation failure. If the failure happens after part of the descriptor chain has already been allocated and DMA-mapped, the partially constructed chain also needs to be released. Fix this by terminating the partially constructed chain on allocation failure and letting the callers unwind it via their existing cleanup paths. Also fix ablk_perform() to preserve the hook pointers before checking for failure, so partially built chains can be freed correctly.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97507", "url": "https://ubuntu.com/security/CVE-2026-97507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dm1105: fix missing error check for dma_alloc_coherent The return value of dm1105_dma_map(), which handles DMA memory allocation, is ignored in dm1105_hw_init(). If dma_alloc_coherent() fails, the driver will proceed using a NULL pointer for DMA transfers, leading to a kernel oops or invalid hardware access. Fix this by checking the return value and propagating -ENOMEM on failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97508", "url": "https://ubuntu.com/security/CVE-2026-97508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Set tb->root_switch to NULL when domain is stopped Similarly what we do with the firmware connection manager. This makes tb_xdp_handle_request() return error to the remote host. However, we need to make sure we keep the uuid alive so that we can reply until the whole domain is released.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97510", "url": "https://ubuntu.com/security/CVE-2026-97510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Release request if tb_cfg_request() fails in __tb_xdomain_response() If tb_cfg_request() fails setting up the request (for example the control channel is shut down already) it returns an error without calling the callback. To avoid leaking that memory, call tb_cfg_request_put() if tb_cfg_request() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-90053", "url": "https://ubuntu.com/security/CVE-2026-90053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_htb: limit htb_classify inner-class filter hops htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent. The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification. htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90054", "url": "https://ubuntu.com/security/CVE-2026-90054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix corruption of urgent data on multi-segment retransmit On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: \t/* tcp_write_xmit() */ \tlimit = mss_now; \tif (tso_segs > 1 && !tcp_urg_mode(tp)) \t\tlimit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: \t/* __tcp_retransmit_skb() */ \tlen = cur_mss * segs;\t\t/* segs > 1, no urg_mode check */ \t... \t/* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: \tseg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) \tseg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) \tseg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90055", "url": "https://ubuntu.com/security/CVE-2026-90055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90056", "url": "https://ubuntu.com/security/CVE-2026-90056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: only stop PTP if it was initialized fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90058", "url": "https://ubuntu.com/security/CVE-2026-90058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai. Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted. Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90062", "url": "https://ubuntu.com/security/CVE-2026-90062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: move hardware offload step after building the chain blob Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90063", "url": "https://ubuntu.com/security/CVE-2026-90063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90067", "url": "https://ubuntu.com/security/CVE-2026-90067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: validate banner payload length When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (`server_feat` and `server_req_feat`). Therefore, `payload_len` must be at least 16 bytes. Fix this by adding a check in `process_banner_prefix()` to reject a `payload_len` smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90068", "url": "https://ubuntu.com/security/CVE-2026-90068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix off-by-one check on the second enum channel The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80x_mux_values. The core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which defaults off.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-93245", "url": "https://ubuntu.com/security/CVE-2026-93245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: policy_int make sure list heads are initialized before fail path If profile create fails before policy_init is complete the list heads are not properly initialized causing profile_free() sanity checks to trigger the following splat. AppArmor WARN aa_policy_destroy: (((!list_empty(&policy->profiles) && (&policy->profiles)->prev != ((void *) 0x122 + (0xdead000000000000UL))))): WARNING: security/apparmor/lib.c:509 at aa_policy_destroy+0x164/0x1b0 security/apparmor/lib.c:509, CPU#0: syz.0.17/5541 Modules linked in: CPU: 0 UID: 0 PID: 5541 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:aa_policy_destroy+0x16b/0x1b0 security/apparmor/lib.c:509 Code: 85 ed 7e 4d e8 96 bc 37 fd 5b 41 5c 41 5e 41 5f 5d e9 19 27 4e 07 cc e8 83 bc 37 fd 48 8d 3d 0c f0 d3 0b 48 c7 c6 a4 eb 38 8e <67> 48 0f b9 3a e9 04 ff ff ff e8 66 bc 37 fd 48 8d 3d ff ef d3 0b RSP: 0018:ffffc9000345eaa0 EFLAGS: 00010293 RAX: ffffffff848f530d RBX: ffff88803f734800 RCX: ffff88801af2a580 RDX: 0000000000000000 RSI: ffffffff8e38eba4 RDI: ffffffff90634320 RBP: 0000000000000000 R08: 0000000000000cc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d95913 R12: dead000000000122 R13: ffff88803f734800 R14: ffff88803f734828 R15: dffffc0000000000 FS: 00007f5f6a1836c0(0000) GS:ffff88808c519000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d02407b048 CR3: 0000000012aa9000 CR4: 0000000000352ef0 Call Trace: aa_free_profile+0x9d/0x9f0 security/apparmor/policy.c:334 aa_alloc_profile+0x1e4/0x3e0 security/apparmor/policy.c:416 unpack_profile security/apparmor/policy_unpack.c:1153 [inline] aa_unpack+0x17db/0x7430 security/apparmor/policy_unpack.c:1748 aa_replace_profiles+0x226/0x2a20 security/apparmor/policy.c:1183 policy_update+0x234/0x4a0 security/apparmor/apparmorfs.c:505 profile_load+0x1cb/0x320 security/apparmor/apparmorfs.c:522 vfs_write+0x296/0xba0 fs/read_write.c:685 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f6939e0d9 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:00007f5f6a183028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f5f69625fa0 RCX: 00007f5f6939e0d9 RDX: 0000000000000041 RSI: 0000200000000400 RDI: 0000000000000003 RBP: 00007f5f6a183090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f5f69626038 R14: 00007f5f69625fa0 R15: 00007ffe23725c18", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90070", "url": "https://ubuntu.com/security/CVE-2026-90070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Return zero on status read failure st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or error path instead of acting on an invalid status value. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90071", "url": "https://ubuntu.com/security/CVE-2026-90071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: restore skb->dev on the slave failure path teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90072", "url": "https://ubuntu.com/security/CVE-2026-90072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90073", "url": "https://ubuntu.com/security/CVE-2026-90073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare \"tc qdisc add ... hhf\" succeeds with a clamped quantum but \"tc qdisc add ... hhf limit 1000\" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90074", "url": "https://ubuntu.com/security/CVE-2026-90074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp default quantum to avoid signed overflow fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90075", "url": "https://ubuntu.com/security/CVE-2026-90075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_codel: clamp default quantum and mtu fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests \"*backlog <= params->mtu\"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memory_limit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double psched_mtu() call. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90078", "url": "https://ubuntu.com/security/CVE-2026-90078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: fix length calculations and avoid invalid header warnings syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act(): !skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55 There are a few issues in tcf_skbmod_act(): 1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets). Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90081", "url": "https://ubuntu.com/security/CVE-2026-90081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in rds_cong_map_updated() rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-89780", "url": "https://ubuntu.com/security/CVE-2026-89780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: restore skb->dev on deaggregated frames rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89789", "url": "https://ubuntu.com/security/CVE-2026-89789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets().", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90088", "url": "https://ubuntu.com/security/CVE-2026-90088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90102", "url": "https://ubuntu.com/security/CVE-2026-90102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: key the data server cache on the NFS version nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4. Two deviceids on one address with different ds_versions[0].version therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL. Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90103", "url": "https://ubuntu.com/security/CVE-2026-90103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix LAYOUTSTATS send buffer exhaustion encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that. ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for. The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held. Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90107", "url": "https://ubuntu.com/security/CVE-2026-90107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free pending qentry in smc_llc_flow_stop() before memset smc_llc_flow_stop() resets a flow struct with a blind memset: \tspin_lock_bh(&lgr->llc_flow_lock); \tmemset(flow, 0, sizeof(*flow)); \tflow->type = SMC_LLC_FLOW_NONE; \tspin_unlock_bh(&lgr->llc_flow_lock); If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object. A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct. Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90114", "url": "https://ubuntu.com/security/CVE-2026-90114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: Reject descending VLAN tunnel ranges A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90126", "url": "https://ubuntu.com/security/CVE-2026-90126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf8563: fix clock provider leak on unbind pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference. The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90128", "url": "https://ubuntu.com/security/CVE-2026-90128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: fix wrong list iterated in add_direct_chain error path In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89779", "url": "https://ubuntu.com/security/CVE-2026-89779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate ef->size covers the record's name and value When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to cover it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89781", "url": "https://ubuntu.com/security/CVE-2026-89781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read in read_log_rec_buf() read_log_rec_buf() copies a log record into a caller buffer starting at \tu32 off = lsn_to_page_off(log, lsn) + log->record_header_len; log->record_header_len (and log->data_off, used for the following pages) comes verbatim from the on-disk restart area and is only checked for 8-byte alignment in is_rst_area_valid(), so off can exceed log->page_size. \"tail = log->page_size - off\" then underflows and memcpy() reads past the page_size-sized buffer returned by read_log_page(), spilling adjacent slab memory into the replay buffer. This is reachable by mounting a crafted NTFS image: BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580 Read of size 64 at addr ffff88800a877ff8 by task exploit/127 read_log_rec_buf fs/ntfs3/fslog.c:2299 log_replay fs/ntfs3/fslog.c:4216 ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324 ntfs_fill_super fs/ntfs3/super.c:1392 get_tree_bdev_flags fs/super.c:1694 __x64_sys_mount fs/namespace.c:4360 The buggy address is located 4088 bytes to the right of the 4096-byte region [ffff88800a876000, ffff88800a877000) Reject an in-page offset outside the current page before the copy. [almaz.alexandrovich@paragon-software.com: replaced the >= sign with >]", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90140", "url": "https://ubuntu.com/security/CVE-2026-90140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cuse: wait for pending RCU callbacks on module exit Since commit 053fc4f755ad (\"fuse: fix UAF in rcu pathwalks\"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory: userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text! The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour). Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90141", "url": "https://ubuntu.com/security/CVE-2026-90141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix integer overflow in ftp helper port/address parsing ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16 (hport) and into unsigned char (p[]) without checking for overflow. A crafted FTP PASV/EPSV response with an over-long port or address octet wraps the value, so the helper configures the data connection with a truncated port/address. The netfilter conntrack FTP helper had the same defect, fixed in commit 2b413fc689ba (\"netfilter: nf_conntrack_ftp: avoid u16 overflows\"). Apply the equivalent fix here: widen the port accumulator to u32 and reject values above 65535, and reject address octets above 255.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90143", "url": "https://ubuntu.com/security/CVE-2026-90143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: kcm: Hold RCU read lock while running BPF parser kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser program. Hold the RCU read lock while running the program.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90151", "url": "https://ubuntu.com/security/CVE-2026-90151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: remove callback IDR entry on client allocation failure nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown. A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it. Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client. This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90157", "url": "https://ubuntu.com/security/CVE-2026-90157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative optlen in cgroup getsockopt hook A cgroup getsockopt BPF program can shrink ctx->optlen after the kernel getsockopt handler has run. The kernel-buffer variant, used by TCP_ZEROCOPY_RECEIVE, only rejects values larger than the original length. If BPF writes a negative optlen, that value is accepted and propagated back to the TCP getsockopt code. It can then be passed to copy_to_sockptr() as a size_t and trigger the hardened usercopy bytes > INT_MAX warning. Reject negative ctx.optlen in __cgroup_bpf_run_filter_getsockopt_kern(), matching the lower-bound validation already present in the sockptr-based getsockopt hook.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90160", "url": "https://ubuntu.com/security/CVE-2026-90160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lwt_bpf: Restore reserved headroom after xmit program ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output. That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise. On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb. Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90198", "url": "https://ubuntu.com/security/CVE-2026-90198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix use-after-free in snd_card_do_free() A use-after-free was detected in snd_card_do_free() when a sound card managed by devres is unbound while a user-space application still holds an open file descriptor. For managed cards, the memory is allocated using devres_alloc(), and its release function is set to __snd_card_release(), which calls snd_card_free(). When the device is unbound, the unbind thread calls snd_card_free(), which drops a reference to the card's device. If the user thread still has an open file descriptor, the reference count does not reach zero, and the unbind thread blocks on wait_for_completion(&released). When the user thread closes the file descriptor, it drops the final reference, invoking the device release callback release_card_device(), which calls snd_card_do_free(). snd_card_do_free() performs cleanup and calls complete(card->release_completion). This wakes up the unbind thread, which returns from snd_card_free() and __snd_card_release(). The devres core then immediately frees the memory block containing the snd_card structure. Meanwhile, the user thread continues execution in snd_card_do_free() and evaluates `if (!card->managed)`. It reads the `managed` boolean from the snd_card structure that was just freed by the unbind thread, triggering a KASAN use-after-free. Fix this by caching the value of card->managed in a local variable before calling complete(). This ensures that the card pointer is not dereferenced after the unbind thread has been woken up and potentially freed the card. BUG: KASAN: use-after-free in snd_card_do_free sound/core/init.c:604 [inline] BUG: KASAN: use-after-free in release_card_device+0x1ab/0x1b0 sound/core/init.c:153 Read of size 1 at addr ffff8881912ec909 by task syz-executor130/5857 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description+0x55/0x1e0 mm/kasan/report.c:378 print_report+0x58/0x70 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 snd_card_do_free sound/core/init.c:604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c:153 device_release+0xc4/0x1f0 drivers/base/core.c:-1 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x222/0x550 lib/kobject.c:737 snd_card_file_remove+0x331/0x390 sound/core/init.c:1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c:2986 __fput+0x418/0xa50 fs/file_table.c:512 fput_close_sync+0x11f/0x240 fs/file_table.c:617 __do_sys_close fs/open.c:1511 [inline] __se_sys_close fs/open.c:1496 [inline] __x64_sys_close+0x7e/0x110 fs/open.c:1496 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90202", "url": "https://ubuntu.com/security/CVE-2026-90202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers _base_release_memory_pools() unconditionally frees every ioc->pcie_sg_lookup[] entry, including ones the setup loop never allocated after a partial failure, causing a \"bad dma\" warning on debug kernels or a NULL pointer dereference otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90203", "url": "https://ubuntu.com/security/CVE-2026-90203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check block offset is not negative If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93252", "url": "https://ubuntu.com/security/CVE-2026-93252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix circular locking dependency in ocfs2_init_acl() A lockdep warning indicates a circular locking dependency between `&oi->ip_xattr_sem` and `&journal->j_trans_barrier`: WARNING: possible circular locking dependency detected is trying to acquire lock: (&oi->ip_xattr_sem){++++}-{4:4}, at: ocfs2_init_acl+0x2fd/0x7e0 fs/ocfs2/acl.c:367 but task is already holding lock: (&journal->j_trans_barrier){.+.+}-{4:4}, at: ocfs2_start_trans+0x3ab/0x700 fs/ocfs2/journal.c:369 The deadlock involves two code paths: Path 1 (setxattr) where `ocfs2_xattr_set()` acquires `ip_xattr_sem` (write) and then starts a transaction, which acquires `j_trans_barrier` (read); and Path 2 (mkdir/mknod) where `ocfs2_mknod()` starts a transaction (`j_trans_barrier` read) and then calls `ocfs2_init_acl()`, which attempts to acquire `ip_xattr_sem` (read) on the parent directory to retrieve the default ACL. Because rw_semaphores are subject to writer priority, a pending writer on `j_trans_barrier` (e.g., the journal commit thread) can cause Path 1 to block, while Path 2 is blocked waiting for Path 1 to release `ip_xattr_sem`. The patch fixes the lock ordering by precomputing the ACL state before starting the OCFS2 transaction, while preserving POSIX ACL storage semantics and the existing inode/security initialization order. By reading the parent directory's default ACL and preparing the new inode's ACLs outside the transaction, `ip_xattr_sem` is always acquired before `j_trans_barrier`. `struct ocfs2_acl_state` encapsulates the prepared ACL state, while `ocfs2_acl_init_prepare()` and `ocfs2_acl_init_release()` avoid code duplication between `ocfs2_mknod()` and `ocfs2_init_security_and_acl()`. `ocfs2_calc_xattr_init()` and `ocfs2_init_acl()` use this precomputed state, removing internal `ip_xattr_sem` acquisition and redundant disk reads. Additionally, remove the `ip_xattr_sem` acquisition from `ocfs2_xattr_set_handle()`. This function is only used while initializing a new inode that has not yet been inserted into the inode hash or attached to a dentry, meaning there is no risk of concurrent access and the lock is unnecessary.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90209", "url": "https://ubuntu.com/security/CVE-2026-90209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/debug: Fix deadlock during unregister Unregistering an s390dbf debug area while one of the associated debugfs files is being written to can cause a deadlock: $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs write debugfs_file_get() debug_unregister() mutex_lock(debug_mutex) debugfs_remove() wait for debugfs_file_put() debug_file_ops.write() debug_input() mutex_lock(debug_mutex) ==> DEADLOCK Fix this by splitting debug_unregister() into an s390dbf and debugfs part, and running only the s390dbf part with debug_mutex locked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90214", "url": "https://ubuntu.com/security/CVE-2026-90214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: fix stream_data leak on open error In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream. Free stream_data and clear the stream pointer on the error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90216", "url": "https://ubuntu.com/security/CVE-2026-90216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubi: Fix rollback for explicit UBI device numbers ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90218", "url": "https://ubuntu.com/security/CVE-2026-90218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix WARNING in res_to_rt syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via addr_handler() during asynchronous address resolution: \" WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ib_addr process_one_req RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c:624 process_one_work kernel/workqueue.c:3375 [inline] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c:3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 \" In addr_handler(), cma_acquire_dev_by_src_ip() is called to populate id_priv->cma_dev and bind the associated ib_device to id_priv->id.device. If cma_acquire_dev_by_src_ip() returns an error (non-zero status), the ID remains unassociated with any RDMA device. Previously, rdma_restrack_add(&id_priv->res) was invoked unconditionally even when cma_acquire_dev_by_src_ip() failed, passing a resource with a NULL dev pointer and triggering the WARN_ON assertion in res_to_rt(). Fix this by only adding the resource to restrack when acquiring the device succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90219", "url": "https://ubuntu.com/security/CVE-2026-90219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Free debugfs on registration failure c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev. Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90221", "url": "https://ubuntu.com/security/CVE-2026-90221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing nci_core_init_rsp_packet_v1() and nci_core_init_rsp_packet_v2() parse the CORE_INIT_RSP packet without validating that the skb contains enough data. A malformed response (e.g. injected via virtual_ncidev) can declare a large num_supported_rf_interfaces while providing insufficient data, causing reads of uninitialized slab memory. This is later used in nci_init_complete_req(), triggering a KMSAN uninit-value warning. Add skb length checks before accessing packet fields: - Validate the skb has at least 1 byte for the status field. - Validate the skb can hold the fixed-size header before parsing. - In v2, bounds-check each variable-length rf_interface entry and its extension parameters within the parsing loop. - In v1, verify the skb is large enough for both the variable-length rf_interfaces array and the trailing rsp_2 structure.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90222", "url": "https://ubuntu.com/security/CVE-2026-90222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: hold a reference to the request skb during send_frame __pn533_send_async() publishes the command and then calls dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame can be matched to this command: the I2C threaded IRQ runs pn533_recv_frame(), which queues cmd_complete_work, and pn533_send_async_complete() frees cmd->req with consume_skb(). On the I2C transport, pn533_i2c_send_frame() still dereferences the same skb after i2c_master_send() returns, so a completion that races the send can free the skb while the transport is still using it. The request skb is owned by the command object and may be freed by command completion at any time after dev->cmd is published, so the transport send path must not assume it stays alive. Hold a temporary reference to the request skb across the send_frame() call so the transport always sees a live skb even if completion races the send. Add a pn533_send_cmd_frame() helper and use it from all three send paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90223", "url": "https://ubuntu.com/security/CVE-2026-90223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound SNL TLV parsing to the skb and add length checks nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed: - For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made \"service_name_len = length - 1\" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90224", "url": "https://ubuntu.com/security/CVE-2026-90224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix double completion race in nci_data_exchange_complete nci_close_device() and nci_rx_work can both call nci_data_exchange_complete() concurrently. After commit 4527025d440ce8 (\"nfc: nci: fix circular locking dependency in nci_close_device\") moved flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock), rx_work is no longer serialized with the explicit completion call in the close path. Both callers read the non-NULL callback pointer and invoke rawsock_data_exchange_complete(), which calls sock_put() -- but only one sock_hold() was taken, so the second sock_put() underflows the refcount and frees the socket while it is still in use. Replace the bare clear_bit(NCI_DATA_EXCHANGE) with test_and_clear_bit() so that only the first caller proceeds to invoke the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90225", "url": "https://ubuntu.com/security/CVE-2026-90225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: read llcp_sock->local under the socket lock in getsockopt nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and then dereferenced the cached pointer inside the locked region. llcp_sock_bind() assigns and clears llcp_sock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on lock_sock(), and then dereference a freed nfc_llcp_local once bind() has unwound. Move the llcp_sock->local read and the NULL check inside the lock_sock(sk) region so bind() cannot mutate or free the pointer between the load and the use.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90226", "url": "https://ubuntu.com/security/CVE-2026-90226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: avoid userspace overflow on invalid optlen nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90228", "url": "https://ubuntu.com/security/CVE-2026-90228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() When a host issues an Identify command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89784", "url": "https://ubuntu.com/security/CVE-2026-89784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6 rpcb_register_inet4() and rpcb_register_inet6() store the result of rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL. rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROC_SET encode path: rpcb_register_call() -> rpc_call_sync() -> rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel. The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890) rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910) rpcauth_wrap_req_encode (net/sunrpc/auth.c:745) call_encode (net/sunrpc/clnt.c:1966) __rpc_execute (net/sunrpc/sched.c:952) rpc_run_task (net/sunrpc/clnt.c:1243) rpc_call_sync (net/sunrpc/clnt.c:1272) rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500) svc_generic_rpcbind_set nfsd_rpcbind_set svc_register svc_setup_socket svc_addsock write_ports nfsctl_transaction_write vfs_write The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFP_KERNEL kstrdup() in rpc_sockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check. Mirror that handling: bail out with -ENOMEM when rpc_sockaddr2uaddr() returns NULL, before the address is fed into the encoder.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90245", "url": "https://ubuntu.com/security/CVE-2026-90245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: kyro: Validate overlay viewport coordinates The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90248", "url": "https://ubuntu.com/security/CVE-2026-90248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: fix teardown of an adopted proto on insert-race loss In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90249", "url": "https://ubuntu.com/security/CVE-2026-90249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes The IIO core does not filter duplicate writes to the event enable attribute, so writing the same value twice invokes write_event_config() twice. Enabling twice leaks a runtime PM reference, preventing the device from ever suspending again; disabling twice underflows the usage count and triggers a \"Runtime PM usage count underflow\" warning. Bail out early when the requested state matches the current state. While at it, switch to pm_runtime_resume_and_get() so a failed resume is propagated to userspace instead of silently marking the event enabled.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90251", "url": "https://ubuntu.com/security/CVE-2026-90251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: \tif (skb->len < sizeof(*rp)) { \t\tbt_dev_err(hdev, \"MSFT supported features length mismatch\"); \t\tgoto failed; \t} evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so \tmsft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, \t\t\t\t GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes (\"skb->len=11 evt_prefix_len=255\", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with \"MSFT event prefix length mismatch\" and msft->evt_prefix is left unset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90257", "url": "https://ubuntu.com/security/CVE-2026-90257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: avoid OOB read of build info string The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read Build Information) and hands the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length. A backend that answers with status only leaves that pointer past the end of the received data, so the walk reads adjacent slab memory until it meets a NUL. Those bytes reach the kernel log and the firmware-info debugfs file. To fix this, print the string with a bounded \"%.*s\" limited to skb->len - 1. A short or unterminated response then prints as much as arrived instead of failing setup. This mirrors commit dd068ef04412 (\"Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()\"), which fixed the identical pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90274", "url": "https://ubuntu.com/security/CVE-2026-90274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: etm4x: fix underflow for usage of (nrseqstate - 1) According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR is implemented only when TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000. IOW, the number of usage in the initialisation or setting TRCSEQEVR with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000. Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR relevant fields setup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90281", "url": "https://ubuntu.com/security/CVE-2026-90281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend Runtime PM must be enabled before creating the PHY, since phy_create() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference. Take a runtime PM usage reference with pm_runtime_get_noresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90283", "url": "https://ubuntu.com/security/CVE-2026-90283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: release subpool on fill_super failure hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size mount options are specified. hugepage_new_subpool() may also reserve huge pages for min_size. If root dentry creation fails after the subpool is created, the failure path frees the subpool with kfree(). This bypasses hugepage_put_subpool() and can leave min_size reservations charged. Use hugepage_put_subpool() on the failure path, matching the normal put_super path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90284", "url": "https://ubuntu.com/security/CVE-2026-90284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: do not queue completed sysfs fallback requests fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to pending_fw_head. device_add() publishes the fallback loading interface, so a userspace helper which discovers the device by scanning sysfs can write 0 to the loading attribute and complete the request before it is queued as pending. In that interleaving firmware_loading_store() calls fw_state_done() while pending_list still points to itself, so it cannot remove an entry from pending_fw_head. The subsequent unconditional list_add() then queues an already-completed fw_priv. Once the request is released, pending_fw_head can retain a pointer to freed memory and the next fallback request can fault while validating the list. Only in-flight fallback requests need suspend or reboot abort handling. If the request is already DONE after device_add(), return success from the fallback path without sending another uevent, waiting again, or queueing it as pending. This preserves the invariant that pending_fw_head contains only active fallback requests.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90285", "url": "https://ubuntu.com/security/CVE-2026-90285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path qla2x00_sysfs_read_vpd() called ha->isp_ops->read_optrom() a second time after releasing optrom_mutex. The repeated read is redundant and, unlike the first, runs without optrom_mutex held, exposing flash access to concurrent optrom operations. Drop the duplicate call.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90286", "url": "https://ubuntu.com/security/CVE-2026-90286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx6: Use PFP on the compute queues too On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90290", "url": "https://ubuntu.com/security/CVE-2026-90290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Restore DAIF state on error Sashiko AI has reported that if swsusp_mte_save_tags() for some reason fails we return from swsusp_arch_suspend() with DAIF being masked - that is not what we'd expect. Restore the saved DAIF state before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93256", "url": "https://ubuntu.com/security/CVE-2026-93256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: mask DAIF before restoring hibernated kernel The arm64 hibernate code manages the exception masking in an unsound way, leading to potential crashes and/or warnings during resume. When a hibernation image is saved in `swsusp_arch_suspend()`, all DAIF exceptions are masked (by virtue of `local_daif_save()`), and the suspended image is saved assuming that all DAIF exceptions will remain masked when the image is restored. When a hibernation image is resumed by `swsusp_arch_resume()`, only interrupts are masked (by virtue of `local_irq_disable()` in `resume_target_kernel()`). When pseudo-NMI is enabled the DAIF.IF bits will be clear, and regardless of pseudo-NMI the DAIF.DA bits will be clear. This means that there are two problems: (1) It is possible to take Debug, SError, or pseudo-NMI exceptions during the resume process. This is unsafe, as during the resume process both the old ane new kernels will tranisently be in an inconsistent state, and swsusp_arch_suspend_exit() won't retain an executable mapping of any exception vectors. Any exception taken here will be fatal and silent. (2) When re-entering the resumed kernel, some DAIF bits will be clear unexpectedly. This permits Debug, SError, or pseudo-NMI exceptions to be taken for a short period while the resumed kernel is not yet in a consistent state. This is detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING. Avoid these issues by masking all DAIF exceptions during resume.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90292", "url": "https://ubuntu.com/security/CVE-2026-90292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix use-after-free in siw_accept() siw_accept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it. The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association. Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90293", "url": "https://ubuntu.com/security/CVE-2026-90293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: post the full-feature receive buffers after session registration isert_put_login_tx() posts the full-feature receive buffers before __transport_register_session() runs, so an initiator that does not wait for the final Login Response can still have a SCSI command executed against an se_session whose se_tpg is NULL - the same oops as the previous patch, at target_submit+0xbe. Post them from isert_get_rx_pdu(), which the previous patch already uses to send that response, and post them before that send: the receive queue is filled at the moment the initiator is told it may use it. Allocating there keeps the existing property that a memory allocation failure cannot happen once the final Login Response is on the wire. The receive queue is already empty between the final Login Request and isert_post_recvm(); this moves the second point later, from a median of 92 us to 172 us over 1200 logins. Only an initiator that sends before it has been told to can reach that window, and on IB and RoCE its send is retried there until the buffers appear - isert_rdma_accept() asks for rnr_retry_count = 7. iWARP has no RNR flow control, so there the same send terminates the connection instead. Measured over rxe, 400 login cycles per run, with an initiator that does not wait: an instrumented build counted no entries to isert_recv_done() before the buffers are posted in 10 runs, where that initiator oopsed 8 of 10 unpatched runs and 5 of 10 with only the previous patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90294", "url": "https://ubuntu.com/security/CVE-2026-90294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: delay the final Login Response until the session is registered isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90295", "url": "https://ubuntu.com/security/CVE-2026-90295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: \timx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), \t\t\t\t GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90296", "url": "https://ubuntu.com/security/CVE-2026-90296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix devres accumulation across driver rebind imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system. Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver(). That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release. Tested by rebinding the driver on qemu's mcimx6ul-evk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90297", "url": "https://ubuntu.com/security/CVE-2026-90297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: crtc: Propagate layer initialization error sun4i_crtc_init() returns plain NULL when layer initialization fails, while all its other error paths return an error pointer. The only caller, sun4i_tcon_bind(), checks the result with IS_ERR() and happily continues with tcon->crtc set to NULL. sun4i_rgb_init() and sun4i_lvds_init() then dereference it in drm_crtc_mask(), which oopses. Return the error pointer instead.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90298", "url": "https://ubuntu.com/security/CVE-2026-90298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: tcon: Drop TCON TOP device reference of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90302", "url": "https://ubuntu.com/security/CVE-2026-90302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: synchronize heartbeat callbacks with o2net teardown Patch series \"ocfs2: harden heartbeat teardown races\". This series fixes two OCFS2 heartbeat/o2net teardown races found by KASAN. This patch (of 2): Heartbeat callbacks stay registered while configfs local-node teardown enters o2net_stop_listening(). A node-down event can still run through o2net_disconnect_node() and o2net_set_nn_state() while teardown is destroying o2net_wq, so the later queue/flush operations can hit a dead workqueue. KASAN has caught this as a slab-use-after-free in __queue_work() with the call chain: KASAN slab-use-after-free in __queue_work+0x56/0xa90 Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __queue_work+0x56/0xa90 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __queue_delayed_work+0x58/0x1e0 queue_delayed_work_on+0xb4/0xc0 o2net_set_nn_state+0x467/0x840 o2net_disconnect_node+0x7b/0xe0 o2net_hb_node_down_cb+0x54/0x60 o2hb_run_event_list+0x236/0x2d0 o2hb_check_slot+0xad4/0xbc0 lock_release+0xc8/0x290 o2hb_check_slot+0x9ea/0xbc0 trace_hardirqs_on+0x18/0x130 o2hb_do_disk_heartbeat+0x646/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) __lock_acquire+0x466/0x2260 lockdep_hardirqs_on_prepare+0xea/0x1a0 ktime_get_with_offset+0xe9/0x230 o2hb_thread+0x14e/0x770 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 __switch_to+0x2e9/0x730 ret_from_fork_asm+0x1a/0x30 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x292/0x760 __alloc_workqueue+0x736/0xc60 alloc_workqueue_noprof+0xb1/0x110 o2net_start_listening+0xe5/0x430 o2nm_node_local_store+0x184/0x310 configfs_write_iter+0x18a/0x210 vfs_write+0x469/0x810 ksys_write+0xd2/0x170 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 rcu_core+0x4f4/0x1320 handle_softirqs+0x156/0x660 queue_delayed_work_on o2net_set_nn_state o2net_disconnect_node o2net_hb_node_down_cb o2hb_run_event_list Keep heartbeat callbacks registered so quorum state still tracks node state, but stop them from driving o2net reconnect/disconnect work once local teardown starts. Mark the transport offline before destroying o2net_wq, wait for any in-flight heartbeat callback to finish, and delay bring-up replay until the new local node is published through o2nm_this_node(). The replay also has to stay serialized with heartbeat callback delivery. Otherwise a live-node snapshot can be copied, a real hb_down callback can install -ENOTCONN for a peer, and the stale replay can call o2net_hb_node_up() for that same peer and queue reconnect work even though heartbeat is already down. The buggy scenario involves two paths, with each column showing the order within that path: local-node teardown: heartbeat node-down callback: 1. configfs local-off enters 1. o2hb_run_event_list() invokes o2net_stop_listening(). o2net_hb_node_down_cb(). 2. teardown heads for 2. the callback reaches destroy_workqueue(o2net_wq). o2net_disconnect_node() and o2net_set_nn_state(). 3. teardown destroys and NULLs 3. the callback flushes or queues o2net_wq. work through o2net_wq.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90303", "url": "https://ubuntu.com/security/CVE-2026-90303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults When CONFIG_DEBUG_USER=y, and cmdline \"user_debug=31\" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the \"oops\" state, acquiring a lock may risk a deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90307", "url": "https://ubuntu.com/security/CVE-2026-90307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it: BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8) Without KASAN the returned bytes are whatever is next in the slab. One run returned \".strtab\". rsp->data[3] in srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90314", "url": "https://ubuntu.com/security/CVE-2026-90314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression \"table_sz - offset - sizeof(*hdr)\", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90316", "url": "https://ubuntu.com/security/CVE-2026-90316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/omap: dsi: Do not copy isr table To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90318", "url": "https://ubuntu.com/security/CVE-2026-90318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: release buffer head after rebuilding parent fat_scan_logstart() leaves the matching directory entry's buffer head in sinfo.bh for the caller to release, just like fat_scan(). fat_rebuild_parent() uses the directory entry to rebuild the parent inode for the nostale_ro NFS export path, but does not release sinfo.bh after a successful scan. Release it once fat_build_inode() has consumed the directory entry data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90319", "url": "https://ubuntu.com/security/CVE-2026-90319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: clear mport->net when rio_add_net() fails rio_alloc_net() stores the newly allocated rio_net in mport->net before rio_scan_alloc_net() registers the device. If rio_add_net() fails, rio_scan_alloc_net() drops the device reference with put_device(), which releases the rio_net through the device release callback. However, mport->net is left pointing at the freed object. A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rio_net again. Clear mport->net in the rio_add_net() failure path, matching the cleanup done for the destID table allocation failure path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90327", "url": "https://ubuntu.com/security/CVE-2026-90327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: do not write beyond optlen in getsockopt pep_getsockopt() clamps the reported length to the caller's buffer with min_t(), but then stores the value with put_user(val, (int __user *) optval), which always writes sizeof(int) bytes. A getsockopt() call with an optlen smaller than sizeof(int) thus reports the clamped length yet writes a full int, one to three bytes past the user buffer. Write the value with copy_to_user() bounded by len, so at most optlen bytes are copied, matching the length reported back to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90329", "url": "https://ubuntu.com/security/CVE-2026-90329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: synchronize input before cleaning up a failed probe hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90334", "url": "https://ubuntu.com/security/CVE-2026-90334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: clear cdev pointer after cdev_add() failure tty_cdev_add() drops the cdev reference when cdev_add() fails, but leaves driver->cdevs[index] pointing to freed memory. tty_unregister_device() later passes that stale pointer to cdev_del(), causing a use-after-free. Clear the slot after dropping the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90341", "url": "https://ubuntu.com/security/CVE-2026-90341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: coreboot: Validate table bounds The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90348", "url": "https://ubuntu.com/security/CVE-2026-90348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90360", "url": "https://ubuntu.com/security/CVE-2026-90360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: use system_freezable_wq for init complete work schedule_delayed_work() uses system_wq, which is non-freezable, allowing regulator_init_complete_work to run concurrently with system suspend. This work fires ~30s after boot to disable unused regulators via I2C. When it races with PM suspend, the I2C adapter may already be suspended, triggering a -ESHUTDOWN warning in __i2c_transfer(): WARNING: ... at __i2c_transfer+0x36c/0x3c8 Call trace: __i2c_transfer i2c_transfer regmap_i2c_write _regmap_update_bits regulator_disable_regmap _regulator_do_disable regulator_late_cleanup regulator_init_complete_work_function process_one_work Switch to system_freezable_wq so the work is frozen before any device is suspended, eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90361", "url": "https://ubuntu.com/security/CVE-2026-90361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix leak in ath11k_service_ready_ext_event() Currently, during ath11k_service_ready_ext_event() processing, svc_rdy_ext.mac_phy_caps can be allocated during TLV parsing. This is a temporary allocation that is freed on the success path, but not on the error path. If parsing succeeds far enough to allocate mac_phy_caps and then fails on a later TLV, the allocation leaks. So free the allocation on the error path. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90362", "url": "https://ubuntu.com/security/CVE-2026-90362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Drop dev_pm_opp_set_rate(0) dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Drop the explicit call to it. Every call site of ops->link_clk_disable() is followed by pm_runtime_put(), so the power vote will be rescinded if deemed safe. Patchwork: https://patchwork.freedesktop.org/patch/742783/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90372", "url": "https://ubuntu.com/security/CVE-2026-90372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss If a peer's VHT/HE MCS map has no supported spatial stream (all fields 0x3), the loop exits with nss == 0 and the function returned (u8)-1 (255), which was then written into the firmware sta_rec_bf beamforming fields. Clamp the result to 0.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90378", "url": "https://ubuntu.com/security/CVE-2026-90378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt792x: Fix memory leak in SDIO TX path When tx_prepare_skb() returns an error in the SDIO TX path, the skb is not freed, leading to a memory leak. This can occur when zero-length frames (such as WNM NULL frames) are dropped to prevent potential hardware TX hangs. Fix this by properly releasing the skb with ieee80211_tx_status_ext() when tx_prepare_skb() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90382", "url": "https://ubuntu.com/security/CVE-2026-90382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set. Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf (\"mt76x2: remove some harmless WARN_ONs in tx status and rx path\") did for the neighboring rx and tx status paths. Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93261", "url": "https://ubuntu.com/security/CVE-2026-93261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/lockdep: Fix NULL pointer dereference in __lock_set_class() register_lock_class() can return NULL when the lock class pool is exhausted, graph_lock() fails, or key validation fails. However, __lock_set_class() uses the return value directly in pointer arithmetic without a NULL check: class = register_lock_class(lock, subclass, 0); hlock->class_idx = class - lock_classes; If class is NULL, this computes a wild offset that corrupts hlock->class_idx. The subsequent reacquire_held_locks() call will invoke hlock_class() with this corrupted index, leading to a NULL or out-of-bounds pointer dereference. Add the missing NULL check, consistent with how __lock_acquire() already handles this case at the same call site.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93283", "url": "https://ubuntu.com/security/CVE-2026-93283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix device_register() error path When device_register() fails in i3c_master_register_new_i3c_devs(), put_device() is called to drop the reference taken by device_register(). That drops the last reference, so the device's release callback i3c_device_release() runs and frees the i3c_device. Two problems follow from that: i3c_device_release() does WARN_ON(i3cdev->desc), so it warns because desc->dev->desc still points back at the descriptor. Clear it before calling put_device(). After put_device() frees the i3c_device, desc->dev is left pointing at freed memory, so clear desc->dev as well. That prevents, for example, i3c_master_unregister_i3c_devs() seeing desc->dev as non-NULL and dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90386", "url": "https://ubuntu.com/security/CVE-2026-90386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90388", "url": "https://ubuntu.com/security/CVE-2026-90388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Check atomic pool allocation result directly The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90391", "url": "https://ubuntu.com/security/CVE-2026-90391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone dmirror_fault() is called from the dmirror_read() and dmirror_write() retry loops after dmirror_do_read() or dmirror_do_write() finds a missing device page table entry. If the mirrored mm has already exited, mmget_not_zero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress. Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90393", "url": "https://ubuntu.com/security/CVE-2026-90393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF in bpf_netns_link_update_prog In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90394", "url": "https://ubuntu.com/security/CVE-2026-90394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sc2731_charger: cancel work on remove The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released. Set the platform drvdata used by remove, then cancel the work after unregistering the notifier. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90395", "url": "https://ubuntu.com/security/CVE-2026-90395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: isp1704_charger: cancel work on remove The USB notifier and initial VBUS detection can schedule isp->work. The remove path unregisters the notifier and power supply, but does not wait for queued or running work before tearing down the power supply state. Cancel the work after unregistering the notifier. Do this before unregistering the power supply. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93262", "url": "https://ubuntu.com/security/CVE-2026-93262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5-ppl: fix use-after-free in ppl_do_flush() The loop in ppl_do_flush() continues iterating after calling ppl_io_unit_finished(), touching io->pending_flushes and leading to a use-after-free. Add a break statement to stop the loop once io is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90403", "url": "https://ubuntu.com/security/CVE-2026-90403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix error path in rtl_pci_probe() In the last error path in rtl_pci_probe(), the cleanup functions are skipped due to a wrong goto label. Moreover, the successful call to rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to be reverted. Fix this issue by updating the labels and adding the relevant cleanup functions to the last error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90411", "url": "https://ubuntu.com/security/CVE-2026-90411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request __nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the rsp_iu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmd_iu unmapped and still marked the op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call .exit_request() when .init_request() fails, the cmd_iu mapping is leaked for every op whose rsp_iu mapping fails. Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and returns the error without marking the op idle, so it stays in the FCPOP_STATE_UNINIT state set by the initial memset().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90413", "url": "https://ubuntu.com/security/CVE-2026-90413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject login PDUs declaring more data than was received isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), \tpayload_length = ntoh24(login_req->dlength); \ttmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90414", "url": "https://ubuntu.com/security/CVE-2026-90414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject PDUs declaring more data than was received isert_recv_done() hands each received PDU to the opcode handlers without ever looking at wc->byte_len, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) - out of the fixed-size descriptor: isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len); Because the declared length is never checked against wc->byte_len, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer. Nothing upstream of isert closes this door: - __iscsit_check_dataout_hdr() bounds the inbound payload against conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check. - iscsi_set_connection_parameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsi_check_acceptor_state(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling. - isert never clamps the negotiated value to its own fixed receive descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated. The imm_data_len == data_len path is more than an over-read: it aliases the receive descriptor via sg_set_buf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated. Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN: BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 isert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout() (ib_isert.c:1160), inlined through isert_rx_opcode(). Validate wc->byte_len against the framing in isert_recv_done() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISER_HEADERS_LEN (commit 29e7b925ae6d (\"IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN\")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all. isert reads the data segment from a fixed offset: isert_get_data() returns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum against wc->byte_len bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything furth ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90415", "url": "https://ubuntu.com/security/CVE-2026-90415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: free STAG index when TPT entry write fails write_tpt_entry() allocates a new STAG index with c4iw_get_resource() and bumps stats.stag.cur before programming the entry. When write_adapter_mem() fails, it returns the error without releasing the index or reversing the statistic. No MR is inserted into rhp->mrs, so deregistration never reclaims it, leaking the index until device teardown. Record whether this call allocated the index and, on a failed write, return it to tpt_table and decrement stats.stag.cur. Key the rollback on both the write error and that flag, not the error alone: a non-reset update carries a caller-owned STAG that this call did not allocate and must not free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90416", "url": "https://ubuntu.com/security/CVE-2026-90416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed \"%d\" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as \"-2147483648\\n\" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with \"%u\" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90419", "url": "https://ubuntu.com/security/CVE-2026-90419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent out-of-bounds read in super root block parsing super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90420", "url": "https://ubuntu.com/security/CVE-2026-90420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix infinite loop in nilfs_clean_segments() syzbot reported a hung task in nilfs_transaction_begin(). This occurs because the cleaner ioctl falls into an infinite loop if nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device is remounted as read-only after an I/O error). Currently in nilfs_clean_segments(), if err is non-zero, it logs the error and sleeps but doesn't abort when it encounters a terminal error like -EROFS. This causes the thread to loop forever. Fix this by breaking out of the loop if nilfs_segctor_construct() returns -EROFS. This matches the behaviour in nilfs_segctor_write_out(), which also handles -EROFS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93264", "url": "https://ubuntu.com/security/CVE-2026-93264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Fix PBL chunk length computation On register MR, when creating the PBL, if it's an indirect PBL we create a chunk list to hold the PBL pages pointers. Each chunk is 4KB in size and can hold 510 addresses (EFA_PTRS_PER_CHUNK) and has a 12-byte control buffer at the end of it holding the next chunk's pointer and its length. If the PBL number of pages is a multiple of EFA_PTRS_PER_CHUNK, the calculated last chunk length is wrongly computed as 0, even though that chunk is fully populated with 510 real page pointers. This wrong length is used both to DMA map the chunk and is propagated to the device, causing the device to see the chunk as empty and reject the memory registration. Fix the calculation so it will be performed only if the number of pages isn't a multiple of EFA_PTRS_PER_CHUNK, if it is, its already handled in the above loop correctly. Also prevent out-of-bounds reach in the chunks array in such scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89782", "url": "https://ubuntu.com/security/CVE-2026-89782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject restart table growth beyond U16_MAX entries During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): \trt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90431", "url": "https://ubuntu.com/security/CVE-2026-90431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: Prevent crash handling to race with rproc_del() There's no synchronization between rproc_crash_handler_work() and rproc_del(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues. To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds. In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a \"deleting\" flag is introduced. This is similar to the RPROC_DELETE state that was introduced to ensure that \"start\" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the \"state\" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90434", "url": "https://ubuntu.com/security/CVE-2026-90434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: release zisofs block pointer buffer head zisofs_fill_pages() reads the compressed block pointer table. The error paths release the current buffer_head, the loop also releases the old buffer_head when it advances. However, the success path leaves the last buffer_head referenced. Release it before returning success.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90435", "url": "https://ubuntu.com/security/CVE-2026-90435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix integer overflow of user QP buffer size set_user_buf_size() computes the QP buffer size by left-shifting the user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers. A sufficiently large rq.wqe_cnt causes signed integer overflow, which is undefined behavior, and yields a small or negative buf_size, causing ib_umem_get() to map a buffer smaller than the hardware will actually write into. Replace the shifts and addition with check_shl_overflow() and check_add_overflow(), rejecting invalid user inputs. Moreover, guard the identical shift computing qp->sq.offset in _create_user_qp() before set_user_buf_size() is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92476", "url": "https://ubuntu.com/security/CVE-2026-92476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Initialize completion before requesting IRQ kmb_ocs_aes_probe() requests the device IRQ before initializing irq_completion. Once the handler is registered it can run immediately, and ocs_aes_irq_handler() unconditionally calls complete(). An interrupt in this window would therefore use an uninitialized completion. Initialize the completion before requesting the IRQ, as the sibling OCS HCU and ECC drivers already do.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89785", "url": "https://ubuntu.com/security/CVE-2026-89785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89787", "url": "https://ubuntu.com/security/CVE-2026-89787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check dir entry fits before reading the hash trailer in ext4_search_dir() For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4_DIRENT_HASHES()), at an offset derived from de->name_len. On the sb_no_casefold_compat_fallback() path ext4_match() reads that trailer, but ext4_search_dir()'s by-hand pre-check only tests de->name + de->name_len <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4_DIRENT_HASHES(de) lands past the block end, so ext4_match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object: BUG: KASAN: use-after-free in ext4_match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4_match (fs/ext4/namei.c:1435) ext4_search_dir (fs/ext4/namei.c:1470) __ext4_find_entry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4_lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filename_lookup (fs/namei.c:2842) vfs_statx (fs/stat.c:353) __do_sys_newfstatat (fs/stat.c:538) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4_match(). This is the same bound ext4_check_dir_entry() already enforces via ext4_dir_rec_len(), so no well-formed entry is rejected. The other caller, ext4_find_dest_de(), runs ext4_check_dir_entry() first and is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92494", "url": "https://ubuntu.com/security/CVE-2026-92494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix buffer_head leak in ext4_init_orphan_info ext4_init_orphan_info() reads orphan file blocks with ext4_bread() and stores the returned buffer_head in oi->of_binfo[i].ob_bh. If ext4_bread() succeeds but the orphan block magic or checksum validation fails, the function jumps to out_free. However, the old out_free loop starts releasing buffers from i - 1, so the current buffer_head at index i is skipped. This leaks the buffer_head reference obtained by ext4_bread() on the bad magic and bad checksum error paths. Fix this by tracking the number of successfully read buffer_heads and releasing exactly those buffer_heads on the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92496", "url": "https://ubuntu.com/security/CVE-2026-92496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx() Currently, in ath11k_wmi_tlv_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Add an upfront length check before dereferencing skb->data as a wmi_cmd_hdr. The check is placed before the trace_ath11k_wmi_event() call to preserve the existing trace semantics (tracing the full raw WMI event including the header), unlike the analogous ath12k fix which could use skb_pull_data() directly. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92498", "url": "https://ubuntu.com/security/CVE-2026-92498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: avoid buffer overreads in WMI event handlers The following WMI event handlers currently read from the event buffer without first verifying that the message was large enough to hold the expected event: ath6kl_wmi_scan_complete_rx() ath6kl_wmi_addba_req_event_rx() ath6kl_wmi_delba_req_event_rx() Add length checks to prevent overread.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92501", "url": "https://ubuntu.com/security/CVE-2026-92501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drain in-flight DIO before buffered write fallback generic/746 started failing intermittently on ext3 (no-extent inodes). The test triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO. Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied, post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback) ----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared() iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async) dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0, 8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range() iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages() invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO) This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92504", "url": "https://ubuntu.com/security/CVE-2026-92504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int3400: clean up ODVP on probe failures evaluate_odvp() creates per-ODVP sysfs files before the thermal zone and later probe resources are registered. The current unwind path only calls cleanup_odvp() from the late sysfs failure path, so failures after evaluate_odvp() but before that label, including thermal_tripless_zone_device_register() failures, leave the ODVP files and storage behind. Move the ODVP cleanup to the common ART/TRT unwind path so every failure after evaluate_odvp() releases the ODVP state. Also clear the cached ODVP pointers in cleanup_odvp(), because evaluate_odvp() can already call it for partial setup failures while probe continues.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92508", "url": "https://ubuntu.com/security/CVE-2026-92508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_free_cq() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93268", "url": "https://ubuntu.com/security/CVE-2026-93268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: skip extra isize expansion during mount to prevent deadlock ext4_try_to_expand_extra_isize() is called from __ext4_mark_inode_dirty() while holding an active jbd2 handle. During mount (!SB_ACTIVE), the expand path may move xattrs to external blocks and release ea_inodes via iput(). When !SB_ACTIVE, iput() calls write_inode_now() which acquires s_writepages_rwsem, creating a circular lock dependency: s_writepages_rwsem --> jbd2_handle --> xattr_sem --> s_writepages_rwsem This can be triggered via: ext4_process_orphan() -> ext4_truncate() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() or: ext4_evict_inode() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() Skip expansion when !SB_ACTIVE. This is a minor loss of functionality (extra isize won't grow for these inodes during mount), which e2fsck can resolve later if needed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89786", "url": "https://ubuntu.com/security/CVE-2026-89786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bounds read in ext4_read_inline_dir() ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: \tdir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic \".\" and \"..\" land at their block-dir offsets. A dirent is formed at \"dir_buf + pos - extra_offset\", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92521", "url": "https://ubuntu.com/security/CVE-2026-92521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92522", "url": "https://ubuntu.com/security/CVE-2026-92522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: validate MADT IOAPIC entry bounds The IOAPIC hotplug lookup parses both MADT and _MAT records directly. The MADT walk previously used a subtable's declared length to advance the cursor after only locating a generic header. The _MAT path likewise passed a generic header to the IOAPIC helper. Validate that a current record has a complete generic header, that its declared length is contained in the available record range, and that a typed IOAPIC record contains the full fixed IOAPIC body before reading its fields. Use the same relation for both MADT and _MAT provider paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92524", "url": "https://ubuntu.com/security/CVE-2026-92524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc() When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93037", "url": "https://ubuntu.com/security/CVE-2026-93037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Propagate sdma_txinit_ahg() errors set_txreq_header_ahg() ignores the return value of sdma_txinit_ahg(). If sdma_txinit_ahg() fails, it returns before initializing tx->txreq. However, set_txreq_header_ahg() ignores the error and returns the AHG change count, causing the caller to continue processing the request as though initialization had succeeded. Propagate sdma_txinit_ahg() failures to the caller and abort request processing when initialization fails. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93039", "url": "https://ubuntu.com/security/CVE-2026-93039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: Keep link pointers valid on realloc failure meson_card_reallocate_links() grows the DAI link and private data arrays with two consecutive krealloc() calls and updates the owner pointers only after both calls have succeeded. A successful krealloc() may move the data: it frees the old block and returns a new one. When that happens for the link array and the second krealloc() then fails, card->dai_link still points to the block that krealloc() already freed, and the error path frees the new block too. The probe error path then calls meson_card_clean_references(), which dereferences card->dai_link and kfree()s it again, resulting in a use-after-free and a double free. Commit card->dai_link and card->num_links right after the first krealloc() succeeds, so the pointer always refers to a valid allocation that meson_card_clean_references() can walk and free. krealloc() with __GFP_ZERO zero-initializes the added entries, so walking them on the error path is safe. With both failure paths reduced to a plain return, drop the goto labels and the error message.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93040", "url": "https://ubuntu.com/security/CVE-2026-93040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize channel state checks pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent. For example, pause() can observe EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93041", "url": "https://ubuntu.com/security/CVE-2026-93041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize abort state updates dw_edma_abort_interrupt() drops vc.lock before changing request and status. issue_pending() can acquire the lock in that small window, observe the old busy state, and skip starting queued descriptors. Then the abort handler overwrites the channel status as idle, leaving the new descriptors stranded for good. Keep descriptor completion and the state transition in the same critical section.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93046", "url": "https://ubuntu.com/security/CVE-2026-93046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: software node: Fix software_node_get_reference_args() with index -1 The bounds check for the index passed to software_node_get_reference_args() was failing when passed UINT_MAX, this in turn would lead to an out of bound access in the property array. Fix the bound check to also cover the UINT_MAX case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93048", "url": "https://ubuntu.com/security/CVE-2026-93048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior. Commit 5daa7b21496a (\"mtd: prepare partition add and del functions for ioctl requests\") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e (\"mtd: add a flags for partitions which should just leave smth. after them\") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value. With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers: WARN_ON((!mtd->erasesize || !master->_erase) && \t\t!(mtd->flags & MTD_NO_ERASE)) in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the \"out of reach\" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error. Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93049", "url": "https://ubuntu.com/security/CVE-2026-93049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdswap: Avoid freeing registered blktrans device twice In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice. add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev. The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89777", "url": "https://ubuntu.com/security/CVE-2026-89777", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio_msi_cap_len() lazily allocates the per-device MSI permission table: \tvdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); \tif (!vdev->msi_perm) \t\treturn -ENOMEM; \tret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); \tif (ret) { \t\tkfree(vdev->msi_perm); \t\treturn ret;\t\t/* vdev->msi_perm left dangling */ \t} When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at \"if (vdev->msi_perm) return len;\" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93051", "url": "https://ubuntu.com/security/CVE-2026-93051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ad525x_dpot: use driver core groups for sysfs files ad_dpot_probe() creates per-RDAC sysfs files manually and then optionally creates the command sysfs group. This leaves probe responsible for rolling back partial sysfs state and makes remove responsible for matching every file that probe created. Move the device attributes into driver core dev_groups for the I2C and SPI drivers and use an is_visible() callback to expose only the attributes supported by the probed device. With this shape, the driver core creates the sysfs files only after probe succeeds and removes them before the remove callback frees the driver data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93052", "url": "https://ubuntu.com/security/CVE-2026-93052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: bcm-vk: Use acquire/release for msgq_inited bcm_vk_sync_msgq() fills the message queue information and then sets msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the message queues and their cached queue information. atomic_set()/atomic_read() do not order those accesses. A reader can see msgq_inited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate. Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the gate and does not publish queue state to readers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93053", "url": "https://ubuntu.com/security/CVE-2026-93053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: speakup: keyhelp: guard letter_offsets possible out-of-range indexing help_init() builds letter_offsets[] by using the first byte of each function name as an index via `(start & 31) - 1`. If function_names are overridden from sysfs (root) with a name starting outside [a–z], the index underflows or exceeds the array, leading to OOB write. Function names can be overridden with the following commands as root: modprobe speakup_soft echo \"0 _bad\" > /sys/accessibility/speakup/i18n/function_names # then press Insert+2 on /dev/tty This fix checks the first letter in help_init(), and if it is not in the [a–z] range the function returns an error to the caller. Eventually this error is propagated to drivers/accessibility/speakup/main.c:2217, which causes a bleep sound.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93054", "url": "https://ubuntu.com/security/CVE-2026-93054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same \"device gone\" state as normal uio_unregister_device().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93055", "url": "https://ubuntu.com/security/CVE-2026-93055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: UDF symlink pathComponent header OOB read udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93056", "url": "https://ubuntu.com/security/CVE-2026-93056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: remove broken string configfs attributes The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for the fn_play, fn_cap, and fn_cntl string options. The store function contains an inverted null check on the kstrndup() return value. This means every write attempt returns -ENOMEM on success and dereferences a NULL pointer on allocation failure. The attributes have been broken and unused for many years. Remove the UAC1_STR_ATTRIBUTE macro and the three attributes it generated. The internal defaults (FILE_PCM_PLAYBACK, FILE_PCM_CAPTURE, FILE_CONTROL) set in f_audio_alloc_inst() are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93061", "url": "https://ubuntu.com/security/CVE-2026-93061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Avoid stack over-read in debug output helpers host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93067", "url": "https://ubuntu.com/security/CVE-2026-93067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clamps an AUX read to the payload limit: \tsize_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: \tif (size) \t\tsize = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 (\"drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer\").", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93271", "url": "https://ubuntu.com/security/CVE-2026-93271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate ath11k can receive HT/VHT/HE frames whose reported MCS is above the maximum that can be expressed in the corresponding mac80211 rate space (e.g. an HE frame reported with MCS 12, while HE tops out at MCS 11). The frame itself is valid and decodes correctly, but for such a frame ath11k_dp_rx_h_rate() leaves rx_status->rate_idx set to the out-of-range value and never assigns rx_status->encoding, so it stays RX_ENC_LEGACY from the ath11k_dp_rx_h_ppdu() initialization. Once that frame reaches mac80211 it trips the rate sanity check and the frame is dropped with a splat: ath11k_pci 0000:03:00.0: Received with invalid mcs in HE mode 12 WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:5433 ieee80211_rx_list+0xb0a/0xe90 [mac80211] Dropping the frame would discard otherwise valid data, so instead cap the reported MCS to the maximum the rate space can express and deliver the frame. Set rx_status->encoding before the range check and assign rate_idx from the capped value, so a frame with an out-of-range MCS no longer leaves partial or bogus rate metadata behind. Also downgrade the logging level since they are not treated as invalid frames now. The only loss is that such a frame is reported as the capped MCS in the rx rate statistics. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93095", "url": "https://ubuntu.com/security/CVE-2026-93095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: validate thread record before delete key rebuild hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93098", "url": "https://ubuntu.com/security/CVE-2026-93098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: glink: fix deadlock in endpoint destroy during driver detach During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89778", "url": "https://ubuntu.com/security/CVE-2026-89778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: fix out-of-bounds page array access on empty zisofs block zisofs_uncompress_block()'s empty-block fast path returns pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the decompression path which returns bytes produced relative to poffset. zisofs_fill_pages() uses that return to advance its page cursor, so when the zisofs block size is below PAGE_SIZE and a sub-page block leaves poffset partway into a page, a following empty block over-counts and advances pages[] one element past its end, after which \"if (poffset && *pages)\" reads pages[1] out of bounds. rock.c only rejects a block-size shift > 17, so a crafted \"ZF\" Rock Ridge record can set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a compressed file on such a mounted ISO9660 image. Return the byte count relative to poffset and zero only [poffset, PAGE_SIZE) of the first page, matching the decompression path. The page-aligned case (poffset == 0) is unaffected. BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290) Read of size 8 at addr ffff88800f5eac48 by task exploit/142 zisofs_read_folio (fs/isofs/compress.c:290) read_pages (mm/readahead.c:184) ... filemap_read (mm/filemap.c:2814) vfs_read (fs/read_write.c:574) __x64_sys_pread64 (fs/read_write.c:769) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address is located 0 bytes to the right of the allocated 8-byte region in the kmalloc-8 cache", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93102", "url": "https://ubuntu.com/security/CVE-2026-93102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Free RX data on late probe failure hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning. If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears down the device data without calling hfi1_free_rx(). This leaks netdev_rx and its dummy netdev. Free the RX support after IB unregistration and before postinit_cleanup(), as done on normal device removal.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93103", "url": "https://ubuntu.com/security/CVE-2026-93103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89783", "url": "https://ubuntu.com/security/CVE-2026-89783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use \"sp->len >= XFRM_MAX_DEPTH\", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]'", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93108", "url": "https://ubuntu.com/security/CVE-2026-93108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ipoib: Drain RCU callbacks during module teardown IPoIB reclamation completions can be signaled from inside an RCU callback. Teardown can wake before the callback returns and unload ib_ipoib while its code is still executing. Client registration failure can also remove already-added devices and queue callbacks. Wait after client and workqueue teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93109", "url": "https://ubuntu.com/security/CVE-2026-93109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Drain RCU callbacks during module teardown devx_free_subscription() can remain queued after the last DevX event file drops its module reference or an auxiliary driver detaches its devices. mlx5_ib can then unload before the callback runs. Registration error unwind has the same risk because driver registration can attach existing devices before failing. Wait after all drivers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93110", "url": "https://ubuntu.com/security/CVE-2026-93110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Wait for RCU callbacks before unloading ib_core put_gid_ndev() is queued with call_rcu() and implemented in ib_core. Stopping the workqueues does not drain callbacks already queued, so RCU could invoke it after the module code has been unloaded. synchronize_rcu() does not wait for callbacks. Wait for them after all producers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93114", "url": "https://ubuntu.com/security/CVE-2026-93114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/surface: acpi-notify: Check ACPI companion before use Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 (\"ACPI: driver: Check ACPI_COMPANION() against NULL during probe\") does for the core ACPI platform drivers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93115", "url": "https://ubuntu.com/security/CVE-2026-93115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93120", "url": "https://ubuntu.com/security/CVE-2026-93120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93130", "url": "https://ubuntu.com/security/CVE-2026-93130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix resource leak on module load failure We need to properly clean up the SMBIOS request and the privacy driver when the module load fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93131", "url": "https://ubuntu.com/security/CVE-2026-93131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-privacy: Fix race condition Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93138", "url": "https://ubuntu.com/security/CVE-2026-93138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire(). Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93140", "url": "https://ubuntu.com/security/CVE-2026-93140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 (\"udf: Mark LVID buffer as uptodate before marking it dirty\"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline] vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline] __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93141", "url": "https://ubuntu.com/security/CVE-2026-93141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: r8a66597: avoid double free of ep0_req in probe error path If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL. Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once. Issue found using a prototype static analysis tool and confirmed by code review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93145", "url": "https://ubuntu.com/security/CVE-2026-93145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister() gdsc_unregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pm_genpd_remove() on the individual generic_pm_domain structures registered by gdsc_init(): \tvoid gdsc_unregister(struct gdsc_desc *desc) \t{ \t\tstruct device *dev = desc->dev; \t\tsize_t num = desc->num; \t\tgdsc_pm_subdomain_remove(desc, num); \t\tof_genpd_del_provider(dev->of_node); \t} That leaves dangling entries on the global gpd_list. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdsc_init() will end up trying to re-register a name that is still in the list and pm_genpd_init() returns -EEXIST. While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh of_genpd_get_from_provider() call racing with the teardown could attach to a domain that is mid-removal. Iterate the scs[] array and pm_genpd_remove() each registered domain after the subdomain links are torn down. The regulators stay devm- managed (devm_regulator_get_optional() in gdsc_register()), so the release happens automatically when the underlying device is unbound; just the genpd accounting needs to be undone explicitly.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93278", "url": "https://ubuntu.com/security/CVE-2026-93278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown cvm_oct_rx_shutdown calls free_irq and netif_napi_del without disabling the napi instance first. As the free_irq only waits for completion of hard interrupt handlers, the napi poll function could still be active. If cvm_oct_remove proceeds to free the plat structure (which holds the NAPI instances), the active poll function will access freed memory, resulting in a use-after-free crash.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93279", "url": "https://ubuntu.com/security/CVE-2026-93279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown The TX cleanup tasklet can be scheduled by the watchdog IRQ handler to execute cvm_oct_tx_do_cleanup. There can be a pending tasklet in the queue which might run after the cvm_oct_remove() frees net_device structures, causing a use-after-free in cvm_oct_tx_do_cleanup() as it iterates cvm_oct_device[] which is an array of netdevice pointers. Add tasklet_kill() after free_irq() to ensure the tasklet is no longer scheduled or running before teardown proceeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93280", "url": "https://ubuntu.com/security/CVE-2026-93280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: greybus: audio: bound the topology section sizes against the fetched size gb_audio_gb_get_topology() fetches a topology blob of a module-supplied size, and gbaudio_tplg_parse_data() then walks it by adding the module-supplied size_dais, size_controls and size_widgets fields to form the control, widget and route section offsets. Those le32 sizes are never checked against the fetched blob, so a module reporting a small topology size but large section sizes makes the offsets point past the allocation, and parsing reads out of bounds. Reject a topology whose section sizes do not fit within the fetched size before it is parsed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93151", "url": "https://ubuntu.com/security/CVE-2026-93151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: fix response resource leak on queue teardown When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm \"kworker/2:1H\", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 unreferenced object 0xffff88814bd05e80 (size 64): comm \"kworker/3:1H\", pid 148, jiffies 4295195428 backtrace (crc e35510cb): __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources() that frees up the RDMA read/write context and the request SGLs of such responses.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93158", "url": "https://ubuntu.com/security/CVE-2026-93158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul - stop probe if context pool creation fails sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool. Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93159", "url": "https://ubuntu.com/security/CVE-2026-93159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes. If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated work_data is not usable for producing RNG output and must not remain associated with the hwrng state. Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data. Fix this by freeing the pending work_data. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93160", "url": "https://ubuntu.com/security/CVE-2026-93160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-ecc - reject hardware ECDH without a public key The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm. atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93161", "url": "https://ubuntu.com/security/CVE-2026-93161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - clear AES key schedule from stack qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame. Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93165", "url": "https://ubuntu.com/security/CVE-2026-93165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Fix memory overread in ring handler `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93167", "url": "https://ubuntu.com/security/CVE-2026-93167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: csky: Fix a4/a5 restoration in syscall trace path The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93170", "url": "https://ubuntu.com/security/CVE-2026-93170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93177", "url": "https://ubuntu.com/security/CVE-2026-93177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup vddInd, vddciInd and mvddInd from VBIOS-parsed tables index into vddc, vddci and vddmem lookup tables without bounds checks across nine sites. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93178", "url": "https://ubuntu.com/security/CVE-2026-93178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93274", "url": "https://ubuntu.com/security/CVE-2026-93274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: bcm2835: Don't remove an unregistered GPIO chip If the devm_pinctrl_register() function fails, bcm2835_pinctrl_probe() calls gpiochip_remove() before gpiochip_add_data() has registered the GPIO chip. This means that upon failure the gpio_chip.gpiodev is NULL resulting in a null pointer dereference inside the gpiochip_remove() function. Remove the unnecessary function call to gpiochip_remove(). No GPIO cleanup is required because the GPIO chip has not yet been registered. Without this change there is potential for a kernel panic upon registration failure", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93183", "url": "https://ubuntu.com/security/CVE-2026-93183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/lima: call drm_mm_init() with a valid allocation range lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2: [ 1.736297] ------------[ cut here ]------------ [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931! [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.750697] Modules linked in: [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree) [ 1.769446] Workqueue: events_unbound deferred_probe_work_func [ 1.775261] PC is at drm_mm_init+0x9c/0xa4 [ 1.779339] LR is at lima_vm_create+0x144/0x17c [ ... ] Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93185", "url": "https://ubuntu.com/security/CVE-2026-93185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rt700-sdw: always drain jack work on remove rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93188", "url": "https://ubuntu.com/security/CVE-2026-93188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: bound device-supplied profile index kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93189", "url": "https://ubuntu.com/security/CVE-2026-93189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path (\"hwmon: prevent packets from going to driver for probe\", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93191", "url": "https://ubuntu.com/security/CVE-2026-93191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix incorrect task context in smack_msg_queue_msgrcv The smack_msg_queue_msgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task. In the msgsnd() syscall path, if a receiver is already waiting, the pipelined_send() optimization is used to push the message directly to the receiver task: ipc/msg.c`pipelined_send(): ` smp_store_release(&msr->r_msg, msg) In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->r_tsk, passed as the 'target' parameter): ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, target := msr->r_tsk,,) However, smack_msg_queue_msgrcv() ignores the 'target' and checks 'current': smack_msg_queue_msgrcv(…) ` smk_curacc_msq(isp, MAY_READWRITE); // current task 'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy. Test: 1) create a sysv message queue with label “foo” 2) echo \"bar foo r\" >/smack/load2 3) msgrcv(,,,0,MSG_NOERROR) in \"bar\"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a \"foo\"-labeled task: \"bar\"-labeled task gets the message. This patch fixes the issue by checking permission on the 'target' task instead of 'current'. (2008-02-04, Casey Schaufler)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2025-40123", "url": "https://ubuntu.com/security/CVE-2025-40123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce expected_attach_type for tailcall compatibility Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-89947", "url": "https://ubuntu.com/security/CVE-2026-89947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: meson: align gxbb_32k_clk_sel number of parents with actual count The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c (\"clk: amlogic: gxbb: drop non existing 32k clock parent\") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80671", "url": "https://ubuntu.com/security/CVE-2026-80671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf sched: Fix register_pid() overflow, strcpy, and BUG_ON register_pid() has several issues when processing untrusted perf.data: 1. Integer overflow: (pid + 1) * sizeof(struct task_desc *) can wrap to a small value on 32-bit systems when pid is large (e.g. 0x40000000), causing realloc to return a tiny buffer followed by out-of-bounds writes in the initialization loop. 2. Heap buffer overflow: strcpy(task->comm, comm) copies the untrusted comm string into a fixed 20-byte COMM_LEN buffer with no length check. 3. BUG_ON on allocation failure: perf.data is untrusted input, so allocation failures should be handled gracefully rather than killing the process. 4. Realloc of sched->tasks assigned directly back, leaking the old pointer on failure; nr_tasks incremented before the realloc, leaving corrupted state on failure. Cap pid at PID_MAX_LIMIT (4194304, matching the kernel's maximum on 64-bit), replace strcpy with strlcpy, guard against NULL comm, replace BUG_ON with NULL returns using safe realloc patterns, and add NULL checks in callers that dereference the result.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-93203", "url": "https://ubuntu.com/security/CVE-2026-93203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: avoid CRC corruption due to parallel claim add batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either * add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone But when the \"new\" claim code was running in parallel to the \"change backbone\" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the \"new\" claim code path: * CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point. * CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc. * CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc The CRC is then wrong for both: * claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs. To avoid this, split the functionality in clear separate parts: * new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back) * update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93204", "url": "https://ubuntu.com/security/CVE-2026-93204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: atomically update mac addresses When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2025-22039", "url": "https://ubuntu.com/security/CVE-2025-22039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix overflow in dacloffset bounds check The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl(). This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer. This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.", "cve_priority": "high", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-21651", "url": "https://ubuntu.com/security/CVE-2025-21651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: don't auto enable misc vector Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below: [ 16.324639] Call trace: [ 16.324641] __queue_delayed_work+0xb8/0xe0 [ 16.324643] mod_delayed_work_on+0x78/0xd0 [ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge] [ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge] [ 16.324666] __handle_irq_event_percpu+0x64/0x1e0 [ 16.324667] handle_irq_event+0x80/0x170 [ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc [ 16.324671] __handle_domain_irq+0x84/0xfc [ 16.324673] gic_handle_irq+0x88/0x2c0 [ 16.324674] el1_irq+0xb8/0x140 [ 16.324677] arch_cpu_idle+0x18/0x40 [ 16.324679] default_idle_call+0x5c/0x1bc [ 16.324682] cpuidle_idle_call+0x18c/0x1c4 [ 16.324684] do_idle+0x174/0x17c [ 16.324685] cpu_startup_entry+0x30/0x6c [ 16.324687] secondary_start_kernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]--- So don't auto enable misc vector when request irq..", "cve_priority": "low", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43088", "url": "https://ubuntu.com/security/CVE-2026-43088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: zero aligned sockaddr tail in PF_KEY exports PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE` Fix those paths by clearing only the aligned sockaddr tail after `pfkey_sockaddr_fill()`.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31420", "url": "https://ubuntu.com/security/CVE-2026-31420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: mrp: reject zero test interval to avoid OOM panic br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock. The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames. Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2025-22103", "url": "https://ubuntu.com/security/CVE-2025-22103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix NULL pointer dereference in l3mdev_l3_rcv When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-21649", "url": "https://ubuntu.com/security/CVE-2025-21649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is sent on HIP08 devices Currently, HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL. But the tx process would still try to set hardware time stamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash. [ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge] [ 128.292938] sp : ffff800059b93140 [ 128.297200] x29: ffff800059b93140 x28: 0000000000003280 [ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080 [ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001 [ 128.315969] x23: 0000000000000000 x22: 0000000000000194 [ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000 [ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000 [ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24 [ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000 [ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368 [ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02 [ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0 [ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000 [ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff [ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294 [ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080 [ 128.390626] Call trace: [ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3] [ 128.405468] xmit_one.constprop.0+0xc4/0x200 [ 128.410600] dev_hard_start_xmit+0x54/0xf0 [ 128.415556] sch_direct_xmit+0xe8/0x634 [ 128.420246] __dev_queue_xmit+0x224/0xc70 [ 128.425101] dev_queue_xmit+0x1c/0x40 [ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch] [ 128.435409] do_output+0x60/0x17c [openvswitch] [ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch] [ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch] [ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch] [ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch] [ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch] [ 128.471460] xmit_one.constprop.0+0xc4/0x200 [ 128.476561] dev_hard_start_xmit+0x54/0xf0 [ 128.481489] __dev_queue_xmit+0x968/0xc70 [ 128.486330] dev_queue_xmit+0x1c/0x40 [ 128.490856] ip_finish_output2+0x250/0x570 [ 128.495810] __ip_finish_output+0x170/0x1e0 [ 128.500832] ip_finish_output+0x3c/0xf0 [ 128.505504] ip_output+0xbc/0x160 [ 128.509654] ip_send_skb+0x58/0xd4 [ 128.513892] udp_send_skb+0x12c/0x354 [ 128.518387] udp_sendmsg+0x7a8/0x9c0 [ 128.522793] inet_sendmsg+0x4c/0x8c [ 128.527116] __sock_sendmsg+0x48/0x80 [ 128.531609] __sys_sendto+0x124/0x164 [ 128.536099] __arm64_sys_sendto+0x30/0x5c [ 128.540935] invoke_syscall+0x50/0x130 [ 128.545508] el0_svc_common.constprop.0+0x10c/0x124 [ 128.551205] do_el0_svc+0x34/0xdc [ 128.555347] el0_svc+0x20/0x30 [ 128.559227] el0_sync_handler+0xb8/0xc0 [ 128.563883] el0_sync+0x160/0x180", "cve_priority": "medium", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2023-52676", "url": "https://ubuntu.com/security/CVE-2023-52676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Guard stack limits against 32bit overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904", "cve_priority": "high", "cve_public_date": "2024-05-17 15:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "low", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-90015", "url": "https://ubuntu.com/security/CVE-2026-90015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89816", "url": "https://ubuntu.com/security/CVE-2026-89816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used Commit 1c6ceeee6ebb (\"drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits\") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93234", "url": "https://ubuntu.com/security/CVE-2026-93234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: validate TV mode names before creating enum property The GUD protocol returns TV mode names as fixed-size GUD_CONNECTOR_TV_MODE_NAME_LEN entries and requires each name to be NUL-terminated. gud_connector_add_tv_mode() currently passes each fixed-size entry directly to drm_mode_create_tv_properties_legacy(), which eventually reaches drm_property_add_enum() and strlen(). If a device returns an entry without a terminating NUL byte, strlen() reads past the end of the slot and can run beyond the allocated buffer, triggering an out-of-bounds read. Validate that each returned TV mode name contains a NUL terminator within its fixed-size slot before passing it to the DRM property code. If a malformed entry is found, reject the device response with -EIO. This fixes the out-of-bounds read without changing the handling of valid devices, and avoids silently truncating malformed protocol data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89817", "url": "https://ubuntu.com/security/CVE-2026-89817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: NUL-terminate TV mode names read from the device gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89821", "url": "https://ubuntu.com/security/CVE-2026-89821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid divide-by-zero in __is_lut_linear() __is_lut_linear() computes the expected value of each entry with \texpected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89823", "url": "https://ubuntu.com/security/CVE-2026-89823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: fix race between partial drm_dev_register() failure and ioctl If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89843", "url": "https://ubuntu.com/security/CVE-2026-89843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89845", "url": "https://ubuntu.com/security/CVE-2026-89845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89846", "url": "https://ubuntu.com/security/CVE-2026-89846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: \tif (IS_FWI2_CAPABLE(ha)) { \t\tsense_data += rsp_info_len; \t\tpar_sense_len -= rsp_info_len; \t} rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): \tif (sense_len > par_sense_len) \t\tsense_len = par_sense_len; \tmemcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89847", "url": "https://ubuntu.com/security/CVE-2026-89847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid double completion in async IOCB timeout qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates \"if (sp->comp) complete(sp->comp)\"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93242", "url": "https://ubuntu.com/security/CVE-2026-93242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb() qla24xx_process_response_queue() advances ring_ptr past the head IOCB before dispatching, so by the time __qla_consume_iocb() runs, ring_ptr already points at the first continuation IOCB. The function however looped purex->entry_count times starting at ring_ptr. As entry_count includes the head, this consumed one entry too many: it stamped RESPONSE_PROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked. Mark the head processed and account for it, then consume only the entry_count - 1 continuation IOCBs, matching __qla_copy_purex_to_buffer().", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89849", "url": "https://ubuntu.com/security/CVE-2026-89849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path qla2x00_status_entry() filters out non-TYPE_SRB entries and the SRB_NVME_CMD, SRB_BIDI_CMD and SRB_TM_CMD types, then falls through to a SCSI fast path that assumes the command is an SRB_SCSI_CMD. The first thing on that path, qla_chk_edif_rx_sa_delete_pending(), and the subsequent handling both evaluate GET_CMD_SP(sp), i.e. sp->u.scmd.cmd. The srb u union overlays the SCSI command pointer with other command layouts (bsg_job, iocb_cmd). If firmware delivers an unexpected STATUS_TYPE IOCB for a non-SCSI handle, sp->u.scmd.cmd can read as a non-NULL garbage pointer, bypassing the NULL checks in qla_chk_edif_rx_sa_delete_pending() and at the cp == NULL test, and leading to a wild pointer dereference. Reject any SRB whose type is not SRB_SCSI_CMD before entering the fast path. The outstanding_cmds slot is left untouched so a genuinely non-SCSI command still completes through its proper handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89850", "url": "https://ubuntu.com/security/CVE-2026-89850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Don't query firmware state while chip is down qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89851", "url": "https://ubuntu.com/security/CVE-2026-89851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace enable parsing in debugfs qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as \"disable\" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89852", "url": "https://ubuntu.com/security/CVE-2026-89852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89853", "url": "https://ubuntu.com/security/CVE-2026-89853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89854", "url": "https://ubuntu.com/security/CVE-2026-89854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix cs84xx use-after-free on host teardown qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89855", "url": "https://ubuntu.com/security/CVE-2026-89855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize flash version read in reset handler The \"update cache versions without reset\" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89856", "url": "https://ubuntu.com/security/CVE-2026-89856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as \"ha->max_req_queues = ha->msix_count - 1\" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent \"ha->max_req_queues--\" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following \"ha->req_q_map[0] = req\" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89858", "url": "https://ubuntu.com/security/CVE-2026-89858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89861", "url": "https://ubuntu.com/security/CVE-2026-89861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89863", "url": "https://ubuntu.com/security/CVE-2026-89863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check qla_chk_edif_rx_sa_delete_pending() obtains the SCSI command via GET_CMD_SP(sp) and immediately dereferences cmd->sc_data_direction. That command pointer can be NULL: the firmware may post a status completion for a command that has already been returned or aborted. The caller qla2x00_status_entry() acknowledges this on the very same status path, re-fetching GET_CMD_SP(sp) and bailing out with the \"Command already returned\" message when it is NULL -- but that check runs only after qla_chk_edif_rx_sa_delete_pending() has already dereferenced the pointer, so a NULL cmd crashes the kernel in interrupt context. Return early when cmd is NULL, before touching cmd->sc_data_direction.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89864", "url": "https://ubuntu.com/security/CVE-2026-89864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: \tstruct qla_i2c_access { \t\tuint16_t device, offset, option, length; \t\tuint8_t buffer[0x40]; \t} __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89865", "url": "https://ubuntu.com/security/CVE-2026-89865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: \tif (len == 1) \t\topt |= BIT_0; \tif (opt & BIT_0) \t\tlen = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89871", "url": "https://ubuntu.com/security/CVE-2026-89871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89872", "url": "https://ubuntu.com/security/CVE-2026-89872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. [Sakari Ailus: Fix subject prefix and coding style a little.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89876", "url": "https://ubuntu.com/security/CVE-2026-89876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tda18250: fix possible integer overflow Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89878", "url": "https://ubuntu.com/security/CVE-2026-89878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: check firmware size before reading trailing marker s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89879", "url": "https://ubuntu.com/security/CVE-2026-89879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: bound JPEG frame size before copying into the buffer s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: \tpayload = le32_to_cpu(pdword[3]); \tif (payload > vc->req_image_size)\t/* payload is checked ... */ \t\treturn -EINVAL; \tvc->pkt_size = payload; \tvc->jpg_size = le32_to_cpu(pdword[4]);\t/* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89880", "url": "https://ubuntu.com/security/CVE-2026-89880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89881", "url": "https://ubuntu.com/security/CVE-2026-89881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89883", "url": "https://ubuntu.com/security/CVE-2026-89883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: sunxi-cir: Unregister rc device on probe failure After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93236", "url": "https://ubuntu.com/security/CVE-2026-93236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common When VIDIOC_TRY_FMT is called with an unsupported pixel format on the OUTPUT queue, vdec_try_fmt_common() falls back to V4L2_PIX_FMT_MPEG2. However, if a distro has locally patched MPEG2 support out (as it has been broken for some time) the platform format table does not contain MPEG2 so find_format() returns NULL and the subsequent dereference of fmt_out->max_width triggers a NULL pointer dereference. Fix this by falling back to the first format in the platform's format array instead of hardcoding V4L2_PIX_FMT_MPEG2. This is always valid since every platform defines at least one format.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89887", "url": "https://ubuntu.com/security/CVE-2026-89887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov7740: fix use-after-destroy in remove The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89888", "url": "https://ubuntu.com/security/CVE-2026-89888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov02a10: fix endpoint parsing use-after-free The ov02a10_check_hwcfg() function calls fwnode_handle_put(ep) immediately after allocating and parsing the endpoint. However, it subsequently calls fwnode_property_read_u32() using the same 'ep' handle, leading to a potential use-after-free. Additionally, reading the optional 'ovti,mipi-clock-voltage' property used to overwrite the 'ret' variable. If the property was missing, 'ret' would become negative, and this failure code would be incorrectly returned at the end of the function, causing probe to fail entirely. Fix the use-after-free by moving fwnode_property_read_u32() before the endpoint is parsed and freed. Avoid the error leak by not assigning the result of fwnode_property_read_u32() to 'ret'.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89890", "url": "https://ubuntu.com/security/CVE-2026-89890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: go7007: defer the ALSA v4l2 put until card release go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89891", "url": "https://ubuntu.com/security/CVE-2026-89891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free of dev_next->devlist on disconnect When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 (\"USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89892", "url": "https://ubuntu.com/security/CVE-2026-89892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: defer audio-only extension registration The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89893", "url": "https://ubuntu.com/security/CVE-2026-89893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: cancel NetUP CI work before teardown netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89894", "url": "https://ubuntu.com/security/CVE-2026-89894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: reject geometry changes while the VBI queue is busy vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: \toffset = lines_completed * (dev->width << 1) + ...; \tif (dma_q->current_field == 2) \t\toffset += dev->width * 2 * dma_q->lines_per_field; \tmemcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89895", "url": "https://ubuntu.com/security/CVE-2026-89895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cobalt: Avoid freeing ALSA private data twice snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89896", "url": "https://ubuntu.com/security/CVE-2026-89896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: fix memory leak in cedrus_init_ctrls() In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89897", "url": "https://ubuntu.com/security/CVE-2026-89897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: Serialize exclusive follower delivery cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89901", "url": "https://ubuntu.com/security/CVE-2026-89901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89923", "url": "https://ubuntu.com/security/CVE-2026-89923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Free guest debug data on vcpu destroy kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89924", "url": "https://ubuntu.com/security/CVE-2026-89924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix old_data leak in guest debug error path __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89925", "url": "https://ubuntu.com/security/CVE-2026-89925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory leak in guest debug handling bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89926", "url": "https://ubuntu.com/security/CVE-2026-89926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix length check __import_wp_info() struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: \twp_info->len = bp_data->len; \t[...] \tif (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) \t\treturn -EINVAL; \twp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89927", "url": "https://ubuntu.com/security/CVE-2026-89927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89930", "url": "https://ubuntu.com/security/CVE-2026-89930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter KVM services local TLB flushes on \"full\" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89932", "url": "https://ubuntu.com/security/CVE-2026-89932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always flush vpid02 on first use Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89936", "url": "https://ubuntu.com/security/CVE-2026-89936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: dac: m62332: Fix regulator reference count imbalance m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89937", "url": "https://ubuntu.com/security/CVE-2026-89937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sgp30: Handle IAQ thread creation failure kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89939", "url": "https://ubuntu.com/security/CVE-2026-89939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89945", "url": "https://ubuntu.com/security/CVE-2026-89945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l34: drain threaded IRQ before runtime suspend cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89946", "url": "https://ubuntu.com/security/CVE-2026-89946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89948", "url": "https://ubuntu.com/security/CVE-2026-89948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89949", "url": "https://ubuntu.com/security/CVE-2026-89949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89951", "url": "https://ubuntu.com/security/CVE-2026-89951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix stale receive device on merged fragments Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89952", "url": "https://ubuntu.com/security/CVE-2026-89952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89953", "url": "https://ubuntu.com/security/CVE-2026-89953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89954", "url": "https://ubuntu.com/security/CVE-2026-89954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: afs: validate v2 image info bounds The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89964", "url": "https://ubuntu.com/security/CVE-2026-89964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: eisa: Fix infinite loop when parsing invalid IRQ value When an invalid value is passed via the \"eisa_irq_edge=\" kernel command line parameter (e.g. \"eisa_irq_edge=16,5\"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89965", "url": "https://ubuntu.com/security/CVE-2026-89965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: reject an arena whose nfree is below the lane count The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89968", "url": "https://ubuntu.com/security/CVE-2026-89968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: reject unsolicited H2CData PDUs nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the \"list_add double add\" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89969", "url": "https://ubuntu.com/security/CVE-2026-89969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as \tqueue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89973", "url": "https://ubuntu.com/security/CVE-2026-89973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: check the data direction of a C2HData PDU nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89979", "url": "https://ubuntu.com/security/CVE-2026-89979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race between non-atomic ops and trigger-start We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89980", "url": "https://ubuntu.com/security/CVE-2026-89980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: harmony: initialize locks before requesting IRQ snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89982", "url": "https://ubuntu.com/security/CVE-2026-89982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89983", "url": "https://ubuntu.com/security/CVE-2026-89983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89984", "url": "https://ubuntu.com/security/CVE-2026-89984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \\ \t./perf bench syscall basic --loop 1000 | \\ \t./perf script -i - --fields brstack|tr ' ' '\\n'| \\ \tgrep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89989", "url": "https://ubuntu.com/security/CVE-2026-89989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89993", "url": "https://ubuntu.com/security/CVE-2026-89993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Initialize IRQ data before requesting IRQs dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89997", "url": "https://ubuntu.com/security/CVE-2026-89997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix resume-vs-remove race If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89999", "url": "https://ubuntu.com/security/CVE-2026-89999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: validate report length in wacom_intuos_pro2_bt_irq wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: \twacom_intuos_pro2_bt_pen(wacom); \tif (type == INTUOSP2_BT || type == INTUOSP2S_BT) { \t\twacom_intuos_pro2_bt_touch(wacom); \t\twacom_intuos_pro2_bt_pad(wacom); \t\twacom_intuos_pro2_bt_battery(wacom); \t} else { \t\twacom_intuos_gen3_bt_pad(wacom); \t\twacom_intuos_gen3_bt_battery(wacom); \t} Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] \t(the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT (\"gen3\"): wacom_intuos_gen3_bt_battery() reads data[45], \tso the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 (\"HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq\") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90000", "url": "https://ubuntu.com/security/CVE-2026-90000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: rmi: fix OOB access with undersized RMI reports The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: \tdata->input_report_size = hid_report_len(input_report); \tdata->output_report_size = hid_report_len(output_report); \talloc_size = data->output_report_size + data->input_report_size; \tdata->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); \tdata->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly \"this probe validated the reports\"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90007", "url": "https://ubuntu.com/security/CVE-2026-90007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Use rollback index when freeing MSI-X vectors pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90011", "url": "https://ubuntu.com/security/CVE-2026-90011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where \tpadding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90017", "url": "https://ubuntu.com/security/CVE-2026-90017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: \tconst u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); \t... \tc = frame_body[0]; \t... \ta = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90018", "url": "https://ubuntu.com/security/CVE-2026-90018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: \tif (attr_ptr + 4 > wps_ie + wps_ielen) \t\tbreak; \tu16 attr_id = get_unaligned_be16(attr_ptr); \tu16 attr_data_len = get_unaligned_be16(attr_ptr + 2); \tu16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: \tmemcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack \"u8 sr\"/\"u8 selected_registrar\" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The \"attr_ptr + 4 > wps_ie + wps_ielen\" header check above was added by commit 1463ca3ec6601 (\"staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()\"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90019", "url": "https://ubuntu.com/security/CVE-2026-90019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: fix null pointer dereference in usb_put_function_instance() usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90020", "url": "https://ubuntu.com/security/CVE-2026-90020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90025", "url": "https://ubuntu.com/security/CVE-2026-90025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix OOB altmode array index The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90031", "url": "https://ubuntu.com/security/CVE-2026-90031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90032", "url": "https://ubuntu.com/security/CVE-2026-90032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: usbtv: keep device alive while ALSA card exists The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90033", "url": "https://ubuntu.com/security/CVE-2026-90033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90034", "url": "https://ubuntu.com/security/CVE-2026-90034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2025-38097", "url": "https://ubuntu.com/security/CVE-2025-38097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: remove encap socket caching to avoid reference leak The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used \"recently\", but it's a lot more complex than just not caching the socket.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2026-89515", "url": "https://ubuntu.com/security/CVE-2026-89515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables() During fuzz testing, the following issue was discovered: BUG: KMSAN: uninit-value in __dma_map_sg_attrs+0x217/0x310 __dma_map_sg_attrs+0x217/0x310 dma_map_sg_attrs+0x4a/0x70 ata_qc_issue+0x9f8/0x1420 __ata_scsi_queuecmd+0x1657/0x1740 ata_scsi_queuecmd+0x79a/0x920 scsi_queue_rq+0x4472/0x4f40 blk_mq_dispatch_rq_list+0x1cca/0x3ee0 __blk_mq_sched_dispatch_requests+0x458/0x630 blk_mq_sched_dispatch_requests+0x15b/0x340 __blk_mq_run_hw_queue+0xe5/0x250 __blk_mq_delay_run_hw_queue+0x138/0x780 blk_mq_run_hw_queue+0x4bb/0x7e0 blk_mq_sched_insert_request+0x2a7/0x4c0 blk_execute_rq+0x497/0x8a0 sg_io+0xbe0/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Uninit was created at: __alloc_pages+0x5c0/0xc80 alloc_pages+0xe0e/0x1050 blk_rq_map_user_iov+0x2b77/0x6100 blk_rq_map_user_io+0x2fa/0x4d0 sg_io+0xad6/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Bytes 14-15 of 16 are uninitialized Memory access of size 16 starts at ffff88800cbdb000 When processing the last unaligned element of the scatterlist, it is supplemented with missing bytes in the amount of pad_len. These bytes remain uninitialized, which leads to a problem. Extend last_sg->length by pad_len first, then use sg_zero_buffer() to zero those pad_len bytes. sg_zero_buffer() uses sg_miter internally, which correctly handles sg entries spanning multiple pages and padding that crosses a page boundary. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80689", "url": "https://ubuntu.com/security/CVE-2026-80689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions mmio_trace_rw() and mmio_trace_mapping() retrieve mmio_trace_array into tr and pass it to __trace_mmiotrace_rw() and __trace_mmiotrace_map(). If these functions are invoked while mmio_trace_array is NULL (e.g. before initialization or after disabled), accessing tr->array_buffer.buffer will result in a NULL pointer dereference crash. Fix this by adding an explicit NULL check for tr at the beginning of __trace_mmiotrace_rw() and __trace_mmiotrace_map().", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80888", "url": "https://ubuntu.com/security/CVE-2026-80888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: drop dma_buf reference on foreign-fd prime import ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-80912", "url": "https://ubuntu.com/security/CVE-2026-80912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: reject an unclaimed class value in security_get_classes() security_get_classes() sizes an array by p_classes.nprim and fills it at value - 1, so a class value the policy never defines leaves a NULL. sel_make_classes() passes every entry to sel_make_dir(), reaching the same d_alloc_name() dereference as the permission array. The class symbol table is allowed to be sparse (policydb_class_isvalid() exists to absorb that), but this getter builds its own array straight from the hash table and has no such predicate. Fail the lookup when a value went unclaimed instead of handing out the NULL. Conforming policies define every class they declare and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-89595", "url": "https://ubuntu.com/security/CVE-2026-89595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix stale object mask after concurrent mark updates When a mark gets a new event bit, fanotify and inotify may avoid recalculating the object mask if the cached aggregate already contains that bit. This is racy with a recalculation triggered by a concurrent update to another mark on the same connector. The concurrent scan can read the mark before the new bit is added, while the updater reads the old aggregate before that scan publishes its result. The updater then skips recalculation and the scan publishes a mask without the bit, leaving the object mask stale after both updates complete. This can be reproduced with two fanotify groups watching the same inode: one thread removes FAN_MODIFY from one existing mark while another thread adds FAN_MODIFY to the other mark. After both fanotify_mark() calls return, writes can fail to produce FAN_MODIFY for the group whose mark now contains the bit. This was reproduced on an unmodified v6.12.95 kernel. The equivalent inotify interleaving loses IN_MODIFY events. For normal fanotify additions, recalculate whenever the raw mark mask changes. The normal mask is not cleared asynchronously, so an unchanged addition cannot introduce missing interest. Always recalculate ignore-mask updates because FS_MODIFY handling may clear the ignore mask without taking mark->lock, making snapshot comparisons unreliable. Always recalculate after updating an existing inotify watch. Its replace path temporarily sets mark->mask to zero, so a concurrent scan can observe zero even when the old and final masks are equal. Assigning the replacement mask directly would avoid the transient zero, but existing-watch updates are infrequent, so unconditional recalculation is simpler.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89603", "url": "https://ubuntu.com/security/CVE-2026-89603", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-74378", "url": "https://ubuntu.com/security/CVE-2026-74378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe get_srq_wqe() reads wqe->dma.num_sge from the shared receive queue buffer, which is mapped into userspace. It validates num_sge against max_sge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify num_sge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe. Read num_sge into a local variable and use it for both the bounds check and the size calculation.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-89488", "url": "https://ubuntu.com/security/CVE-2026-89488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix CT limit teardown use-after-free Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state. An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down. Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists. Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization. The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90049", "url": "https://ubuntu.com/security/CVE-2026-90049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80977", "url": "https://ubuntu.com/security/CVE-2026-80977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't touch shared zerocopy state in skb_tx_error() skb_tx_error() completes the zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone shares, while the caller only owns the reference it is about to drop. Through a clone it tells the producer its pages are free and drops SKBFL_SHARED_FRAG for an skb that is still in flight. Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC: clone_execute() sends a skb_clone() into ovs_dp_process_packet() while do_execute_actions() keeps forwarding the original, and skb_clone() does not privatise the frags here -- skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN. A flow miss on the clone then strips the marker from the packet still being forwarded, and a later local ESP delivery decrypts in place over frags it does not own privately. Skip it for a cloned skb. Nothing is lost: skb_release_data() clears the zerocopy state once the last reference to the shared data goes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80928", "url": "https://ubuntu.com/security/CVE-2026-80928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix cred UAF in smack_file_send_sigiotask() When inspecting the credentials of another task, objective credentials (->real_cred, accessed with __task_cred()) must always be used. Accessing ->cred on a non-current task is forbidden unless that task is being created or destroyed; a task is allowed to change its own ->cred pointer with no synchronization, and changing ->cred should only affect the current syscall. smack_file_send_sigiotask() was accessing both sets of credentials: First tsk->cred, then __task_cred(tsk). Fix it, always access the objective credentials here. I have tested that this bug can lead to a KASAN-reported UAF of struct cred in smack_file_send_sigiotask(), and that this fix prevents the race.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-93222", "url": "https://ubuntu.com/security/CVE-2026-93222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: avoid shared siginfo namespace rewrites send_signal_locked() rewrites sender ids for the target namespace. Group sends reuse the same siginfo, so one recipient can affect the next. Copy the siginfo before changing it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-80930", "url": "https://ubuntu.com/security/CVE-2026-80930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80931", "url": "https://ubuntu.com/security/CVE-2026-80931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: ds28e17: reject an oversize length on an I2C block read w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the device. The downstream slave puts a length byte in buf[0]. The driver then reads that many bytes into buf[1] with w1_f19_i2c_read(). buf[0] is controlled by the device and can be 0 to 255. w1_f19_i2c_read() only rejects a zero count. The caller buffer is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read run past it, up to about 222 bytes out of bounds. The SMBus core does check buf[0] against I2C_SMBUS_BLOCK_MAX. That check runs after master_xfer returns. By then the write is already done. i2c-algo-bit rejects an oversize length before it copies, and returns -EPROTO. Reject a length above I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites, the same way i2c-algo-bit does.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80932", "url": "https://ubuntu.com/security/CVE-2026-80932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: flush works in dependency order virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work. In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it. KASAN reported: BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80938", "url": "https://ubuntu.com/security/CVE-2026-80938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex mt7615_suspend() acquired the mt76 mutex and then called cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the same mutex via mt7615_mutex_acquire() at the top of the worker, so if mac_work is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against. Flush scan_work and mac_work before taking the mutex, matching the suspend paths in mt7921 and mt7925. scan_work only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps mac_work from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80941", "url": "https://ubuntu.com/security/CVE-2026-80941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb() The skb passed to the rtw_hci_tx_write() is expected to be freed when the function fails, but the error path in rtw_txq_push_skb() does not free the skb before returning. This can lead to a memory leak in rtw_txq_push() where a dequeued skb is passed to rtw_txq_push_skb().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80944", "url": "https://ubuntu.com/security/CVE-2026-80944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Detach sync cmd buffer on interrupted wait mwifiex synchronous commands keep the caller-provided data buffer in cmd_node->data_buf. Several callers pass stack-allocated objects there. If wait_event_interruptible_timeout() is interrupted, the caller can return and release that stack object while the firmware command is still the current command. A late firmware response then reaches the normal response handler, which can copy data through cmd_node->data_buf into the stale stack address. This fixes a stack corruption observed during repeated association and disassociation cycles. The panic trace showed the command wait being interrupted immediately before a bad pointer dereference: cmd_wait_q terminated: -512 Unable to handle kernel paging request at virtual address 002c583837384662 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted ... Tainted: [M]=MACHINE_CHECK The fault address decodes as little-endian ASCII: 0x002c583837384662 -> \"bF878X,\\0\" which is a fragment of the VERSION_EXT firmware string exposed as debugfs \"verext\": w8997o-V4, RF878X, FP92, 16.92.21.p153.7 The same runs also showed corrupted control data containing: 0x2400372e333531 -> \"153.7\\0$\" which is the tail of the same VERSION_EXT string. This points at a late VERSION_EXT response writing through a stale stack-backed data_buf after the interrupted wait returned. After cancelling pending commands on an interrupted or timed-out wait, detach the caller-owned data buffer from the still-current command. This preserves the existing command cancellation behaviour while preventing a late response from writing through a pointer whose lifetime ended with the waiting caller. Tested on an i.MX8MP board using an 88W8997.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80949", "url": "https://ubuntu.com/security/CVE-2026-80949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() The memory allocated for buf is not freed in some of the error paths in brcmf_sdio_read_control(). Fix that by adding vfree() calls. [arend: rework as suggested by Johannes]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80951", "url": "https://ubuntu.com/security/CVE-2026-80951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: bound IBI payload to the requested max_payload_len svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into the IBI slot. The loop is bounded by the hardware FIFO size (SVC_I3C_FIFO_SIZE), not by the slot size. slot->data points into the IBI pool, which i3c_generic_ibi_alloc_pool() sizes at max_payload_len per slot. svc_i3c_master_request_ibi() only rejects a max_payload_len larger than SVC_I3C_FIFO_SIZE, so a driver can request a smaller one. mctp-i3c requests 1. Each readsb() then copies the controller RXCOUNT bytes (up to 31) with no check against the slot size. A device that sends more bytes than the slot holds writes past slot->data, an out-of-bounds write into the IBI pool. Bound the loop by dev->ibi->max_payload_len and clamp each read to the space left in the slot, the same way dw-i3c does. A device can still send more than the requested payload. Flush the leftover bytes from the RX FIFO so they do not leak into the next transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80952", "url": "https://ubuntu.com/security/CVE-2026-80952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix info leak and UAF in device unregister path i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During device_unregister(), device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct i3c_device_info, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind. Keep desc valid until device_unregister() has completed. Since device_unregister() drops the device reference and may free the device, take an extra reference with get_device() before unregistering. Clear desc afterwards and release the extra reference with put_device(). This preserves the release-time invariant that desc must be NULL while avoiding both the information leak and a potential use-after-free from writing desc after the device has been released.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80963", "url": "https://ubuntu.com/security/CVE-2026-80963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-stats: fix a crash if allocation of per-cpu data fails If \"dm_kvzalloc(percpu_alloc_size, cpu_to_node(cpu))\" fails, the code jumps to the \"out\" label and calls dm_stat_free. dm_stat_free does \"for_each_possible_cpu(cpu) { dm_kvfree(s->stat_percpu[cpu][0].histogram, s->histogram_alloc_size);\", which crashes with NULL pointer dereference if s->stat_percpu[cpu] is NULL. This commit fixes the bug by testing s->stat_percpu[cpu] for NULL before using it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80964", "url": "https://ubuntu.com/security/CVE-2026-80964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: virmidi: Check card index validity at probe virmidi driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80965", "url": "https://ubuntu.com/security/CVE-2026-80965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: serial-u16550: Check card index validity at probe serial-u16550 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80966", "url": "https://ubuntu.com/security/CVE-2026-80966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: portman2x4: Check card index validity at probe Although portman2x4 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80967", "url": "https://ubuntu.com/security/CVE-2026-80967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcxhr: initialize mutexes before requesting threaded IRQ pcxhr_probe() requests pcxhr_threaded_irq() before initializing mgr->lock, even though the threaded handler takes that mutex. Initialize the manager locks before request_threaded_irq() so an early interrupt cannot run against uninitialized mutex state during probe.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80968", "url": "https://ubuntu.com/security/CVE-2026-80968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mts64: Check card index validity at probe Although mts64 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80969", "url": "https://ubuntu.com/security/CVE-2026-80969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mpu401: Check card index validity at probe mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80971", "url": "https://ubuntu.com/security/CVE-2026-80971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: clear the URB pointers on disconnect bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind: \tusb_kill_urb(bcd2k->midi_out_urb); \tusb_kill_urb(bcd2k->midi_in_urb); \tusb_free_urb(bcd2k->midi_out_urb); \tusb_free_urb(bcd2k->midi_in_urb); The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core: \tbcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE; \t... \tret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC); usb_kill_urb() does not stop a later submission either, so a submit that races the disconnect can requeue the URB after it has been reaped. midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits it from the completion handler. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000] Write of size 4 at addr ffff00001827d388 by task bpoc/168 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 Freed by task 168: usb_free_urb bcd2000_disconnect [snd_bcd2000] BUG: KASAN: slab-use-after-free in usb_submit_urb Read of size 8 at addr ffff00001827d3b8 by task bpoc/168 Clear both pointers after freeing and test them on the paths that can still run. Poison the URBs before freeing them: usb_poison_urb() waits for a running completion handler and rejects any later submission, so after it returns the input path is quiesced and only the rawmidi trigger path can still reach bcd2000_midi_send(). No unpoison is needed; the URBs are freed on the next line. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80972", "url": "https://ubuntu.com/security/CVE-2026-80972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Check card index validity at probe aloop driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80973", "url": "https://ubuntu.com/security/CVE-2026-80973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: bound the MIDI event length from the device usb6fire_comm_receiver_handler() forwards a MIDI event using a length byte the device supplies, with no bound and no check that the transfer delivered that many bytes: \tif (!urb->status) { \t\tif (rt->receiver_buffer[0] == 0x10) /* midi in event */ \t\t\tif (midi_rt) \t\t\t\tmidi_rt->in_received(midi_rt, \t\t\t\t\t\trt->receiver_buffer + 2, \t\t\t\t\t\trt->receiver_buffer[1]); \t} receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the device chooses, so a device that answers with 0x10 and a length of 0xFF makes snd_rawmidi_receive() read 255 bytes starting two bytes into a 64-byte object. The bytes past the buffer are handed to userspace through the rawmidi read path. urb->actual_length is not consulted either, so a short transfer leaves both the type byte and the length byte at their previous values and the handler acts on stale data. The receiver URB is submitted from usb6fire_comm_init() at probe, so the read happens on plug with no user action; forwarding to userspace also needs a MIDI input substream open, since usb6fire_midi_in_received() only calls snd_rawmidi_receive() when rt->in is set. KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device: BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive Read of size 255 at addr ffff000009f64682 by task bash/183 __asan_memcpy snd_rawmidi_receive usb6fire_midi_in_received [snd_usb_6fire] usb6fire_comm_receiver_handler [snd_usb_6fire] Allocated by task 11: usb6fire_comm_init [snd_usb_6fire] usb6fire_chip_probe [snd_usb_6fire] The buggy address is located 2 bytes inside of allocated 64-byte region [ffff000009f64680, ffff000009f646c0) Reject the event when the length exceeds the bytes that follow the header, and require the transfer to have delivered the header plus that many bytes. The receiver URB is submitted with a 64-byte transfer_buffer_length, so a genuine device cannot deliver an event longer than those 62 bytes and nothing valid is dropped. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80976", "url": "https://ubuntu.com/security/CVE-2026-80976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: reset IP6CB after IPv6 decapsulation decap_and_validate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags. End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet. The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports: BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu ip6_protocol_deliver_rcu+0x1118/0x1450 ip6_input_finish+0x11b/0x240 seg6_local_input_core+0xed/0x2e0 lwtunnel_input+0x1e9/0x4e0 ipv6_rthdr_rcv+0x525f/0x6c50 ip6_protocol_deliver_rcu+0xcb7/0x1450 Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field. Use IP6CB(skb)->iif rather than skb->skb_iif because VRF processing can replace skb_iif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKB_L3SLAVE for the same reason.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80978", "url": "https://ubuntu.com/security/CVE-2026-80978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap advertised IP tunnel headroom IP tunnel devices derive their advertised needed_headroom from lower output devices. A stack of user-created devices can make the derived value larger than the 16-bit skb header offsets can represent. Once IP output reserves it, skb head expansion can wrap those offsets. The runtime transmit path already caps a growing needed_headroom at 512. Apply the same cap when tunnel configuration publishes needed_headroom derived from a lower output device. Capping the advertised value is safe: IP tunnel transmit still expands the skb when a packet needs more headroom. A nonsensical stacked configuration can therefore incur an extra reallocation, but it cannot publish an unbounded reservation to upper layers.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80983", "url": "https://ubuntu.com/security/CVE-2026-80983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket refcount leak in smc_switch_conns() smc_switch_conns() takes a reference on the SMC socket before dropping lgr->conns_lock, so the connection stays alive while the CDC slot is fetched: sock_hold(&smc->sk); read_unlock_bh(&lgr->conns_lock); /* pre-fetch buffer outside of send_lock, might sleep */ rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend); if (rc) goto err_out; The err_out label only drops the wr_tx link reference, so this early exit returns without the matching sock_put(). The second error exit is not affected, because sock_put() has already run by then. A leaked sk_refcnt means the smc_sock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down. smc_cdc_get_free_slot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smc_switch_conns() run in the first place. Restructure so there is a single sock_put() covering both outcomes, instead of adding a second one to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80987", "url": "https://ubuntu.com/security/CVE-2026-80987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Reject oversized TX buffers ntb_process_tx() handles an oversized buffer by calling tx_handler() with a NULL data pointer and returning success. ntb_netdev therefore neither frees the skb in its completion callback nor takes its enqueue error path, leaking it. Reject oversized buffers in ntb_transport_tx_enqueue() before acquiring a queue entry and return -EMSGSIZE. The caller retains ownership of the buffer, and the preceding netdev patch frees the skb when enqueue returns this permanent error.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80988", "url": "https://ubuntu.com/security/CVE-2026-80988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Fail TX enqueue when the QP link is down Commit f195a1a6fe41 (\"ntb: Drop packets when qp link is down\") meant to make ntb_transport_tx_enqueue() drop packets submitted while the QP link is down, but it only returns 0 without consuming the packet. Zero means success by this function's contract, so ntb_netdev reports NETDEV_TX_OK and forgets the skb: nothing queued it, nothing frees it, and it leaks, one skb for every transmit racing a link-down. Return -ENOLINK instead, restoring the contract that a non-zero return leaves the buffer owned by the caller. With the preceding patch, ntb_netdev frees the skb on non-retryable enqueue failures and returns NETDEV_TX_OK, so a packet racing with link-down is dropped without leaking or entering a busy retry loop.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80994", "url": "https://ubuntu.com/security/CVE-2026-80994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix flow mask use-after-free on flow deletion The commit in the Fixes tag below made so flow->mask free is scheduled via RCU right after it is removed from the flow table. The pointer stays in the flow structure and it can be accessible while in the same RCU critical section. This is done to avoid requiring ovs_mutex for the ovs_flow_free(). However, while removing the flow during processing of CMD_DEL, we do not take RCU read lock before the removal, and ovs_flow_cmd_fill_info() uses the flow->mask pointer afterwards. The RCU read lock is taken, but it's already late at that point. The comment on that line acknowledges that the lock is cosmetic and doesn't serve a real purpose. This leads to use-after-free if the RCU grace period passes between removal and the filling. It is a short race window, but it is there and can lead to a real crash in case memory allocation for the info takes a bit longer: BUG: KASAN: slab-use-after-free in __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 BUG: KASAN: slab-use-after-free in ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 Read of size 4 at addr ffff88801ee89970 by task ovs_flow_del_ec/9487 Call Trace: __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c:930 ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c:1467 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Allocated by task 9487: mask_alloc net/openvswitch/flow_table.c:967 flow_mask_insert net/openvswitch/flow_table.c:1012 ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c:1084 ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c:1086 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Freed by task 9485: rcu_free_sheaf+0x1e/0x100 mm/slub.c:5978 rcu_do_batch kernel/rcu/tree.c:2645 rcu_core+0x59c/0x10c0 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9a0 kernel/softirq.c:622 ... instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 ovs_flow_tbl_remove() must be called after the ovs_flow_cmd_fill_info() to avoid this race. This also helps with cleaning up the forced cast and the cosmetic RCU read lock. Before the commit in the Fixes tag the order did not matter as long as the flow object itself was not freed. A wider RCU critical section could be another option, but we have a GFP_KERNEL allocation in the way. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-32042.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81000", "url": "https://ubuntu.com/security/CVE-2026-81000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tun: bound receive headroom tun_get_user() uses tun->align both as skb headroom and when choosing how much packet data to keep linear. OVS can propagate an oversized headroom request from another port to TUN or TAP. When align is larger than the usable space in a one-page skb head, SKB_MAX_HEAD(align) underflows and the result becomes negative when stored in good_linear. That value later wraps when assigned to the size_t linear variable, and tun_alloc_skb() can place skb->data outside the allocated head. Bound the headroom stored by TUN to the one-page skb-head budget and the largest non-sentinel 16-bit skb header offset. Leave one linear byte for raw TUN and a complete Ethernet header for TAP, including NET_IP_ALIGN. Also pull the raw-TUN protocol byte and the TAP Ethernet header before accessing them, so these checks remain safe for nonlinear skbs supplied by other allocation paths.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81001", "url": "https://ubuntu.com/security/CVE-2026-81001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: fix use-after-free in sl_sync() slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor. priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop: \t/* Snapshot list, allow later requests */ \tlist_replace_init(&net_todo_list, &list); \t__rtnl_unlock(); \t... \t\tif (dev->priv_destructor) \t\t\tdev->priv_destructor(dev);\t/* slip_devs[i] = NULL */ \t\tif (dev->needs_free_netdev) \t\t\tfree_netdev(dev); \t\t... \t\t/* Free network device */ \t\tkobject_put(&dev->dev.kobj); So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed */ sl = netdev_priv(dev) if (sl->tty || sl->leased) /* use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860 Commit e58c19124189 (\"slip: Fix use-after-free Read in slip_open\") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it. Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: the ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81002", "url": "https://ubuntu.com/security/CVE-2026-81002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xdp: fix zero-copy frame layout xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page and advertises PAGE_SIZE as its frame size. It allows the copied frame to occupy the page tail needed by skb_shared_info and records zero headroom even when metadata separates the frame header from packet data. An AF_XDP zero-copy packet redirected through cpumap can therefore make the skb overlap skb_shared_info or place it beyond the allocated page. Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result. BUG: KASAN: slab-out-of-bounds in skb_gro_receive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skb_gro_receive (net/core/gro.c:174) udp_gro_receive (net/ipv4/udp_offload.c:812) inet_gro_receive (net/ipv4/af_inet.c:1539) dev_gro_receive (net/core/gro.c:515) gro_receive_skb (net/core/gro.c:633) cpu_map_kthread_run (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Kernel panic - not syncing: KASAN: panic_on_warn set ...", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81003", "url": "https://ubuntu.com/security/CVE-2026-81003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: filter frames in afiucv_hs_rcv() by ingress device afiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-byte name fields in the transport header alone. No check is made against the net_device the frame arrived on. This can cause a frame arriving on any netdev to be delivered to an AF_IUCV socket. Three problems follow. First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL. iucv_sock_bind() takes the classic path whenever the requested userid matches iucv_userid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucv_hs_callback_syn() for such a match inherits hs_dev = NULL and transport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable. Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections Third, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() calls sk_alloc(&init_net, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAP_NET_RAW capability valid within that namespace can send a raw ETH_P_AF_IUCV frame on its own lo device and have it matched against init_net sockets. Fix all three by skipping any socket whose hs_dev does not match the ingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hs_dev is always a device in init_net (iucv_sock_bind() scans for_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket. Note that AF_IUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81005", "url": "https://ubuntu.com/security/CVE-2026-81005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: si: Fix NULL pointer dereference after failed registration try_smi_init() allocates new_smi->si_sm and later calls ipmi_register_smi_mod(), which maps to ipmi_add_smi(). During ipmi_add_smi(), the upper IPMI message handler obtains the initial BMC device information through __bmc_get_device_id(). This can fail if the BMC does not return a successful response to the Get Device ID command. When the BMC returns a nonzero completion code, the device-id helper retries the command and eventually returns -EIO if the device ID still cannot be fetched. On this failure path, ipmi_add_smi() logs \"Unable to get the device id\" and goes to out_err_started, where it invokes the lower driver's shutdown callback. try_smi_init() then logs the returned registration failure: ipmi_si IPI0001:00: IPMI message handler: Unable to get the device id: -5 ipmi_si IPI0001:00: Unable to register device: error -5 For ipmi_si, the shutdown callback is shutdown_smi(), which cleans up the SI state machine data, frees smi_info->si_sm, and sets smi_info->si_sm and smi_info->intf to NULL. However, intf->in_shutdown is not set on this failed-registration rollback path. Therefore, the asynchronous redo_bmc_reg work item can still retry BMC device-id probing after the lower driver has already cleared its SI state machine data. In the observed case, that retry path reached start_next_msg(), which passed the NULL smi_info->si_sm pointer to the selected KCS state machine handler: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Workqueue: events redo_bmc_reg [ipmi_msghandler] RIP: start_kcs_transaction+0x2c/0x190 [ipmi_si] Call Trace: start_next_msg+0x50/0x80 [ipmi_si] check_start_timer_thread.part.9+0x3b/0x50 [ipmi_si] sender+0x69/0x80 [ipmi_si] i_ipmi_request+0x2ac/0x9d0 [ipmi_msghandler] __get_device_id.isra.29+0xaa/0x180 [ipmi_msghandler] __bmc_get_device_id+0xef/0x950 [ipmi_msghandler] redo_bmc_reg+0x52/0x60 [ipmi_msghandler] process_one_work+0x1a7/0x360 Set intf->in_shutdown on the out_err_started path before invoking the lower driver's shutdown callback. This prevents later redo_bmc_reg retries from using an interface whose lower driver state has been cleaned up, and applies the same shutdown state to other IPMI interfaces as well.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81007", "url": "https://ubuntu.com/security/CVE-2026-81007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: validate write message length ipmb_write() read message fields before validating the length byte. A zero or short write can read uninitialized stack bytes. A length smaller than the SMBus header underflows the block write length. Require a non-empty buffer and the minimum IPMB request length. Also require the length byte plus payload before parsing the message.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81008", "url": "https://ubuntu.com/security/CVE-2026-81008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: interconnect: Fix use after free in icc_get() and of_icc_get_by_index() In of_icc_get_by_index() and icc_get(), if the dynamic allocation for path->name fails via kasprintf(), the error handling path directly calls kfree(path) to free the path object and returns an error. However, prior to this point, path_find() calls path_init(), which already links the path's requests into the req_list of the respective interconnect nodes via hlist_add_head(). Directly invoking kfree(path) leaves dangling pointers in the hlist. A subsequent call to icc_get() or icc_set_bw() will traverse or modify these corrupted lists, triggering a slab use afterfree. KASAN report showing the vulnerability when reproducing via debugfs: BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0 Fix this by replacing kfree(path) with the proper teardown function, icc_put(path), which safely removes the requests from the req_list using hlist_del() and drops the provider usage references before freeing the memory. Additionally, in icc_get(), ensure that the icc_lock mutex is released prior to calling icc_put(path) to avoid a deadlock, as icc_put() internally acquires the same lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81017", "url": "https://ubuntu.com/security/CVE-2026-81017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Bound the EC-reported sensor number Each EC FIFO event carries an 8-bit sensor number (in->sensor_num). cros_ec_sensorhub_ring_handler() validates the FIFO event count, the per-read count and the ring bound, but not the sensor number, which cros_ec_sensor_ring_process_event() then uses unchecked to index sensorhub->batch_state[] - allocated with only sensorhub->sensor_num entries. A sensor number of sensor_num or larger is an out-of-bounds read and write of batch_state[]. Validate the sensor number in the ring handler, where each event is read from the EC, and drop a malformed event before it is used.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89440", "url": "https://ubuntu.com/security/CVE-2026-89440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: via-sdmmc: stop card-detect handling on probe failure request_irq() registers the SD card-detect interrupt and the probe enables it before mmc_add_host() runs. If mmc_add_host() fails, the error path only unmaps the registers and returns: the interrupt stays registered, so the handler keeps running against the host once it is freed. via_sdc_isr() dereferences sdhost and its MMIO base and schedules carddet_work, which via_sdc_card_detect() also runs against freed memory through its container_of() dereference. Add a probe-error path that disables and frees the interrupt and cancels carddet_work before unmapping. carddet_work can re-enable the device interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it again after cancelling the work. This issue was found by an in-house static analysis tool and confirmed by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89444", "url": "https://ubuntu.com/security/CVE-2026-89444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer set_attribute() populates the security area of the BIOS attribute request buffer with the current admin password via populate_security_buffer(), then dumps the whole request buffer with print_hex_dump_bytes(). This can expose the plaintext admin password in the kernel log. The same issue was fixed for the password attribute path by commit d1a196e0a6dc (\"platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data\"). Remove the remaining dump from the BIOS attribute path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93206", "url": "https://ubuntu.com/security/CVE-2026-93206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/proc: Use file_ns_capable() when checking config space read access proc_bus_pci_read() decides how much of the config space is readable based on capable(CAP_SYS_ADMIN), which checks the credentials of the task calling read(), not the credentials of the process that opened the file. The sysfs equivalent, pci_read_config(), has checked the credentials of the opening process since commit de139a339395 (\"pci: check caps from sysfs file open to read device dependent config space\"), so a privileged process can open the config space file and pass the file descriptor to an unprivileged process (for example, a process running a KVM guest with an assigned device), which can then read the entire config space. The check was subsequently routed through the LSM framework in commit 47970b1b2aa6 (\"pci: use security_capable() when checking capablities during config space read\") and converted to the dedicated helper in commit ab0fa82b2df9 (\"pci-sysfs: use proper file capability helper function\"). Thus, the two interfaces check the same capability against different credentials. Checking the credentials of the task calling read() makes the outcome depend on who reads rather than who opened, so the restriction is bypassed whenever a more privileged process reads through the descriptor. Checking the credentials recorded in file->f_cred settles the decision at open() time and ties it to the file, where it cannot change with the caller. Use file_ns_capable() to check CAP_SYS_ADMIN against the credentials in effect when the file was opened, bringing the procfs interface in line with the sysfs behaviour. As a result, a file descriptor opened by a privileged process and passed to an unprivileged one now allows the entire config space to be read through procfs, matching sysfs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89456", "url": "https://ubuntu.com/security/CVE-2026-89456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Propagate partial completion length across ERP recovery dasd_default_erp_postaction() copies the timing and device state from the finished ERP request back to the original request but drops proc_bytes. A request that was partially completed, an ESE read of a not-yet-allocated track returns fewer bytes than requested, and then recovered through the ERP chain loses its partial-completion length. __dasd_cleanup_cqr() then sees proc_bytes == 0 and completes the whole request instead of requeueing the remainder, silently returning zeroed data for the part that was never read. Carry proc_bytes over to the original request like the other per-request state.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89457", "url": "https://ubuntu.com/security/CVE-2026-89457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Guard sysfs discipline callbacks against unallocated private data Several sysfs show/store handlers call a discipline callback that dereferences device->private, either directly or through the DASD_DEFINE_ATTR() macro. During dasd_generic_set_online() the discipline is assigned before check_device() allocates device->private, so an unprivileged read of one of these world-readable attributes in that window dereferences a NULL pointer and panics. Guard the dereference inside each callback that actually touches device->private.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89458", "url": "https://ubuntu.com/security/CVE-2026-89458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Do not complete a failed ESE read as successful dasd_int_handler() completes an NRF read of an unallocated ESE track by calling ese_read() and unconditionally marking the request DASD_CQR_SUCCESS. dasd_eckd_ese_read() can return an error before it has zeroed the destination buffer: a failed sense-data parse or a current track outside the requested range both return early, leaving the destination pages untouched. The request is still completed successfully, so the block layer is handed stale / uninitialized memory instead of zeros. Check the ese_read() return value and fail the request through the normal error path instead of forcing DASD_CQR_SUCCESS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89461", "url": "https://ubuntu.com/security/CVE-2026-89461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: synchronize work cancellation on suspend max17040_work() requeues itself after every poll. cancel_delayed_work() only cancels a pending instance and does not wait for a callback that is already running. If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns. Use cancel_delayed_work_sync() to ensure polling is quiesced before suspend completes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89463", "url": "https://ubuntu.com/security/CVE-2026-89463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ucs1002: fix use-after-free on remove ucs1002 has no remove callback, so unbind runs entirely through devm. The alert IRQ handler queues the health_poll delayed work, and the work reschedules itself while the chip reports a bad-health condition. devm frees the alert IRQ, which only synchronizes the handler; it does not cancel the delayed work, which can then run after devm frees the driver data and dereference it. Register health_poll with devm_delayed_work_autocancel() before the alert IRQ is requested. devm then frees the IRQ before cancelling the work, so the handler can no longer queue it and the work is cancelled before the driver data is freed. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89464", "url": "https://ubuntu.com/security/CVE-2026-89464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: twl4030_charger: cancel workers via devm bci is devm-allocated. Two workers (bci->work and bci->current_worker) dereference it. twl4030_bci_remove() disables charging and masks interrupts. It cancels neither worker. A worker pending at remove() can run after devm frees bci. The USB transceiver comes from devm_usb_get_phy_by_node(). devm unregisters its notifier only after remove() returns. A cancel_work_sync() in remove() can then race a notifier reschedule. devm_work_autocancel() and devm_delayed_work_autocancel() avoid that. They cancel the workers during devm release, before bci is freed. The current_worker is registered first, since devm will cancel in reverse order and bci->work can reschedule current_worker. [Move comment about order into the commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89469", "url": "https://ubuntu.com/security/CVE-2026-89469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: lp8727: fix use-after-free in lp8727_release_irq() lp8727_isr_func(), the threaded IRQ handler, is the only caller that arms pchg->work via schedule_delayed_work(). lp8727_release_irq() currently cancels the work before freeing the IRQ, so an IRQ delivered in between can re-arm the work through the threaded handler. After .remove returns the devm layer frees pchg while lp8727_delayed_func() may still run and dereference it. Free the IRQ first so the threaded handler is quiesced and can no longer queue work, then cancel the delayed work to drain the final generation. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89470", "url": "https://ubuntu.com/security/CVE-2026-89470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS Currently the cros_usbpd-charger driver probe iterates based on raw charger port count returned by the embedded controller. The only check is against the number of USB PD ports which the embedded controller also defines. A malicious embedded controller could return an inaccurate port count (up to 255) resulting in an out of bounds write and subsequent memory corruption. Update helper functions in cros_usbpd-charger to limit port counts to EC_USB_PD_MAX_PORTS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89471", "url": "https://ubuntu.com/security/CVE-2026-89471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd-charger: bound the EC-reported port count cros_usbpd_charger_probe() reads two port counts from the EC and uses one of them, num_charger_ports, as the loop bound when populating a fixed-size array: \tstruct port_data *ports[EC_USB_PD_MAX_PORTS];\t/* 8 entries */ \t... \tfor (i = 0; i < charger->num_charger_ports; i++) \t\tcharger->ports[charger->num_registered_psy++] = port; Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports (from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The only validation is a sanity check that compares the two EC-reported values against each other: \tif (num_charger_ports < num_usbpd_ports || \t num_charger_ports > num_usbpd_ports + 1) \t\treturn -EPROTO; It never checks either count against EC_USB_PD_MAX_PORTS, the size of the ports[] array. A malfunctioning, malicious or compromised EC that reports num_usbpd_ports == num_charger_ports == N for any N > 8 (for example both 255) passes this check, and the loop then writes N pointers into the 8-entry ports[] array embedded in the devm_kzalloc()'d charger_data, overflowing it by up to 255 - 8 = 247 entries (~1976 bytes): a slab out-of-bounds write. Reject a port count larger than the ports[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89474", "url": "https://ubuntu.com/security/CVE-2026-89474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: drain usb_work before freeing the charger The USB-PHY notifier queues usb_work, whose handler calls power_supply_changed(bq->charger). The reset devm action only unregisters the notifier and was registered before the power supplies, so devm frees bq->charger on unwind before the action runs; a usb_work still queued can then dereference it. Register the reset action after the power supplies, so it unregisters the notifiers and drains usb_work before the supplies are released. Initialize usb_work and obtain the PHY references before registering the notifiers, so the worker cannot run before the supplies exist. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89475", "url": "https://ubuntu.com/security/CVE-2026-89475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq24257: fix use-after-free on remove The STAT-pin interrupt is devm-managed, so it stays armed until the devm cleanup that runs after remove() returns. remove() cancels bq->iilimit_setup_work while the threaded handler can still fire; that handler reschedules the work and dereferences bq, so the work runs against freed memory once devm frees bq. Make the delayed work device-managed with devm_delayed_work_autocancel(), registered before the interrupt request. The devm cleanup then releases the interrupt first, so the handler can no longer reschedule the work, and cancels the work before bq is freed. The explicit cancel_delayed_work_sync() in remove() is no longer needed and is dropped. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89476", "url": "https://ubuntu.com/security/CVE-2026-89476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix stream->outcnt underflow on duplicate RECONF responses A cached RECONF chunk may contain more than one request parameter. A duplicate response can therefore find and process the same ADD_OUT request again while another parameter is still outstanding, rolling back outcnt twice and possibly underflowing it. Track outstanding request types as bits and clear each bit after its first response. Later responses for the same request are then ignored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89477", "url": "https://ubuntu.com/security/CVE-2026-89477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix NULL deref on untransmitted RECONF completion sctp_process_strreset_outreq(), sctp_process_strreset_addstrm_out() and sctp_process_strreset_resp() complete a pending stream reconfiguration request by stopping the reconf timer on the transport it was sent on: \tt = asoc->strreset_chunk->transport; \tif (timer_delete(&t->reconf_timer)) \t\tsctp_transport_put(t); chunk->transport is assigned by __sctp_packet_append_chunk() when the chunk is appended to an outbound packet, and sctp_outq_flush_ctrl() arms the reconf timer at that same point. A request already published in asoc->strreset_chunk but not yet transmitted has neither, so completing it dereferences NULL. Two ways to get there. sctp_send_asconf_del_ip() sets asoc->src_out_of_asoc_ok without sending anything when the address being removed is the association's last one, and sctp_outq_flush_ctrl() then leaves every non-ASCONF control chunk queued; as only sctp_process_asconf_ack() clears that flag, it persists. An unprivileged process that removes such an address and then asks for a stream reset panics the kernel from softirq. A peer needs neither ASCONF nor local help: sctp_cmd_interpreter() uncorks the outqueue only once the whole packet has been processed, so a reply built while walking a RECONF chunk stays untransmitted for the rest of that walk, and one RECONF chunk carrying [Incoming SSN Reset Request, Outgoing SSN Reset Request, Response] -- or two RECONF chunks in one packet -- reaches the same dereference. KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef] RIP: 0010:timer_delete+0x67/0x110 Call Trace: sctp_process_strreset_addstrm_out (net/sctp/stream.c:832) sctp_sf_do_reconf (net/sctp/sm_statefuns.c:4212) sctp_do_sm (net/sctp/sm_sideeffect.c:1172) sctp_assoc_bh_rcv (net/sctp/associola.c:1044) sctp_rcv (net/sctp/input.c:243) ip_local_deliver (net/ipv4/ip_input.c:262) process_backlog (net/core/dev.c:6680) A response can only acknowledge a request that was actually sent, so do not match asoc->strreset_chunk while chunk->transport is NULL. Guarding the lookup covers all three completion sites.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89478", "url": "https://ubuntu.com/security/CVE-2026-89478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: drop a chunk if its transport was removed sctp_rcv() resolves the transport once per packet and leaves it in chunk->transport. The lookup reference, or the one sctp_add_backlog() takes if the socket is owned by userspace, keeps it around until the chunk has been processed. An authenticated ASCONF DEL-IP can remove it in the meantime. sctp_assoc_rm_peer() takes the transport out of the association and calls sctp_transport_free(), which tags it dead and drops the reference the association held. There is a window on both paths: the packet can sit on the socket backlog, and on the direct path the lookup completes before bh_lock_sock(). The DATA chunk in that packet puts the removed transport back into asoc->peer.last_data_from. Once the packet is done that reference goes away and the transport is freed by RCU, so the next delayed SACK carries the pointer into the SACK chunk and sctp_outq_select_transport() reads the freed transport's state. Drop the chunk in sctp_inq_push(), next to the existing rcvr->dead check. Both paths reach it with the association's socket lock held. The peer retransmits it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89479", "url": "https://ubuntu.com/security/CVE-2026-89479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stop processing a packet once its association is deleted sctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference. A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(), so the association and its transports are freed. The endpoint loop has no counterpart to the asoc->base.dead check in sctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed transport and is then passed to sctp_do_sm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context. The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctp_inq_free() releases the chunk on the association receive path. sctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89480", "url": "https://ubuntu.com/security/CVE-2026-89480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: reject a read that transferred too few bytes nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above. A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target. Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89482", "url": "https://ubuntu.com/security/CVE-2026-89482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone Commit 25e5cb780e62 (\"nvme-tcp: fix possible crash in write_zeroes processing\") established that blk_rq_payload_bytes() must not be read without first checking blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight, because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now tests the same two.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89483", "url": "https://ubuntu.com/security/CVE-2026-89483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: zero the discard fallback page nvme_setup_discard() always maps sizeof(struct nvme_dsm_range) * NVME_DSM_MAX_RANGES = 4096 bytes as the DSM payload however many ranges the command declares, because some devices ignore the 'Number of Ranges' field - the Fixes: commit records two that read past the declared ranges. A single-range discard fills only the first 16 bytes. Normally the buffer comes from kzalloc() and the other 4080 bytes are zero. When that allocation fails the code falls back to the per-controller ctrl->discard_page, which nvme_init_ctrl() obtains with alloc_page(GFP_KERNEL) and nothing ever zeroes, so those 4080 bytes are whatever the page last held and are handed to the controller. Reaching it requires the kzalloc(GFP_ATOMIC | __GFP_NOWARN) to fail, that is memory pressure; it is not remotely triggerable. Failing the allocation under KMSAN reproduces it, with the leaked tail full of vmemmap struct page pointers. The extent in the report is a partial transfer of the payload, not the whole 4096 bytes; the 16-byte boundary in it is the one declared range: [ 11.991601] BUG: KMSAN: uninit-value in dma_map_phys+0x14c8/0x1900 [ 11.991969] dma_map_phys+0x14c8/0x1900 [ 11.992220] dma_map_page_attrs+0xcf/0x130 [ 11.992485] e1000_xmit_frame+0x4099/0x6d10 [ 11.992768] dev_hard_start_xmit+0x22f/0xa80 [ 11.993068] sch_direct_xmit+0x35c/0xcb0 [ 11.993315] __dev_queue_xmit+0x1ee5/0x5eb0 [ 11.993608] ip_finish_output2+0x1903/0x1c30 [ 11.993881] ip_finish_output+0x288/0x870 [ 11.994125] ip_output+0x15e/0x400 [ 11.994365] __ip_queue_xmit+0x1e85/0x1fb0 [ 11.994639] ip_queue_xmit+0x60/0x80 [ 11.994899] __tcp_transmit_skb+0x4e71/0x5fa0 [ 11.995210] tcp_write_xmit+0x3a36/0x9160 [ 11.995533] __tcp_push_pending_frames+0xc5/0x3c0 [ 11.995854] tcp_push+0x7dc/0x840 [ 11.996076] tcp_sendmsg_locked+0x766c/0x8400 [ 11.996371] tcp_sendmsg+0x4b/0x90 [ 11.996572] inet_sendmsg+0x134/0x2a0 [ 11.996823] __sock_sendmsg+0x265/0x360 [ 11.997076] sock_sendmsg+0x100/0x1e0 [ 11.997293] nvme_tcp_try_send+0x196f/0x6370 [ 11.997605] nvme_tcp_queue_rq+0x1d54/0x20b0 [ 11.997882] blk_mq_dispatch_rq_list+0x5ee/0x2e50 [ 11.998175] __blk_mq_sched_dispatch_requests+0x16dc/0x24a0 [ 11.998539] blk_mq_sched_dispatch_requests+0x11b/0x2c0 [ 11.998865] blk_mq_run_work_fn+0x13b/0x280 [ 11.999146] process_scheduled_works+0x966/0x1ad0 [ 11.999465] worker_thread+0xe44/0x1480 [ 11.999709] kthread+0x53b/0x600 [ 11.999927] ret_from_fork+0x29f/0x7c0 [ 12.000191] ret_from_fork_asm+0x1a/0x30 [ 12.000460] [ 12.000558] Uninit was created at: [ 12.000788] __alloc_frozen_pages_noprof+0x8bf/0xd30 [ 12.001096] alloc_pages_mpol+0x1d0/0x5f0 [ 12.001326] alloc_pages_noprof+0x102/0x290 [ 12.001627] nvme_init_ctrl+0x5a3/0x9f0 [ 12.001891] nvme_tcp_create_ctrl+0xd75/0x19b0 [ 12.002170] nvmf_dev_write+0x4c68/0x4fd0 [ 12.002426] vfs_write+0x587/0x1a10 [ 12.002636] __x64_sys_write+0x207/0x4f0 [ 12.002874] x64_sys_call+0x2ff0/0x3ea0 [ 12.003123] do_syscall_64+0x147/0x3b0 [ 12.003400] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 12.003680] [ 12.003777] Bytes 16-2843 of 2844 are uninitialized [ 12.004068] Memory access of size 2844 starts at ffff888109f82000 [ 12.004412] [ 12.004530] CPU: 0 UID: 0 PID: 101 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMECTL-gf5098b6bae76 #1 PREEMPT(lazy) [ 12.005127] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 12.005762] Workqueue: kblockd blk_mq_run_work_fn [ 12.006073] ===================================================== Allocate the page with __GFP_ZERO. The single allocation site covers every use of it: bytes no discard has written stay zero, and bytes one did write hold that controller's own range list, which it has already been sent.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89485", "url": "https://ubuntu.com/security/CVE-2026-89485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: pin next file across nlm_inspect_file lock-drop nlm_traverse_files() pins the current file with f_count++ across a mutex_unlock for nlm_inspect_file(), but nothing pins the saved next pointer. A concurrent nlm_release_file() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step. Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock. Always call nlm_file_release() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlm_file_inuse(), which does a live walk of the inode lock list, rather than the cached f_locks field, so skipped files that never ran nlm_inspect_file() are evaluated correctly. Because every file in a hash bucket is now pinned and released, files skipped by the is_failover_file predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89487", "url": "https://ubuntu.com/security/CVE-2026-89487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: only skb_tx_error() a packet we are about to drop queue_userspace_packet() borrows the packet skb -- it only copies it into a private netlink message (user_skb) and does not own it; on return do_execute_actions() keeps forwarding it through the flow's remaining actions. Its error path nevertheless calls skb_tx_error(skb), which via skb_zcopy_clear() does skb_shinfo(skb)->flags &= ~SKBFL_ALL_ZEROCOPY, stripping SKBFL_SHARED_FRAG from that live skb (skb_tx_error()'s kerneldoc says \"skb must be freed afterwards\"). For a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG is what makes esp_input() skb_cow_data() before in-place AEAD; once it is stripped a later local ESP-in-UDP delivery decrypts in place over pages the sender does not own -- an unprivileged page-cache write (the \"Fragnesia\" primitive). do_execute_actions() ignores output_userspace()'s return value, so any action after a failed USERSPACE upcall inherits the stripped skb. Move the skb_tx_error() to the flow-miss drop path - the \"default\" branch of ovs_dp_process_packet()'s switch(error), before kfree_skb(). The call has been here since commit 36d5fe6a0007 (\"core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors\") but was harmless until esp_input() began relying on SKBFL_SHARED_FRAG to gate in-place decrypt; only then did stripping it on a still-forwarded skb become a page-cache write primitive.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89489", "url": "https://ubuntu.com/security/CVE-2026-89489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openrisc: fix arbitrary kernel memory access via or1k_atomic syscall sys_or1k_atomic() (syscall 244 in the \"or1k\" ABI) takes two user pointers, v1 and v2, and swaps the words they point to in hand-written assembly. l.lwz r29,0(r4) l.lwz r27,0(r5) l.sw 0(r4),r27 l.sw 0(r5),r29 The pointers are not checked with access_ok(). The four memory accesses also have no exception table entries. A caller passes a kernel address as either pointer, and the syscall reads from and writes to it directly. This gives an unprivileged process a kernel read/write primitive. It overwrites kernel data such as the sys_call_table, gaining code execution in kernel context. Check both pointers before entering the critical section. Add fixups for the four memory accesses so faults on valid but unmapped user addresses return -EFAULT. [shorne@gmail.com: fix comment style]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89490", "url": "https://ubuntu.com/security/CVE-2026-89490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix readdir position truncation on 32-bit kernels In ocfs2_dir_foreach_blk_el(), the directory cookie position is rebuilt with \tctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset; `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask \t~(sb->s_blocksize - 1) is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB block size). In the AND expression with the 64-bit `ctx->pos`, that unsigned operand is zero-extended to 64 bits per the usual arithmetic conversions, yielding 0x00000000fffff000. The high 32 bits of `ctx->pos` are silently cleared, even though directory size is allowed to exceed 4 GiB. When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position is reset back into the first 4 GiB block, making the re-validation path re-enumerate already-returned dirents indefinitely. This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken for all non-inline directories, so a directory large enough to cross 4 GiB reaches it. This is the same class of bug that commit 3dce5bb82c97 (\"exfat: Fix bitwise operation having different size\") fixed in exfat, and the fix mirrors the equivalent ext4 fix in this series. Cast the operand to loff_t so the mask is 64-bit before the AND: \tctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89491", "url": "https://ubuntu.com/security/CVE-2026-89491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cluster: don't sleep while holding o2hb_live_lock in o2hb_region_pin() Patch series \"ocfs2: cluster: o2hb_region_pin() fixes\", v2. This series fixes three related issues in o2hb_region_pin(), all are from the original implementation in commit: 58a3158a5d17 (\"ocfs2/cluster: Pin/unpin o2hb regions\"): 1) It is called with o2hb_live_lock (a spinlock) held, but the underlying configfs_depend_item() sleeps (takes inode rwsem and pins the filesystem). This triggers BUG under CONFIG_DEBUG_ATOMIC_SLEEP. 2) When called from the configfs drop_item callback, it creates a lock order inversion: parent inode_lock -> configfs root inode_lock, which can deadlock against subsystem unregistration paths taking root -> parent. 3) If pinning fails partway through o2hb_region_inc_user(), the o2hb_dependent_users counter is leaked and partially-pinned regions are never released, leaving heartbeat regions unprotected on subsequent mounts. Patch 1 reworks o2hb_region_pin() to drop o2hb_live_lock across each sleeping configfs_depend_item() call, using a config_item reference to keep the region alive while unlocked. Patch 2 adds a from_callback parameter to select configfs_depend_item_unlocked() when called from configfs context, avoiding the inode_lock nesting. Patch 3 fixes the error path in o2hb_region_inc_user() to unpin and decrement the counter on failure. This patch (of 3): o2hb_region_pin() is always called with the o2hb_live_lock spinlock held (from o2hb_region_inc_user() and o2hb_heartbeat_group_drop_item()), but it calls o2nm_depend_item() -> configfs_depend_item(), which sleeps: it pins the configfs filesystem and takes the configfs root inode rwsem. Under CONFIG_DEBUG_ATOMIC_SLEEP this triggers: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c in_atomic(): 1, ... name: mount.ocfs2 down_write configfs_depend_item o2hb_region_pin o2hb_region_inc_user o2hb_register_callback dlm_register_domain_handlers ... ocfs2_dlm_init ocfs2_mount_volume ocfs2_fill_super Rework o2hb_region_pin() to pin one region at a time with the lock dropped across the sleeping call: under o2hb_live_lock find the next eligible region and take a config_item reference to keep it alive, drop the lock, call o2nm_depend_item(), then retake the lock and record the pin. The config_item_put() is done with the lock released as well, since o2hb_region_release() also acquires o2hb_live_lock and can sleep. The region list may change while unlocked, so the scan restarts from the top after each pin. Local heartbeat still pins only the matching region; global heartbeat pins all eligible regions. The unpin path is unaffected: configfs_undepend_item() only takes a spinlock and does not sleep.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89493", "url": "https://ubuntu.com/security/CVE-2026-89493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate rl_used against rl_count in refcount block validator ocfs2_find_refcount_rec_in_rl() walks the on-disk refcount record array with: \tfor (; i < le16_to_cpu(rb->rf_records.rl_used); i++) { \t\trec = &rb->rf_records.rl_recs[i]; \t\t... rl_recs[] lives in a single metadata block (4096 bytes on the common configuration), so its real capacity is fixed by ocfs2_refcount_recs_per_rb(sb) (247 records for a 4K block with the 16-byte ocfs2_refcount_rec). rl_used and rl_count are both read directly off disk by ocfs2_validate_refcount_block() and are never checked against that capacity, nor against each other, before any refcount/reflink/CoW operation walks the array. A crafted (or corrupted) refcount block with rl_used == 0xffff makes the loop above walk far past the end of the block, dereferencing rl_recs[i] for i up to 65534. The resulting index is then handed to the sibling ocfs2_insert_refcount_rec(), whose insert-shift does: \tif (index < le16_to_cpu(rf_list->rl_used)) \t\tmemmove(&rf_list->rl_recs[index + 1], \t\t\t&rf_list->rl_recs[index], \t\t\t(le16_to_cpu(rf_list->rl_used) - index) * \t\t\t sizeof(struct ocfs2_refcount_rec)); i.e. a memmove() of up to (0xffff - index) * 16 bytes (~1 MiB) from an offset already past the block. This is reachable from an ordinary reflink (FICLONE) against a crafted/corrupted ocfs2 image: attaching an extent whose cpos sorts past every real record in the leaf forces the lookup to run off the end instead of returning early on a match. The attacker model is local: CAP_SYS_ADMIN mounting a crafted or corrupted ocfs2 image, or a raw write to the block device backing an already-mounted ocfs2 filesystem. ocfs2_validate_refcount_block() already validates the block's ECC, signature, rf_blkno and rf_fs_generation, but never rl_count/rl_used against the block's actual on-disk capacity. This is the same class of gap that ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) already closes for the sibling extent-list header, which checks both the record capacity and the \"used\" bound before any code walks h_list.l_recs[]: \tif (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) { \t\trc = ocfs2_error(...); \t\tgoto bail; \t} \tif (le16_to_cpu(eb->h_list.l_next_free_rec) > \t le16_to_cpu(eb->h_list.l_count)) { \t\trc = ocfs2_error(...); \t\tgoto bail; \t} Add the equivalent pair of checks to ocfs2_validate_refcount_block(): reject a refcount block whose rl_count does not match the fixed per-block capacity returned by ocfs2_refcount_recs_per_rb(), and reject rl_used > rl_count. Both checks are skipped when OCFS2_REFCOUNT_TREE_FL is set, because in that case the same union bytes hold an ocfs2_extent_list (rf_list), not the refcount record list (rf_records) -- that layout is already validated separately by ocfs2_validate_extent_block() when the referenced extent block is read. This mirrors the existing \"!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)\" guard used elsewhere in this file (e.g. ocfs2_get_refcount_rec()) to decide whether rf_records or rf_list is the live member of the union. With this in place, a forged rl_used/rl_count is caught at block validation time (ocfs2_error()), consistent with every other corruption check in this function, instead of driving an out-of-bounds read in ocfs2_find_refcount_rec_in_rl() and a subsequent out-of-bounds memmove() in ocfs2_insert_refcount_rec(). Verified against a crafted image on a v6.19 KASAN (KASAN_GENERIC) build: replaying the same reflink (FICLONE) reliably hit a KASAN report in __ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() before this patch, and triggers no report once ocfs2_validate_refcount_block() rejects the forged rl_used/rl_count.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89494", "url": "https://ubuntu.com/security/CVE-2026-89494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate lengths in dlm_mig_lockres_handler A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres->ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain. Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres->lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len <= DLM_LOCKID_NAME_MAX, num_locks <= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89495", "url": "https://ubuntu.com/security/CVE-2026-89495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: bound namelen in dlm_migrate_request_handler Patch series \"ocfs2/dlm: bound peer-controlled lengths in the o2dlm\". The o2dlm receive handlers trust u8 length and count fields from the wire without bounding them, so a node in a DLM domain can corrupt or panic any other node with a malformed message. Three defects: - dlm_migrate_request_handler() passes migrate->namelen unchecked to dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an o2dlm_mle slab object: a heap out-of-bounds write of up to ~215 attacker-controlled bytes. - dlm_mig_lockres_handler() passes mres->lockname_len unchecked to dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname slab object: a heap out-of-bounds write of up to ~223 bytes. - the same handler trusts mres->num_locks without checking that the message is large enough to hold that many entries, so dlm_process_recovery_data() walks mres->ml[] past the kmalloc(data_len) copy and trips a BUG_ON (an out-of-bounds read ending in a panic). The other o2dlm receive handlers already reject an oversized name; the migration and recovery handlers have omitted it since the DLM was added (see the Fixes tags). Patch 1 bounds namelen; patch 2 validates lockname_len, num_locks, and the payload size. Conforming recovery and migration traffic is unaffected. o2net authenticates peers only by the DLM domain key, so any node that has joined the domain -- including a compromised or malicious member -- can send these messages. There is no local trigger; the attacker must already be a member of the cluster. Each sink was confirmed under KASAN with an out-of-tree module mirroring it exactly -- a kmem_cache/kmalloc of the real destination size, then the same unclamped memcpy/loop: slab-out-of-bounds Write for the two writes, Read for the recovery walk, and a panic. A userspace AddressSanitizer build faults identically under -m32 and -m64. Scrubbed logs are available on request. I reported this privately to security@kernel.org and the ocfs2 maintainers on 2026-06-20; with no response after the standard embargo period I am posting the fix publicly. I have no embargo requirement. This patch (of 2): A node receiving a DLM_MIGRATE_REQUEST message trusts the peer-supplied name length (migrate->namelen) without bounding it. dlm_init_mle() then copies that many bytes into the fixed DLM_LOCKID_NAME_MAX-byte mname[] array of an o2dlm_mle slab object, so a malformed message from a cluster peer overflows the slab object by up to ~215 bytes: a heap out-of-bounds write of attacker-controlled data, reachable by any node in the domain. Reject an oversized name, the way dlm_master_request_handler() and the other o2dlm receive handlers already do; the migration handler omits the check entirely. Conforming messages are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89496", "url": "https://ubuntu.com/security/CVE-2026-89496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: always run deallocs on copy-on-write completion Local fuzzing of 6.12.94 has found the following memory leak caused by doing 'copy_file_range()' within the same filesystem: unreferenced object 0xffff88812192c980 (size 32): comm \"syz.0.49\", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................ c0 c5 92 21 81 88 ff ff 00 02 00 00 00 06 00 00 ...!............ backtrace (crc 7068d63f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] ocfs2_find_per_slot_free_list fs/ocfs2/alloc.c:6618 [inline] ocfs2_cache_block_dealloc+0x155/0x4b0 fs/ocfs2/alloc.c:6786 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:944 [inline] direct_splice_actor+0x232/0x480 fs/splice.c:1167 splice_direct_to_actor+0x4b4/0xb60 fs/splice.c:1111 do_splice_direct_actor fs/splice.c:1210 [inline] do_splice_direct+0x10f/0x1c0 fs/splice.c:1236 do_sendfile+0x430/0xbf0 fs/read_write.c:1388 unreferenced object 0xffff88812192c5c0 (size 32): comm \"syz.0.49\", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 29 70 00 00 00 00 00 00 19 00 00 00 00 00 00 00 )p.............. backtrace (crc afec850f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ocfs2_cache_block_dealloc+0x25c/0x4b0 fs/ocfs2/alloc.c:6793 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:9 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89497", "url": "https://ubuntu.com/security/CVE-2026-89497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: skip leading spaces before parsing client debug masks orangefs_prepare_cdm_array() sizes each client debug keyword buffer with strcspn(cds_head, \" \"), but then parses the keyword with %s. The %s conversion skips leading whitespace, while strcspn() does not. If a client debug entry starts with a space, the allocation can be sized for an empty keyword while sscanf() copies the following non-empty token. This can write past the end of the allocated keyword buffer. Skip leading spaces before computing the keyword length so the allocation matches the string parsed by sscanf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89498", "url": "https://ubuntu.com/security/CVE-2026-89498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix double-free of trailer_buf on readdir copy failure On a readdir downcall, orangefs_devreq_write_iter() frees op->downcall.trailer_buf with vfree() when copy_from_iter_full() fails, but does not clear the pointer before goto Efault. The waiter in do_readdir() is then woken with a negative status and frees the same pointer again on its r < 0 path, causing a deterministic double-free. A client holding /dev/pvfs2-req triggers it by sending a readdir downcall whose declared trailer_size exceeds the bytes it supplies. Clear the pointer after freeing so the readdir-side vfree() becomes a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89504", "url": "https://ubuntu.com/security/CVE-2026-89504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: as3722_get_regulator_dt_data: fix premature of_node_put leaving dangling of_node pointer In as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a reference on np, which is then assigned to pdev->dev.of_node. The function immediately calls of_node_put(np), releasing the reference and leaving pdev->dev.of_node as a dangling pointer. Remove the of_node_put(np) call to let the device hold the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89508", "url": "https://ubuntu.com/security/CVE-2026-89508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Lock the handler in ucma_set_ib_path() ucma_set_ib_path() calls ucma_event_handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference: \tmutex_lock(&ctx->file->mut);\t\t\t/* file A */ \tlist_add_tail(&uevent->list, &ctx->file->event_list);\t/* file B */ \tmutex_unlock(&ctx->file->mut);\t\t\t/* file B */ \twake_up_interruptible(&ctx->file->poll_wait);\t/* file B */ A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION caller sleeps in mutex_lock(), so the list_add_tail() lands on file B's event_list while only file A's mutex is held, racing every other user of that list: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0 Read of size 8 at addr ffff888153c6a418 by task poc_corr/486 Call Trace: __list_add_valid_or_report+0x1aa/0x1c0 ucma_event_handler+0x1be/0xc00 ucma_set_ib_path+0x45e/0x710 ucma_set_option+0x32e/0x590 ucma_write+0x1f9/0x330 Allocated by task 505: ucma_write_cm_event+0x1a1/0x660 Freed by task 505: kfree+0x1da/0x4c0 ucma_get_event+0x5d5/0x7e0 The freed object is a ucma_event that another thread dequeued from file B's list under file B's mutex. File A's mut is left held on top of that, wedging its next writer in uninterruptible sleep. This path needs a bound and address-resolved cm_id, so it requires an RDMA device to be present. Take the handler lock around the call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89510", "url": "https://ubuntu.com/security/CVE-2026-89510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Cancel reg_work before freeing device on remove c4iw_uld_state_change() queues reg_work to register the RDMA device. c4iw_remove() can free ctx->dev while this work is pending or running, leaving c4iw_register_device() accessing the freed device. Cancel reg_work before removing the device. The registration work can tear down ctx->dev when registration fails, so do not unregister or deallocate it again in that case. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89511", "url": "https://ubuntu.com/security/CVE-2026-89511", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: Fix NULL pointer dereference in TPA fragment processing Under memory pressure, the qede driver encounters NULL pointer dereferences when processing TPA continuation fragments. Commit 8a8633978b84 (\"qede: Add build_skb() support.\") accidentally dropped the assignment of tpa_info->buffer.data in qede_tpa_start(). When memory pressure causes an SKB allocation failure in qede_tpa_start(), the driver sets tpa_start_fail = true and attempts to recycle the physical page later in qede_tpa_end() via qede_reuse_page(). However, because buffer.data was left uninitialized (NULL), qede_reuse_page() pushes a \"ghost\" BD (valid DMA mapping but NULL data pointer) back into the active Rx ring. The next time the hardware uses this ring slot, it passes a NULL page to qede_fill_frag_skb(), causing a kernel panic. Example crash from production system: BUG: unable to handle kernel NULL pointer dereference at 0x8 RIP: qede_fill_frag_skb+0x96/0x430 [qede] Call Trace: qede_rx_int+0xb06/0x1de0 qede_poll+0x2f4/0x6c0 __napi_poll+0x2d/0x130 Fix the root cause by restoring the tpa_info->buffer.data assignment in qede_tpa_start(), ensuring valid pages are correctly tracked and recycled. Additionally, update the stale comment for struct qede_agg_info::buffer to reflect its current usage.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89512", "url": "https://ubuntu.com/security/CVE-2026-89512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: scp: Fix device reference leak on failed lookup Make sure to drop the reference taken to the SCP device when attempting to look up its driver data before the driver has been bound. Note that holding a reference to a device does not prevent its driver data from going away.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89524", "url": "https://ubuntu.com/security/CVE-2026-89524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: clamp assoc request/response lengths before subtracting IE offsets ath6kl_cfg80211_connect_event() subtracts fixed IE offsets from assoc_req_len (-= 4) and assoc_resp_len (-= 6), both u8, with no lower bound. The aggregate check recently added to ath6kl_wmi_connect_event_rx() bounds the declared lengths from above (their sum must fit the received event), but an assoc request/response shorter than its fixed offset still underflows here: the u8 wraps to ~250, and cfg80211_connect_result() / cfg80211_roamed() then treat that wrapped value as the IE length and copy that many bytes out of the small assoc_info buffer to user space via nl80211, disclosing adjacent slab memory. Clamp both lengths to their offsets before subtracting. Found by 0sec (https://0sec.ai) using automated source analysis; the missing lower bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89525", "url": "https://ubuntu.com/security/CVE-2026-89525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: reject VAT indexes equal to the entry count UDF 1.50 virtual partition mapping uses the VAT as an array of physical block mappings. s_num_entries stores the number of entries in that array, not the highest valid index. The valid VAT indexes are therefore below s_num_entries. udf_get_pblock_virt15() currently rejects only indexes greater than s_num_entries. A crafted image can request index s_num_entries, pass the bounds check, and make the kernel read one entry past the allocated VAT table. Change the check to reject block >= s_num_entries, so the count is handled as an exclusive upper bound. A crafted UDF image reproduced this on origin/master commit 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53 with a KASAN slab-out-of-bounds report in udf_get_pblock_virt15(). Trail of Bits has a reproducer that triggers kernel panic demonstrating the bug, and can share it if needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89532", "url": "https://ubuntu.com/security/CVE-2026-89532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix pcl_for_each_segment for empty chunks When a parsed chunk list contains a chunk whose ch_segcount is zero, pcl_for_each_segment computes its inclusive upper bound as &chunk->ch_segments[ch_segcount - 1]. ch_segcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the ch_segments flex array. The loop body then walks unrelated memory at sizeof(struct svc_rdma_segment) stride until it faults. A zero-segcount chunk is reachable from the wire: xdr_check_write_chunk() only rejects segcount values greater than rc_maxpages, and pcl_alloc_write() links a freshly allocated chunk onto rc_write_pcl/rc_reply_pcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves ch_segcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svc_rdma_get_inv_rkey() iterates all four PCLs with pcl_for_each_segment and dereferences segment->rs_handle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault. xdr_check_write_list / xdr_check_reply_chunk pcl_alloc_write() chunk = pcl_alloc_chunk(...) /* ch_segcount = 0 */ list_add_tail(&chunk->ch_list, &pcl->cl_chunks) /* fill loop iterates zero times for wire segcount 0 */ svc_rdma_get_inv_rkey() pcl_for_each_chunk(rc_write_pcl) pcl_for_each_segment(segment, chunk) pos <= &ch_segments[0u - 1u] /* 0xFFFFFFFF */ segment->rs_handle /* OOB read -> GPF */ Fix by switching the macro to a half-open upper bound that uses ch_segcount directly. For ch_segcount == 0 the loop start equals the loop end and the body is skipped; for ch_segcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and net/sunrpc/xprtrdma/svc_rdma_rw.c remain correct under the new bound, so no caller changes are needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89533", "url": "https://ubuntu.com/security/CVE-2026-89533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix offset arithmetic in read_chunk_range svc_rdma_read_chunk_range() walks a Read chunk's segment list to build a sub-range starting at byte offset and spanning length bytes for a Position-Zero or Call chunk. Two arithmetic defects in the per-segment loop produce wrong DMA lengths and a u32 underflow: pcl_for_each_segment(segment, chunk) { if (offset > segment->rs_length) { offset -= segment->rs_length; continue; } dummy.rs_handle = segment->rs_handle; dummy.rs_length = min_t(u32, length, segment->rs_length) - offset; dummy.rs_offset = segment->rs_offset + offset; First, the skip predicate uses '>' instead of '>='. When offset equals the segment's full rs_length, the segment is fully consumed and should be skipped, but the loop falls through into the body. The resulting dummy.rs_length is min_t(u32, length, rs_length) - rs_length, which underflows to a near-UINT_MAX u32 when length is smaller than rs_length, or is zero otherwise. Second, the length formula subtracts offset from the min_t() result rather than from segment->rs_length before the cap. For offset > 0 the segment's residual is rs_length - offset, not rs_length, so the cap must be applied to the residual. With the current bracketing, whenever length is smaller than rs_length - offset the per-segment length becomes length - offset instead of length, silently dropping offset bytes from the rebuilt chunk. Combined with the boundary case above it also enables the u32 underflow path, which propagates a huge nr_bvec into svc_rdma_build_read_segment() and a multi-MiB kmalloc_array_node() in svc_rdma_get_rw_ctxt(). Additionally, svc_rdma_read_call_chunk() can invoke this function with length == 0 when the last Read chunk ends exactly at the end of the Call chunk. With the corrected >= predicate, every segment is skipped and the function returns the initial -EINVAL, rejecting a valid request. Return success immediately when length is zero. Also break out of the loop once length is fully consumed to avoid passing zero-length segments to svc_rdma_build_read_segment(). Fix by using '>=' so a fully-consumed segment is skipped, by moving '- offset' inside min_t() so the cap is applied to the segment's residual length, by returning success for zero-length requests, and by stopping iteration when the requested range has been consumed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89538", "url": "https://ubuntu.com/security/CVE-2026-89538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field gss_krb5_unwrap_v2() sets buf->len to a logical length, which can be much smaller than head[0].iov_len (the allocated receive-page capacity). It then calls xdr_buf_trim() with a trim length derived from the 16-bit \"extra count\" (ec) field in the Kerberos v2 token header. The ec field is authenticated by the post-decrypt memcmp() against the encrypted header copy, so a randomly-mutated value is rejected. However, any peer holding a valid GSS context can legitimately encrypt a token whose ec exceeds the plaintext length. Per RFC 4121, such a token is structurally malformed. Although xdr_buf_trim() now clamps the buf->len subtraction to avoid unsigned underflow, the buffer is still left in a semantically invalid state (zero length, inconsistent iov lengths) when ec is oversized. Reject these tokens before calling xdr_buf_trim(), giving callers a well-defined GSS_S_DEFECTIVE_TOKEN error and keeping the xdr_buf internally consistent. The wrapped blob begins at a nonzero offset -- both callers pass len as offset + opaque_len -- so buf->len still counts the offset bytes that precede the blob. Compare the trim length against the remaining wrapped segment, buf->len - offset, rather than the whole buffer; comparing against buf->len alone leaves an offset-wide window in which an oversized ec passes the test and xdr_buf_trim() cuts into the bytes ahead of the blob.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89540", "url": "https://ubuntu.com/security/CVE-2026-89540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: init gssp_lock before publishing proc entry create_use_gss_proxy_proc_entry() publishes /proc/net/rpc/use-gss-proxy via proc_create_data() before init_gssp_clnt() runs mutex_init() on sn->gssp_lock. Once the dentry is linked under proc_subdir_lock it is immediately reachable from userspace, so a write that lands in the window drives set_gssp_clnt() into mutex_lock() on a zero-initialized struct mutex. create_use_gss_proxy_proc_entry(net) proc_create_data(\"use-gss-proxy\", ...) /* dentry live */ init_gssp_clnt(sn) mutex_init(&sn->gssp_lock) /* too late */ write_gssp() set_gssp_clnt(net) mutex_lock(&sn->gssp_lock) /* uninitialized */ gssp_rpc_create(...) sn->gssp_clnt = clnt mutex_unlock(&sn->gssp_lock) The window spans only the two statements between proc_create_data() returning and init_gssp_clnt(), so a writer reaches it only if the registering thread is preempted there while another task is already opening the freshly published file. register_pernet_subsys() runs in preemptible context under pernet_ops_rwsem, so that preemption is possible, and the window widens on auth_rpcgss module load, when the proc entry is created for every live net namespace whose tasks are already running. A writer that wins the race locks a zero-filled struct mutex. On CONFIG_DEBUG_MUTEXES the missing magic value trips a \"lock used without init\" splat; on a production kernel the fast path acquires the lock via CMPXCHG(owner, 0, current). In the latter case a second writer that arrives before init_gssp_clnt() re-zeroes owner can enter set_gssp_clnt() concurrently, shut down the first writer's clnt while it is still in use, and leak the loser's clnt. Fix by initializing sn->gssp_lock in sunrpc_init_net() so its lifetime matches the sunrpc_net it lives in. sn->gssp_clnt is already NULL from the kzalloc that backs net_generic storage, so the lazy helper is no longer needed; drop init_gssp_clnt(), its prototype, and the call from create_use_gss_proxy_proc_entry(). sunrpc.ko is a build-time dependency of auth_rpcgss.ko, so sunrpc_init_net() has always run on every netns before any auth_gss pernet init can publish the proc entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89541", "url": "https://ubuntu.com/security/CVE-2026-89541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_unwrap_resp_priv length checks gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 (\"SUNRPC: svcauth_gss: enforce krb5 token minimum length\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89542", "url": "https://ubuntu.com/security/CVE-2026-89542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_krb5_unwrap_v2 against short tokens gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and ptr+6 before validating that the token is at least GSS_KRB5_TOK_HDR_LEN (16) bytes long, and its rotate_left() helper passes buf->len - base to xdr_buf_subsegment() without verifying that base <= buf->len. When a caller hands in a sub-16-byte token, or a token whose declared len leaves base past the end of the buffer, three distinct failures follow: gss_krb5_unwrap_v2(offset, len, buf) ptr = buf->head[0].iov_base + offset ec = *(ptr + 4) /* OOB read on short head */ rrc = *(ptr + 6) /* OOB read on short head */ rotate_left(offset + 16, buf, rrc) xdr_buf_subsegment(buf, &subbuf, base, buf->len - base) /* u32 wrap when base > len */ _rotate_left(&subbuf, shift) shift %= buf->len /* divide-by-zero when base == len */ After decryption, the cleanup arithmetic has the same shape: movelen = min_t(unsigned int, buf->head[0].iov_len, len); movelen -= offset + GSS_KRB5_TOK_HDR_LEN + headskip; BUG_ON(offset + GSS_KRB5_TOK_HDR_LEN + headskip + movelen > buf->head[0].iov_len); The BUG_ON re-adds the value just subtracted, so it reduces to min(A, B) > A and is permanently false; it cannot catch the unsigned underflow of movelen, which then drives a ~UINT_MAX-byte memmove(). Add four defense-in-depth guards inside the unwrap core so it is safe regardless of what its callers validate: - reject tokens with len - offset < GSS_KRB5_TOK_HDR_LEN before touching ptr+4/ptr+6; - bail from rotate_left() when buf->len <= base, covering both the underflow and zero-length cases; - return early from _rotate_left() when buf->len is zero, so the shift %= buf->len modulo cannot fault; - replace the dead BUG_ON with a live check that returns GSS_S_DEFECTIVE_TOKEN before the movelen subtraction.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89548", "url": "https://ubuntu.com/security/CVE-2026-89548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: always drain cache_cleaner before destroying a cache_detail sunrpc_destroy_cache_detail() only cancels the global cache_cleaner delayed_work when cache_list is empty. During per-netns teardown cache_list is never empty because init_net's caches remain registered, so the cancel never fires. After unlink, the caller proceeds to cache_destroy_net() which kfrees the cache_detail while cache_clean() may still hold a dangling pointer to it. The result is a use-after-free: cache_dequeue() takes cd->queue_lock on freed memory, and cache_put() dereferences cd->cache_put as a function pointer from freed slab. Drop the list_empty guard so that cancel_delayed_work_sync() always runs, ensuring any in-flight cache_clean() completes before the cache_detail is freed. Re-arm the cleaner afterwards if other caches are still registered.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89549", "url": "https://ubuntu.com/security/CVE-2026-89549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: route to a populated pool in svc_pool_for_cpu() svc_set_num_threads() spreads the requested threads evenly across the service's pools (base = nrservs / sv_nrpools). When a service runs fewer threads than it has pools -- e.g. an nfsd configured with fewer threads than the host has NUMA nodes while running in \"pernode\" or \"percpu\" mode -- the trailing pools are left with no threads at all. svc_xprt_enqueue() selects a pool from the CPU servicing the transport, queues the transport on that pool's sp_xprts, and only wakes a thread from the same pool. Each thread services exclusively its own pool, so a transport that lands on a threadless pool is enqueued on sp_xprts and never picked up: the connection hangs indefinitely. Have svc_pool_for_cpu() skip pools that currently have no threads, falling back to the next populated pool. This trades NUMA locality for a guarantee that the work is actually serviced. sp_nrthreads is only updated under the service mutex; the lockless read here is a best-effort routing hint, so annotate it with data_race().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89551", "url": "https://ubuntu.com/security/CVE-2026-89551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow xdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by walking the tail, pages, and head iovecs. Each per-section step uses min_t() so it never removes more bytes than that section holds, but the final accounting at the fix_len label subtracts the total bytes actually consumed from buf->len without any clamp: fix_len: buf->len -= (len - trim); When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches xdr_buf_trim() in exactly that state: buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip; buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip); xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip); buf->len is a small wire-derived value while the iov_lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder. Fix by clamping the decrement so buf->len bottoms out at zero: buf->len -= min_t(unsigned int, buf->len, len - trim); On the normal path where the iov_lens sum to buf->len, (len - trim) is always <= buf->len and the result is identical to before. No callers change behavior outside the underflow case.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89554", "url": "https://ubuntu.com/security/CVE-2026-89554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection. Restore subflow_req->local_id from the cookie entry, as done for the other fields.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89555", "url": "https://ubuntu.com/security/CVE-2026-89555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: reload header after pskb_may_pull() mpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop when an MPLS route has multiple nexthops. While walking the MPLS label stack, the hash routine caches hdr for the current label. After finding the bottom-of-stack label, it calls pskb_may_pull() before reading the inner IP header. If an skb is constructed with the inner IP header in nonlinear data and insufficient tailroom in the linear head, pskb_may_pull() calls pskb_expand_head() to replace the skb head and free the old one. This leaves hdr pointing to freed memory. The IPv6 path can invalidate hdr again when it performs a second pull for the larger header. The issue was found through static analysis. A reproducer sending a legal Geneve packet through a bareudp/MPLS multipath setup triggered the same KASAN report in 2 of 2 unpatched runs: BUG: KASAN: slab-use-after-free in mpls_select_multipath Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23 Call Trace: mpls_select_multipath mpls_forward __netif_receive_skb_list_core netif_receive_skb_list_internal napi_complete_done gro_cell_poll __napi_poll net_rx_action Freed by task 23: kfree pskb_expand_head __pskb_pull_tail mpls_select_multipath Reload hdr from the current skb head after each successful pull before deriving the inner IPv4 or IPv6 header pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89557", "url": "https://ubuntu.com/security/CVE-2026-89557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: do overflow check for sb->bblog_shift in super_1_load() In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 } bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c. Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller. This may avoid unnecessary check, make the badblocks API code more simple and elegant.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89559", "url": "https://ubuntu.com/security/CVE-2026-89559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Prevent integer overflow in __nd_label_validate() The on-media namespace index field nslot is a u32 read from the DIMM label storage area. __nd_label_validate() bounds it against the config area size, but sizeof_namespace_label() returns unsigned, so the product nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before the comparison. A crafted nslot passes the bound and is then used as the loop trip count in nd_label_data_init(), whose memset() walks off the end of the config_size buffer: an out-of-bounds write. The field is not trusted -- it comes from the medium, or from userspace via ND_CMD_SET_CONFIG_DATA. Evaluate the product in 64-bit so the bound check is exact; conforming labels are unaffected. The check was safe when introduced by commit 4a826c83db4e (\"libnvdimm: namespace indices: read and validate\"): it multiplied by sizeof(struct nd_namespace_label), a size_t, so on a 64-bit build the product did not wrap. Commit 564e871aa66f (\"libnvdimm, label: add v1.2 nvdimm label definitions\") narrowed it to 32 bits when the label size became a runtime value read via sizeof_namespace_label().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93226", "url": "https://ubuntu.com/security/CVE-2026-93226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU iterator to dump route exceptions rt6_nh_dump_exceptions() uses hlist_for_each_entry() to iterate over RCU-protected exception lists. The caller holds rcu_read_lock(), but does not hold rt6_exception_lock, so rt6_insert_exception() can concurrently add an entry with hlist_add_head_rcu(). KCSAN reports this race (irrelevant details omitted): ================================================================== BUG: KCSAN: data-race in rt6_insert_exception / rt6_nh_dump_exceptions write (marked) to 0xffff8a7c44c59620 of 8 bytes by interrupt on cpu 5: rt6_insert_exception+0x3bb/0x760 __ip6_rt_update_pmtu+0x4fe/0x750 ip6_sk_update_pmtu+0x19a/0x3b0 udpv6_err+0x3ff/0x800 icmpv6_notify+0x1e1/0x440 icmpv6_rcv+0x8c0/0xab0 ip6_protocol_deliver_rcu+0x616/0x840 ip6_input_finish+0xb9/0x160 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff8a7c44c59620 of 8 bytes by task 549 on cpu 14: rt6_nh_dump_exceptions+0xb3/0x260 rt6_dump_route+0x53e/0x5f0 fib6_dump_node+0x6d/0xf0 fib6_walk_continue+0x290/0x2d0 fib6_dump_table+0x28d/0x360 inet6_dump_fib+0x37d/0x620 rtnl_dumpit+0x7b/0xd0 netlink_dump+0x3ae/0x7e0 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f 4 locks held by dumper/549: ... #1: (rcu_read_lock){....}-{1:3}, at: inet6_dump_fib+0x88/0x620 #2: (&tb->tb6_lock){+.-.}-{3:3}, at: fib6_dump_table+0x1e9/0x360 #3: (rcu_read_lock){....}-{1:3}, at: rt6_dump_route+0x483/0x5f0 value changed: 0xffff8a7c44e05700 -> 0xffff8a7c45d60100 Reported by Kernel Concurrency Sanitizer on: CPU: 14 UID: 0 PID: 549 Comm: dumper Not tainted 7.2.0-rc7-virtme #38 PREEMPT(lazy) ... Use hlist_for_each_entry_rcu() to safely iterate over the exception list.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89562", "url": "https://ubuntu.com/security/CVE-2026-89562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: fix hardware header length for NBMA tunnels ip6gre_tnl_link_config_route() accumulates the lower device's hardware header length into dev->hard_header_len whenever header_ops is set. This is incorrect for both users of header_ops. ip6gretap and ip6erspan have a fixed Ethernet hardware header length. For an NBMA ip6gre tunnel, ip6gre_header() creates only the GRE header, the optional FOU or GUE header, and the outer IPv6 header. The lower device header is headroom needed later, not part of the tunnel device's hardware header. Keep the lower device header in needed_headroom. Set hard_header_len to the tunnel header length only for ARPHRD_IP6GRE devices with header_ops, and leave the fixed Ethernet header length unchanged for tap and erspan devices.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89563", "url": "https://ubuntu.com/security/CVE-2026-89563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit() ip6_tnl_xmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skb_realloc_headroom(), copies skb->sk ownership, consumes the original skb, and then continues processing with the replacement skb kept only in its local variable. That is safe only if the helper cannot fail afterwards. But this helper still has post-reallocation error exits. collect_md tunnels reject non-NONE encap after the replacement, and ip6_tnl_encap() can also fail later. In those cases the helper returns an error to its callers while the caller still only has the original skb pointer. Both ip6_tnl_start_xmit() and the IPv6 GRE paths free the caller skb on error, so they can end up freeing an skb that ip6_tnl_xmit() already consumed. Use skb_cow_head() instead. It provides the required headroom and writability without privately replacing the caller-owned skb, so later error returns cannot leave callers with a stale pointer. The Ethernet users, ip6gretap and ip6erspan, clear IFF_TX_SKB_SHARING and already call skb_cow_head() before entering ip6_tnl_xmit(). They do not rely on the removed skb_shared() reallocation. This also makes the IPv6 tunnel path consistent with ip_tunnel_xmit().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89569", "url": "https://ubuntu.com/security/CVE-2026-89569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: serialize security confirmation handling rfcomm_security_cfm() looks up a session on session_list and then walks its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown uses rfcomm_mutex, krfcommd can close and free the same session and DLCs concurrently: hci_rx_work krfcommd ----------- --------- rfcomm_session_get() rfcomm_lock() rfcomm_session_close() rfcomm_dlc_unlink() rfcomm_session_del() kfree(s) rfcomm_unlock() walk s->dlcs The callback can then read a freed session list head and touch freed DLCs while updating their flags or timers. Serialize the session lookup and DLC traversal in rfcomm_security_cfm() with rfcomm_mutex. This matches the existing RFCOMM session lifetime rules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink() from tearing the objects down while the callback is using them. KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440 Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89 Workqueue: hci0 hci_rx_work Call Trace: rfcomm_security_cfm+0x41c/0x440 hci_encrypt_cfm+0x139/0x590 hci_encrypt_change_evt+0x37b/0xc40 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 69: rfcomm_session_add+0x9e/0x2f0 rfcomm_run+0x44b/0x41e0 Freed by task 69: kfree+0x131/0x3c0 rfcomm_session_del+0x188/0x220 rfcomm_run+0x1985/0x41e0", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89573", "url": "https://ubuntu.com/security/CVE-2026-89573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm array: reject an array block whose value size is not the caller's array_block_check() can only compare the header against itself, so a block with value_size 4 and max_entries 1018 is internally consistent and passes. dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and the roots for both live in the superblock. Point the mappings root at a hint block and __load_mappings() walks it through an info whose value size is 8, so element_at() strides 8 bytes over 4-byte entries and reaches offset 8160 of a 4096-byte block. get_ablock() and __shadow_ablock() are the two places that hold the block and the caller at once. Reject there when the two value sizes disagree. Arrays only ever read their own blocks, so this fires on crafted metadata only.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89575", "url": "https://ubuntu.com/security/CVE-2026-89575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm raid1: reserve space for NUL-terminator in build_constructor_string() Reserve space for the termination NUL after the maximum 20 decimal digits of a long long value to avoid buffer overflow in sprintf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89576", "url": "https://ubuntu.com/security/CVE-2026-89576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-era: fix shadowed superblock leak on take-snap failure metadata_take_snap() bumps the live superblock refcount and then dm_tm_shadow_block() allocates a new block for the metadata snapshot. If the subsequent dm_sm_inc_block() of writeset_tree_root or era_array_root fails, the function only unlocks the clone and returns. The newly allocated shadow block is never returned to the metadata space map, so each failed take-snap permanently leaks one metadata block. Free the clone with dm_sm_dec_block() on those error paths, matching the final step of metadata_drop_snap().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89582", "url": "https://ubuntu.com/security/CVE-2026-89582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix double free in bnx2x_init_firmware() error path bnx2x_init_firmware() frees bp->init_ops, bp->init_data and bp->init_ops_offsets in its error path without setting them to NULL. The cleanup function bnx2x_release_firmware() frees the same three pointers unconditionally, so if init_firmware fails and release_firmware is later called (e.g. from __bnx2x_remove or through the function state machine), all three are freed a second time. Set each pointer to NULL after kfree() in the error path so that the subsequent kfree(NULL) in bnx2x_release_firmware() is a safe no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89585", "url": "https://ubuntu.com/security/CVE-2026-89585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: auxdisplay: charlcd: cancel backlight work on registration failure With CONFIG_CHARLCD_BL_FLASH, charlcd_init() schedules bl_work before charlcd_register() calls misc_register(). If registration fails, the caller frees the charlcd object while delayed work still contains its address. Add charlcd_deinit() to cancel the delayed work and turn the backlight off. Use it for both registration rollback and normal unregistration.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89586", "url": "https://ubuntu.com/security/CVE-2026-89586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes ata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the UNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command. The TRIM descriptor is built by ata_format_dsm_trim_descr() into the 2048-byte ata_scsi_rbuf staging buffer, and the number of bytes copied is compared against the logical sector size by the caller: \tsize = ata_format_dsm_trim_descr(scmd, trmax, block, n_block); \tif (size != len)\t\t/* len == sdp->sector_size */ \t\tgoto invalid_param_len; ata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE (2048). On a device whose logical sector size exceeds that (e.g. a 4Kn device, where sector_size == 4096) the function can never return more than 2048, while the caller expects it to return sector_size. The comparison therefore always fails, so every TRIM is rejected with \"Parameter list length error\" and WARN_ON() splats on each attempt. TRIM / discard is thus completely broken on such devices. The descriptor was incorrectly sized from the logical sector size. A DSM TRIM payload is a list of 512-byte pages, each holding up to ATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical sector size. The Block Limits VPD page already advertises a single such page as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical blocks), so the block layer never sends a request that needs more than one page. Emit exactly one 512-byte page, independent of the logical sector size, and transfer only that page (COUNT == 1). For a 512-byte-sector device this is unchanged; devices with larger logical sectors now work instead of failing every TRIM.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89594", "url": "https://ubuntu.com/security/CVE-2026-89594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device The OMAP SSI driver uses a synthetic HSI controller device allocated via hsi_alloc_controller(), which does not go through the normal OF/platform device initialization path. As a result, the embedded struct device does not have a DMA mask initialized by default. After recent DMA API hardening changes, dma_map_sg() and related helpers now require a valid dma_mask to be present, otherwise the driver may crash or trigger warnings when attempting DMA mapping operations. Fix this by explicitly initializing the DMA mask for the SSI controller device and setting a 32-bit DMA mask, which matches the hardware capabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89596", "url": "https://ubuntu.com/security/CVE-2026-89596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix off-by-one when saving/restoring non-PCI config space nv_suspend() and nv_resume() walk the non-PCI configuration space with \tfor (i = 0; i <= np->register_size/sizeof(u32); i++) which runs one iteration too many. saved_config_space is declared as \tu32 saved_config_space[NV_PCI_REGSZ_MAX/4]; and NV_PCI_REGSZ_VER3 is equal to NV_PCI_REGSZ_MAX (0x604), so on a VER3 device register_size/sizeof(u32) is exactly the array length and the last iteration addresses one element past the end. The element it lands on is np->name_rx[0..3]: saved_config_space[] is followed immediately by char name_rx[IFNAMSIZ + 3], and char needs no padding. Nothing observable is corrupted by that, because nv_request_irq() rewrites name_rx with sprintf() before it is ever passed to request_irq(). The bug is the out-of-bounds access itself, which UBSAN reports and which CONFIG_UBSAN_TRAP=y turns into a trap that aborts the running kernel code, plus an MMIO read and, on resume, an MMIO writel() to base + 0x604, one dword past the range the driver mapped: \tnp->base = ioremap(addr, np->register_size); VER1 and VER2 devices stay inside the array, but they too get the stray read and the stray write one dword past their own window. Caught by UBSAN on an Apple Macmini3,1 (MCP79) during a deep S3 cycle. The splat below is trimmed: the build path in the file name, the CPU and taint lines, the Workqueue line, the \"?\" hint frames, and the frames below device_suspend are all cut. The kernel was tainted, with an out-of-tree nouveau and CPU_OUT_OF_SPEC; forcedeth itself was the stock module. UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c:6225:25 index 385 is out of range for type 'u32 [385]' Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... Both loops are hit. UBSAN reports each source location only once per module load (__ubsan_handle_out_of_bounds() calls suppress_report(), which does test_and_set_bit(REPORTED_BIT, ...) on the struct source_location), so the two splats land in the first S3 cycle after the module is loaded and later cycles are silent even though the access still runs off the end every time. In that first cycle line 6225 is reported from pci_pm_suspend and line 6240 from pci_pm_resume. The same off-by-one was fixed in nv_get_regs() by commit ba9aa134287f (\"forcedeth: fix buffer overflow\") in 2012; these two loops were missed. The suspend and resume side was reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix, but the patch was attached rather than sent inline and the thread ended there. Use < instead of <=, which saves and restores exactly register_size bytes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89597", "url": "https://ubuntu.com/security/CVE-2026-89597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: unregister connector callback on init failure uvesafb_init() registers the v86d connector callback before registering the platform driver. If platform_driver_register() fails, the function returns the error directly and leaves the connector callback registered. The later platform-device failure path already unregisters the callback. Add the same cleanup before the final return when platform-driver registration fails. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89599", "url": "https://ubuntu.com/security/CVE-2026-89599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: panel-dsi-cm: initialize lock before registering display dsicm_probe() registers the display before initializing ddata->lock. Once omapdss_register_display() publishes the display, another consumer can reach a dsicm callback that takes this mutex while it is still uninitialized. Initialize the mutex before registering the display so the published callbacks always see a valid lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89605", "url": "https://ubuntu.com/security/CVE-2026-89605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: release message context on send failure ecryptfs_send_message_locked() moves a message context from the free list to the allocated list before sending the request to the userspace daemon. If ecryptfs_send_miscdev() fails, the context is left on the allocated list and cannot be reused. Move it back to the free list on failure and clear the caller's pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89606", "url": "https://ubuntu.com/security/CVE-2026-89606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject too-small tag 70 packets ecryptfs_parse_tag_70_packet() subtracts fixed metadata fields from the parsed packet body size to derive the encrypted filename size. A malformed packet with a body smaller than those fixed fields can underflow that size calculation. Reject tag 70 packets before the subtraction unless the body contains the signature, cipher code, and at least one byte of encrypted filename data.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89607", "url": "https://ubuntu.com/security/CVE-2026-89607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key() sets decrypted_key_size = encrypted_key_size and performs two out-of-bounds writes: 1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into decrypted_key[64] via scatterlist, overflowing into the parent ecryptfs_auth_tok struct. 2. memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes into crypt_stat->key[64], corrupting root_iv, keysig_list, and mutexes in ecryptfs_crypt_stat. Only AES-192 (cipher code 0x08) enables this because it sets crypt_stat->key_size = 24 independently of encrypted_key_size, allowing crypto_skcipher_setkey() to succeed while encrypted_key_size exceeds ECRYPTFS_MAX_KEY_BYTES. The PKI decryption path (parse_tag_65_packet) already validates decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path omits this check. Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also protects the 512-byte encrypted_key[] buffer, so the former 512-byte check is removed as redundant. [tyhicks: Adjust the code comment to refer to macros representing the buffer sizes rather than mentioning the buffer size values since they may change in the future]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89608", "url": "https://ubuntu.com/security/CVE-2026-89608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: pass packet set buffer size to parser ecryptfs_parse_packet_set() receives a pointer into the file header, but it calculates the remaining packet buffer size from PAGE_SIZE - 8. For version 1 headers the packet set starts later in the header, so this can overstate the available buffer. Pass the actual packet set buffer length from the caller and calculate per-packet limits from the remaining bytes in that buffer. Recompute the remaining length after consuming a tag 3 packet before parsing the following tag 11 packet.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89609", "url": "https://ubuntu.com/security/CVE-2026-89609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: hold msg ctx list lock when cleaning daemon queue ecryptfs_exorcise_daemon() drops queued messages from a dying daemon without holding ecryptfs_msg_ctx_lists_mux, but ecryptfs_msg_ctx_alloc_to_free() requires that lock. Take the list lock while moving the queued contexts back to the free list to avoid racing with other global msg ctx list users.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89615", "url": "https://ubuntu.com/security/CVE-2026-89615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound page_lcns[] index by the log record The copy_lcns loop and the redo shorten loop index page_lcns[] at j + i, where i runs up to the log record's lcns_follow. That count is checked only against the record's own length, not the target entry, so check_dp_table() (which validates the entry's lcns_follow) does not cover it: the copy_lcns entry may even be freshly allocated after that check, and find_dp() bounds j but not i. A crafted record thus overflows page_lcns[] of an otherwise valid entry. Add dp_range_ok() and reject, before each loop, any record whose run does not fit the entry. These are the only two page_lcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded. [almaz.alexandrovich@paragon-software.com: original patch contained changes to the problem already handled, applied partly]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89616", "url": "https://ubuntu.com/security/CVE-2026-89616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame() ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target pages and then trusts decompress_lznt()'s return value: unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem, frame_size); if ((ssize_t)unc_size < 0) err = unc_size; else if (!unc_size || unc_size > frame_size) err = -EINVAL; decompress_lznt() stops as soon as the compressed stream is exhausted (e.g. a zero chunk header) and returns the number of bytes it actually wrote, which may be far less than frame_size. The bytes between unc_size and frame_size are never written. The only memset() that follows zeroes the region beyond i_valid; when the frame lies entirely within the file's valid size that memset() does not run, so the gap retains whatever was in the just-vmapped pages. All pages are then marked uptodate and returned to userspace, disclosing uninitialized (recently-freed) kernel page memory. A crafted compressed file whose stream decompresses to only a few bytes leaks the remainder of every frame on a plain read(2), which is enough to recover kernel pointers and defeat KASLR. Zero the [unc_size, frame_size) tail immediately after a successful LZNT decompress so the remainder reads back as zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89617", "url": "https://ubuntu.com/security/CVE-2026-89617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate dirty page table on log replay Each DIR_PAGE_ENTRY ends in a page_lcns[] array whose length is the on-disk lcns_follow field. check_rstbl() validates the table bookkeeping but never checks that this array fits in the entry, so a crafted lcns_follow lets the v0->v1 conversion memmove and later replay passes run off the entry. Add check_dp_table() to reject, right after check_rstbl(), any entry larger than its size claims via struct_size() (the same expression used to allocate these entries, so the check is overflow-safe by construction). All consumers can then trust lcns_follow as the real capacity. This covers every page_lcns[] access whose index is bounded by the entry itself (the conversion memmove, the HotFix store via find_dp(), and the self-bounded scan loops). Accesses whose index comes from the log record need a separate bound and are handled in a follow-up patch.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89621", "url": "https://ubuntu.com/security/CVE-2026-89621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: mcp2221: validate report size in mcp2221_raw_event() mcp2221_raw_event() never validates the size of incoming HID reports. In the MCP2221_I2C_GET_DATA path it trusts the device-supplied data[3] as the copy length without checking that 4 + data[3] bytes actually exist in the received report. A malicious or misbehaving USB device can send a short report with a large data[3], causing the memcpy to read past the valid report data in the HID transfer buffer and leak uninitialized kernel memory back to userspace through the I2C/SMBus read path. Add a minimum size check at entry and validate that the source range fits within the received report before the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89626", "url": "https://ubuntu.com/security/CVE-2026-89626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix field sysfs group cleanup on failure hid_sensor_custom_add_attributes() creates one sysfs group for each custom sensor field. If sysfs_create_group() fails after some groups have already been created, the function returns the error without removing the previously created groups. Add a local unwind path to remove the groups that were already created. With enable_sensor exposed only after the field attributes are ready, this path can free sensor_inst->fields without leaving enable_sensor able to access pointers into that array.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89627", "url": "https://ubuntu.com/security/CVE-2026-89627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: free buffered reports when destroying device roccat_report_event() duplicates each report with kmemdup() and stores the allocation in a circular-buffer slot. The allocation is released only when that slot is reused. The device destruction paths free struct roccat_device without releasing reports still stored in cbuf[]. This makes those allocations unreachable and leaks up to ROCCAT_CBUF_SIZE report buffers per device. Add a small destructor that frees every buffered report before freeing the device, and use it in both paths that can destroy a registered device.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89628", "url": "https://ubuntu.com/security/CVE-2026-89628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: picolcd: clamp eeprom debugfs read to bytes actually received picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte supplied by the device in its REPORT_EE_DATA reply -- clamped only to the caller's read() count: \tret = resp->raw_data[2]; \tif (ret > s) \t\tret = s; \tif (copy_to_user(u, resp->raw_data+3, ret)) It never checks resp->raw_size, the number of bytes picolcd_raw_event() actually copied into the 64-byte raw_data[] of the kmalloc'd struct picolcd_pending. A device (or a spoofed picoLCD) returning a length byte of 0xff, read with a count >= 255, makes copy_to_user() read past raw_data[] into adjacent slab memory and return it to userspace through the debugfs \"eeprom\" file: \tBUG: KASAN: slab-out-of-bounds in _copy_to_user \tRead of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd] The debug-dump path in the same file already validates the device length byte against the received size before trusting it; this read does not. The file is created S_IRUSR (root-only) and a crafted device is needed, so it is neither unprivileged- nor remotely-triggerable. Clamp the copy length to resp->raw_size - 3 (the payload actually received, minus the 3-byte header), floored at 0 for short replies.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89643", "url": "https://ubuntu.com/security/CVE-2026-89643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: avoid dropping live tree ref on fsnotify rule autoremove audit_del_rule() is used for both netlink deletion templates and internal fsnotify autoremove. The former passes a parsed template which owns a temporary tree reference; the latter passes the installed entry itself. The unconditional audit_put_tree() at the end of audit_del_rule() assumes the template case. For mixed AUDIT_DIR plus AUDIT_EXE rules, an fsnotify autoremove event therefore drops the installed rule's live tree reference. Repeating this across rules sharing the same tree can free the tree while another rule still references it, and a later autoremove dereferences the freed pathname while comparing rules. Move the temporary-tree put to audit_rule_change(), the caller that owns deletion templates. Keep it in the AUDIT_DEL_RULE cleanup so both successful deletion and -ENOENT still release the parser-owned tree. [PM: dropped unnecessary comment for line length reasons]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89649", "url": "https://ubuntu.com/security/CVE-2026-89649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound xattr value length in __build_xattrs() __build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare \"p += len\" and no ceph_decode_need() check that \"len\" bytes remain in the blob. For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob. The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space. Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89650", "url": "https://ubuntu.com/security/CVE-2026-89650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound num_export_targets array for mds info v2/v3 ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from each per-mds info record and advances the decode cursor by num_export_targets * sizeof(u32) without first checking that many bytes remain. The only upper-bound check that catches a runaway cursor (*p > info_end) is gated on info_v >= 4, because info_end is left NULL for info_v 2 and 3. When the monitor sends an MDS map whose per-mds info version is 2 or 3 with an oversized num_export_targets, the cursor moves past the message front buffer and the later export-targets loop calls the unchecked ceph_decode_32() on out-of-bounds memory. A kernel client processes CEPH_MSG_MDS_MAP from its monitor session (net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an on-path attacker on an unsigned/unencrypted messenger session, can therefore drive an out-of-bounds read in the client kernel; on x86_64 with KASAN it is reported as a slab-out-of-bounds read in ceph_mdsmap_decode(). The decoded values land in the internal info->export_targets[] array, so the consequence is a kernel out-of-bounds read, not an information leak to the attacker. Impact: a malicious or compromised Ceph monitor sending an MDS map with a per-mds info version of 2 or 3 and an oversized num_export_targets field triggers an out-of-bounds read in the CephFS client kernel. Add a ceph_decode_need() for the export-targets array before advancing the cursor, so the bound is enforced for every info_v >= 2, not only info_v >= 4. This mirrors the count-then-need idiom already used for m_data_pg_pools later in the same function. Compute the export-targets byte count with size_mul() and reuse that checked length when advancing the cursor, so the attacker-controlled num_export_targets multiplication fails closed on overflow rather than relying on the later kcalloc() guard.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89653", "url": "https://ubuntu.com/security/CVE-2026-89653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode MDSMap export_targets entries are monitor controlled. check_new_map() uses each entry as a bit number in a fixed stack bitmap, so a rank outside the protocol namespace can make set_bit() write past the end of the array. Reject ranks outside CEPH_MAX_MDS while decoding the map. Do not validate against possible_max_rank here because maps may legitimately reference ranks beyond a temporarily reduced max_mds.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89655", "url": "https://ubuntu.com/security/CVE-2026-89655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock list_for_each_entry() iterates ci->i_cap_flush_list but drops i_ceph_lock to send cap messages. During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid <= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock. When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next on freed memory. The race timeline: __kick_flushing_caps() handle_cap_flush_ack() ----------------------- ----------------------- holds i_ceph_lock <--- iterates to cf (tid=10) prepares FLUSH message drops i_ceph_lock <--- __send_cap() ── FLUSH(tid=10) \t MDS sends FLUSH_ACK(tid=10) ---> acquires i_ceph_lock cf->tid(10) <= flush_tid(10), detaches cf from i_cap_flush_list drops i_ceph_lock ceph_free_cap_flush(cf) <- frees it! acquires i_ceph_lock <--- for-loop advances: cf = list_next_entry(cf, i_list) -- UAF on freed cf->i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS may respond with FLUSH_ACK quickly enough that handle_cap_flush_ack() frees cf before __kick_flushing_caps can finish the iteration. Fix by converting to a manual while loop: save the next pointer under i_ceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89656", "url": "https://ubuntu.com/security/CVE-2026-89656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject buckets with mismatched CRUSH ids crush_decode() stores bucket data by array slot, and the mapper later derives the per-bucket workspace index from the decoded bucket id. A malformed map can therefore make one bucket reuse another bucket's workspace by encoding an id different from -1 - slot. For uniform buckets, the second replica selection expands the source bucket's permutation into that aliased workspace buffer. If the source bucket is larger than the aliased bucket, the write runs past the smaller permutation array and can escape the kvmalloc'd CRUSH workspace. KASAN reports a slab OOB write of 4 bytes in bucket_perm_choose(). Reject buckets whose encoded id does not match their array slot. Valid CRUSH maps already use the canonical negative id corresponding to the bucket slot, so this restores the invariant expected by work->work[-1 - in->id] without changing valid map behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89662", "url": "https://ubuntu.com/security/CVE-2026-89662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent lock owner use-after-free during client teardown __destroy_client() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on cl_ownerstr_hashtbl. client_has_state() does not count a bare owner, so DESTROY_CLIENTID can reach __destroy_client() with such owners present. __destroy_client() then walks the table, calling remove_blocked_locks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flc_owner. The per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently of client state. The two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks(). nfsd4_release_lockowner() holds a reference across the same call; __destroy_client() does not. Hold cl_lock across the walk, taking a reference and unhashing each owner, then drop it before remove_blocked_locks() and nfs4_put_stateowner(), which take blocked_locks_lock and cl_lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89663", "url": "https://ubuntu.com/security/CVE-2026-89663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: revoke copy-notify stateids before dropping their reference Copy-notify stateids live in the s2s_cp_stateids IDR and on their parent stid's sc_cp_list, pinned by a single membership reference. _free_cpntf_state_locked() only unlinks an entry once its refcount reaches zero, so any revoke path that runs while a concurrent find_cpntf_state()/manage_cpntf_state() holder has elevated cs_count drops the reference without unlinking, leaving the entry discoverable with its membership reference already consumed. A second revoke or a laundromat tick then frees it while the reader still holds the pointer -- a KASAN-detectable use-after-free at the reader's nfs4_put_cpntf_state(). This affected all three revoke paths: - The parent-stid drain (nfs4_free_cpntf_statelist()) repeatedly called _free_cpntf_state_locked() on the first list entry; a holder that had bumped cs_count made it return early, so the next iteration re-decremented and burned the holder's reference. - OFFLOAD_CANCEL (manage_cpntf_state()) and laundromat expiry likewise used _free_cpntf_state_locked() and could drop 2->1 without unlinking. Add revoke_cpntf_state_locked(), which unhashes the entry from the IDR and sc_cp_list first (deferring the final free to any holder), and use it from all three revoke paths. The drain now walks with list_for_each_entry_safe() and revokes each entry unconditionally, so it terminates in one pass per entry regardless of cs_count. The unhash is gated on !list_empty(&cps->cp_list); the idr_remove() gate matters because idr_alloc_cyclic() may have recycled the so_id by then. Keep _free_cpntf_state_locked() for the reference-holder put path only, where a concurrent revoke may already have unlinked the entry (its list_del_init() then a no-op).", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89665", "url": "https://ubuntu.com/security/CVE-2026-89665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE The NFSv2 sattr decoder converts the wire useconds to nanoseconds in svcxdr_decode_sattr(): \tiap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC; tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds value such as 4294968 wraps to tv_nsec == 704. The corruption therefore happens during decode, before any proc function can inspect the value, and a later range check on tv_nsec would see an in-range result and accept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply. NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return for a malformed time argument, and the check cannot move to the proc function the way the v3/v4 nsec range checks do. Guard the raw useconds before the multiplication and reject values greater than 1000000. useconds == 1000000 is kept: it is the Sun convention for \"set to the current server time\", and the in-tree Linux NFSv2 client emits it in both the atime and the mtime field for a plain touch / utimes(file, NULL) (see encode_sattr() and xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000 would turn that common operation into a hard decode failure for both SETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap on ILP32, so the Sun convention value passes through safely. Only genuinely out-of-range values (> 1000000) are rejected. The atime and mtime guards are therefore symmetric. The decoder only applied the Sun convention in the mtime block, which clears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a client puts 1000000 in the atime field but not in the mtime field, the atime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET set, so the bogus value reached the filesystem. Apply the convention in the atime block as well, clearing ATTR_ATIME_SET so the server uses its current time and ignores the value. Only ATTR_ATIME_SET is cleared there. The mtime block keeps its existing behavior, where 1000000 means \"set both atime and mtime to now\". [ cel: various tweaks, addenda, and clean-ups ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89669", "url": "https://ubuntu.com/security/CVE-2026-89669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: initialize copy-notify stateid before publishing it nfsd4_copy_notify() finished initializing the cpntf state after nfs4_alloc_init_cpntf_state() had already linked it into the s2s_cp_stateids IDR and the parent's sc_cp_list, with cs_count == 1 (the membership reference) and none held for the caller. A racing OFFLOAD_CANCEL (crafted cl_id == nn->s2s_cp_cl_id plus the guessable so_id) could reach manage_cpntf_state() and free the entry, turning the caller's subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid writes into use-after-free. The owning clientid was also only recorded after publication, so it could not gate an ownership check in that window. Record cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state() before nfs4_init_cp_state() publishes the entry, and return it with an extra reference. The caller reads the stateid under that reference and drops it with nfs4_put_cpntf_state(); on a late error the laundromat reaps the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89673", "url": "https://ubuntu.com/security/CVE-2026-89673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo nfsd4_ff_encode_getdeviceinfo() computes the da_addr_body reservation as 16 + netid_len + addr_len, but the subsequent xdr_encode_opaque() calls emit 8 + round_up(netid_len, 4) + round_up(addr_len, 4) bytes. The mismatch means the declared da_addr_body length exceeds the actual encoded data by 2-8 bytes on every flexfile GETDEVICEINFO reply, leaking stale reply-page content to the client and mis-aligning the subsequent version list decode. Use xdr_align_size() for each string length to match what xdr_encode_opaque() actually writes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89674", "url": "https://ubuntu.com/security/CVE-2026-89674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client: - fh_len doesn't account for XDR padding on the file handle data - uid and gid lengths use \"8 + len\" but xdr_encode_opaque() actually writes \"4 + xdr_align_size(len)\" bytes - ds_len omits the flags and stats_collect_hint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client. Fix this by breaking out every encoded field explicitly in the ds_len calculation, using xdr_align_size() for all variable-length opaque fields, and correcting the header constants.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89684", "url": "https://ubuntu.com/security/CVE-2026-89684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix cpntf publish race in nfs4_init_cp_state nfs4_alloc_init_cpntf_state() published the new cpntf entry into the s2s_cp_stateids IDR (with cs_type set) in one s2s_cp_lock section, then took the lock again to list_add() it onto p_stid->sc_cp_list. In the gap the entry is reachable by so_id but cp_list is still {NULL,NULL} from kzalloc. A racing OFFLOAD_CANCEL (so_id is echoed to the client as cnr_stateid, so any NFSv4.2 client can drive it) reaches manage_cpntf_state() -> _free_cpntf_state_locked() and does list_del() on the zeroed list_head, oopsing the server. Fold the cs_type assignment and the list_add() into the same critical section as idr_alloc_cyclic(), so a concurrent lookup either misses the entry or sees a fully linked cp_list. INIT_LIST_HEAD() the entry after allocation and switch _free_cpntf_state_locked() to list_del_init() so a stale unlink is a no-op. nfs4_init_copy_state() passes NULL p_stid and skips the list_add, preserving NFS4_COPY_STID semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89694", "url": "https://ubuntu.com/security/CVE-2026-89694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: check client ownership when cancelling a copy-notify stateid On the OFFLOAD_CANCEL path (clp != NULL), manage_cpntf_state() freed the target cpntf state without checking ownership. The lookup key st->si_opaque.so_id is allocated cyclically (guessable) and the embedded clientid is the fixed per-net nn->s2s_cp_cl_id, so any authenticated NFSv4.2 client could cancel and free another client's copy-notify stateid. Compare the creating clientid recorded in state->cp_p_clid against the requesting client's cl_clientid and return nfserr_bad_stateid on a mismatch instead of freeing the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89696", "url": "https://ubuntu.com/security/CVE-2026-89696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref When CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return success with fh_dentry and fh_export both NULL if fh_verify() returns nfserr_stale and putfh->no_verify is true. The NFSD4_FH_FOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserr_nofilehandle check -- it does not prevent subsequent ops from running with a NULL fh_dentry. A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes check_if_stalefh_allowed() to set no_verify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fh_want_write() which dereferences fh_export->ex_path.mnt without calling fh_verify() first, causing a NULL pointer dereference in the nfsd kthread. Fix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set and fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow) and ops with ALLOWED_WITHOUT_FH (which don't need a resolved filehandle) may proceed. All other ops receive nfserr_stale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERR_STALE returned at that point.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89697", "url": "https://ubuntu.com/security/CVE-2026-89697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: add fh_want_write() for early-verified SETATTR in nfsd_proc_setattr() The BOTH_TIME_SET branch calls fh_verify() early so setattr_prepare() can inspect the dentry. This causes nfsd_setattr() to skip fh_want_write(), so notify_change() runs without a mount write reference. Add the missing fh_want_write() call after the early fh_verify().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89699", "url": "https://ubuntu.com/security/CVE-2026-89699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: validate symlink target length in NFSv4 CREATE nfsd4_decode_create() accepts an unbounded cr_datalen from the wire for NF4LNK symlink targets, allowing a client to force a kmalloc of up to the maximum RPC payload size (several MiB) per COMPOUND op that persists until compound teardown. The VFS rejects oversized targets with ENAMETOOLONG, but the allocation has already occurred. Reject cr_datalen == 0 early with nfserr_inval and cr_datalen greater than NFS4_MAXPATHLEN (PATH_MAX) with nfserr_nametoolong to bound the allocation.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89704", "url": "https://ubuntu.com/security/CVE-2026-89704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: sample writeback error cursor before async COPY loop _nfsd_copy_file_range() samples dst->f_wb_err into \"since\" after the copy loop, then uses it to detect writeback errors via filemap_check_wb_err() once vfs_fsync_range() returns. Because the nfsd_file cache reuses a single struct file across requests targeting the same inode, a concurrent COMMIT or stable WRITE on dst advances dst->f_wb_err to the current mapping->wb_err via file_check_and_advance_wb_err() during its own vfs_fsync_range(). If that advancement lands between the writeback error appearing in mapping->wb_err and the COPY worker sampling \"since\", the worker captures the already-advanced cursor, errseq_check() sees cur == since and returns zero, and NFSD4_COPY_F_COMMITTED is set even though writeback failed. CB_OFFLOAD then encodes wr_stable_how = FILE_SYNC4, the client treats the copied data as durable, and the failure becomes silent data loss. Sample since once at the start of the function. The cursor then reflects state in effect before this COPY issues any writes, and filemap_check_wb_err() detects any error that occurs during the copy regardless of which thread first observes it. This matches the pattern used by nfsd_vfs_write() and nfsd4_clone_file_range().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89706", "url": "https://ubuntu.com/security/CVE-2026-89706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: Reset write verifier when async COPY writeback fails Async COPY captures nn->writeverf at request time and reports it to the client via CB_OFFLOAD after the worker kthread completes. When the post-copy vfs_fsync_range() or filemap_check_wb_err() in _nfsd_copy_file_range() reports an error, the worker correctly leaves NFSD4_COPY_F_COMMITTED clear so that CB_OFFLOAD encodes wr_stable_how as NFS_UNSTABLE, but the server's write verifier is not rotated. A client that receives NFS_UNSTABLE in CB_OFFLOAD follows up with COMMIT to make the copied data durable. With the verifier unchanged, COMMIT returns the same value the client just received via CB_OFFLOAD, and the client concludes the copy is durable -- silently dropping the data whose writeback in fact failed. This violates the UNSTABLE+COMMIT durability contract (RFC 7862 section 15.1, RFC 8881 section 18.32) and matches the bug just fixed in nfsd_vfs_write() and nfsd_commit(). Rotate nn->writeverf at the writeback-failure site. The async COPY worker has no svc_rqst, so commit_reset_write_verifier() is not available here; calling nfsd_reset_write_verifier() directly mirrors the trace-less reset already used by nfsd_file_check_write_error() for the same purpose. Filter out -EAGAIN and -ESTALE, matching commit_reset_write_verifier(), since neither indicates a durable-storage failure.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89710", "url": "https://ubuntu.com/security/CVE-2026-89710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget path When the server returns a new layout stateid while a valid one is still held, pnfs_layout_process() calls pnfs_mark_matching_lsegs_return() on the on-stack free_me list and jumps to out_forget. Segments whose reference count drops to zero are unlinked from lo->plh_segs and moved to free_me by mark_lseg_invalid(); for an idle cached segment the layout header holds the only reference, so this happens on the first decrement. out_forget never drains free_me -- only the success path calls pnfs_free_lseg_list(). Commit 814b84971388 (\"pNFS/NFSv4: Fix a layout segment leak in pnfs_layout_process()\") added the drain; commit 08bd8dbe8882 (\"pNFS/NFSv4: Try to return invalid layout in pnfs_layout_process()\") removed it while switching the destination to lo->plh_return_segs, which is drained elsewhere. Commit fb700ef02676 (\"NFSv4.1: Simplify layout return in pnfs_layout_process()\") switched the destination back to free_me without restoring the drain. Restore the pnfs_free_lseg_list() call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89711", "url": "https://ubuntu.com/security/CVE-2026-89711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check The header for commit e75b23f9e323 (\"nfsd: check d_can_lookup in fh_verify of directories\") details the assumption that justified adding the WARN_ON_ONCE to nfsd_mode_check(), that assumption is invalid (in the case of NFS reexport). When NFSD exports an NFS filesystem it is very possible for nfsd_mode_check() to encounter a @dentry that doesn't have i_op->lookup (see nfs_fhget()'s NFS_ATTR_FATTR_MOUNTPOINT and NFS_ATTR_FATTR_V4_REFERRAL handling, and d_flags_for_inode()). So remove nfsd_mode_check()'s WARN_ON_ONCE(). The nfserr_notdir return on that branch must stay. It guards the subsequent lookup_one_unlocked() -> __lookup_slow() path, which calls inode->i_op->lookup() with no NULL check, so returning nfserr_notdir is what keeps a client LOOKUP into such a @dentry from dereferencing a NULL method pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89712", "url": "https://ubuntu.com/security/CVE-2026-89712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock nfsd4_ssc_expire_umount() walks nn->nfsd_ssc_mount_list with list_for_each_entry_safe(ni, tmp, ...). For each expired entry it sets nsui_busy = true, drops nfsd_ssc_lock to run mntput() on the source vfsmount, then reacquires the lock to list_del + kfree the entry and continue iterating via the macro's saved tmp pointer. The nsui_busy flag protects the current ni from concurrent nfsd4_ssc_setup_dul() finders during the lock-drop window, but it does not pin tmp. Another nfsd RPC thread that fails its source- server mount and reaches nfsd4_ssc_cancel_dul() will, during that same window, take nfsd_ssc_lock, list_del + kfree its own ssc_umount item, and release the lock. If that item is the saved tmp of the expire walk, the next iteration dereferences a freed nfsd4_ssc_umount_item. Restart the walk from the head after the mntput() unlock window so no saved next pointer survives the lock-drop. The list is bounded by the number of active inter-server source mounts (typically small) and the expire delayed-work runs periodically rather than per-IO, so the restart is cheap.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89720", "url": "https://ubuntu.com/security/CVE-2026-89720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: fix out-of-bounds read in signature length check ubifs_sb_verify_signature() bounds the on-disk ubifs_sig_node->len field before handing the signature payload to verify_pkcs7_signature(), but the check has the wrong sign: \tif (le32_to_cpu(signode->len) > snod->len + sizeof(struct ubifs_sig_node)) The signature bytes start sizeof(struct ubifs_sig_node) (UBIFS_SIG_NODE_SZ, 64 bytes) into the node, so the payload is at most \tsnod->len - sizeof(struct ubifs_sig_node) bytes long. Adding the header size instead of subtracting it accepts a declared length up to 2 * UBIFS_SIG_NODE_SZ larger than the node actually holds -- past the end of c->sbuf, which is vmalloc(c->leb_size). verify_pkcs7_signature() -> pkcs7_parse_message() -> asn1_ber_decoder() is then handed that inflated length and reads beyond the allocation while walking the DER headers. The node length comes straight from the mounted image, so a crafted signed UBIFS image reaches this via ubifs_read_superblock() before the signature is cryptographically checked. snod->len is guaranteed to be >= UBIFS_SIG_NODE_SZ by the node scanner (c->ranges[UBIFS_SIG_NODE].min_len == UBIFS_SIG_NODE_SZ), so the corrected subtraction cannot underflow. Legitimately signed images are unaffected: a correct superblock never declares a signature longer than the node it is embedded in.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93213", "url": "https://ubuntu.com/security/CVE-2026-93213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: of: fix out-of-bounds read in of_alias_scan() stem parser The stem parser tests isdigit(*(end - 1)) before checking end > start and so reads one byte before the property name when the name is empty or all digits. Check the bound first.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89723", "url": "https://ubuntu.com/security/CVE-2026-89723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after truncation Shuangpeng Bai reported that KASAN detected a slab-out-of-bounds error in nilfs_direct_propagate() during testing. Analysis revealed that after truncating a file, a node block immediately below the B-tree root was not deleted. Instead, it remained in the B-tree node cache in a dirty state. The log writer subsequently detected this block and incorrectly invoked nilfs_direct_propagate() on it, which is designed to handle only data blocks in direct mapping. B-tree nodes in the cache are managed by virtual block numbers, and their logical keys typically exceed the range expected by direct mapping. Consequently, processing such a node as a direct mapping entry triggers a slab-out-of-bounds access. The root cause is that when a B-tree mapping collapses into a direct mapping during truncation, an intermediate node block pointed to by the root node is left behind as garbage instead of being explicitly deleted. This resolves the issue by adding a nilfs_btree_discard() operation to delete the remaining intermediate node block during the conversion. A 'deform' flag is added to the bop_delete interface to explicitly signal that the deletion is part of a mapping transformation. This allows the B-tree mapping implementation to perform the necessary cleanup and discarding of the residual node structure that would be otherwise be left orphaned after the transition.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89724", "url": "https://ubuntu.com/security/CVE-2026-89724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vicodec: fix out-of-bounds write in FWHT encoder vidioc_s_fmt_vid_out() sizes the encoder CAPTURE buffer from the compressed descriptor pixfmt_fwht, whose sizeimage_mult is 3: coded_w * coded_h * 3 + sizeof(struct fwht_cframe_hdr). fwht_encode_frame() encodes one plane per component, and an incompressible plane takes the FWHT_FRAME_UNENCODED path in encode_plane(), copying the plane verbatim. For a 4-component pixel format all four planes are full resolution (width_div == height_div == 1), so a frame that forces every plane through the unencoded fallback writes sizeof(struct fwht_cframe_hdr) + 4 * coded_w * coded_h bytes, overrunning the plane by coded_w * coded_h, which can result in corruption of adjacent kernel heap memory. Bump pixfmt_fwht.sizeimage_mult from 3 to 4, matching the largest components_num among the supported raw formats, so the capture buffer is always large enough for the unencoded fallback.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89725", "url": "https://ubuntu.com/security/CVE-2026-89725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: stm32: prevent out-of-bounds write on RX overflow stm32_rx_done() appends each received CEC byte to rx_msg.msg[] using rx_msg.len as the write index, incrementing it on every RXBR (receive-byte-ready) interrupt without checking it against the buffer size: \tcec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF; rx_msg.msg[] is a fixed CEC_MAX_MSG_SIZE (16) byte array in struct cec_msg, and rx_msg.len is only reset on RXACKE/RXOVR or after a completed message (RXEND). The number of bytes received before RXEND is decided by the remote CEC device (it sets EOM), not by the driver. A peer that keeps sending bytes without ending the message drives RXBR repeatedly, pushing rx_msg.len past 16 and writing peer-controlled bytes out of bounds into the surrounding memory. This is reachable in normal operation once the driver has probed and receiving is enabled, from the IRQ thread, without any local privilege. The length check in the CEC core runs on the consumer side, after the byte has been stored, so it does not prevent the overflow. Bound the index in the driver before the store, as the other platform CEC drivers already do (e.g. tegra_cec), dropping the excess bytes of an overlong frame. Found by static analysis tool CodeQL.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89726", "url": "https://ubuntu.com/security/CVE-2026-89726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen() Patch series \"lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()\", v2. This series fixes an off-by-one out-of-bounds read in ucs2_strnlen(). The first patch is the real fix, the second patch comes as a bonus and fixes the code indentation. This patch (of 2): ucs2_strnlen() checks the current character before checking whether the caller-provided maximum length has been reached. If the input is not NUL-terminated within that bound, the loop can read one ucs2_char_t past the limit. Test the length before dereferencing to prevent an off-by-one out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89729", "url": "https://ubuntu.com/security/CVE-2026-89729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature sensor_hub_get_feature() clamps its return value to the caller's buffer size, but the copy loop still copies field->report_size / 8 bytes for each report value. A malicious HID descriptor can advertise a large feature field size while an IIO caller supplies a small stack buffer, such as a single s32, causing an out-of-bounds write. HID core stores parsed report values in __s32 slots and clamps extracted values to 32 bits. Reject feature fields that require more than one slot per value, guard the total byte count calculation, and clamp each per-value copy to the remaining caller buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89730", "url": "https://ubuntu.com/security/CVE-2026-89730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write The trailing byte path in altera_cvp_send_block() dereferences a u32 pointer even when only 1-3 bytes remain in the input buffer. If the buffer ends at a page or scatterlist boundary, this can read past the valid image data and fault. Copy the remaining bytes into a zero-initialized u32 before writing the final word so only valid bytes are read from the input buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89732", "url": "https://ubuntu.com/security/CVE-2026-89732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Prevent deadlock during ep0 read loop Currently, ffs_ep0_read() holds ffs->mutex when it prepares to go to sleep waiting for an event. When no setup events are pending, it calls wait_event_interruptible_exclusive_locked_irq() with the mutex still held. The wait macro deliberately drops the waitqueue spinlock before sleeping but does not drop the mutex. If a userspace daemon is polling ep0 via read() and the gadget is asynchronously torn down via configfs (e.g., echo \"\" > UDC), a deadlock can occur: 1. The configfs teardown calls functionfs_unbind(), which queues a FUNCTIONFS_UNBIND event. 2. The daemon wakes up, consumes the event, and drops the mutex. 3. However, if the daemon loops and immediately issues another read() before exiting, it reacquires ffs->mutex and again goes into an interruptible sleep. 4. Meanwhile, functionfs_unbind() continues execution and attempts to acquire ffs->mutex to tear down ep0req. 5. The kernel deadlocks because the configfs thread is stuck in an uninterruptible sleep waiting for the mutex, while the userspace daemon is in an interruptible sleep holding the mutex forever because no more events will arrive. To fix this, we drop both the waitqueue spinlock and ffs->mutex before going to sleep, and use wait_event_interruptible_exclusive() instead. Upon waking up, we jump back to the `retry` label to safely reacquire the mutex and re-evaluate the state machine. By not sleeping with ffs->mutex held, we natively decouple gadget teardowns (which require the mutex) from userspace polling.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89733", "url": "https://ubuntu.com/security/CVE-2026-89733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and uvc_function_unbind() In uvc_function_bind() error path, we use usb_ep_free_request which uses uvc->control_req but does not set it to NULL afterwards. Thus, uvc->control_req is a dangling pointer causing a UAF. Also we do not set the uvc->control_buf pointer to NULL after freeing it, which is another dangling pointer. Fix it by setting uvc->control_req to NULL after we run usb_ep_free_request() and uvc->control_buf to NULL after kfree. Do the same for uvc_function_unbind().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93214", "url": "https://ubuntu.com/security/CVE-2026-93214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: fix deadlock in usbg_make_tpg() usbg_make_tpg() held dep_lock while calling configfs_depend_item_unlocked(), which acquires the configfs root inode lock when operating across subsystems. This creates a circular lock dependency with configfs_rmdir(): dep_lock -> configfs root inode lock -> su_mutex -> dep_lock In usbg_make_tpg(), dep_lock only serialized the read of opts->ready, which is a monotonic flag that transitions from false to true exactly once (in tcm_set_name()) and never reverts. Remove dep_lock from usbg_make_tpg() entirely and use READ_ONCE/WRITE_ONCE to access opts->ready locklessly instead.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89736", "url": "https://ubuntu.com/security/CVE-2026-89736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: Fix use-after-free on sound card disconnect g_audio_cleanup() invokes snd_card_free_when_closed() to initiate sound card teardown and immediately frees the underlying struct snd_uac_chip context. However, snd_card_free_when_closed() returns asynchronously while ALSA control elements (kctls) remain open in userspace. When userspace control applications access or close these open file descriptors, kctl callbacks attempt to dereference kctl->private_data pointing to &uac->c_prm or &uac->p_prm within the freed uac structure, resulting in a use-after-free (UAF) memory corruption. Fix this issue by deferring the destruction of struct snd_uac_chip until all references to the ALSA sound card are released. Register a custom card->private_free callback (u_audio_card_free) during g_audio_setup() that frees uac and its associated playback/capture request and ring buffers only when the sound card reference count drops to zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89741", "url": "https://ubuntu.com/security/CVE-2026-89741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"media: v4l2-dev: fix error handling in __video_register_device()\" This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a. The intentions of that patch were good, but it doesn't work. The idea is that if device_register fails, you have to do a put_device to let the ref counter release resources. However, the V4L2 API says that if video_register_device() fails, then you have to call video_device_release(), which kfree()s the video_device struct. But the put_device() will already have freed the struct, so you end up in a double-free scenario. There is not really a good way of fixing this without breaking video_register_device() into two parts, one that initializes everything, and one that does the actual device_register, and then converting all V4L2 drivers to this new model. That is a massive job, and it is very unlikely that device_register will fail. So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89742", "url": "https://ubuntu.com/security/CVE-2026-89742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: mport_cdev: fix use-after-free in dma_req_free() dma_req_free() acquires buf_mutex through req->map, drops the mapping reference with kref_put(), and then dereferences req->map again to unlock the mutex. If kref_put() drops the last reference, mport_release_mapping() frees the mapping, and the subsequent mutex_unlock() dereferences a freed object. This is a use-after-free. Fix this by caching map and md before kref_put(), clearing req->map while holding buf_mutex, and using the cached md for mutex unlocking. The bug is reachable from userspace via the RapidIO mport character device interface.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89749", "url": "https://ubuntu.com/security/CVE-2026-89749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix crash passing ERR_PTR to kthread_stop() event_test_stuff() calls kthread_run() and unconditionally passes the returned task_struct pointer to kthread_stop(). kthread_run() returns an error pointer such as ERR_PTR(-ENOMEM) when kthread creation fails, for example under memory pressure during the boot-time event self-test. kthread_stop() then dereferences the invalid pointer, crashing the kernel. Check the result of kthread_run() before passing it to kthread_stop(). Use WARN_ON() so that a failure to create the self-test thread does not go unnoticed, matching the ring-buffer self-test fix in commit 91542863abad (\"ring-buffer: Fix crash passing ERR_PTR to kthread_stop()\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89752", "url": "https://ubuntu.com/security/CVE-2026-89752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: memcg: stop reclaim when a limit update is superseded kernfs serializes file operations only per open file, so separate open files can update the same memory.high or memory.max file concurrently. Both handlers store the new limit before synchronous reclaim, but continue to use the writer's local target in the reclaim loop. If another writer raises or removes the limit, the first writer can continue reclaiming toward a stale target. For memory.max, this can leave the writer looping indefinitely once reclaim retries are exhausted. The OOM path sees sufficient margin under the current limit and returns true without killing, while the writer still compares usage against its stale target and records another OOM event. Check the current limit at the start of each reclaim iteration and stop if it no longer matches the writer's target. Reproducer: Populate a cgroup with anonymous memory and disable swapping. Lower memory.max from one open file, then restore it to \"max\" through another open file after the new limit becomes visible. Without the patch, the first writer remains blocked and repeatedly increments the OOM event counter. With the patch, it returns normally. This was not motivated by a reported production workload. We found it through automated randomized testing for our cgroup observability work and reduced it to the reproducer above.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89753", "url": "https://ubuntu.com/security/CVE-2026-89753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: \t0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 \ttask:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89765", "url": "https://ubuntu.com/security/CVE-2026-89765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers/itimer: Zero-init old itimerval before copy to userspace On native sparc64, struct __kernel_old_timeval contains a four-byte hole after tv_usec because tv_sec is 64-bit while __kernel_suseconds_t is 32-bit. put_itimerval() fills only the named fields in a stack-allocated __kernel_old_itimerval and copies the entire object to userspace, so getitimer() can expose the two padding holes. Zero-initialize the aggregate before assigning the fields so implicit padding is deterministic before it crosses the user/kernel boundary.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93219", "url": "https://ubuntu.com/security/CVE-2026-93219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/timer-sun4i: Advertise a real minimum delta sun4i_clkevt_next_event() compensates for the timer stop/start synchronization delay by programming evt - TIMER_SYNC_TICKS into the hardware interval register. The clockevent device currently advertises TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed to call set_next_event() with evt == TIMER_SYNC_TICKS. That programs a zero-tick interval. With oneshot/highres/nohz timer operation this can leave the next event stuck, which was observed as a boot hang on Allwinner D1 after the clockevents core started reusing forced minimum-delta events. Advertise one extra tick instead, so the smallest event accepted by the core still programs at least one hardware tick after the synchronization compensation.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-23191", "url": "https://ubuntu.com/security/CVE-2026-23191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix racy access at PCM trigger The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers. For addressing the UAF, this patch changes two things: - It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.", "cve_priority": "high", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-80824", "url": "https://ubuntu.com/security/CVE-2026-80824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbfs: fix use-after-free of usb_device in usbdev_release() usbdev_release() drops its reference to the struct usb_device before draining the list of completed async URBs, but that drain path reads back through the same object: free_async() calls dec_usb_memory_use_count() for any URB whose buffer came from the usbfs mmap() region, and its first statement is bus_to_hcd(ps->dev->bus). After a disconnect the usbfs reference can be the last one, in which case usb_put_dev() frees the device and the subsequent loop reads offset 80 of freed memory and uses the result as a struct usb_hcd *, which hcd_buffer_free_pages() then dereferences. This is reachable by an unprivileged process that has read/write access to a /dev/bus/usb node: mmap() the fd, submit one URB with a buffer inside the mapping, wait for the device to be unplugged, then munmap() and close(). It reproduces on every attempt rather than being a race, because a live MAP_SHARED vma holds a reference on the struct file, so usbdev_release() cannot run until the last vma is gone and the freeing branch of dec_usb_memory_use_count() is always taken. BUG: KASAN: slab-use-after-free in dec_usb_memory_use_count+0x3ae/0x410 Read of size 8 at addr ffff8880122ee050 by task poc/769 CPU: 1 UID: 1000 PID: 769 Comm: poc Tainted: G B 6.12.94 #3 Call Trace: dec_usb_memory_use_count+0x3ae/0x410 free_async+0x2aa/0x4f0 usbdev_release+0x375/0x460 __fput+0x3ea/0xb50 __x64_sys_close+0x86/0x100 Allocated by task 11: usb_alloc_dev+0x55/0xd90 hub_event+0x2524/0x43d0 Freed by task 769: kfree+0x121/0x360 device_release+0xd2/0x280 usb_put_dev+0x23/0x30 usbdev_release+0x2d8/0x460 Release the device reference after the drain loop instead. Nothing between the two points requires it to have been dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80826", "url": "https://ubuntu.com/security/CVE-2026-80826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: c67x00: fix use-after-free in c67x00_add_iso_urb() When TD creation fails for the last packet of an isochronous URB, c67x00_add_iso_urb() gives the URB back before updating the endpoint scheduling state. c67x00_giveback_urb() frees the URB private data, and the completion callback may release the final URB reference. The following accesses to urbp->ep_data, urb->interval, and urbp->cnt can therefore use freed memory. Update next_frame and cnt before giving back the failed final packet, making the giveback the last operation that uses the URB and its private data.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80827", "url": "https://ubuntu.com/security/CVE-2026-80827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: option: fix slab OOB read in interrupt URB callback The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. [ johan: use dev_err(); split signals declaration and initialisation ]", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80828", "url": "https://ubuntu.com/security/CVE-2026-80828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Complete cleanup after system-resume errors A failed system resume can leave the card unusable until reboot. usb_audio_resume() jumps to err_out when snd_usb_pcm_resume() or snd_usb_mixer_resume() fails. The error path skips the out: block, which restores D0 and decrements chip->num_suspended_intf. The card stays in SNDRV_CTL_POWER_D3hot, so later control access blocks in snd_power_ref_and_wait(). USB core logs an interface resume callback error. It does not retry that callback, so a later callback cannot complete the skipped cleanup. usb_audio_suspend() increments num_suspended_intf before returning success. A system-resume callback must consume the system-suspend count even if a component resume fails. Otherwise, the stranded count skews later suspend and resume cycles. Do not apply this cleanup to runtime-resume errors. Runtime PM can retry -EAGAIN or -EBUSY without another suspend callback. The count must continue to describe that suspended interface. Other runtime-resume errors latch runtime_error in the PM core and do not cause an immediate callback retry. Both parts of the system-resume error path are longstanding. Commit 88a8516a2128a (\"ALSA: usbaudio: implement USB autosuspend\") introduced err_out past the D0 restore. Commit 862b2509d157c (\"ALSA: usb-audio: Fix inconsistent card PM state after resume\") later moved num_suspended_intf-- into the out: block. The error path now skips both operations. No third-party code is needed to reach the error path. snd_usb_mixer_resume() ends in snd_usb_mixer_activate(), which returns the result of usb_submit_urb() for devices that have a mixer status URB. Its mixer->private_resume hook can also fail through scarlett2_init_notify(). snd_usb_pcm_resume() issues a SET_CUR request to a UAC3 power domain. It can return -EPIPE or -EIO when the device stalls the request. Route a component error through out: only when system_suspend is nonzero. Continue to return runtime-resume errors through err_out. Later component resume stages remain skipped. The original error still reaches USB core. A later transfer can fail if the device did not recover. I reproduced the system-resume failure on an Audient iD14 MkI with an out-of-tree diagnostic mixer resume hook. An injected -EIO on the unpatched core left control readers in uninterruptible sleep in snd_power_ref_and_wait() until a reboot. With this patch, the same failure restored control access. A second system suspend and resume also succeeded after I disabled fault injection.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80829", "url": "https://ubuntu.com/security/CVE-2026-80829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output() snd_usbmidi_novation_output() lays out a two-byte header at transfer_buffer[0..1] and passes &transfer_buffer[2] together with a length of ep->max_transfer - 2 to snd_rawmidi_transmit(): \tcount = snd_rawmidi_transmit(ep->ports[0].substream, \t\t\t\t &transfer_buffer[2], \t\t\t\t ep->max_transfer - 2); ep->max_transfer comes from the output endpoint's wMaxPacketSize via usb_maxpacket(). A malformed or malicious device can advertise a bulk OUT endpoint with a wMaxPacketSize of 1 - the USB core only clamps this value downwards - so ep->max_transfer becomes 1 and the count argument becomes -1. snd_rawmidi_transmit() passes the negative count on to __snd_rawmidi_transmit_peek(), where \"if (count1 > count) count1 = count\" leaves count1 negative; get_aligned_size() keeps it negative for a byte-stream substream, so the following memcpy(buffer, ..., count1) runs with a (size_t)-1 length and writes far past the transfer buffer, which was allocated with usb_alloc_coherent(ep->max_transfer). This is the same class of bug that was fixed for snd_usbmidi_akai_output() in commit 0970274613fb (\"ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()\"); the novation output routine was left unguarded. Bail out when the endpoint cannot hold the two-byte header plus at least one payload byte.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80830", "url": "https://ubuntu.com/security/CVE-2026-80830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: Add lock to usb_wakeup_notification() Add a spin lock to usb_wakeup notification to prevent a race condition with dereferencing freed memory. This could be hit by the xHCI driver as it calls this function from an IRQ and could race with the hub_disconnect() function, which properly grabs this lock to protect the state of the device.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80921", "url": "https://ubuntu.com/security/CVE-2026-80921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: zero stale crypto bits When shadowing crypto access bits from a format0 apcb (crycb 0 or 1), the bits 64..255 are unchanged from whatever is in the vsie page in the crycb and thus in the apcb. This gives a nested guest potential access to a device no longer available. Zero out the remaining bits.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80831", "url": "https://ubuntu.com/security/CVE-2026-80831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: mxs-dcp - fix source scatterlist length access mxs_dcp_aes_block_crypt() uses sg_dma_len() without mapping the source scatterlist with dma_map_sg() first. Therefore, sg_dma_len() is invalid and could return zero or a stale DMA length, causing encryption and decryption to process the wrong number of bytes when CONFIG_NEED_SG_DMA_LENGTH=y. Use the original scatterlist length instead.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80832", "url": "https://ubuntu.com/security/CVE-2026-80832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qce - fix CCM AAD buffer underallocation The AAD buffer allocated in qce_aead_ccm_prepare_buf_assoclen() can be smaller than the length later programmed into the DMA scatterlist. The allocation size is currently calculated as: ALIGN(assoclen, 16) + MAX_CCM_ADATA_HEADER_LEN while the DMA length is set to: ALIGN(assoclen + adata_header_len, 16) Since ALIGN() does not distribute over addition, the allocation can be smaller than the DMA length. For example, when assoclen = 32 and adata_header_len = 2: allocation = ALIGN(32, 16) + 6 = 38 DMA length = ALIGN(32 + 2, 16) = 48 As a result, the QCE hardware can read beyond the allocated buffer while computing the CBC-MAC over the associated data. The extra bytes are folded into the authentication tag, resulting in an incorrect tag and causing CCM self-test failures such as: alg: aead: ccm-aes-qce encryption test failed (wrong result) on test vector 8 Fix the allocation by adding the maximum possible AAD header length before alignment: ALIGN(assoclen + MAX_CCM_ADATA_HEADER_LEN, 16) This guarantees that the allocated buffer is large enough for the fully padded AAD data for all supported header sizes.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80840", "url": "https://ubuntu.com/security/CVE-2026-80840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: seg6: clear IPv4 control block on IPIP decapsulation End.DX4 and End.DT4 decapsulate an IPv4 packet through decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), which normally clears IPCB before IPv4 interprets skb->cb. The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts. The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40. Both tcp_v4_save_options() and __ip_options_echo() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls __ip_options_echo(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte option-data area. Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced: BUG: KASAN: slab-out-of-bounds in __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm. Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80842", "url": "https://ubuntu.com/security/CVE-2026-80842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: fix use-after-free of a master VLAN's multicast context br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so once it is cleared under the lock no reader can arm the context again. For a master VLAN the handshake never runs. __vlan_del() clears BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so br_multicast_toggle_one_vlan(masterv, false) returns early on !br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is never taken. br_vlan_put_master() then drains the context in br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a reader still inside rcu_read_lock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no br_vlan_is_brentry() test and flips the flag under br->multicast_lock, so it is not affected. The reader is the bridge transmit path. For a master VLAN br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after br_multicast_ctx_deinit() has already stopped them. BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 Allocated by task 610: br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 Only test br_vlan_is_brentry() when enabling, like the br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before br_multicast_ctx_deinit() drains the context.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80843", "url": "https://ubuntu.com/security/CVE-2026-80843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix xfrm_state_construct() auth-trunc leak attach_auth_trunc() can allocate x->aalg while leaving x->props.aalgo at zero when the selected auth algorithm has no sadb_alg_id. One real case is cmac(aes). xfrm_state_construct() then treats !x->props.aalgo as \"no auth algorithm attached yet\" and calls attach_auth(). That overwrites x->aalg and loses the first allocation. Any later failure or teardown only frees the replacement pointer. Check whether x->aalg is already attached instead of inferring that state from x->props.aalgo.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80844", "url": "https://ubuntu.com/security/CVE-2026-80844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah6: validate routing header segments_left AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6_rearrange_rthdr() assumes that segments_left is not larger than the number of addresses described by the routing header's hdrlen field. That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segments_left value. With segments_left equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access. Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80846", "url": "https://ubuntu.com/security/CVE-2026-80846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: drop ESP-in-TCP packets with no ingress device ESP-in-TCP receives records through the TCP strparser. handle_esp() restores skb->dev from the saved skb_iif before passing the packet into the XFRM input path. Queued TCP data can be processed after the original ingress device has been removed, for example during veth or net namespace teardown. In that case dev_get_by_index_rcu() returns NULL. The XFRM IPv4 and IPv6 input paths both expect skb->dev to be valid while building the route lookup, so queued ESP-in-TCP data can dereference a NULL device. Drop the packet if the saved ingress device can no longer be resolved. Such a packet can no longer be routed through the normal XFRM receive path, and this preserves the existing behaviour for packets whose ingress device still exists.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80848", "url": "https://ubuntu.com/security/CVE-2026-80848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: fix UAF during close ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80854", "url": "https://ubuntu.com/security/CVE-2026-80854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: keep port count until LUN teardown completes tcm_usbg_drop_nexus() permits session removal once tpg_port_count reaches zero. However, usbg_port_unlink() currently decrements that count from the fabric_pre_unlink() callback, before core_dev_del_lun() waits for active se_lun references to drain. If removal of the last LUN races a nexus removal, the latter can observe a zero port count and call target_remove_session(). This frees sess_cmd_map while an in-flight struct usbg_cmd, including its work item, can still be accessed. Overlapping the last-LUN unlink with nexus removal reproduces this lifetime violation as a DEBUG_OBJECTS \"free active\" warning for usbg_cmd_work, followed by a target-core BUG/Oops. The generic target-core unlink path has no callback after core_dev_del_lun() completes. Add an optional fabric_post_unlink() callback and use it for the f_tcm port count. The count now remains nonzero until core_dev_del_lun() has finished draining active LUN references, preventing nexus removal from freeing the session during command completion.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80855", "url": "https://ubuntu.com/security/CVE-2026-80855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on open O_TRUNC DAX failure fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open(\"file\", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80856", "url": "https://ubuntu.com/security/CVE-2026-80856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on setattr writeback failure fuse_do_setattr() takes filemap_invalidate_lock() for a DAX truncate (fault_blocked = true) and releases it at the out:/error: labels. But when a writeback flush is also needed, a write_inode_now() failure returns directly and leaks the lock, so any later fault or truncate on the file stalls on the stale rwsem. For example, truncate(2) on a setuid file reaches fuse_do_setattr() with both ATTR_SIZE and ATTR_MODE set: truncate(2) └─ do_truncate() ├─ dentry_needs_remove_privs() # S_ISUID └─ notify_change() # KILL_SUID -> ATTR_MODE └─ fuse_setattr() # no killpriv: │ # ia_valid |= ATTR_MODE └─ fuse_do_setattr() ├─ filemap_invalidate_lock() # IS_DAX && is_truncate └─ write_inode_now() # is_wb && ATTR_MODE └─ if (err) # e.g. daemon -> -EIO return err # <- lock leaked Fix this by adding an unlock label that releases the lock before returning the error, and use it for the fuse_dax_break_layouts() failure path as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80923", "url": "https://ubuntu.com/security/CVE-2026-80923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: dbgtty: Fix unregister on tty_register_driver() failure If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80768", "url": "https://ubuntu.com/security/CVE-2026-80768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: ft260: fix stack-use-after-return write in I2C read race ft260_i2c_read() points dev->read_buf at a caller-supplied buffer (often an on-stack variable), arms a completion and waits up to five seconds for the device to return the data. The HID input callback ft260_raw_event() runs in the input/IRQ path, independent of the dev->lock mutex held by the read path, and copies the device-supplied payload into dev->read_buf after a plain NULL check. These two paths share read_buf, read_idx and read_len with no serialization. If the device delays its response until the read times out, ft260_i2c_read() resets the controller, clears read_buf and returns, unwinding the stack frame the buffer lived in. A response that arrives at that moment lets ft260_raw_event() pass the NULL check and then memcpy() the device-controlled payload into the now-freed stack location, a bounded but attacker-influenced stack-use-after-return write triggerable by malicious or malfunctioning hardware. Add a dedicated spinlock that serializes every access to read_buf, read_idx and read_len. ft260_raw_event() now holds it across the NULL check, the memcpy and the index update, while the read path takes it when arming and when clearing the buffer, so the teardown can no longer slip between the check and the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80766", "url": "https://ubuntu.com/security/CVE-2026-80766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: fix use-after-free of inrange_timer on remove uclogic_remove() cancels the pen in-range timer and then stops the device: \ttimer_delete_sync(&drvdata->inrange_timer); \thid_hw_stop(hdev); timer_delete_sync() only guarantees the timer is idle at that instant. uclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop() stops the transport several lines later, and every report with pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer: \tmod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); A report landing between the timer_delete_sync() call and the transport teardown in hid_hw_stop() re-arms inrange_timer after it was cancelled. uclogic_remove() then returns and the devm drvdata is freed, while hid_hw_stop() has already freed the input device drvdata->pen_input points at, so when the timer fires ~100 ms later uclogic_inrange_timeout() dereferences freed memory -- a use-after-free in timer-softirq context. Swapping the two calls is not a fix: stopping the device first frees drvdata->pen_input via hidinput_disconnect() while the timer may still be pending, so a timer already armed before removal fires on the freed input device in the window before timer_delete_sync() runs. Use timer_shutdown_sync() before hid_hw_stop() instead. It cancels the timer, waits for a running callback while pen_input is still valid, and prevents any further re-arming -- a later mod_timer() from an in-flight report is silently ignored -- so the timer is provably dead before hid_hw_stop() frees the inputs. This is the ordering the timer core documents for this \"timer re-armed from another path\" teardown case.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80789", "url": "https://ubuntu.com/security/CVE-2026-80789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: bound SGL data length before allocating command buffers nvmet_tcp_map_data() reads the host-controlled 32-bit sgl->length and, for the in-capsule offset descriptor (type 0x01), checks it against port->inline_data_size before use. Any other SGL descriptor type -- including the non-inline transport SGL data-block descriptor (type (NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, the type a real host uses for out-of-capsule writes) skips that check entirely and falls straight through to: \tcmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt); with len taken directly from the wire, unbounded up to 4 GiB. nvmet_req_init() only parses the command and never inspects sgl->length, and nvmet_check_transfer_len() -- the only other place transfer_len is validated -- runs later, from req->execute(), after the allocation has already happened. For a write command the target responds with an R2T and parks the command waiting for the host to send the data; if the host (or an unauthenticated peer that simply never follows up) never does, the sgl_alloc() buffer stays resident for the life of the command. NVMe/TCP has no mandatory authentication in the default configuration, so any peer able to reach the target portal and complete a Fabrics connect can drive this with a single crafted command, repeatable across queues and connections for amplification. This is unbounded kernel memory allocation triggered by a remote, effectively unauthenticated peer. Validate len against the same NVMET_TCP_MAXH2CDATA ceiling this file already uses to bound per-PDU H2C data, for every SGL descriptor type, before doing any allocation. This closes the gap for the non-inline descriptor while leaving the existing, tighter inline_data_size check in place for the in-capsule case. Runtime-verified on a v6.19 KASAN stand: with this bound in place, a crafted write command carrying an oversized non-inline SGL length is rejected before sgl_alloc() runs, where the same request previously drove an unbounded ~256 MiB kernel allocation (up to 4 GiB) that stayed resident pending an R2T the host never satisfies.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80783", "url": "https://ubuntu.com/security/CVE-2026-80783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event() magicmouse_raw_event() handles DOUBLE_REPORT_ID (0xf7) packets, which pack two touch reports into one, by splitting the packet and calling itself on each half. The only guard against runaway recursion is a \"size < 1\" check, which stops zero-sized calls but does not bound the recursion depth. A malicious HID device that matches this driver can send a report starting with DOUBLE_REPORT_ID and filled with the sequence [0xf7, 0x00]. Each level consumes two bytes and recurses on the remainder, so an incoming report of up to HID_MAX_BUFFER_SIZE (16 KiB) drives roughly 8000 nested calls. That easily exhausts the 16 KiB kernel stack, leading to a stack overflow: a panic with CONFIG_VMAP_STACK, or memory corruption without it. A double report only ever wraps two normal reports; it is never legitimately nested. Refuse to re-enter the DOUBLE_REPORT_ID case from a recursive call so the recursion depth is bounded to two, while all valid packets keep being parsed exactly as before.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80796", "url": "https://ubuntu.com/security/CVE-2026-80796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: add data_len bound checks to activation parameter extractors nci_extract_activation_params_iso_dep() and nci_extract_activation_params_nfc_dep() read an inner length byte from the NCI RF_INTF_ACTIVATED_NTF payload and use it to memcpy() into fixed kernel buffers, but neither function receives the caller-validated activation_params_len. A crafted NCI notification with activation_params_len=1 and an inner length byte of up to 20 (NFC-A) or 50 (NFC-B) causes memcpy() to read that many bytes past the one valid byte in the activation params region -- a slab out-of-bounds read of kernel memory adjacent to the NCI skb. The sibling nci_extract_rf_params_*() family was given equivalent protection by commit 571dcbeb8e63 (\"net: nfc: nci: Fix parameter validation for packet data\"), but the two activation parameter extractors were not updated at that time. Add a data_len parameter to both functions, guard against an empty region before consuming the inner length byte, decrement the remaining count after consuming it, and clamp the copy length to what is actually available. Update both call sites to pass ntf.activation_params_len, which is already validated against the skb at ntf.c:801.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80807", "url": "https://ubuntu.com/security/CVE-2026-80807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid block index in GC ioctl Syzbot reported list corruption caused by a double list_add_tail() call on bh->b_assoc_buffers within nilfs_lookup_dirty_data_buffers(). Analysis revealed that the root cause was the insertion of a page/folio with a page index of ULONG_MAX into the page cache via the GC ioctl. filemap_get_folios_tag(), called by nilfs_lookup_dirty_data_buffers(), repeatedly detects a dirty folio with a page index of ULONG_MAX due to index wrap-around, leading to duplicate processing of dirty buffers. As a preparatory step, the GC ioctl loads the page/folio of the block to be moved during GC and inserts it into the page cache based on information in the nilfs_vdesc structure passed as an argument. Normally, this does not cause issues because the user-space GC library configures the nilfs_vdesc structure properly. However, since there is no range check on the parameters determining the page index, a request with artificially crafted parameters -- such as those generated by Syzbot -- can result in a page/folio being inserted with a page index of ULONG_MAX, triggering the above problem. This resolves the issue by checking the ranges of 'vd_offset' and 'vd_vblocknr' in the nilfs_vdesc structure that determine the page index, thereby preventing the invalid page/folio insertions.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80916", "url": "https://ubuntu.com/security/CVE-2026-80916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcov: fix data corruption and race conditions on PREEMPT_RT syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area. On PREEMPT_RT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state. Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites. Note that while the temporary storage is now on a per-thread basis, the per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that kcov_remote_start() and kcov_remote_stop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state. It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when __init function of built-in module runs. But this patch also fixes crashing the kernel when vmalloc_node() in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in (1) doing vmalloc() in kcov_remote_start() despite !in_task() context (2) out-of-array-bounds access if (1) succeeded but kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE (3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes problems.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-43437", "url": "https://ubuntu.com/security/CVE-2026-43437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain() In the drain loop, the local variable 'runtime' is reassigned to a linked stream's runtime (runtime = s->runtime at line 2157). After releasing the stream lock at line 2169, the code accesses runtime->no_period_wakeup, runtime->rate, and runtime->buffer_size (lines 2170-2178) — all referencing the linked stream's runtime without any lock or refcount protecting its lifetime. A concurrent close() on the linked stream's fd triggers snd_pcm_release_substream() → snd_pcm_drop() → pcm_release_private() → snd_pcm_unlink() → snd_pcm_detach_substream() → kfree(runtime). No synchronization prevents kfree(runtime) from completing while the drain path dereferences the stale pointer. Fix by caching the needed runtime fields (no_period_wakeup, rate, buffer_size) into local variables while still holding the stream lock, and using the cached values after the lock is released.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-53089", "url": "https://ubuntu.com/security/CVE-2026-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in offloaded map/prog info fill When querying info for an offloaded BPF map or program, bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns() obtain the network namespace with get_net(dev_net(offmap->netdev)). However, the associated netdev's netns may be racing with teardown during netns destruction. If the netns refcount has already reached 0, get_net() performs a refcount_t increment on 0, triggering: refcount_t: addition on 0; use-after-free. Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains valid, they cannot prevent the netns refcount from reaching zero. Fix this by using maybe_get_net() instead of get_net(). maybe_get_net() uses refcount_inc_not_zero() and returns NULL if the refcount is already zero, which causes ns_get_path_cb() to fail and the caller to return -ENOENT -- the correct behavior when the netns is being destroyed.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2025-40102", "url": "https://ubuntu.com/security/CVE-2025-40102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000) Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-39925", "url": "https://ubuntu.com/security/CVE-2025-39925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: j1939: implement NETDEV_UNREGISTER notification handler syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 (\"can: j1939: move j1939_priv_put() into sk_destruct callback\") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on \"struct j1939_priv\" held by j1939_sk_bind() call prevents \"struct net_device\" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. [mkl: remove space in front of label]", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2024-58095", "url": "https://ubuntu.com/security/CVE-2024-58095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before txBeginAnon() call Added a read-only check before calling `txBeginAnon` in `extAlloc` and `extRecord`. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes. Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-58094", "url": "https://ubuntu.com/security/CVE-2024-58094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before truncation in jfs_truncate_nolock() Added a check for \"read-only\" mode in the `jfs_truncate_nolock` function to avoid errors related to writing to a read-only filesystem. Call stack: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) If the `isReadOnly(ip)` condition is triggered in `jfs_truncate_nolock`, the function execution will stop, and no further data modification will occur. Instead, the `xtTruncate` function will be called with the \"COMMIT_WMAP\" flag, preventing modifications in \"read-only\" mode.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-46754", "url": "https://ubuntu.com/security/CVE-2024-46754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Remove tst_run from lwt_seg6local_prog_ops. The syzbot reported that the lwt_seg6 related BPF ops can be invoked via bpf_test_run() without without entering input_action_end_bpf() first. Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a (\"ipv6: sr: Add seg6local action End.BPF\"). The reason is that the per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self test case but each BPF function expects it. Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.", "cve_priority": "low", "cve_public_date": "2024-09-18 08:15:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-80806", "url": "https://ubuntu.com/security/CVE-2026-80806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't enable DAX on new encrypted files Currently, when a new encrypted regular file is created, the call to ext4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made before EXT4_INODE_ENCRYPT is set. As a result, it can set S_DAX if the filesystem is mounted with \"-o dax=always\". EXT4_INODE_ENCRYPT then actually gets set a bit later in __ext4_new_inode(), when it calls fscrypt_set_context() which calls ext4_set_context(). ext4_set_context() sets EXT4_INODE_ENCRYPT and calls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too. This was intended to clear S_DAX as well. However, this was broken by commit 043546e46dc7 (\"fs/ext4: Only change S_DAX on inode load\"). This causes data written to the file to bypass encryption, also causing xfstests failures such as generic/548 (when \"-o dax=always\" is used). Fix this by simplifying the flow by making __ext4_new_inode() set EXT4_INODE_ENCRYPT earlier. This makes it take effect in ext4_set_inode_flags(inode, init=true), making S_DAX never be set. Similarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first place on new encrypted inodes. Then it doesn't need to be cleared. As a result of these simplifications, ext4_set_context() no longer needs to change inode flags or state when 'handle != NULL'. Remove that too.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80863", "url": "https://ubuntu.com/security/CVE-2026-80863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix OOB in free_rd_atomic_resources() free_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic. Updating max_dest_rd_atomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] BUG: KASAN: slab-out-of-bounds in rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 Write of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063 CPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xf7/0x600 mm/kasan/report.c:482 kasan_report+0xe4/0x120 mm/kasan/report.c:595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fefc75a70cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fefc8495018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd RDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007 RBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0 Allocated by task 11063: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5296 [inline] __kmalloc_noprof+0x32a/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:155 [inline] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_ma ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80590", "url": "https://ubuntu.com/security/CVE-2026-80590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 (\"net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list\") and by commit 9e4b7a99a03a (\"net: gso: fix panic on frag_list with mixed head alloc types\") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 (\"tun: Allow GSO using virtio_net_hdr\"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80765", "url": "https://ubuntu.com/security/CVE-2026-80765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: validate initial device info bounds The Hyper-V synthetic HID host supplies SYNTH_HID_INITIAL_DEVICE_INFO messages that contain a HID descriptor followed by the report descriptor bytes. mousevsc_on_receive_device_info() trusts bLength and wDescriptorLength without checking that the received packet contains both byte ranges. A malformed host or backend message can therefore make the guest read past the received VMBus packet while copying the report descriptor. Pass the received initial-device-info size into the parser and reject descriptor lengths that exceed the packet. Impact: A malicious Hyper-V host or backend can crash a guest by sending a short initial device-info message with an oversized HID report descriptor length.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80767", "url": "https://ubuntu.com/security/CVE-2026-80767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix use-after-free in enable_sensor enable_sensor_store() can call set_power_report_state(), which dereferences sensor_inst->power_state and sensor_inst->report_state. These pointers refer to entries in sensor_inst->fields. Create the field attributes before exposing the enable_sensor sysfs attribute, so enable_sensor cannot be accessed before the state it depends on has been initialized. On remove, delete enable_sensor before freeing the field attributes, so a concurrent sysfs write cannot dereference freed memory through power_state or report_state.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80918", "url": "https://ubuntu.com/security/CVE-2026-80918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix number/pointer type confusion on long items When fetch_item() is called by hid_scan_report() on an item with HID_ITEM_TAG_LONG, it stores a pointer to the item data in item->data.longdata instead of storing a value directly in item->data.{u8/u16/u32}. When item_udata() or item_sdata() encounters such an item, it incorrectly assumes that the item is in short format, and therefore returns the lower part of a kernel pointer reinterpreted as a number. When a HID device is connected whose descriptor contains a HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this causes the lower half of a kernel pointer to be printed into dmesg as a number, like this: hid (null): invalid report_size 107953555 To fix it, let item_udata() and item_sdata() verify that the item is in short format. Note that this bug only affects hid_scan_report(), while the main parsing pass hid_parse_collections() will always bail out when encountering a long item. Sidenote: There are currently no users of data.longdata; maybe we should just remove any parsing of long-format descriptors as a follow-up.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80889", "url": "https://ubuntu.com/security/CVE-2026-80889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix timer drain order, wakeup handling and tx_gen ordering This patch is a follow-up to commit cf070fe33bfb (\"can: isotp: serialize TX state transitions under so->rx_lock\") which addresses following sashiko-bot findings: - isotp_sendmsg(): drain so->txfrtimer first so a stale callback can't re-arm echotimer after the claim - isotp_release(): wake so->wait after forcing ISOTP_SHUTDOWN so a sleeping sendmsg() claim isn't stranded - isotp_sendmsg(): have both wait_event_interruptible() calls in isotp_sendmsg() also wake on ISOTP_SHUTDOWN and do not return claim to IDLE to avoid corrupting a concurrent isotp_release() process. - isotp_sendmsg(): handle potential claim of a new transfer when the wait_event_interruptible() call returns in CAN_ISOTP_WAIT_TX_DONE mode. Don't touch timers and states of the new transfer if a new thread incremented so->tx_gen before getting the lock at err_event_drop. - isotp_sendmsg(): handle a stuck can_send() and omit timer and state changes if a new transfer was claimed. wait_tx_done() returns the error recorded in so->tx_result[], tagged with the caller's own generation. - isotp_tx_timeout(): on a claimed timeout, record the ECOMM error for the timed-out transfer's own generation in so->tx_result[]; sk->sk_err is raised unconditionally, same as every other error path here. - isotp_tx_gen_done()/isotp_tx_timeout(): always read tx.state (acquire) before tx_gen - the reverse order let a weakly ordered CPU pair a fresh tx.state with a stale tx_gen/tx_result slot. - isotp_sendmsg(): wait_tx_done: drain sk_err via sock_error() once we have read the result from so->tx_result[], so an already-reported error doesn't stay latched for a later poll()/SO_ERROR. Also align the remaining lock-free so->tx.state/rx.state/cfecho accesses and use skb->hash as unique loopback echo frame indicator.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-46170", "url": "https://ubuntu.com/security/CVE-2026-46170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: free sk if last When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on \"itself\".", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46158", "url": "https://ubuntu.com/security/CVE-2026-46158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: always decrease sk refcount When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as \"unlikely\".", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-80555", "url": "https://ubuntu.com/security/CVE-2026-80555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Free all memory if cp_init() fails The routine cp_free() is called to unpin/free any memory once an I/O is completed successfully, or if cp_prefetch() fails. But if cp_init() fails, and cp->initialized is not enabled, the same routine cannot be used to free all the memory. An attempt to address this exists in ccwchain_handle_ccw(), where a single call to ccwchain_free() is made for the currently-processed CCW segment. But this will leak other segments (created as a result of a Transfer in Channel) that had been allocated as part of the same channel program. Address this by performing the cleanup outside of the recursive ccwchain_handle_ccw()/ccwchain_loop_tic() logic.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2025-68794", "url": "https://ubuntu.com/security/CVE-2025-68794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: adjust read range correctly for non-block-aligned positions iomap_adjust_read_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio. Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-80781", "url": "https://ubuntu.com/security/CVE-2026-80781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix OOB read of field->usage in hid_set_field() hid_set_field() hands field->usage + offset to hid_dump_input() before the guard that bounds offset: \thid_dump_input(field->report->device, field->usage + offset, value); \tif (offset >= field->report_count) { \t\thid_err(...); \t\treturn -1; \t} Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is allocated inline with the hid_field in hid_register_field() and holds field->maxusage entries, so an offset past it reads off the end of the kvzalloc()ed allocation and into a neighbouring object. Had the guard run first, offset < report_count <= maxusage would already have confined the pointer to the array. A caller supplies such an offset today. picolcd_fb_send_tile() validates only report->maxfield before issuing hid_set_field(report->field[0], 11 + i, ...) for i = 0..31, so its offsets are fixed at 11..42 and are never checked against the bound field. When the device registers that field with fewer usages, the framebuffer deferred-io work drives the read on every tile. KASAN reports a 4-byte slab-out-of-bounds read in hid_dump_input() below hid_set_field(), and the same boot logs \"offset (1) exceeds report_count (1)\" from the guard that runs only afterwards. Move the hid_dump_input() call below the guard. Because field->maxusage >= field->report_count, the guard then establishes that field->usage + offset lies inside the array before it is dereferenced, for every caller and without changing behaviour on the valid path. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80782", "url": "https://ubuntu.com/security/CVE-2026-80782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: do not keep a stale msc->input if no input is claimed magicmouse_input_mapping() caches the first hid_input's input_dev in msc->input while the report descriptor is parsed, and the rest of the driver treats a non-NULL msc->input as proof that an input device was registered. That does not hold on the hid-input error path. If hidinput_connect() fails -- for instance because input_register_device() returns an error -- it unwinds through hidinput_disconnect(), which frees every input_dev it created, including the one cached in msc->input. The failure does not abort the probe. hid_connect() only skips the claim: \tif ((connect_mask & HID_CONNECT_HIDINPUT) && !hidinput_connect(hdev, \t\t\t\tconnect_mask & HID_CONNECT_HIDINPUT_FORCE)) \t\thdev->claimed |= HID_CLAIMED_INPUT; and the \"device has no listeners\" bailout below it does not fire for this driver, which sets ->raw_event; on the USB Magic Mouse 2 / Magic Trackpad 2 paths hidraw and hiddev are claimed as well. hid_hw_start() therefore returns 0 and magicmouse_probe() continues with msc->input pointing at freed memory. Being non-NULL, it passes the \"input not registered\" check in probe and the NULL checks in ->raw_event and ->event, so the next input report dereferences freed memory. Clear msc->input when the HID core did not claim an input device, so the existing NULL checks cover this case as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-80583", "url": "https://ubuntu.com/security/CVE-2026-80583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses The \"DEC0 MODE\" to \"DEC7 MODE\" controls are enumerated, but tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 (\"ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type\") and commit 0ea5eff7c606 (\"ASoC: codecs: va-macro: fix accessing array out of bounds for enum type\"), but tx-macro was missed. On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value sanity check catches the 4 bytes written past the enumerated item and every read of these controls fails with -EINVAL: snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80587", "url": "https://ubuntu.com/security/CVE-2026-80587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid combining some incoming suboptions Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80547", "url": "https://ubuntu.com/security/CVE-2026-80547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Implement a crw lock Unlike the channel_program struct, which covers synchronous I/O submissions and asynchronous interrupts, the CRW region relies exclusively on asynchronous events coming from hardware. Implement a lock to manage the list of those payloads, to ensure they are read cohesively.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80548", "url": "https://ubuntu.com/security/CVE-2026-80548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Selectively expand io_mutex The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80552", "url": "https://ubuntu.com/security/CVE-2026-80552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure index for read/write regions are within range The introduction of the capability chain rightly clamped the region indexes to the range of the capabilities itself, but neglected to do so for the existing read/write regions which should also be enforced.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80788", "url": "https://ubuntu.com/security/CVE-2026-80788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations When fuzzing the nvme target code, I tripped a kernel warning in nvmet_tcp_map_data() because the length passed into the allocator is controlled by the remote initiator. A remote initiator that sends a command with an SGL claiming a huge number, can create a scatterlist and iovec allocation of over 1 million entries, which causes the backing kmalloc call to exceed MAX_PAGE_ORDER and then the page allocator will trip on a WARN_ON_ONCE_GFP() message: WARNING: mm/page_alloc.c:5280 __alloc_frozen_pages_noprof Workqueue: nvmet_tcp_wq nvmet_tcp_io_work ... sgl_alloc_order nvmet_tcp_map_data nvmet_tcp_try_recv_pdu As it's never good to trip a kernel warning remotely due to many systems having panic-on-warn enabled, let's silence it by just add GFP_NOWARN to the allocation flags.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80790", "url": "https://ubuntu.com/security/CVE-2026-80790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: fix invalid free in LS IOD error path nvmet_fc_alloc_ls_iodlist() advances iod while initializing the LS IOD array. If an rqstbuf allocation or response buffer DMA mapping fails, the unwind loop decrements iod past the start of the array. The final kfree(iod) therefore frees an address before the allocated object. This can be reproduced with nvme-fcloop and failslab by setting fail-nth to 6 before creating a target port. KASAN reports: BUG: KASAN: invalid-free in nvmet_fc_register_targetport Free of addr ffff88816cf8ff48 by task nvmet_fail_nth/9552 Free the original allocation base stored in tgtport->iod instead. With this fix applied, the same sysfs write with fail-nth=6 returns -ENOMEM without any KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80792", "url": "https://ubuntu.com/security/CVE-2026-80792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix use-after-free in ip6_finish_output2() ip6_finish_output2() caches a pointer to the IPv6 destination address (daddr) before invoking lwtunnel_xmit(). The LWT-BPF transmit path or other encapsulation operations within lwtunnel_xmit() can reallocate the skb head, freeing the memory that daddr points to. When lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, the function continues to use the stale daddr pointer to compute the nexthop and to look up or create the neighbour entry. This results in a use-after-free read, which can leak sensitive kernel data, pollute the neighbour table with arbitrary values, misdirect traffic, or crash the system. Fix this by re-fetching the IPv6 header and the destination address pointer after lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, ensuring that the subsequent nexthop computation and neighbour lookup operate on valid memory.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80793", "url": "https://ubuntu.com/security/CVE-2026-80793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: reject undersized MTUs in ip_do_fragment() ip_do_fragment() subtracts the IPv4 header length from the effective MTU and passes the resulting payload MTU to ip_frag_next(). If the effective MTU is smaller than hlen + 8, ip_frag_next() rounds the fragment payload length down to zero. The fragmentation state then never makes forward progress: state->left, state->ptr and state->offset stay unchanged while ip_do_fragment() keeps allocating and transmitting header-only fragments until the softlockup detector fires. This is reproducible with a route installed using \"mtu lock 20\", but it is also reproducible without route MTU lock, for example by forwarding a packet to a device whose MTU is 20. Fix it in ip_do_fragment() by rejecting mtu < hlen + 8 with -EMSGSIZE, matching the existing IPv6 fragmentation check.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80557", "url": "https://ubuntu.com/security/CVE-2026-80557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix OOB read in decode_watchers() via missing bounds check ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80794", "url": "https://ubuntu.com/security/CVE-2026-80794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix uninit-value in the RF discover/activated NTF handlers nci_rf_discover_ntf_packet() and nci_rf_intf_activated_ntf_packet() each parse a notification into an on-stack struct (nci_rf_discover_ntf / nci_rf_intf_activated_ntf) that is not initialised. The RF technology-specific parameters are only extracted when rf_tech_specific_params_len is non-zero, so a notification that reports a zero length leaves the rf_tech_specific_params union uninitialised - and both handlers then pass it to nci_add_new_protocol(), which reads it: - discover: nci_add_new_target() -> nci_add_new_protocol(); - activated: nci_target_auto_activated() -> nci_add_new_protocol(). nci_add_new_protocol() uses nfca_poll->nfcid1_len as both a branch condition and a memcpy() length and copies nfcid1/sens_res/sel_res into ndev->targets, which is later exposed to user space via NFC_CMD_GET_TARGET. BUG: KMSAN: uninit-value in nci_add_new_protocol+0x624/0x6c0 nci_add_new_protocol+0x624/0x6c0 nci_ntf_packet+0x25b2/0x3c30 nci_rx_work+0x318/0x5d0 process_scheduled_works+0x84b/0x17a0 worker_thread+0xc10/0x11b0 kthread+0x376/0x500 Local variable ntf.i created at: nci_ntf_packet+0xbc2/0x3c30 Zero-initialise both on-stack notifications so the union reads back as zero when no technology-specific parameters are present.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80795", "url": "https://ubuntu.com/security/CVE-2026-80795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix out-of-bounds write in nci_target_auto_activated() nci_target_auto_activated() appends a target to the fixed-size array ndev->targets[NCI_MAX_DISCOVERED_TARGETS] and increments ndev->n_targets without first checking the array is full; unlike its sibling nci_add_new_target(), which bails out when n_targets already equals NCI_MAX_DISCOVERED_TARGETS. ndev->n_targets is only cleared by nci_clear_target_list(), so an NFCC that repeatedly re-runs discovery (RF_DISCOVER_RSP, which re-enters NCI_DISCOVERY without clearing the target list) and reports an auto-activated target (RF_INTF_ACTIVATED_NTF) drives n_targets past the limit. The append then writes a struct nfc_target past the end of the array (a slab out-of-bounds write), and nfc_targets_found() goes on to walk the array with the inflated count: BUG: KASAN: slab-out-of-bounds in nci_add_new_protocol+0x94/0x2ac [nci] Write of size 2 at addr ffff0000c7299a18 by task kworker/u8:0/12 Workqueue: nfc0_nci_rx_wq nci_rx_work [nci] Call trace: nci_add_new_protocol+0x94/0x2ac [nci] nci_ntf_packet+0xddc/0x11a0 [nci] nci_rx_work+0x15c/0x1e0 [nci] process_one_work+0x2dc/0x500 worker_thread+0x240/0x460 kthread+0x1c0/0x1d0 ret_from_fork+0x10/0x20 The buggy address belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1024 bytes to the right of allocated 1560-byte region [ffff0000c7299000, ffff0000c7299618) Guard nci_target_auto_activated() with the same check used by nci_add_new_target().", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80823", "url": "https://ubuntu.com/security/CVE-2026-80823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: validate ATR_REQ length against the received frame st21nfca_tm_recv_atr_req() checks that the received ATR_REQ frame is at least ST21NFCA_ATR_REQ_MIN_SIZE and that the self-declared atr_req->length is at least sizeof(struct st21nfca_atr_req), but never checks that atr_req->length does not exceed the actual received length (skb->len). st21nfca_tm_send_atr_res() then trusts the declared length: \tgb_len = atr_req->length - sizeof(struct st21nfca_atr_req); \t... \tmemcpy(atr_res->gbi, atr_req->gbi, gb_len); so an RF peer that sends a short frame but sets atr_req->length larger than the frame makes gb_len exceed the general bytes actually present, and the memcpy reads out of bounds past the received skb. Those bytes are placed in the ATR_RES and sent back to the peer (kernel-memory disclosure to a proximity attacker); a larger declared length is an out-of-bounds read (DoS). Reject frames whose declared length exceeds the received length. The adjacent nfc_tm_activated() path in the same function already derives its general-bytes length from skb->len rather than the declared field. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80797", "url": "https://ubuntu.com/security/CVE-2026-80797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: purge fragmented skbs during cleanup pn53x_common_clean() purges resp_q before freeing the common PN533 state, but it leaves fragment_skb untouched. The fragmentation helpers queue transmit fragments there while sending large initiator or target-mode frames, and those skbs remain owned by the driver until they are sent or discarded. If the device is removed while fragments are still queued, the common cleanup path frees the PN533 state without releasing the queued fragment skbs, leaking them. Purge fragment_skb during cleanup alongside resp_q.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80798", "url": "https://ubuntu.com/security/CVE-2026-80798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: reject PDUs shorter than the LLCP header Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes before parsing it. nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/ nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a CONNECT or CC PDU then computes \ttlv_array_len = skb->len - LLCP_HEADER_SIZE; as a size_t and hands it to the TLV walk. When the frame is shorter than the header the subtraction wraps to a huge value and the walk runs far past the buffer, an out-of-bounds read. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Guard the common receive choke point __nfc_llcp_recv(), shared by both the target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so a short skb is dropped before the rx_work worker parses it. Use pskb_may_pull() rather than a skb->len test so the two header bytes are guaranteed to sit in the skb linear area even for a non-linear skb, matching how the sibling NCI and HCI receive paths validate their headers. Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on linux-next. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80799", "url": "https://ubuntu.com/security/CVE-2026-80799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain three related bugs in their TLV parsing loops: 1. 'offset' is declared u8 but tlv_array_len is u16. When TLV data advances offset past 255 it silently wraps to zero, causing infinite loops or double-processing of buffer data. 2. Before reading tlv[0] (type) and tlv[1] (length) there is no check that offset+2 <= tlv_array_len. A truncated TLV causes an OOB read of one byte past the buffer end. 3. After reading the length field, the value bytes are accessed without checking offset+2+length <= tlv_array_len. A crafted length=0xFF on a short buffer causes up to 255 bytes of OOB read past the buffer end. Both functions are reachable without authentication via nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes directly into nfc_llcp_parse_gb_tlv() with no additional validation. Fix all three issues by widening offset from u8 to u16 and adding bounds checks for both the TLV header and value field before each access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80800", "url": "https://ubuntu.com/security/CVE-2026-80800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound the connect_sn TLV walk to the skb Commit 27256cdb290e (\"nfc: llcp: bound SNL TLV parsing to the skb and add length checks\") fixed the unbounded TLV walk in nfc_llcp_recv_snl(), and commit d8bd2dedbde5 (\"nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers\") subsequently bounded nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv(). One sibling parser sharing the same pattern remains unbounded: nfc_llcp_connect_sn(). nfc_llcp_connect_sn() walks a TLV list, reading a two-byte header (type, length) followed by length bytes of value, without checking that the two header bytes or the declared length stay within the buffer. It returns a pointer to a service name of up to 255 bytes that may point past the end of the skb; it is subsequently consumed by memcmp() in nfc_llcp_sock_from_sn(). In addition tlv_array_len was computed as \"skb->len - LLCP_HEADER_SIZE\" in size_t, so a CONNECT/CC frame shorter than the LLCP header underflows to a huge length and the walk runs far past the buffer. nfc_llcp_connect_sn() is reachable from nfc_llcp_recv_connect() and nfc_llcp_recv_cc(), i.e. from received CONNECT and CC PDUs. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP, and the nfc_llcp_rx_skb() dispatcher applies no minimum-length guard. Walk the TLV list by pointer, bounded by skb_tail_pointer(skb), and validate each declared length before use, matching the approach already used for nfc_llcp_recv_snl(). Starting the walk at &skb->data[LLCP_HEADER_SIZE] against the tail pointer also removes the size_t underflow for short frames. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80801", "url": "https://ubuntu.com/security/CVE-2026-80801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: microread: validate target discovery payload lengths microread_target_discovered() parses target discovery payloads from skb->data according to the HCI gate. The fixed field offsets and UID copies were checked only against the destination nfc_target buffers, not against the actual skb length. Validate that each gate-specific payload contains the fixed fields and UID bytes before reading or copying them.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80802", "url": "https://ubuntu.com/security/CVE-2026-80802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: bound the device-reported read length and fix an skb leak fdp_nci_i2c_read() takes the next packet length from two device-supplied bytes and never validates it. The value is a u16 used as the i2c_master_recv() count into a 261-byte on-stack buffer: a malicious, counterfeit or malfunctioning controller (or an i2c bus interposer) can drive it far past the buffer for a stack out-of-bounds write that clobbers the canary and return address, or below the minimum frame size (directly, or by truncating the computed sum) so the header/LRC strip and the next length read run past a short receive. Reject a length outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD], as a corrupted packet already is, and force resynchronization. The same loop allocates one data skb per iteration and assumes a length packet followed by a data packet; a device that sends two data packets in one call leaks the first skb when the second allocation overwrites it. Free a previously allocated skb before allocating the next.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80803", "url": "https://ubuntu.com/security/CVE-2026-80803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: digital: clamp SENSF_RES length to the destination buffer digital_in_recv_sensf_res() memcpy()s resp->len bytes from a remote NFC-F device response into the NFC_SENSF_RES_MAXSIZE-byte target.sensf_res field without an upper-bound check. A nearby malicious NFC-F device can send an oversized SENSF_RES response to overflow the stack-local struct nfc_target. Clamp resp->len to NFC_SENSF_RES_MAXSIZE before the copy. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80536", "url": "https://ubuntu.com/security/CVE-2026-80536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: bounds-check buffer log item's dirty bitmap xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: \tmemcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), \t\titem->ri_buf[i].iov_base, \t\tnbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80553", "url": "https://ubuntu.com/security/CVE-2026-80553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Cancel existing workqueues The initialization of the io_work and crw_work workqueues begs the question of whether they should be un-initialized. Add the corresponding cleanup tags in _release_dev to ensure work isn't dispatched after the private struct is free'd.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74662", "url": "https://ubuntu.com/security/CVE-2026-74662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: publish queues before arming timer inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74666", "url": "https://ubuntu.com/security/CVE-2026-74666", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: synchronize pressure clearing with ring reconfiguration packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74663", "url": "https://ubuntu.com/security/CVE-2026-74663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: reject overly deep qdisc hierarchies Deep qdisc hierarchies can lead to excessive recursion in qdisc tree walkers and exhaust the kernel stack. The existing loop check does not cover the create-and-graft path, so a hierarchy can still be extended by creating a new child qdisc below an already deep parent. Store the hierarchy depth in struct Qdisc and update it when qdiscs are grafted. Reject new child qdiscs once the parent is already at the maximum allowed depth.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74668", "url": "https://ubuntu.com/security/CVE-2026-74668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in TX_RING send path tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative. Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb(). The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74582", "url": "https://ubuntu.com/security/CVE-2026-74582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in non-ring send paths packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-80737", "url": "https://ubuntu.com/security/CVE-2026-80737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: synchronize DMA teardown dmaengine_terminate_all() does not wait for a running callback, so the TX callback can still touch the TX buffer after it is freed. The RX poll timer reads the RX buffers without the port lock. Switch to dmaengine_terminate_sync() and delete the RX timer before freeing the buffers.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74626", "url": "https://ubuntu.com/security/CVE-2026-74626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_netdev: Preserve RX queue depth on allocation failure ntb_netdev_rx_handler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception. A retry path could refill the queue later, but ntb_netdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74637", "url": "https://ubuntu.com/security/CVE-2026-74637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix group leader use-after-free after sibling detach perf_group_detach() handles leader and sibling detach differently. When the group leader is detached, all siblings are promoted to singleton events and their group_leader pointer is reset to themselves. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. That is harmless when the sibling is being closed and freed immediately, as in the DETACH_DEAD path. It is not safe when the sibling is detached but kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the sibling is removed from the context, while its file descriptor can still keep it alive. A typical failing sequence is: - A group contains leader L and sibling S. - CPU hot-unplug detaches S with DETACH_GROUP, removing it from L->sibling_list but leaving S->group_leader == L. - L is later closed and freed. - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and dereferences the freed leader. This was reproduced by running the perf event fuzzer, CPU hotplug, and a stress workload concurrently: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT pc : perf_ioctl+0x34c/0xc68 x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908) Call trace: perf_ioctl+0x34c/0xc68 (P) __arm64_sys_ioctl+0xa0/0xf4 invoke_syscall+0x58/0xe4 el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x40/0xc0 el0t_64_sync_handler+0x68/0xdc el0t_64_sync+0x1c4/0x1c8 The fault happened in perf_ioctl(), where perf_event_for_each() follows the stale group_leader pointer and perf_event_for_each_child() then dereferences the freed leader's context. Fix the use-after-free by promoting the detached sibling to a singleton. Also fix __event_disable() cgroup accounting and event state change.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74647", "url": "https://ubuntu.com/security/CVE-2026-74647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Remove buffer from list prior to unmap operation fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74632", "url": "https://ubuntu.com/security/CVE-2026-74632", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix huge_zero_pfn race Patch series \"mm/huge_memory: fix huge_zero_pfn race\", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80562", "url": "https://ubuntu.com/security/CVE-2026-80562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: ml-ioh: use raw_spinlock_t for the register lock ioh_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irq_set_type callback additionally emits a dev_warn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same fix as commit a02b8950d619 (\"gpio: pch: use raw_spinlock_t for the register lock\"); this driver shares the same structure as gpio-pch.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80805", "url": "https://ubuntu.com/security/CVE-2026-80805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: validate attr entry pointer before field access xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen, valuelen) before checking if the entry pointer itself is within bounds. If nameidx is crafted to point near the end of the buffer, these field accesses can read out-of-bounds before the bounds check at name_end > buf_end is performed. Add explicit bounds checks for entry pointers before accessing their fields. Use offsetof() to check that the start of the flexible array member (nameval/name) is within bounds, which ensures all preceding fields are safe to access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80808", "url": "https://ubuntu.com/security/CVE-2026-80808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: stop retrying saturated xattr cache entries ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked. Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop. Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition. Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80809", "url": "https://ubuntu.com/security/CVE-2026-80809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix missing metadata reservation for large xattrs [BUG] lsetxattr() panics the kernel when setting a large xattr value on a fragmented filesystem where the file already has an external xattr block. [CAUSE] ocfs2_calc_xattr_set_need() never reserves metadata blocks for a new xattr value's extent tree when the file already has an external xattr block. The not_found path leaves meta_add at zero, so meta_ac is NULL when ocfs2_xattr_extend_allocation() runs. A new value root has room for a single extent record. On a fragmented filesystem, the allocator cannot satisfy the xattr value in one contiguous run, so each non-contiguous run requires its own extent record. When the value root's extent list is full and meta_ac is NULL, ocfs2_add_clusters_in_btree() returns RESTART_META, and ocfs2_xattr_extend_allocation() hits BUG_ON(why == RESTART_META). [FIX] The case where no xattr block exists yet already calls ocfs2_extend_meta_needed(&def_xv.xv.xr_list) to reserve value tree metadata. Add the same reservation to the case where an xattr block already exists, making the two cases consistent. Replace the BUG_ON with a -ENOSPC return so that if RESTART_META is returned despite the reservation, the error propagates to userspace instead of panicking the kernel.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80812", "url": "https://ubuntu.com/security/CVE-2026-80812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dummy: Check card index validity at probe snd_dummy_probe() blindly trusts that the given devptr->id value is within the proper card index range. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80814", "url": "https://ubuntu.com/security/CVE-2026-80814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rndis_host: add overflow check in rndis_rx_fixup() Add an overflow check to ensure that data_offset + data_len + 8 does not wrap, which would enable an OOB read of the USB data buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80819", "url": "https://ubuntu.com/security/CVE-2026-80819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept rfcomm_sock_recvmsg() completes a deferred setup by calling rfcomm_dlc_accept() without holding any RFCOMM lock: \tif (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { \t\trfcomm_dlc_accept(d); \t\treturn 0; \t} and rfcomm_dlc_accept() dereferences the session on its first line: \tstruct sock *sk = d->session->sock->sk; Every other path that touches d->session runs under rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). rfcomm_connect_ind() is even documented as \"called under rfcomm_lock()\". This call site is the only one that skips it. The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against teardown, since __rfcomm_dlc_close() returns early when it wins the test_and_clear. But rfcomm_recv_disc() forces the state first: \td->state = BT_CLOSED; \t__rfcomm_dlc_close(d, err); and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2. With the state already BT_CLOSED that switch does not match, the bit is never consulted, and __rfcomm_dlc_close() falls through to rfcomm_dlc_unlink(), which sets d->session = NULL. So a remote DISC on a deferred dlc clears the session while leaving RFCOMM_DEFER_SETUP set. The next recvmsg() then passes the test_and_clear and dereferences a NULL session. No timing window is needed: once the DISC has been processed, the dereference is unconditional. Give rfcomm_dlc_accept() the same shape as rfcomm_dlc_open() and rfcomm_dlc_close(): an exported wrapper that takes rfcomm_mutex and re-checks the session, around a __rfcomm_dlc_accept() that the two in-core callers, which already hold the mutex, keep using. Reproduced on a KASAN + PROVE_LOCKING kernel with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session, opens a dlc on a channel bound with BT_DEFER_SETUP, and sends DISC after the socket is accepted. recv() on the accepted socket then hits: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10 is the offset of sock in struct rfcomm_session. With this patch the same run completes with recv() returning 0 and no report, and lockdep stays quiet, confirming rfcomm_mutex is still taken before lock_sock on this path as it is on the thread side.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80917", "url": "https://ubuntu.com/security/CVE-2026-80917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems On 32-bit systems the config space is too large to ioremap in one go, so pci_ecam_create() maps each bus segment separately and relies on the ->add_bus callback (pci_ecam_add_bus) to populate the per-bus mapping in cfg->winp[]. pci_ecam_map_bus() then uses that mapping as the base for every config access. The generic ECAM ops (pci_generic_ecam_ops) already provide the ->add_bus and ->remove_bus callbacks, but the CAM (legacy) ops in pci-host-generic.c do not. As a result, on a 32-bit host using \"pci-host-cam-generic\" the per-bus mapping is never set up and the first config read dereferences a NULL base, crashing during bus enumeration: Unable to handle kernel NULL pointer dereference at virtual address 00000800 Oops [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 6.9.7+ #43 Hardware name: Digilent Nexys-Video-A7 RV32 (DT) epc : pci_generic_config_read+0x40/0xb0 ra : pci_generic_config_read+0x2c/0xb0 [] pci_generic_config_read+0x40/0xb0 [] pci_bus_read_config_dword+0x50/0xb0 [] pci_bus_generic_read_dev_vendor_id+0x3c/0x1ec [] pci_scan_single_device+0xa4/0x11c [] pci_scan_slot+0x9c/0x23c [] pci_scan_child_bus_extend+0x58/0x2f4 [] pci_scan_root_bus_bridge+0x64/0xe8 [] pci_host_probe+0x20/0xc8 [] pci_host_common_probe+0x144/0x1e4 Fix this by giving the CAM ops the same ->add_bus/->remove_bus callbacks. Since pci_ecam_add_bus() and pci_ecam_remove_bus() are static to ecam.c, move the CAM ops definition there as pci_generic_cam_ops (mirroring pci_generic_ecam_ops) and export it for pci-host-generic.c to reference. [mani: removed timestamp from log]", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2022-1205", "url": "https://ubuntu.com/security/CVE-2022-1205", "cve_description": "A NULL pointer dereference flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system.", "cve_priority": "high", "cve_public_date": "2022-08-31 16:15:00 UTC" }, { "cve": "CVE-2022-50303", "url": "https://ubuntu.com/security/CVE-2022-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix double release compute pasid If kfd_process_device_init_vm returns failure after vm is converted to compute vm and vm->pasid set to compute pasid, KFD will not take pdd->drm_file reference. As a result, drm close file handler maybe called to release the compute pasid before KFD process destroy worker to release the same pasid and set vm->pasid to zero, this generates below WARNING backtrace and NULL pointer access. Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step of kfd_process_device_init_vm, to ensure vm pasid is the original pasid if acquiring vm failed or is the compute pasid with pdd->drm_file reference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10", "cve_priority": "medium", "cve_public_date": "2025-09-15 15:15:00 UTC" }, { "cve": "CVE-2023-53320", "url": "https://ubuntu.com/security/CVE-2023-53320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info() The function mpi3mr_get_all_tgt_info() has four issues: 1) It calculates valid entry length in alltgt_info assuming the header part of the struct mpi3mr_device_map_info would equal to sizeof(u32). The correct size is sizeof(u64). 2) When it calculates the valid entry length kern_entrylen, it excludes one entry by subtracting 1 from num_devices. 3) It copies num_device by calling memcpy(). Substitution is enough. 4) It does not specify the calculated length to sg_copy_from_buffer(). Instead, it specifies the payload length which is larger than the alltgt_info size. It causes \"BUG: KASAN: slab-out-of-bounds\". Fix the issues by using the correct header size, removing the subtraction from num_devices, replacing the memcpy() with substitution and specifying the correct length to sg_copy_from_buffer().", "cve_priority": "low", "cve_public_date": "2025-09-16 17:15:00 UTC" }, { "cve": "CVE-2025-39726", "url": "https://ubuntu.com/security/CVE-2025-39726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ism: fix concurrency management in ism_cmd() The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that. This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well. A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it. On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.", "cve_priority": "high", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39779", "url": "https://ubuntu.com/security/CVE-2025-39779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: subpage: keep TOWRITE tag until folio is cleaned btrfs_subpage_set_writeback() calls folio_start_writeback() the first time a folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tag even if there are still dirty blocks in the folio. This can break ordering guarantees, such as those required by btrfs_wait_ordered_extents(). That ordering breakage leads to a real failure. For example, running generic/464 on a zoned setup will hit the following ASSERT. This happens because the broken ordering fails to flush existing dirty pages before the file size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode or for compressed writes, it locks several folios for delalloc and starts writing them out. Let's call the last locked folio folio X. Suppose the write range only partially covers folio X, leaving some pages dirty. Process A calls btrfs_subpage_set_writeback() when building a bio. This function call clears the TOWRITE tag of folio X, whose size = 8K and the block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range. Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. It calls tag_pages_for_writeback() to tag dirty folios with PAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then, B collects tagged folios using filemap_get_folios_tag() and must wait for folio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE) However, between tagging and collecting, process A may call btrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY) As a result, process B won't see folio X in its batch, and returns without waiting for it. This breaks the WB_SYNC_ALL ordering requirement. Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retains the TOWRITE tag. We now manually clear the tag only after the folio becomes clean, via the xas operation.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39810", "url": "https://ubuntu.com/security/CVE-2025-39810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix memory corruption when FW resources change during ifdown bnxt_set_dflt_rings() assumes that it is always called before any TC has been created. So it doesn't take bp->num_tc into account and assumes that it is always 0 or 1. In the FW resource or capability change scenario, the FW will return flags in bnxt_hwrm_if_change() that will cause the driver to reinitialize and call bnxt_cancel_reservations(). This will lead to bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc may be greater than 1. This will cause bp->tx_ring[] to be sized too small and cause memory corruption in bnxt_alloc_cp_rings(). Fix it by properly scaling the TX rings by bp->num_tc in the code paths mentioned above. Add 2 helper functions to determine bp->tx_nr_rings and bp->tx_nr_rings_per_tc.", "cve_priority": "low", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-37861", "url": "https://ubuntu.com/security/CVE-2025-37861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.", "cve_priority": "low", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-38643", "url": "https://ubuntu.com/security/CVE-2025-38643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() Callers of wdev_chandef() must hold the wiphy mutex. But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes: WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985", "cve_priority": "low", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38615", "url": "https://ubuntu.com/security/CVE-2025-38615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: cancle set bad inode after removing name fails The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted. The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's \"icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier\". In some it's outright \"we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles\".", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38361", "url": "https://ubuntu.com/security/CVE-2025-38361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check dce_hwseq before dereferencing it [WHAT] hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used. (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)", "cve_priority": "low", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38259", "url": "https://ubuntu.com/security/CVE-2025-38259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd9335: Fix missing free of regulator supplies Driver gets and enables all regulator supplies in probe path (wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup in final error paths and in unbind (missing remove() callback). This leads to leaked memory and unbalanced regulator enable count during probe errors or unbind. Fix this by converting entire code into devm_regulator_bulk_get_enable() which also greatly simplifies the code.", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38239", "url": "https://ubuntu.com/security/CVE-2025-38239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix invalid node index On a system with DRAM interleave enabled, out-of-bound access is detected: megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it accordingly.", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2022-50071", "url": "https://ubuntu.com/security/CVE-2022-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: move subflow cleanup in mptcp_destroy_common() If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE eBPF program, the MPTCP protocol ends-up leaking all the subflows: the related cleanup happens in __mptcp_destroy_sock() that is not invoked in such code path. Address the issue moving the subflow sockets cleanup in the mptcp_destroy_common() helper, which is invoked in every msk cleanup path. Additionally get rid of the intermediate list_splice_init step, which is an unneeded relic from the past. The issue is present since before the reported root cause commit, but any attempt to backport the fix before that hash will require a complete rewrite.", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2025-37920", "url": "https://ubuntu.com/security/CVE-2025-37920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: Fix race condition in AF_XDP generic RX path Move rx_lock from xsk_socket to xsk_buff_pool. Fix synchronization for shared umem mode in generic RX path where multiple sockets share single xsk_buff_pool. RX queue is exclusive to xsk_socket, while FILL queue can be shared between multiple sockets. This could result in race condition where two CPU cores access RX path of two different sockets sharing the same umem. Protect both queues by acquiring spinlock in shared xsk_buff_pool. Lock contention may be minimized in the future by some per-thread FQ buffering. It's safe and necessary to move spin_lock_bh(rx_lock) after xsk_rcv_check(): * xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers. * xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-43456", "url": "https://ubuntu.com/security/CVE-2026-43456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix type confusion in bond_setup_by_slave() kernel BUG at net/core/skbuff.c:2306! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306 RSP: 0018:ffffc90004aff760 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900 RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780 R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0 Call Trace: ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900 dev_hard_header include/linux/netdevice.h:3439 [inline] packet_snd net/packet/af_packet.c:3028 [inline] packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592 ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646 __sys_sendmsg+0x170/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe1a0e6c1a9 When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond, bond_setup_by_slave() directly copies the slave's header_ops to the bond device: bond_dev->header_ops = slave_dev->header_ops; This causes a type confusion when dev_hard_header() is later called on the bond device. Functions like ipgre_header(), ip6gre_header(),all use netdev_priv(dev) to access their device-specific private data. When called with the bond device, netdev_priv() returns the bond's private data (struct bonding) instead of the expected type (e.g. struct ip_tunnel), leading to garbage values being read and kernel crashes. Fix this by introducing bond_header_ops with wrapper functions that delegate to the active slave's header_ops using the slave's own device. This ensures netdev_priv() in the slave's header functions always receives the correct device. The fix is placed in the bonding driver rather than individual device drivers, as the root cause is bond blindly inheriting header_ops from the slave without considering that these callbacks expect a specific netdev_priv() layout. The type confusion can be observed by adding a printk in ipgre_header() and running the following commands: ip link add dummy0 type dummy ip addr add 10.0.0.1/24 dev dummy0 ip link set dummy0 up ip link add gre1 type gre local 10.0.0.1 ip link add bond1 type bond mode active-backup ip link set gre1 master bond1 ip link set gre1 up ip link set bond1 up ip addr add fe80::1/64 dev bond1", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2022-49858", "url": "https://ubuntu.com/security/CVE-2022-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix SQE threshold checking Current way of checking available SQE count which is based on HW updated SQB count could result in driver submitting an SQE even before CQE for the previously transmitted SQE at the same index is processed in NAPI resulting losing SKB pointers, hence a leak. Fix this by checking a consumer index which is updated once CQE is processed.", "cve_priority": "medium", "cve_public_date": "2025-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-22057", "url": "https://ubuntu.com/security/CVE-2025-22057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: decrease cached dst counters in dst_release Upstream fix ac888d58869b (\"net: do not delay dst_entries_add() in dst_release()\") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30 Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-22083", "url": "https://ubuntu.com/security/CVE-2025-22083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang: 1. Use-after-free when no tpgs are found: This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If a scsi request is then sent we do: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend which sees the vs_tpg we just did a kfree on. 2. Tpg dir removal hang: This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1. The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg. Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir. 3. Tpg leak: This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names. The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs. Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2024-58096", "url": "https://ubuntu.com/security/CVE-2024-58096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode ath11k_hal_srng_* should be used with srng->lock to protect srng data. For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock. So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319 So add srng->lock for them to avoid such warnings. Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct hal_srng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_process_rx(). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-21947", "url": "https://ubuntu.com/security/CVE-2025-21947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix type confusion via race condition when using ipc_msg_send_request req->handle is allocated using ksmbd_acquire_id(&ipc_ida), based on ida_alloc. req->handle from ksmbd_ipc_login_request and FSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion between messages, resulting in access to unexpected parts of memory after an incorrect delivery. ksmbd check type of ipc response but missing add continue to check next ipc reponse.", "cve_priority": "high", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2022-49562", "url": "https://ubuntu.com/security/CVE-2022-49562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing \"random\" pfns for pretty much any other VM_PFNMAP case.", "cve_priority": "low", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2025-21812", "url": "https://ubuntu.com/security/CVE-2025-21812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: rcu protect dev->ax25_ptr syzbot found a lockdep issue [1]. We should remove ax25 RTNL dependency in ax25_setsockopt() This should also fix a variety of possible UAF in ax25. [1] WARNING: possible circular locking dependency detected 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted ------------------------------------------------------ syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated---", "cve_priority": "high", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21801", "url": "https://ubuntu.com/security/CVE-2025-21801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ravb: Fix missing rtnl lock in suspend/resume path Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations. Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down", "cve_priority": "low", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-54683", "url": "https://ubuntu.com/security/CVE-2024-54683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: IDLETIMER: Fix for possible ABBA deadlock Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs: | ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20 | | but task is already holding lock: | ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v] | | which lock already depends on the new lock. A simple reproducer is: | #!/bin/bash | | while true; do | iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\" | iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\" | done & | while true; do | cat /sys/class/xt_idletimer/timers/testme >/dev/null | done Avoid this by freeing list_mutex right after deleting the element from the list, then continuing with the teardown.", "cve_priority": "medium", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2024-53220", "url": "https://ubuntu.com/security/CVE-2024-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to account dirty data in __get_secs_required() It will trigger system panic w/ testcase in [1]: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2752! RIP: 0010:new_curseg+0xc81/0x2110 Call Trace: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is if checkpoint_disabling and lfs_mode are both on, it will trigger OPU for all overwritten data, it may cost more free segment than expected, so f2fs must account those data correctly to calculate cosumed free segments later, and return ENOSPC earlier to avoid run out of free segment during block allocation. [1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2025-21759", "url": "https://ubuntu.com/security/CVE-2025-21759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: extend RCU protection in igmp6_send() igmp6_send() can be called without RTNL or RCU being held. Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection.", "cve_priority": "high", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57999", "url": "https://ubuntu.com/security/CVE-2024-57999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing. These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range. The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries Workqueue: events work_for_cpu_fn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100 LR [c00000000005e830] iommu_init_table+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620 [c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 There are 2 issues in the code 1. The index is \"int\" while the address is \"unsigned long\". This results in negative value when setting the bitmap. 2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well.", "cve_priority": "low", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57982", "url": "https://ubuntu.com/security/CVE-2024-57982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: state: fix out-of-bounds read during lookup lookup and resize can run in parallel. The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array. rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask; While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) { This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again). Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent. The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side. xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2022-49651", "url": "https://ubuntu.com/security/CVE-2022-49651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: srcu: Tighten cleanup_srcu_struct() GP checks Currently, cleanup_srcu_struct() checks for a grace period in progress, but it does not check for a grace period that has not yet started but which might start at any time. Such a situation could result in a use-after-free bug, so this commit adds a check for a grace period that is needed but not yet started to cleanup_srcu_struct().", "cve_priority": "low", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2022-49359", "url": "https://ubuntu.com/security/CVE-2022-49359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Job should reference MMU not file_priv For a while now it's been allowed for a MMU context to outlive it's corresponding panfrost_priv, however the job structure still references panfrost_priv to get hold of the MMU context. If panfrost_priv has been freed this is a use-after-free which I've been able to trigger resulting in a splat. To fix this, drop the reference to panfrost_priv in the job structure and add a direct reference to the MMU structure which is what's actually needed.", "cve_priority": "high", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2022-49234", "url": "https://ubuntu.com/security/CVE-2022-49234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: Avoid cross-chip syncing of VLAN filtering Changes to VLAN filtering are not applicable to cross-chip notifications. On a system like this: .-----. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-' '-1-2-' '-1-2-' Before this change, upon sw1p1 leaving a bridge, a call to dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1. In this scenario: .---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-' When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be called for sw2 and sw3 with a non-existing port - leading to array out-of-bounds accesses and crashes on mv88e6xxx.", "cve_priority": "medium", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2024-57945", "url": "https://ubuntu.com/security/CVE-2024-57945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Fix the out of bound issue of vmemmap address In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)). However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page. For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END. This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base.", "cve_priority": "low", "cve_public_date": "2025-01-21 13:15:00 UTC" }, { "cve": "CVE-2024-53210", "url": "https://ubuntu.com/security/CVE-2024-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct() Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skb_queue_purge() and WARN_ON in iucv_sock_destruct() during socket close. To fix this decrease skb refcount by one if MSG_PEEK is set in order to prevent memory leak and WARN_ON. WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53187", "url": "https://ubuntu.com/security/CVE-2024-53187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check for overflows in io_pin_pages WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2170108, 2170970, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168549, 2168549, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168510, 2168199, 2168214, 2107442, 2129861 ], "changes": [ { "cves": [ { "cve": "CVE-2025-68190", "url": "https://ubuntu.com/security/CVE-2025-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked() kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-46242", "url": "https://ubuntu.com/security/CVE-2026-46242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s \"*pprev = next\" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays.", "cve_priority": "high", "cve_public_date": "2026-05-30 13:16:00 UTC" }, { "cve": "CVE-2025-38349", "url": "https://ubuntu.com/security/CVE-2025-38349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: don't decrement ep refcount while still holding the ep mutex Jann Horn points out that epoll is decrementing the ep refcount and then doing a mutex_unlock(&ep->mtx); afterwards. That's very wrong, because it can lead to a use-after-free. That pattern is actually fine for the very last reference, because the code in question will delay the actual call to \"ep_free(ep)\" until after it has unlocked the mutex. But it's wrong for the much subtler \"next to last\" case when somebody *else* may also be dropping their reference and free the ep while we're still using the mutex. Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion. A mutex \"unlock\" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up. See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics: \t\"mutex_unlock() may access the mutex structure even after it has \t internally released the lock already - so it's not safe for \t another context to acquire the mutex and assume that the \t mutex_unlock() context is not using the structure anymore\" So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops _their_ reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it. Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole _point_ of refcounts: unlike mutexes, they are inherently about object lifetimes).", "cve_priority": "high", "cve_public_date": "2025-07-18 08:15:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-80726", "url": "https://ubuntu.com/security/CVE-2026-80726", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-46113", "url": "https://ubuntu.com/security/CVE-2026-46113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, \"KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE\", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the \"correct\" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the \"wrong\" shadow page. However, that was only an imprecision until 2032a93d66fa (\"KVM: MMU: Don't allocate gfns page for direct mmu pages\") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-52988", "url": "https://ubuntu.com/security/CVE-2026-52988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase Publish new hooks in the list into the basechain/flowtable using splice_list_rcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on.", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2023-53231", "url": "https://ubuntu.com/security/CVE-2023-53231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: Fix detection of atomic context Current check for atomic context is not sufficient as z_erofs_decompressqueue_endio can be called under rcu lock from blk_mq_flush_plug_list(). See the stacktrace [1] In such case we should hand off the decompression work for async processing rather than trying to do sync decompression in current context. Patch fixes the detection by checking for rcu_read_lock_any_held() and while at it use more appropriate !in_task() check than in_atomic(). Background: Historically erofs would always schedule a kworker for decompression which would incur the scheduling cost regardless of the context. But z_erofs_decompressqueue_endio() may not always be in atomic context and we could actually benefit from doing the decompression in z_erofs_decompressqueue_endio() if we are in thread context, for example when running with dm-verity. This optimization was later added in patch [2] which has shown improvement in performance benchmarks. ============================================== [1] Problem stacktrace [name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291 [name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi [name:core&]preempt_count: 0, expected: 0 [name:core&]RCU nest depth: 1, expected: 0 CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1 Hardware name: MT6897 (DT) Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4 [2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/", "cve_priority": "medium", "cve_public_date": "2025-09-15 15:15:00 UTC" }, { "cve": "CVE-2023-53707", "url": "https://ubuntu.com/security/CVE-2023-53707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1 The type of size is unsigned int, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later.", "cve_priority": "medium", "cve_public_date": "2025-10-22 14:15:00 UTC" }, { "cve": "CVE-2024-49568", "url": "https://ubuntu.com/security/CVE-2024-49568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg When receiving proposal msg in server, the fields v2_ext_offset/ eid_cnt/ism_gid_cnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2_ext_offset, once exceed the max value, there has the chance to access wrong address, and crash may happen. This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt before using them.", "cve_priority": "high", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2026-89560", "url": "https://ubuntu.com/security/CVE-2026-89560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation Whiteout objects are used in the upper layer of an OverlayFS to indicate that the file with this name does not exist in the unified view, even if it is present in one of the lower layer file systems. For the userspace implementations of OverlayFS (fuse-overlayfs), whiteout objects can be created from userspace as well: * mknod(2) with S_IFCHR and makedev(0, 0) * renameat2(2) with RENAME_WHITEOUT, creating the whiteout in the old place of the moved file. This commit guards whiteout creation in both of these cases with LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered character devices and are not bound to a driver. LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a whiteout object: creating one is the only S_IFCHR creation that the VFS exempts from CAP_MKNOD, so it is as unprivileged as creating a regular file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that expose a kernel interface [1]. For the mknod(2) case, introduce a Landlock erratum. The creation of whiteout objects through mknod(2) was previously guarded using LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using LANDLOCK_ACCESS_FS_MAKE_REG. For the renameat2(2) case, fix a bug: Before this commit, renameat2(2) with RENAME_WHITEOUT would create a directory entry even when all LANDLOCK_ACCESS_FS_MAKE_* rights were denied. This does not affect normal renames within layered OverlayFS mounts: When doing a regular rename() on a mounted fuse-overlayfs, it is the fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT, and only the Landlock domain of that daemon is checked there. Depends-on: 49c9e09d9610 (\"landlock: Fix handling of disconnected directories\") Depends-on: fe72ce6710cb (\"landlock: Add errata documentation section\") [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and add link(2) to the user doc]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2024-41062", "url": "https://ubuntu.com/security/CVE-2024-41062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bluetooth/l2cap: sync sock recv cb and release The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work \t l2cap_sock_release hci_acldata_packet \t l2cap_sock_kill l2cap_recv_frame \t sk_free l2cap_conless_channel \t l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.", "cve_priority": "high", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2022-50406", "url": "https://ubuntu.com/security/CVE-2022-50406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: iomap: fix memory corruption when recording errors during writeback Every now and then I see this crash on arm64: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dm_thin_pool dm_persistent_data XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296). dm_bio_prison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0 dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECT potentially unexpected fatal signal 6. nf_reject_ipv6 potentially unexpected fatal signal 6. ipt_REJECT nf_reject_ipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) ip_tables pc : 000003fd6d7df200 x_tables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wb_workfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseq_set+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : __filemap_set_wb_err+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseq_set+0x1c/0x100 __filemap_set_wb_err+0x24/0xe0 iomap_do_writepage+0x5e4/0xd5c write_cache_pages+0x208/0x674 iomap_writepages+0x34/0x60 xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: ---truncated---", "cve_priority": "low", "cve_public_date": "2025-09-18 16:15:00 UTC" }, { "cve": "CVE-2026-97523", "url": "https://ubuntu.com/security/CVE-2026-97523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close race between scheduler and state change The mptcp scheduler may race with subflow sockets state change: data transmission on the selected socket may fail and a later release could try to use mss_now reset to 0 for a divide operation. Address the issue by explicitly checking for the critical scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97524", "url": "https://ubuntu.com/security/CVE-2026-97524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid unneeded actions on subflow reset Once in a blue moon, the mptcp receive path can recursively call mptcp_data_ready() via state change under unlucky error conditions, and then try to hold the data lock again. Break the recursion loop explicitly checking for the exceptional condition. Add a new flag instead of using an existing one like 'closing', to exit early in subflow_state_change(), and explicitly flush the RX queue at reset time. This avoids unneeded processing to check for available data -- calling get_mapping_status() and more on a dying subflow -- but also in error reporting and worker scheduling. Note that we must consume the currently peeked skb before invoking mptcp_dss_corruption to avoid consuming it again after the eventual reset has freed it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-80833", "url": "https://ubuntu.com/security/CVE-2026-80833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ss support which is one of the only remaining ones. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. Also, it had a buffer overread bug in the line 'memcpy(ctx->seed, d + dlen, ctx->slen);'. There's no point in fixing these bugs separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80834", "url": "https://ubuntu.com/security/CVE-2026-80834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ce support which is one of the only remaining ones. Note that the sun8i-ce support for hwrng remains in place. That is the interface that actually matters. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. There's no point in fixing this separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-74496", "url": "https://ubuntu.com/security/CVE-2026-74496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Fix use-after-free in fou_create() fou_create() publishes struct fou through sk_user_data before adding the new FOU port to the per-netns list. If fou_add_to_port_list() fails, the error path frees fou while it is still reachable through sk_user_data. A concurrent receive can then dereference the freed object in fou_from_sock(). This ordering issue was previously noted in the linked discussion. The failure is reachable when local port 0 is requested. Each socket binds to a different ephemeral port, but fou_cfg_cmp() compares the requested port 0 and reports -EALREADY once an entry already exists. Release the tunnel socket before freeing fou so sk_user_data is cleared first, and defer reclamation with kfree_rcu() to protect concurrent RCU readers. This matches the lifetime handling in fou_release().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-93286", "url": "https://ubuntu.com/security/CVE-2026-93286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: appletalk: fix NULL pointer dereference in aarp_send_ddp() aarp_send_ddp() calls atalk_find_dev_addr(dev) in the LocalTalk fast path without checking for NULL. When the device has no AppleTalk interface configured (dev->atalk_ptr == NULL), this leads to a NULL pointer dereference at the at->s_net access. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:aarp_send_ddp (net/appletalk/aarp.c:552 (discriminator 2)) Call Trace: atalk_sendmsg (net/appletalk/ddp.c:1715) __sys_sendto (net/socket.c:2265 (discriminator 1)) __x64_sys_sendto (net/socket.c:2272) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Add a NULL check consistent with the other callers of atalk_find_dev_addr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93287", "url": "https://ubuntu.com/security/CVE-2026-93287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: reject oversized block transfers in the common path The SMBus block transfer length data->block[0] is validated in i2c_smbus_xfer_emulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbus_xfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked. Add an early validation in __i2c_smbus_xfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback runs. data->block[0] is filled in by the device on SMBus block reads, so the check is scoped to operations where the length is actually supplied by the caller. This is consistent with the existing -EINVAL convention in the emulated path and protects all downstream consumers at once: the smbus_write tracepoint, all native smbus_xfer driver implementations, and the emulated path. Two distinct bugs are fixed by this change: Bug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h) trace_smbus_write() fires before any validation and copies data->block[0]+1 bytes into a 34-byte event buffer. With block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221. BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91 Call Trace: __asan_memcpy+0x23/0x80 trace_event_raw_event_smbus_write+0x27c/0x530 __i2c_smbus_xfer+0x43a/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c) stub_xfer() implements .smbus_xfer directly and only clamps block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With block[0]=0xff and command=0 the loop accesses block[1+i] for i up to 254, far past the 34-byte union. UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44 index 34 is out of range for type '__u8 [34]' Call Trace: __ubsan_handle_out_of_bounds+0xd7/0x120 stub_xfer+0x1971/0x198f [i2c_stub] __i2c_smbus_xfer+0x306/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97931", "url": "https://ubuntu.com/security/CVE-2026-97931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: us122l: Prevent write upgrades for read mappings The hwdep mmap callback rejects read-buffer mappings that are initially writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ. A process that can open the hwdep node O_RDWR can later use mprotect() to make the mapping writable. The read allocation begins with struct usb_stream. Its read_size member is used by the fault handler to decide which pages belong to the read buffer. The read VMA intentionally remains expandable because pcm_usb_stream uses mremap() after reading that size. Changing read_size first can therefore map and access pages beyond the allocation. The same member is also consumed by usb_stream_free(), where changing it can make free_pages_exact() release pages outside the allocation. Clear VM_MAYWRITE for read-buffer mappings after rejecting an initially writable VMA. This keeps the separate output-buffer mapping writable while preventing later permission upgrades.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97568", "url": "https://ubuntu.com/security/CVE-2026-97568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: syncookies: remember the request backup flag Instead of using an uninitialised bit when copying the info in subflow_ulp_clone(). To fix this, no need to extend the join_entry structure: backup is coming from struct mptcp_subflow_request_sock, only one bit. Do the same here by using one bit for both.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97572", "url": "https://ubuntu.com/security/CVE-2026-97572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Propagate RX ring init failures in bnxt_init_nic() bnxt_init_rx_rings() returns an error when bnxt_alloc_one_rx_ring() fails, but bnxt_init_nic() discards that return value and calls bnxt_init_chip(), which enables TPA. If an allocation fails, this could leave rxr->rx_tpa[] partially zeroed and TPA would be enabled over an array with zeroed entries. This would lead to a zeroed DMA address being handed out if the agg_idx is translated to a SW index at a zeroed entry. Fix this by propagating the error out of bnxt_init_nic(). Both callers already check its return value and unwind with bnxt_free_skbs() and bnxt_free_mem(), which tolerate a partially initialized RX ring.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97573", "url": "https://ubuntu.com/security/CVE-2026-97573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset() bnxt_rx_ring_reset() frees the ring buffers and then reallocates them, ignoring the result. bnxt_alloc_one_rx_ring() can fail in bnxt_alloc_one_tpa_info_data(), which returns -ENOMEM on the first failed allocation and leaves the remaining rxr->rx_tpa[] entries zeroed. The error isn't propagated up, so the loop in bnxt_rx_ring_reset continues and at the end the code re-enables TPA with partially unallocated rx_tpa array. This means that when the agg_id from hardware is mapped to a SW index in rxr->rx_tpa[], an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by falling back to a global reset, which is what the existing code already does when other functions fail, but unlike the other failure cases this particular failure has to return because TPA can't be re-enabled since the allocation failed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97576", "url": "https://ubuntu.com/security/CVE-2026-97576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC tile counts The stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from column_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[] and use them as tile-loop bounds, but std_validate_compound() does not bound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling enabled whose tile counts exceed the uAPI array capacity, mirroring the existing compound-control range checks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97582", "url": "https://ubuntu.com/security/CVE-2026-97582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gpio-fan) Fix use-after-free in alarm work fan_alarm_irq_handler() queues fan_data->alarm_work, but nothing cancels it. fan_alarm_notify() dereferences fan_data and its hwmon device. On unbind, devres frees the interrupt, which only waits for the handler itself, and then releases the hwmon device and fan_data, so a pending fan_alarm_notify() can run after those frees. Replace INIT_WORK() with devm_work_autocancel(), registered before devm_request_irq(). The devres cleanup then frees the interrupt first, so no new work can be queued, and cancels the work while fan_data and the hwmon device are still alive. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97592", "url": "https://ubuntu.com/security/CVE-2026-97592", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done. Similar with the buffers which are part of the gcm_sg_walk structs from the variables gw_in and gw_out.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97596", "url": "https://ubuntu.com/security/CVE-2026-97596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reject invalid states in connection template sync records IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6 records.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97598", "url": "https://ubuntu.com/security/CVE-2026-97598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: bound automatic table ID allocation fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment (\"ip rule ... table 0\") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TABLE_MAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable. The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97601", "url": "https://ubuntu.com/security/CVE-2026-97601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97604", "url": "https://ubuntu.com/security/CVE-2026-97604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vfb: defer cleanup until the last reference FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114) Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489) unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97608", "url": "https://ubuntu.com/security/CVE-2026-97608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: unregister loggers before per-net teardown nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL lock nf_log_mutex find logger in loggers[][] net->nf.nf_loggers[pf] = logger unlock nf_log_mutex nf_log_unregister(logger) lock nf_log_mutex loggers[pf][type] = NULL unlock nf_log_mutex synchronize_rcu() module exit returns module core frees backend memory Later, a sysctl read or packet logging operation can dereference the stale per-net logger pointer. Fix this by unregistering the global logger backends before tearing down per-net state. Once the global registrations are gone, later writers can no longer rebind the logger. unregister_pernet_subsys() already waits for an RCU grace period after the pre-exit callback clears the per-net selection, while nf_log_unregister() continues to cover readers of the global logger table. Apply this ordering fix to both nf_log backends that combine per-net teardown with global logger registration.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97611", "url": "https://ubuntu.com/security/CVE-2026-97611", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix use-after-free of the flow table mask array tbl_mask_array_realloc() retires the old mask_array before it stops being reachable: \told = ovsl_dereference(tbl->mask_array); \tif (old) { \t\t... \t\tcall_rcu(&old->rcu, mask_array_rcu_cb); \t} \trcu_assign_pointer(tbl->mask_array, new); call_rcu() only waits for read-side critical sections already in flight. tbl->mask_array still points at old between the call_rcu() and the rcu_assign_pointer(), so a reader entering ovs_flow_tbl_lookup_stats() in that window picks up old in a fresh critical section that the pending grace period does not cover. tbl_mask_array_realloc() runs in process context under ovs_mutex, so the window is preemptible and can outlast the grace period. Then mask_array_rcu_cb() frees old before the swap runs: BUG: KASAN: slab-use-after-free in flow_lookup.constprop.0+0x2bf/0x2f0 Read of size 8 at addr ffff888020b3e018 by task poc/741 flow_lookup.constprop.0+0x2bf/0x2f0 ovs_flow_tbl_lookup_stats+0x4a3/0x5c0 ovs_dp_process_packet+0x19c/0x710 ovs_vport_receive+0x243/0x390 internal_dev_xmit+0x81/0x170 Freed by task 728: kfree+0x16a/0x4e0 rcu_core+0x853/0x1030 Publish the new array before retiring the old one. The kfree_rcu() that call_rcu() replaced ran after the swap.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97612", "url": "https://ubuntu.com/security/CVE-2026-97612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: clear inner_protocol when the last label is popped skb_mpls_push() records the pre-encapsulation network header once, gated on !skb->inner_protocol. skb_mpls_pop() never clears that record, so it outlives the encapsulation it describes. Open vSwitch can then re-push MPLS onto a packet whose inner_network_header still points at the older, deeper offset: push a label, pop every label, recirculate (ovs_flow_key_update() re-derives key->eth.type and resets network_header, but leaves inner_*), then push again. ovs_fragment() trusts the record: \tskb->network_header = skb->inner_network_header; so skb_network_offset() goes negative. The bound check is signed: \tif (skb_network_offset(skb) > MAX_L2_LEN) a negative offset passes it, and prepare_frag() widens the value: \tunsigned int hlen = skb_network_offset(skb); \tmemcpy(&data->l2_data, skb->data, hlen); which is a ~4GiB memcpy out of a 30-byte per-CPU buffer. Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8): BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 prepare_frag+0x3df/0x4e0 ovs_fragment+0x589/0x7e0 do_output+0x4ce/0x5e0 do_execute_actions+0x55d2/0x7b30 ovs_execute_actions+0xea/0x450 Same root-cause shape as commit 975b5b067f52 (\"ipv6: sr: restore network header before routing and forwarding\"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path. Clear inner_protocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/act_mpls.c is the only other skb_mpls_pop() caller and gets the same fix; sch_frag.c saves and restores inner_protocol around fragmentation in the same way OVS does.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97899", "url": "https://ubuntu.com/security/CVE-2026-97899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix memory leak in query_perf_config_list() When krealloc() fails, free the original oa_config_ids before returning to avoid a memory leak. (cherry picked from commit 9977e9d84f46d4f12ad35fbbc0ec4638554bce87)", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97904", "url": "https://ubuntu.com/security/CVE-2026-97904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: initialize policy rwsem before sysfs publication cpufreq_policy_alloc() initializes policy->rwsem after kobject_init_and_add() has created the policy sysfs directory and its default attributes. A sysfs access can therefore reach a policy callback before the semaphore has been initialized. Initialize policy->rwsem before publishing the policy kobject so sysfs callbacks always see an initialized semaphore.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97905", "url": "https://ubuntu.com/security/CVE-2026-97905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: zero-initialize policy cpumask before sysfs publication cpufreq_policy_alloc() allocates policy->cpus with alloc_cpumask_var(), i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate kmalloc_node() allocation, so its bitmap holds whatever the slab allocator left behind: cpufreq_online() cpufreq_policy_alloc() alloc_cpumask_var(&policy->cpus) /* bitmap is uninitialized */ kobject_init_and_add() /* policy%u/ appears in sysfs */ cpufreq_policy_online() cpumask_copy(policy->cpus, cpumask_of(cpu)) /* first valid value */ This leaves a window in which the sysfs attributes are already reachable while policy->cpus is still garbage. show()/store() gate on policy_is_inactive(), i.e. cpumask_empty(policy->cpus), so a non-zero bitmap makes them run the attribute callbacks on a policy that is not initialized yet. Fix this by using zalloc_cpumask_var() for policy->cpus.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97909", "url": "https://ubuntu.com/security/CVE-2026-97909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: initialize IRQ lock before requesting IRQ uni_reader_init() registers the shared IRQ before initializing reader->irq_lock. A pending interrupt can invoke the handler while the lock is still uninitialized. Initialize the lock before registering the IRQ so the interrupt path always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97910", "url": "https://ubuntu.com/security/CVE-2026-97910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sprd: validate compress buffer sizes against fixed allocations sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the fixed allocations. A fragment_size larger than the 32K IRAM data area makes the stage 0 copy_from_user() overflow past the IRAM allocation, and a buffer_size larger than the 2M DDR buffer makes the wrapping copy at the end of sprd_platform_compr_copy() write fully user controlled data past the buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP state reaches the copy callback directly. Reject parameters that do not fit into the fixed buffers in set_params(), and fix the advertised max fragment size: 128K never fitted into the 32K IRAM buffer. The caps values may have been carried over from the qdsp6 driver, which allocates its buffers according to the advertised maxima, unlike this driver. With 32K as max fragment size the advertised limits are self-consistent: 32K * 64 = 2M equals the DDR buffer size. Discovered by Atuin - Automated Vulnerability Discovery Engine.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97923", "url": "https://ubuntu.com/security/CVE-2026-97923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the var ref when its initialization fails create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 (\"tracing: Use hist trigger's var_ref array to destroy var_refs\") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it. The call was correct when it was written, before var refs were taken out of destroy_hist_field(). init_var_ref() cannot free it either. The caller owns the field, so init_var_ref() undoes only its own string allocations and leaves the field alone. Freeing it there would leave create_var_ref() passing freed memory to destroy_hist_field(), which reads its flags. Call __destroy_hist_field(), which frees the field without consulting the flag.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97926", "url": "https://ubuntu.com/security/CVE-2026-97926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: validate cylinder group metadata before caching it ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: \tucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); \tucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); \tucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); \tucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: - c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32 bit count outside the s_csp allocation. - c_frotor becomes a bitmap scan start, start = c_frotor >> 3, and then length = ((s_fpg + 7) >> 3) - start. A start beyond the block bitmap wraps the unsigned length to a huge value, so ubh_scanc() walks far past the cylinder group buffers. c_irotor drives the inode bitmap the same way. A crafted image can set any of these freely, turning an ordinary allocation into an out of bounds access. Reject a cylinder group whose recorded index does not match the group being read, or whose rotors fall outside the group, before the metadata is cached. Valid filesystems keep cg_cgx equal to the group number and the rotors within the group, so only malformed images are rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97927", "url": "https://ubuntu.com/security/CVE-2026-97927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: create the root dentry after loading cylinder metadata ufs_fill_super() installed sb->s_root before it loaded the cylinder group structures for a writable mount: \tsb->s_root = d_make_root(inode); \t... \tif (!sb_rdonly(sb)) \t\tif (!ufs_read_cylinder_structures(sb)) \t\t\tgoto failed; When ufs_read_cylinder_structures() failed, the error path freed the in-core superblock information and set sb->s_fs_info to NULL while sb->s_root stayed installed. get_tree_bdev() then reached deactivate_locked_super(), and because s_root was present, generic_shutdown_super() called sync_filesystem() and the put_super operation. Both dereference UFS_SB(sb), which is now NULL, so a mount that fails only while reading the cylinder groups oopses during teardown. A crafted image whose first cylinder group cannot be read reaches this path. Load the cylinder group metadata first and create the root dentry last, so the superblock is published to the VFS only once it is fully set up. ufs_setup_cstotal() and ufs_read_cylinder_structures() take only the super_block and do not use the root inode, so the reordering is safe.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97930", "url": "https://ubuntu.com/security/CVE-2026-97930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf The in04_last array in struct usx2ydev is declared as char[24], but in04_buf is allocated as sizeof(struct us428_ctls) which is 21 bytes. In i_usx2y_in04_int(), when ctl_snapshot_last == -2 (initialization path): memcpy(usx2y->in04_last, usx2y->in04_buf, sizeof(usx2y->in04_last)); This copies 24 bytes from a 21-byte slab allocation, reading 3 bytes past the end of the source object. Introduce a USX2Y_IN04_SIZE constant defined as sizeof(struct us428_ctls) and use it consistently for the in04_last array, the in04_buf allocation, the URB transfer length, and the comparison loop, replacing the bare 24 and 21 literals throughout.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97940", "url": "https://ubuntu.com/security/CVE-2026-97940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix fib6 walker UAF on seq stop ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a never-started iterator with a zeroed private object is not treated as linked. The same stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only widens the race.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97948", "url": "https://ubuntu.com/security/CVE-2026-97948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver The commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") refactored the EEH code such that the pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken. [<0>] 0xc00000011c78f870 [<0>] __switch_to+0xfc/0x1a0 [<0>] pci_lock_rescan_remove+0x30/0x44 [<0>] eeh_rmv_device+0x290/0x2e0 [<0>] eeh_pe_dev_traverse+0x80/0x130 [<0>] eeh_reset_device+0xcc/0x23c [<0>] eeh_handle_normal_event+0x830/0xa80 [<0>] eeh_event_handler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] start_kernel_thread+0x14/0x18 The issue is seen for cases where the errors are detected on the PHB directly AND|OR for devices where the driver error_detected() returns PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no error handlers like slot_reset(), resume() etc defined).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-74743", "url": "https://ubuntu.com/security/CVE-2026-74743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: inherit needed_headroom and needed_tailroom from lowerdev macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-89792", "url": "https://ubuntu.com/security/CVE-2026-89792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds reads in share config responses Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-97951", "url": "https://ubuntu.com/security/CVE-2026-97951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands When a LUN_RESET aborts a WRITE command that is in the TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and waits for the frontend to finish processing. If the initiator subsequently sends the remaining dataout PDUs, __iscsit_check_dataout_hdr() catches the payload, stops the dataout timer if the sequence is final and finally dumps the data. However, the iSCSI target doesn't trigger the completion process for these aborted commands. Because of this, the abort path hangs indefinitely in target_put_cmd_and_wait(), leading to a deadlocked target worker thread. Fix this by explicitly calling target_complete_cmd() when the final dataout PDU is received for an aborted WRITE command. target_complete_cmd() detects the CMD_T_ABORTED flag and cleanly routes the command into target_abort_work, allowing the abort completion to successfully unblock.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-97952", "url": "https://ubuntu.com/security/CVE-2026-97952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunvdc: unmap LDC cookies when the descriptor send fails __send_request() maps the request's pages into the LDC channel's map table (ldc_map_sg()), fills in the descriptor and marks it VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger(). When the trigger fails, the error path only prints a message: the descriptor stays READY and the cookies are never unmapped. The mapping is normally released in vdc_end_one() when the peer completes the descriptor - but a descriptor whose doorbell was never sent will never complete, and since dr->prod is not advanced on failure, the reset path (vdc_requeue_inflight(), which walks [cons, prod)) never visits it either. The map table entries are leaked permanently. Since commit a11f6ca9aef9 (\"sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN\") trigger failures occur in practice under load, so every resulting I/O error also leaks one request's worth of entries from the fixed-size (8192 entries per channel) map table. Because the allocator hands out contiguous ranges, fragmentation makes large multi-segment requests fail first as the table drains, until ldc_map_sg() fails permanently and the disk is dead until reboot. It also makes any retry-based recovery unusable: requeuing the request on -EAGAIN remaps the pages on every attempt, overwriting desc->cookies and orphaning the previous mapping, so the table drains at the retry rate. This is the memory exhaustion observed when the requeue approach was first tested in October 2025. Roll back on failure: unmap the cookies, mark the descriptor FREE again and clear the request entry. If the trigger failed with -ENOTCONN, __vdc_tx_trigger() has already reset the port, which tears down and reallocates both the dring and the LDC channel including its map table - nothing to roll back, and the stale descriptor must not be touched.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97954", "url": "https://ubuntu.com/security/CVE-2026-97954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix tcp stream corruption with large pages rds_message_map_pages() assigns PAGE_SIZE bytes to every scatterlist entry, even when total_len ends in a partial page. The RDS congestion map is defined as 8192 bytes, so on systems with PAGE_SIZE greater than 8192 the scatterlist maps bytes beyond the end of the congestion map. RDS-TCP transmits the SG contents according to those lengths, so the extra bytes become part of the TCP RDS stream and are interpreted as subsequent RDS message headers, corrupting the stream. Limit the final scatterlist mapping to the number of bytes remaining. This has no effect on systems with a 4K page size and allows RDS-TCP to be used on systems with 16K and larger page sizes. The RDS selftest, which previously hung on 16K pages, now passes.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97957", "url": "https://ubuntu.com/security/CVE-2026-97957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix mailbox segment buffer overflow check_mbox_seq_id_and_seg_len() validates that seq_id does not exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed MBOX_SEG_LEN (48). However, this allows the last segment (seq_id=42) to carry a full 48-byte payload, writing to offset 42*48=2016 for 48 bytes (ending at byte 2064). The receive buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a 16-byte heap buffer overflow. The hinic3 driver already handles this correctly by defining MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it exceeds the remaining buffer space. Apply the same fix to the hinic driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97958", "url": "https://ubuntu.com/security/CVE-2026-97958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain(). If a netlink socket sends RTM_GETCHAIN requests repeatedly without recv()ing the responses, tc_ctl_chain() hogs CPU and triggers Hung Task splat. [0] As caught in the stack trace, netlink_attachskb() could confuse tc_ctl_chain() by returning -EAGAIN when the userspace netlink socket's receive buffer is full. The replay: label exists since commit 32a4f5ecd738 (\"net: sched: introduce chain object to uapi\") but was not used initially. Since commit 9f407f1768d3 (\"net: sched: introduce chain templates\"), the label is needed for RTM_NEWCHAIN because tcf_proto_lookup_ops() may release RTNL to call request_module(). However, the replay logic is unnecessary for RTM_GETCHAIN. Let's apply the replay logic only for RTM_NEWCHAIN. [0]: INFO: task repro:1018 is blocked on a mutex likely owned by task repro:1022. task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 task_flags:0x400040 flags:0x00080000 Call Trace: ? clockevents_program_event (kernel/time/clockevents.c:372) ? pskb_expand_head (net/core/skbuff.c:615) ? skb_release_data (net/core/skbuff.c:1122) ? netlink_attachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/af_netlink.c:1232) ? __netlink_lookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/af_netlink.c:499) ? tc_chain_notify (net/sched/cls_api.c:3045) ? tc_chain_notify (./include/linux/skbuff.h:1384 net/sched/cls_api.c:3041) ? netlink_unicast (net/netlink/af_netlink.c:1335) ? rtnl_unicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985) ? tc_ctl_chain (net/sched/cls_api.c:3242) ? rtnetlink_rcv_msg (net/core/rtnetlink.c:7146) ? netlink_unicast (net/netlink/af_netlink.c:1354) ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:7177) ? netlink_rcv_skb (net/netlink/af_netlink.c:2556) ? netlink_unicast (net/netlink/af_netlink.c:1319) ? netlink_sendmsg (net/netlink/af_netlink.c:1900) ? __sock_sendmsg (net/socket.c:800) ? __sys_sendto (net/socket.c:2281) ? __x64_sys_sendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284) ? do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97959", "url": "https://ubuntu.com/security/CVE-2026-97959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_route: free emptied bucket on filter move route4_change can move an existing filter to a different top-level bucket: route4_set_parms recomputes the handle from TCA_ROUTE4_TO/ FROM/IIF, and the handle-mismatch check is gated on the 'new' flag, so for an existing filter the new handle may differ from the old one and land in a different bucket. When this happens, the filter is unlinked from the old bucket, but the bucket itself is never freed once it goes empty. The stale empty bucket remains in head->table[], causing route4_delete to report *last=false even after the last live filter is gone. That pins the empty tcf_proto and causes a leak. Fix this by refcounting the filters linked to a bucket and freeing the bucket when the count drops to zero. The existing scan in route4_delete goes away with it. The count is updated at all sites that link or unlink a filter during add, change and delete, and the bucket is dropped from head->table[] as soon as it reaches zero. Conditions to recreate the bug: CONFIG_NET_CLS_ROUTE4=y, CONFIG_NET_SCH_INGRESS=y, CONFIG_NET_CLS_ACT=y. tc qdisc replace dev lo clsact tc filter add dev lo ingress protocol ip pref 100 route from 1 to 1 tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \\ route from 1 to 2 tc filter del dev lo ingress protocol ip pref 100 handle 0x10002 \\ route from 1 to 2 tc filter show dev lo ingress | grep -c 'pref 100 route chain 0 '", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97963", "url": "https://ubuntu.com/security/CVE-2026-97963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: initialize ptp_lock at probe time priv->ptp_lock is only initialized in stmmac_ptp_register(), which runs during __stmmac_open(). However, the lock is also used while the interface is down and has never been opened: tc_taprio_configure() invokes the PTP gettime64() callback to compute the EST base time when offloading a TAPRIO schedule, and stmmac_get_time() takes priv->ptp_lock. Using an uninitialized rwlock is undefined behaviour. Move the rwlock_init() to __stmmac_dvr_probe(), together with the other private locks, so that ptp_lock is always valid regardless of the interface state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97964", "url": "https://ubuntu.com/security/CVE-2026-97964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_synctty: ensure a writeable skb header ppp_sync_txmunge() checks headroom before prepending the address and control bytes, but does not ensure that the skb header is writable. A received skb can reach this function through PPP channel bridging without passing through ppp_start_xmit(), which calls skb_cow_head(). For example, a PPPoE frame may share its buffer with a clone queued to an AF_PACKET socket. If it is bridged to a synchronous tty channel, the address/control bytes can overwrite data still visible to that socket. Use skb_cow_head() to ensure both sufficient headroom and a writable header.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97969", "url": "https://ubuntu.com/security/CVE-2026-97969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix clock leak and spurious timer in settimeout() msc313e_wdt_settimeout() unconditionally calls msc313e_wdt_start() which introduces two severe bugs: 1. If the watchdog is already active, calling start() again will increase the reference count of the clock again. However stop() is only called once, the reference count is unbalance. 2. If the watchdog is stopped, calling settimeout() will start the hardware timer accidentally. Factor out the register-writing logic into a helper function. Only call it in settimeout() if the watchdog is running. Otherwise, simply update `wdev->timeout`.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97970", "url": "https://ubuntu.com/security/CVE-2026-97970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Avoid division by zero clk_get_rate() could return 0. Avoid a division by zero panic.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97981", "url": "https://ubuntu.com/security/CVE-2026-97981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Count dropped frames as NAPI work The RX loop only consumes budget when it successfully delivers a frame. Error paths keep consuming descriptors without reducing the budget, so a stream of bad frames can process the entire receive ring in one poll. Move the budget accounting to a common end-of-frame path. This counts each completed frame as NAPI work whether it was delivered or dropped, matching the behavior of the vendor driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97982", "url": "https://ubuntu.com/security/CVE-2026-97982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Fix budget accounting The gmac_rx() function returns the remaining NAPI budget, but its caller treats the return value as the number of packets received. An idle poll therefore reports a full budget and remains scheduled. Return the number of received packets instead. Preserve the existing free queue refill accounting by adding that count directly; continuing to subtract it from the budget would invert the refill behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97991", "url": "https://ubuntu.com/security/CVE-2026-97991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim_blk: reject out-of-range sector starts vdpasim_blk_check_range() logs an invalid start sector but continues validating the request. The subsequent unsigned capacity subtraction can underflow and let an out-of-range buffer offset reach the data path. The invalid offset is used by three request paths. VIRTIO_BLK_T_OUT copies guest data to blk->buffer + offset through vringh_iov_pull_iotlb(), causing an out-of-bounds write in _copy_from_iter() or memcpy(). VIRTIO_BLK_T_IN copies from blk->buffer + offset to the guest through vringh_iov_push_iotlb(), causing an out-of-bounds read in _copy_to_iter(). VIRTIO_BLK_T_WRITE_ZEROES passes blk->buffer + offset to memset(), causing an out-of-bounds write. Reject starts at or beyond the capacity before the subtraction. Treat the capacity boundary as invalid because the IN and OUT paths round byte counts down to sectors for validation but later copy the original byte counts. A sub-sector request at the capacity boundary would otherwise still access past the end of the buffer. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97993", "url": "https://ubuntu.com/security/CVE-2026-97993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx vhost_vdpa_set_config_call() swaps the eventfd_ctx_fdget() return value into v->config_ctx before checking it, so on failure the field briefly holds an ERR_PTR: \tctx = fd == VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd); \tswap(ctx, v->config_ctx); \tif (!IS_ERR_OR_NULL(ctx)) \t\teventfd_ctx_put(ctx); \tif (IS_ERR(v->config_ctx)) { \t\tlong ret = PTR_ERR(v->config_ctx); \t\tv->config_ctx = NULL; \t\treturn ret; \t} Commit 0bde59c1723a (\"vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails\") added that clearing, and spelled out the invariant the rest of the file relies on: \"we consider 'v->config_ctx' valid if it is not NULL\". The window between the swap and the clearing still breaks it. vhost_vdpa_config_cb() only tests for NULL, so a config interrupt delivered inside the window hands the ERR_PTR to eventfd_signal(). Check the fd before installing it instead. That closes the window and matches how vhost_vring_ioctl() handles the same failure for the vq call fd. It also stops a rejected fd from tearing down a config interrupt that was working: until now the swap replaced the live context and put it, so after an EBADF the device silently stopped delivering config interrupts until userspace installed a new fd.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97995", "url": "https://ubuntu.com/security/CVE-2026-97995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_console: do not free control-out buffers on remove __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): \tfree_buf \tremove_vqs \tvirtcons_remove \tunbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97998", "url": "https://ubuntu.com/security/CVE-2026-97998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: cope with concurrent instance destruction Instances are refcounted. However, only memory release happens on the 1 -> 0 transition; the unlink from hashes can occur with any refcount. Uncooperative userspace can force a situation where a queue is pending for destruction from netlink event while a different socket with same portid processes an UNBIND request. With right timing, this will unhash the instance again: Oops: general protection fault, [..] Call Trace: nfulnl_recv_config+0x31a/0xd50 nfnetlink_rcv_msg+0x7c2/0xeb0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98006", "url": "https://ubuntu.com/security/CVE-2026-98006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev The epq_in_urb object belonging to the caiaq device is coupled within the struct snd_usb_caiaqdev. After usb_submit_urb(epq_in_urb, GFP_KERNEL) executes successfully, epq_in_urb is successfully added to the urbp_list queue of the dummy HCD driver (userspace specifies dummy_hcd as the HCD layer driver for the caiaq USB device). When init_card() calls snd_usb_caiaq_send_command() which subsequently fails due to a timeout, and proceeds to call snd_card_free() to release the card, the embedded ep1_in_urb object is also freed. When the dummy HCD driver detects that the URB has been unlinked, it returns the URB (by usb_hcd_giveback_urb()), which triggers [1]. Decouple the ep1_in_urb object from the struct snd_usb_caiaqdev and switch to using a pointer instead. Separately allocate and manage the memory for ep1_in_urb to prevent the release of the snd_card memory object from interfering with it. midi_out_urb has the same issue as ep1_in_urb and is handled in the same way. [1] BUG: KASAN: slab-use-after-free in usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 Write of size 4 at addr ffff88803cee1050 by task ktimers/1/29 Call Trace: usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 dummy_timer+0xaac/0x4d50 drivers/usb/gadget/udc/dummy_hcd.c:2019 __run_hrtimer kernel/time/hrtimer.c:2067 [inline] __hrtimer_run_queues+0x3eb/0xaf0 kernel/time/hrtimer.c:2124 hrtimer_run_softirq+0x1e1/0x2e0 kernel/time/hrtimer.c:2141 Allocated by task 36: snd_card_new+0x7b/0x110 sound/core/init.c:184 create_card sound/usb/caiaq/device.c:429 [inline] snd_probe+0x236/0x1af0 sound/usb/caiaq/device.c:544 Freed by task 36: snd_card_free_when_closed sound/core/init.c:630 [inline] snd_card_free+0x138/0x1d0 sound/core/init.c:662 snd_probe+0x162b/0x1af0 sound/usb/caiaq/device.c:553", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98009", "url": "https://ubuntu.com/security/CVE-2026-98009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: clamp quantum in parse and fallback paths ets_qdisc_change() falls back to psched_mtu() with no floor for bands without an explicit quantum. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so a zero psched_mtu on a headerless device makes the deficit-refill loop spin under the qdisc lock. Move the floor into ets_quantum_parse() so explicitly configured quanta are also clamped to [256, 1<<20], not just the fallback path. Conditions to recreate the bug: CONFIG_NET_SCH_ETS=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root ets bands 3 strict 2 quanta 1 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98010", "url": "https://ubuntu.com/security/CVE-2026-98010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: drr: clamp quantum in change class drr_change_class() rejects explicit quantum==0 but falls back to psched_mtu() with no floor. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 (or a zero psched_mtu on a headerless device) makes the deficit-refill loop spin under the qdisc lock. Add clamp_t(u32, quantum, 256, 1<<20) after the zero reject and on the fallback path. The explicit-zero reject is preserved. Conditions to recreate the bug: CONFIG_NET_SCH_DRR=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root drr tc class add dev dummy0 parent 1: classid 1:1 drr quantum 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98011", "url": "https://ubuntu.com/security/CVE-2026-98011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum in change and init paths hhf_change() accepts any quantum from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) in hhf_change() matching fq_codel_change(). Clamp hhf_init() to [256, 1<<20] matching the siblings, and remove the old fallback that only set quantum=256 on overflow. Conditions to recreate the bug: CONFIG_NET_SCH_HHF=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root hhf tc qdisc change dev dummy0 root hhf quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98012", "url": "https://ubuntu.com/security/CVE-2026-98012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum in change path sfq_change() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and the init clamp. Conditions to recreate the bug: CONFIG_NET_SCH_SFQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root sfq tc qdisc change dev dummy0 root sfq quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98013", "url": "https://ubuntu.com/security/CVE-2026-98013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp quantum in change path fq_pie_change() accepts any quantum value from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Conditions to recreate the bug: CONFIG_NET_SCH_FQ_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq_pie tc qdisc change dev dummy0 root fq_pie quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98014", "url": "https://ubuntu.com/security/CVE-2026-98014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch, prevent mc_list repopulation during vport disable In mlx5_esw_vport_disable(), move esw_apply_vport_rx_mode() ahead of esw_vport_change_handle_locked() so vport->allmulti_rule is NULL before the change handler observes it. During FW-fatal recovery the disable runs while dev->state == INTERNAL_ERROR. The promisc query inside esw_update_vport_rx_mode() fails and returns early, leaving vport->allmulti_rule intact, so esw_update_vport_mc_promisc() runs and adds MLX5_ACTION_ADD entries to vport->mc_list whose flow rules are then installed in the FDB by esw_add_mc_addr(). esw_destroy_legacy_table() tears down the FDB with those refs still held, corrupting the sub-tree and leaving dangling flow_rule pointers in vport->mc_list. Two-stage failure on `echo 1 > /sys/bus/pci/devices//reset`: refcount_t: underflow; use-after-free. tree_put_node+0xef/0x110 [mlx5_core] clean_tree+0x44/0xd0 [mlx5_core] (x5) mlx5_fs_core_cleanup+0x57/0x1c0 [mlx5_core] mlx5_unload+0x65/0xd0 [mlx5_core] ... mlx5_health_try_recover BUG: unable to handle page fault for address: 0000000003000055 down_write+0x1c/0x60 mlx5_del_flow_rules+0x33/0x1f0 [mlx5_core] esw_del_mc_addr+0x7b/0x170 [mlx5_core] esw_apply_vport_addr_list+0x56/0xf0 [mlx5_core] esw_vport_change_handle_locked+0x28b/0x310 [mlx5_core] mlx5_esw_vport_enable+0x270/0x4a0 [mlx5_core] ... mlx5_load ... mlx5_health_try_recover esw_apply_vport_rx_mode(false, false) clears vport->allmulti_rule via its local state machine even when the FW del fails. With the rule NULL the !IS_ERR_OR_NULL(allmulti_rule) gate in the change handler closes, no rules are installed during disable, and the reload starts with a clean mc_list.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98015", "url": "https://ubuntu.com/security/CVE-2026-98015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put In mlx5_eswitch_termtbl_put(), the zero-ref cleanup check reads tt->ref_count after termtbl_mutex has been released. Two concurrent callers on the same mlx5_termtbl_handle race: one decrements ref_count to zero, removes the hash entry, and calls kfree(tt) while the other has already dropped the mutex and is about to evaluate if (!tt->ref_count), producing a use-after-free. Fix this by capturing the result of the decrement into a stack-local last variable before dropping the mutex. The cleanup decision is now made entirely under termtbl_mutex, and tt is not touched after kfree.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98016", "url": "https://ubuntu.com/security/CVE-2026-98016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free race in sample_restore_put() Concurrent teardown of TC sample rules sharing the same restore context may re-read restore->count after dropping restore_lock. At that point another thread may already have completed cleanup and freed the restore object. Use the result of the refcount decrement while holding restore_lock to determine whether cleanup is needed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98022", "url": "https://ubuntu.com/security/CVE-2026-98022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations Several subsystems allocate ring buffers sized by dev->tx_queue_len with no upper bound. An unprivileged user (via unshare -Urn) can set a huge tx_queue_len and exhaust global memory with ring allocations: - pfifo_fast: pfifo_fast_init() and pfifo_fast_change_tx_queue_len() allocate 3 skb_array rings of tx_queue_len entries each. - tun: tun_queue_resize() and the queue-attach path resize ptr_rings to tx_queue_len on the NETDEV_CHANGE_TX_QUEUE_LEN notifier. - tap (macvtap/ipvtap): tap_queue_resize() and tap_init() resize/init ptr_rings to tx_queue_len on the same notifier. netif_change_tx_queue_len() is the single entry point for IFLA_TXQLEN, sysfs, and the SIOCSIFTXQLEN ioctl. Cap new_len at S16_MAX (32767) there so the oversized value is rejected at set time. This takes effect whether the device is up or down, before dev->tx_queue_len is written, before any notifier fires, and before any ring is allocated. The \"> S16_MAX\" check also subsumes the previous unsigned-long truncation test, and a negative ifr_qlen from the ioctl lands far above the cap after conversion, so both old failure modes are covered by the one comparison. tx_queue_len is ambigious: both a per-ring sizing multiplier and a default queue-length/limit knob for consumers that allocate nothing at set time (pfifo/bfifo/gred/plug/sfb limits, htb direct_qlen, qfq max_classes, teql). 32767 is chosen as the largest value NLA_POLICY_FULL_RANGE can express for the u32 IFLA_TXQLEN policy in patch 2/3 while staying a legitimate queue length on high-BDP paths; the ring-memory trade-off of a shared knob is disclosed below. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn). - pfifo_fast: create veth pairs, set tx_queue_len to 500000, attach mq+pfifo_fast. ~28 iterations OOMs a 2GB guest. - tun: create 50 tun devices with IFF_MULTI_QUEUE, set tx_queue_len to 500000, open 8 queues each. ~1.6GB of ptr_ring allocations OOMs a 512MB guest. - tap: same as tun with IFF_TAP. ~960MB OOMs a 512MB guest. - On the fixed kernel the oversized tx_queue_len is rejected with -ERANGE at set time (all four paths: RTM_SETLINK, RTM_NEWLINK create, sysfs, ioctl - the latter two via this check, the former two via this check and the 2/3 parse policy respectively).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98023", "url": "https://ubuntu.com/security/CVE-2026-98023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: reject dynamic fdb entries that reference a nexthop id The commit cited in the Fixes tag allowed VXLAN FDB entries to point to FDB nexthops so that overlay traffic could be load balanced across multiple VTEPs. Such entries can only be configured from user space, cannot be learned and cannot roam. They only make sense with a user space control plane such as E-VPN where data plane learning is disabled. Despite that, the VXLAN driver does not currently prevent such entries from being configured with the \"dynamic\" flag. The per-nexthop FDB list is only protected by the per-device hash lock, which is not sufficient when two VXLAN devices point to the same FDB nexthop and therefore share the list. Aging runs in softirq context without RTNL, so an entry deleted by one device can race with an addition or deletion from the other, leading to list corruption: list_del corruption. next->prev should be ffff8881069d9548, but was dead000000000122. (next=ffff8881069d9448) WARNING: CPU: 0 PID: 90 at lib/list_debug.c:65 __list_del_entry_valid_or_report+0x1aa/0x210 ... vxlan_fdb_destroy+0x5b8/0xad0 vxlan_cleanup+0x328/0x450 call_timer_fn+0x2a/0x1c0 run_timer_softirq+0x18c/0x210 BUG: KASAN: slab-use-after-free in vxlan_fdb_destroy Fix this by rejecting the bogus configuration of dynamic FDB entries that point to FDB nexthops, both when created and when an existing entry is updated. As such, the per-nexthop FDB list is only ever mutated under the RTNL lock. Add test cases to make sure that this does not regress in the future.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98025", "url": "https://ubuntu.com/security/CVE-2026-98025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is \t} else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB \"frame\" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98027", "url": "https://ubuntu.com/security/CVE-2026-98027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer size mv88e6xxx_get_rxnfc() uses rxnfc->rule_cnt as the write index while dumping the policy IDR, clobbering the input value before it has been looked at. That input is the number of entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed policy rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Count into a local so the caller's limit survives the walk, and stop with -EMSGSIZE once it is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98030", "url": "https://ubuntu.com/security/CVE-2026-98030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size bcm_sf2_cfp_rule_get_all() walks the whole cfp.unique bitmap into rule_locs[] without consulting nfc->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed CFP rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98031", "url": "https://ubuntu.com/security/CVE-2026-98031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: Initialize extack in remove_nh_grp_entry() remove_nh_grp_entry() prints the extack message when a listener fails to replace the reduced nexthop group. However, extack is not initialized and listeners are not required to set a message when returning an error. Neither netdevsim nor mlxsw do so when an allocation fails, resulting in the dereference of an uninitialized stack pointer. Fix by zero-initializing extack, as was done in commit 6347c5314cee (\"nexthop: initialize extack in nh_res_bucket_migrate()\").", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98063", "url": "https://ubuntu.com/security/CVE-2026-98063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref in btf_var_show() btf_var_show() calls btf_type_id_resolve() unconditionally, which dereferences btf->resolved_ids. That is NULL for a base BTF - e.g. the vmlinux BTF that bpf_snprintf_btf() renders against - since base BTF is not resolved during parsing. btf_modifier_show() guards this with 'if (btf->resolved_ids)', but btf_var_show() does not. A BPF program that passes the type_id of a BTF_KIND_VAR from the vmlinux BTF to bpf_snprintf_btf() thus NULL-derefs: KASAN: probably user-memory-access in range [0x46638-0x4663f] RIP: 0010:btf_var_show (kernel/bpf/btf.c:2929) Call Trace: btf_type_show (kernel/bpf/btf.c:8259) btf_type_snprintf_show (kernel/bpf/btf.c:8329) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Resolve the var's type directly with btf_type_skip_modifiers() when resolved_ids is NULL, mirroring btf_modifier_show().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98064", "url": "https://ubuntu.com/security/CVE-2026-98064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref when showing a void BTF type btf_modifier_show() resolves the modifier and then calls btf_type_ops(t)->show() unconditionally. For the void type (type_id 0, BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL. A \"const void\" (a modifier resolving to void) cannot be a map key or value - map_check_btf() rejects it because void has no size - so the map dump path does not reach it. But bpf_snprintf_btf() takes a type_id straight from the BPF program, and passing such a \"const void\" from the vmlinux BTF NULL-derefs: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:btf_modifier_show (kernel/bpf/btf.c:2914) Call Trace: btf_type_show (kernel/bpf/btf.c:8251) btf_type_snprintf_show (kernel/bpf/btf.c:8321) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fall back to btf_df_show() when the resolved type has no show op; it emits the \"\" placeholder already used for kinds like FWD and FUNC. bpf_snprintf_btf() then returns the length as usual.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98066", "url": "https://ubuntu.com/security/CVE-2026-98066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Fix potential double-free at error path The fix for caiaq driver's resource management to handle the errors tries to release the resources in a common destructor call, but as a sashiko review for another patch suggested, some of the audio resources such as URBs have been already freed, and this may lead to a double-free. For addressing the double-free, call the common destructor function from each place, and assure that the resource pointers get cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98068", "url": "https://ubuntu.com/security/CVE-2026-98068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: don't let rds_conn_shutdown() consume a concurrent drop rds_conn_shutdown() finishes by moving the path from RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts RDS_CONN_ERROR as the starting state of that final transition, so that a FIN processed in softirq context during the teardown does not derail the shutdown into a noisy error path. But consuming that RDS_CONN_ERROR also consumes the shutdown pass that came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN is a no-op. For the FIN case that is harmless - the socket the FIN arrived on is the very socket the teardown just released. It is not harmless for a dropper that attached something to the path first. rds_tcp_accept_one() is such a dropper. Its path claim in rds_tcp_accept_one_path() transitions RDS_CONN_DOWN -> RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous socket in softirq context, an administrative reset - can put the path into RDS_CONN_ERROR between that claim and the state check that follows, which accepts RDS_CONN_ERROR. The accept then installs the freshly accepted socket with rds_tcp_set_callbacks() while the queued teardown - which sampled tc->t_sock before this socket existed - is still running. rds_connect_path_complete() fails its transition to RDS_CONN_UP and drops the path again, queueing the pass that should reap the socket it just installed. If the in-flight shutdown's final transition consumes that drop's RDS_CONN_ERROR, the queued pass finds the path in RDS_CONN_DOWN and does nothing. The installed socket is never torn down: it sits established with its callbacks armed and its rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some later event drops it again. Reproduced with widened race windows as an ever-growing receive queue on a socket owned by a path stuck in RDS_CONN_DOWN, with the peer's send path wedged behind it. Make the final transition only DISCONNECTING -> DOWN. If it fails because the path is in RDS_CONN_ERROR, a drop raced the teardown: cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one piece of the skipped tail that must not be left behind - and return, letting the pass the drop queued finish the job: it tears down whatever attached to the path in the meantime, completes the transition to RDS_CONN_DOWN, and re-arms the reconnect from its own tail. The timer quiesce in that branch matters because the racing drop does not always queue that pass: rds_conn_path_drop() returns without queueing when a destroy is pending - exactly the situation during a netns teardown or module unload, when a FIN on the dying socket is processed while rds_conn_path_destroy() flushes cp_down_w. If the flushed pass is the one that takes this return, no later pass exists, and rds_conn_path_destroy() would find cp_conn_w still armed (WARN_ON) and then free a path whose reconnect timer can still fire. With the cancel in the branch, every exit of a shutdown pass leaves the timer quiesced no matter which pass completes the transition. The FIN case keeps making progress, one pass later and still without noisy logging. Any other state keeps today's rds_conn_path_error() handling; no current cp_state writer can leave a DISCONNECTING path in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from a non-DISCONNECTING state), so that branch is defensive. On kernels without the preceding patches the same hazard exists with the sample-based quiesce; the fix applies there equally.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98069", "url": "https://ubuntu.com/security/CVE-2026-98069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire the fastpath locks in rds_conn_shutdown() rds_conn_shutdown() quiesces the transmit and receive-refill paths by waiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and then runs the transport shutdown and rds_conn_path_reset(). Sampling the bits clear is not the same as owning them: the moment after the wait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or rds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run concurrently with the teardown. The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the transmit state under it. Oracle UEK fixed the same class of crashes - a 14-year tail of BUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL dereferences in rds_ib_send_cqe_handler() during failover testing - by making the teardown path *acquire* the fastpath bit locks instead of testing them (\"rds: Make sure transmit path and connection tear-down does not run concurrently\"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed. Do the same here: take both locks before calling the transport shutdown, hold them across rds_conn_path_reset(), and release them explicitly with a wake-up afterwards. Both are released with clear_bit_unlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rds_send_path_reset() are ordered before either bit is seen clear by the next acquire_in_xmit() or acquire_refill(). The fastpath users of these bits - rds_send_xmit() and rds_ib_recv_refill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rds_tcp_reset_callbacks() is different: since the previous patch it acquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rds_tcp_accept_one() on the single-threaded krdsd workqueue and holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown(). An IB path's drain in rds_ib_conn_path_shutdown() has no round cap, but no blocking waiter either: rds_tcp_reset_callbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDS_CONN_DISCONNECTING. Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on the path's ordered cp_wq, whose only execution slot is occupied by the blocked cp_down_w itself, so they are pending at most and cancel without flushing - a reliance on cp_wq being ordered that is now noted next to those cancels (on ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98070", "url": "https://ubuntu.com/security/CVE-2026-98070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks() rds_tcp_reset_callbacks() quiesces the transmit path by setting the path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to be sampled clear before swapping the underlying socket and calling rds_send_path_reset(). Sampling the bit clear is not the same as owning it: rds_send_xmit() can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its state recheck after taking the lock is a store-buffering pattern (the resetter writes the state and reads the bit, the sender writes the bit and reads the state) and acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write and the transmit path then runs concurrently with rds_send_path_reset() rewriting cp_xmit_* state - which is exactly what the comment above rds_send_path_reset() tells its callers to prevent. Take the lock instead, hold it across the socket swap and rds_send_path_reset(), and release it with a wake-up at the end. The lock-ordering constraint documented above the wait still holds: the lock is acquired before lock_sock(), so a sender inside tcp_sendmsg() can never be waited on while we hold the socket lock. Two details of the old code go away with the same change: - t_sock is now read only after the lock is acquired. The old code cached it before waiting; the teardown in rds_conn_shutdown() releases that socket and clears t_sock, so a pointer cached before the wait can be stale by the time the accept path resumes. Reading it under RDS_IN_XMIT is what makes the exclusion complete once the teardown owns the same lock, which the next patch arranges; until then the teardown still only samples the bit, and the two paths remain as exposed to each other as they are today. - The old !osock early path called rds_send_path_reset() with no serialization at all. It now runs under the lock like the normal path. The conditional RDS_CONN_RESETTING transition of the previous patch happens before the socket check either way: a path found without a socket is either still connecting (its reconnect worker blocked on t_conn_path_lock) and legitimately goes RESETTING -> UP on the new socket, or it has been torn down meanwhile and is dropped. The in-function comment describing the old wait-based quiesce is rewritten to describe the lock-based one, and the stale block comment above the function (which still described a return value and an incomplete list of t_sock writers) is refreshed to name all four writers - the connect, accept, teardown and swap paths - and what serializes each of them.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98071", "url": "https://ubuntu.com/security/CVE-2026-98071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: clear cp_flags bits individually in rds_conn_path_reset() rds_conn_path_reset() wipes the whole flag word with a plain cp->cp_flags = 0 store. Every other accessor of that word uses atomic bitops, and some of them can run concurrently with the reset: RDS_LL_SEND_FULL is set from rds_send_xmit() and cleared from the transport completion paths, neither of which holds anything that excludes the shutdown worker. A plain store racing an atomic read-modify-write on the same word is a data race, and whichever side loses has its update silently discarded. Clear the two bits the reset is actually responsible for instead. RDS_IN_XMIT and RDS_RECV_REFILL need no store at all here: they belong to the caller, rds_conn_shutdown(), which waits for both to be clear before calling the transport shutdown and this reset. This also gives every bit in cp_flags a single well-defined writer discipline, which the following patches rely on when they turn RDS_IN_XMIT and RDS_RECV_REFILL into bit locks held across the teardown: a blanket store mid-teardown would destroy lock ownership that an atomic clear preserves. Oracle UEK carries the same conversion (\"net/rds: Preserve essential connection state flags\"), motivated by its asynchronous shutdown state machine, whose progress and destroy flags must survive the reset. UEK's variant also clears RDS_IN_XMIT and RDS_RECV_REFILL because there the reset runs as the final step of a teardown that owns both bits, making those clears its unlock. Upstream that release belongs in rds_conn_shutdown(): once a later patch in this series turns the two bits into locks held across the teardown, ending ownership needs release semantics and a wake-up that a plain clear inside the reset would not provide. Based on Oracle UEK commit \"net/rds: Preserve essential connection state flags\" by Gerd Rausch.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98072", "url": "https://ubuntu.com/security/CVE-2026-98072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in release_in_xmit() release_in_xmit() clears RDS_IN_XMIT with clear_bit_unlock() and then checks waitqueue_active() to decide whether anyone needs waking. clear_bit_unlock() is only a release operation: it orders the critical section before the bit clear, but does not order the subsequent plain load of the wait queue head after it. The waiter side does the mirror image - it adds itself to the wait queue and then tests the bit. That is the classic store-buffering pattern: the releasing CPU can read the wait queue as empty while the waiting CPU still reads the bit as set, so the sleeper is never woken. The waiters are rds_conn_shutdown() and rds_tcp_reset_callbacks(), both in uninterruptible wait_event() with no timeout. A lost wake-up strands the shutdown worker on its single-threaded workqueue until some other sender releases the bit again - and on a connection that is being torn down precisely because it failed, there may never be another sender. The barrier used to be there: release_in_xmit() did clear_bit() followed by smp_mb__after_atomic() until commit 1422f28826d2 (\"rds: introduce acquire/release ordering in acquire/release_in_xmit()\") folded both into clear_bit_unlock(), which strengthened the lock hand-off but silently dropped the full barrier the wake-up check depends on. The refill counterpart, release_refill() in net/rds/ib_recv.c, still carries its smp_mb__after_atomic() for exactly this reason. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98074", "url": "https://ubuntu.com/security/CVE-2026-98074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: do not clear curr_active_slave prematurely when releasing all slaves When releasing all slaves during bond destruction (all == true), __bond_release_one() unconditionally clears bond->curr_active_slave to NULL in every iteration. If a backup slave is released before the active slave, bond_alb_deinit_slave() triggers rlb_teach_disabled_mac_on_primary(), which increments the active slave dev promiscuity counter and sets bond_info->primary_is_promisc = 1. Because bond->curr_active_slave was prematurely cleared to NULL when releasing the backup slave, the subsequent iteration releasing the active slave evaluates oldcurrent as NULL, so bond_change_active_slave(bond, NULL) is skipped. Consequently, bond_alb_handle_active_change() is never called to decrement the promiscuity counter, permanently leaking promiscuous mode on the physical device after bond teardown. When oldcurrent == slave, bond_change_active_slave(bond, NULL) already sets bond->curr_active_slave to NULL. We only need to avoid selecting a new active slave when all == true. Replace the if (all) branch with if (!all && oldcurrent == slave).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98075", "url": "https://ubuntu.com/security/CVE-2026-98075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject BPF_PSEUDO_FUNC reference to the main program fixups.c:jit_subprogs() rewrites BPF_PSEUDO_FUNC loads to contain real function addresses. This function is invoked from bpf_jit_subprogs() only when env->subprog_cnt > 1. Meaning that for any program like below: int main(void *ctx) { void *ptr = main; ... bpf_timer_set_callback(..., ptr); ... } The 'ptr' won't be ever converted to contain an address. In combination with e.g. bpf_timer_set_callback() this would lead to a function call at a bogus address. Instead of complicating the implementation, just assume that no useful program needs main to be a sync or async callback and reject BPF_PSEUDO_FUNC loads for the main subprogram.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98076", "url": "https://ubuntu.com/security/CVE-2026-98076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/probes: Fix use-after-free on field name/type of events with multiple probes The fields of a probe-based dynamic event (kprobe, uprobe, eprobe and fprobe events) are created in traceprobe_define_arg_fields() by handing the probe_arg name/type strings to trace_define_field(), which only stores the pointers without copying. Those strings are owned by the trace_probe and are freed when that probe is removed. An event can have several probes attached. The field list is defined only once, by the first probe that registers the event, but it is kept alive by any surviving sibling probe. Deleting just that first probe by symbol - # primary A: fields are defined from A's args echo 'p:kprobes/ev vfs_read a1=$arg1' > kprobe_events # append B: shares A's event call echo 'p:kprobes/ev vfs_write a1=$arg1' >> kprobe_events # delete only A (matched by symbol), B survives echo '-:kprobes/ev vfs_read' >> kprobe_events frees A's args (trace_probe_cleanup() -> traceprobe_free_probe_arg()), but trace_probe_unlink() keeps the trace_probe_event because the probe list is not empty. The event call stays registered via B while its fields now reference freed memory. Any field lookup then reads it, e.g. echo 'a1 == 1' > events/kprobes/ev/filter BUG: KASAN: slab-use-after-free in strcmp+0xa7/0xb0 Call Trace: strcmp trace_find_event_field parse_pred process_preds create_filter apply_event_filter event_filter_write field->name references parg->name (kstrdup'd, freed with the probe) and, for array arguments, field->type references parg->fmt (kmalloc'd, freed with the probe) - the scalar type otherwise points at the static fmttype rodata, which is safe. Have traceprobe_define_arg_fields() duplicate the name and type strings and anchor the copies on the trace_probe_event, which embeds the event call and outlives every individual probe; trace_probe_event_free() releases them. The reproducer above triggers reliably; the field lookup and the delete both run under event_mutex, so this is a dangling reference after removal rather than a race. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98077", "url": "https://ubuntu.com/security/CVE-2026-98077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace() sip_skip_whitespace() returns dptr unchanged when its own loop exhausts the buffer (dptr == limit), instead of NULL like its sibling sip_follow_continuation() returns on its own \"no more data\" path. ct_sip_get_header() only checks for NULL after calling it: dptr = sip_skip_whitespace(dptr, limit); if (dptr == NULL) break; if (*dptr != ':' || ++dptr >= limit) break; so a recognized header name followed only by spaces/tabs running to the exact end of the SIP payload, with no colon, makes the very next statement read one byte past the buffer. Make both \"no more data\" outcomes return NULL, matching the convention sip_follow_continuation() already uses and that both existing callers already check for.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98078", "url": "https://ubuntu.com/security/CVE-2026-98078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix reversed sequence option serialization hton_seq() expects the host-order source first and the unaligned network-order destination second. The version 1 sync sender passes these arguments in reverse for both sequence blocks. This leaves 24 bytes of the kmalloc-backed message unwritten. It may disclose stale heap data and replace the live connection sequence state with values read from the buffer. Pass the connection sequence state as the source and the message payload as the destination for both blocks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98080", "url": "https://ubuntu.com/security/CVE-2026-98080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not force reloc root creation during qgroup_account_snapshot() [BUG] When running btrfs/252 with quota enabled through MKFS_OPTIONS=\"-O quota\", it has a high chance to trigger the following kernel warning and flips the fs RO: BTRFS info (device dm-2): relocating block group 30408704 flags metadata|dup ------------[ cut here ]------------ WARNING: fs/btrfs/extent-tree.c:879 at lookup_inline_extent_backref+0x74b/0x960 [btrfs], CPU#4: btrfs/2173 CPU: 4 UID: 0 PID: 2173 Comm: btrfs Not tainted 7.2.0-rc6-custom+ #457 PREEMPT(full) 3adc6528fb66f7a55fe1095385818e742f200aab Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:lookup_inline_extent_backref+0x74b/0x960 [btrfs] Call Trace: insert_inline_extent_backref+0x7c/0x160 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_inc_extent_ref+0xa9/0x270 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_run_delayed_refs+0x4af/0x11c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_run_delayed_refs+0x9d/0xf0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshot+0x39d/0xf00 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshots+0x9b/0xc0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_commit_transaction+0x280/0xeb0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] prepare_to_relocate+0x147/0x200 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] relocate_block_group+0x6b/0x5e0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_block_group+0x92c/0x2380 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_balance+0xa2c/0x19c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_ioctl+0x2839/0x2d30 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS info (device dm-2): leaf 4593991680 gen 233 total ptrs 175 free space 5953 owner 2 BTRFS info (device dm-2): refs 3 lock_owner 2173 current 2173 \titem 0 key (166772736 METADATA_ITEM 1) itemoff 16250 itemsize 33 \t\textent refs 1 gen 222 flags 2 \t\tref#0: tree block backref root 266 [ Skip the tree dump ] \titem 174 key (263225344 METADATA_ITEM 0) itemoff 10328 itemsize 33 \t\textent refs 1 gen 162 flags 258 \t\tref#0: tree block backref root 267 BTRFS error (device dm-2): extent item not found for insert, bytenr 179847168 num_bytes 16384 parent 4594335744 root_objectid 273 owner 0 offset 0 BTRFS error (device dm-2): failed to run delayed ref for logical 179847168 num_bytes 16384 type 182 action 1 ref_mod 1: -117 [CAUSE] The above error is showing that there is a tree reference to a metadata extent that is no longer there. With \"ref_verify\" mount option (requires CONFIG_BTRFS_DEBUG), there is some extra debug output: BTRFS error (device dm-2): dumping block entry [180961280 16384], num_refs 0, metadata 1, from disk 0 BTRFS error (device dm-2): root entry 256, num_refs 18446744073709551615 BTRFS error (device dm-2): root entry 273, num_refs 18446744073709551615 BTRFS error (device dm-2): Ref action 3, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 1 btrfs_force_cow_block+0x129/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_insert_empty_items+0x3a/0x70 [btrfs] insert_with_overflow+0x53/0x130 [btrfs] btrfs_insert_dir_item+0x125/0x290 [btrfs] btrfs_add_link+0xaa/0x410 [btrfs] btrfs_rename+0x5ea/0xcd0 [btrfs] btrfs_rename2+0x28/0x60 [btrfs] vfs_rename+0x5b2/0xe10 filename_renameat2+0x244/0x430 __x64_sys_rename+0x48/0x70 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98088", "url": "https://ubuntu.com/security/CVE-2026-98088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() dev_to_node() can return NUMA_NO_NODE (-1) on systems without NUMA topology information for the PCI device, such as single-socket boards that don't expose device-to-node affinity. Passing -1 directly into cpumask_of_node() indexes node_to_cpumask_map[-1], an out-of-bounds array read caught by UBSAN: UBSAN: array-index-out-of-bounds in arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' Fall back to cpu_online_mask when no NUMA node is available, rather than assuming dev_to_node() always returns a valid node index.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98090", "url": "https://ubuntu.com/security/CVE-2026-98090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: restore active device pointers after failed sprout btrfs_init_new_device() switches latest_dev and possibly s_bdev from the seed device to the new sprout device before creating the first writable chunks. If chunk creation or the subsequent sprout setup fails, the error path releases the new device without switching those pointers back. btrfs_show_devname() can then dereference the freed latest_dev and crash. Restore the active device pointers to the latest seed device before removing and releasing the failed sprout device.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98091", "url": "https://ubuntu.com/security/CVE-2026-98091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: detach failed sprout device from transaction update list When creating the first metadata chunk for a sprout filesystem, create_chunk() adds the new device to the transaction dev_update_list through device->post_commit_list. If the subsequent system chunk creation fails, btrfs_init_new_device() aborts the transaction and releases the device while post_commit_list is still linked. This triggers a warning in btrfs_free_device() and leaves the transaction list referencing freed memory. Detach the device while holding chunk_mutex before releasing it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98094", "url": "https://ubuntu.com/security/CVE-2026-98094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: fbtft: make dirty_lock IRQ-safe fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled. Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again. The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled: WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2} CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); lock(console_owner); *** DEADLOCK *** Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98095", "url": "https://ubuntu.com/security/CVE-2026-98095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_packet: Don't cast tpacket_hdr.tp_len to int in tpacket_parse_header(). syzbot reported BUG() in sock_sendmsg_nosec(). [0] The problem is that tpacket_parse_header() casts user-provided tpacket_hdr.tp_len, which is u32, to int. If the length is larger than INT_MAX, the following condition in tpacket_parse_header() passes, if (unlikely(tp_len > size_max)) and any negative value can be returned to the caller, up to sock_sendmsg_nosec(). The repro set tpacket_hdr.tp_len to 0xfffffdef, which is cast to -EIOCBQUEUED (-529), triggering BUG() in sock_sendmsg_nosec(). *(uint64_t*)0x200000000008 = 0xfffffdef; ... syscall(__NR_write, /*fd=*/r[0], /*buf=*/0x200000000000ul, /*count=*/1ul); Let's define the local tp_len as u32 in tpacket_parse_header(). [0]: kernel BUG at net/socket.c:803! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 5628 Comm: syz-executor176 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 RIP: 0010:sock_sendmsg_nosec+0x145/0x180 net/socket.c:803 Code: 06 67 48 0f b9 3a eb 95 e8 e8 3a 22 f8 48 89 df 4c 89 f6 4c 89 e2 4d 89 fb 2e e8 32 a5 5c 16 e9 51 ff ff ff e8 cc 3a 22 f8 90 <0f> 0b e8 c4 3a 22 f8 48 83 c3 18 48 89 d8 48 c1 e8 03 42 80 3c 28 RSP: 0018:ffffc90003aefb48 EFLAGS: 00010293 RAX: ffffffff89a578d4 RBX: ffff8880764c67c0 RCX: ffff88807fb23e80 RDX: 0000000000000000 RSI: 00000000fffffdef RDI: 00000000fffffdef RBP: 00000000fffffdef R08: ffffc90003aef747 R09: 1ffff9200075dee8 R10: dffffc0000000000 R11: fffff5200075dee9 R12: 0000000000000001 R13: dffffc0000000000 R14: ffffc90003aefbc0 R15: ffffffff8aac4310 FS: 000055559101b400(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000210 CR3: 0000000073dca000 CR4: 00000000003526f0 Call Trace: __sock_sendmsg net/socket.c:815 [inline] sock_write_iter+0x2de/0x3e0 net/socket.c:1266 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x612/0xba0 fs/read_write.c:687 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f173130ecb9 Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 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 d8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd67e44248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f173130ecb9 RDX: 0000000000000001 RSI: 0000200000000000 RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd67e44388 R13: 0000000000000002 R14: 00002000000000c0 R15: 0000000000000002 ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98096", "url": "https://ubuntu.com/security/CVE-2026-98096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: restore network header before routing and forwarding ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative. This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows. Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98098", "url": "https://ubuntu.com/security/CVE-2026-98098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL deref in tipc_named_node_up() on empty publication list User-space applications can bind a large number of service addresses to one or more sockets. Each binding of a local-scope service address inserts one entry (publication) into the TIPC name table. If the number of these publications exceeds TIPC_MAX_PUBL (65535), protocol service types (such as node state and link state) are no longer inserted into the name table. This causes two issues: 1. User-space applications subscribing to node or link up/down events stop receiving notifications. 2. A NULL pointer dereference can occur: BUG: kernel NULL pointer dereference, address: 00000000000000d0 ... CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full) ... RIP: 0010:tipc_named_node_up (./include/linux/skbuff.h:2251 net/tipc/name_distr.c:195 net/tipc/name_distr.c:221) ... Call Trace: tipc_node_write_unlock (net/tipc/node.c:428) tipc_rcv (net/tipc/node.c:934 net/tipc/node.c:2189) tipc_udp_recv (net/tipc/udp_media.c:389) Thread 1 (tipc_net_finalize) | Thread 2 (named_distribute) -----------------------------|----------------------------- | ... | list_for_each_entry(publ, pls, binding_node) { | ... | __skb_queue_tail(list, skb); | ... | } | ... | hdr = buf_msg(skb_peek_tail(list)); ... | tipc_nametbl_publish(); | If 'tipc_nametbl_publish()' (Thread 1) fails because the number of local publications reaches TIPC_MAX_PUBL, list (Thread 2) will be empty. As a result, NULL is passed to 'buf_msg()', leading to a NULL pointer dereference. Fix these issues by allowing protocol service types (node state, link state, and topology server) to be inserted into the name table unconditionally. This ensures that users subscribing to these types always receive notifications. In addition, the maximum number of local user publications is reduced to (TIPC_MAX_PUBL - 1). This ensures that the maximum bulk size calculated in tipc_link_set_queue_limits() remains valid.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98108", "url": "https://ubuntu.com/security/CVE-2026-98108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan l2cap_new_connection() sets default value of channel mode to match the parent channel. l2cap_le_connect_req() left this at the default, and created L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that mode. This causes FLAG_DEFER_SETUP channels to reply to L2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect. It can also result to stack OOB write (of l2cap_alloc_cid determined values) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not limit maximum number of deferred channels or check for duplicate ident. Fix by setting chan->mode correctly in l2cap_le_connect_req(). Also check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE instead of OOB write to make it less brittle.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98113", "url": "https://ubuntu.com/security/CVE-2026-98113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: rate limit unmapped SID errors A client can include many structurally valid but unmapped SIDs in a DACL. Logging every mapping failure lets one request generate hundreds of kernel error messages. Rate limit the message to prevent an authenticated client from flooding the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98116", "url": "https://ubuntu.com/security/CVE-2026-98116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation with an mmap_count check performed under the PCM stream lock, but the lock is released long before the buffer is actually freed: snd_pcm_sync_stop(), constraint refinement and do_free_pages() all happen in between. snd_pcm_mmap_data(), on the other hand, takes no lock at all: it validates against the old buffer's state and dma_bytes, remaps its pages into the VMA, and only then increments mmap_count. A concurrent mmap() can therefore slip in between the check and the free. remap_pfn_range() installs writable PTEs for the old buffer's pages without taking page references, and the subsequent do_free_pages() returns those pages to the page allocator while the VMA still maps them. This leaves a stale, writable mapping of freed pages: a page-level use-after-free that can be leveraged for local privilege escalation. Make snd_pcm_mmap_data() participate in the buffer-access scheme introduced for hw_params/hw_free: acquire runtime->buffer_accessing before validating and remapping, and release it afterwards. Buffer reallocation already fails with -EBUSY while accessors are active, and the mmap side now fails with -EBUSY while a reallocation is in progress, so the validate/remap sequence and the check/free sequence can no longer interleave. A reproducer that turns this race into a stale writable mapping of the freed DMA buffer pages is available on request.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98121", "url": "https://ubuntu.com/security/CVE-2026-98121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix NULL pointer dereference in PM callbacks msc313e_wdt_probe() doesn't set the driver data for the platform device. As a result, dev_get_drvdata() in msc313e_wdt_suspend() and msc313e_wdt_resume() will return NULL, leading to a NULL pointer dereference afterward. Set the platform device driver data in msc313e_wdt_probe().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98123", "url": "https://ubuntu.com/security/CVE-2026-98123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration sctp_verify_asconf() walks ASCONF-ACK parameters with sctp_walk_params(), which advances by SCTP_PAD4(length), while the consumer sctp_get_asconf_response() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset. When those bytes yield a length of zero, the while loop over asconf_ack_len makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help). The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read. Reject SCTP_PARAM_ERR_CAUSE parameters shorter than sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERR_CAUSE parameter the consumer can see, so the consumer's asconf_ack_len check is dropped and it returns err_param->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTP_PARAM_ERR_CAUSE per RFC 5061. The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98130", "url": "https://ubuntu.com/security/CVE-2026-98130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START The SCTP_CMD_TIMER_START handler checks timer_pending() before calling timer_reduce(). The timer can expire and detach between these operations, causing timer_reduce() to rearm the timer without taking the association reference required for the newly armed timer. The timer callback later unconditionally drops its association reference, which can leave the association reference count unbalanced and result in use-after-free during association teardown. Use the return value of timer_reduce() to determine whether the timer was actually armed. Take the association reference only when timer_reduce() successfully starts a new timer, closing the race between checking the timer state and rearming it. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98154", "url": "https://ubuntu.com/security/CVE-2026-98154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix -EIO cleanup order in queue_rq On -EIO, the RDMA queue_rq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete. Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98157", "url": "https://ubuntu.com/security/CVE-2026-98157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation The poll_msec sysfs store file uses simple_strtoul() which accepts an unsigned long, but the target field (poll_msec) is unsigned int. On 64-bit systems, a value > UINT_MAX is silently truncated when stored. Fix the mismatch by using kstrtouint() instead. This rejects values larger than UINT_MAX at parse time, making truncation impossible. Also add a check for value < 1 to reject the 0-delay case, which would cause the poll work to spin without delay and consume 100% CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89796", "url": "https://ubuntu.com/security/CVE-2026-89796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid infinite kdamond_merge_regions() internal loop Patch series \"mm/damon: unurgent fixes for infinite loop, NULL de-ref and races\", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-98158", "url": "https://ubuntu.com/security/CVE-2026-98158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_async: drop the errored frame instead of resetting its headroom ppp_receive_nonmp_frame() prepends a two-byte direction tag before running the pass/active BPF filters: \t*(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG); Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in ppp_async's process_input_packet() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD: \terr: \t\tif (skb) { \t\t\t/* make skb appear as freshly allocated */ \t\t\tskb_trim(skb, 0); \t\t\tskb_reserve(skb, - skb_headroom(skb)); \t\t} ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head: skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev: kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled ppp_decompress_frame() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason. Rather than restore the headroom, drop the errored frame - as ppp_synctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read. The original V1 of this patch made room in ppp_receive_nonmp_frame() with skb_cow_head(); Eric pointed out that fixing the root cause in the transport is the right approach. Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-93288", "url": "https://ubuntu.com/security/CVE-2026-93288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state sashiko reports: \"nfnl_log_net_exit() calls nf_log_unset(), which clears the logger pointer without an RCU grace period. Immediately after, ops_free_list() frees the per-net state while concurrent packets might still be executing nf_log_packet() under rcu_read_lock().\" Clear the pointer via .pre_exit to make sure rcu readers have completed before pernet storage is free'd. The change in nf_log_syslog.c is only done for consistency: it doesn't use pernet data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93782", "url": "https://ubuntu.com/security/CVE-2026-93782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: flush backend after device ioctls vhost-scsi translates guest response descriptors into userspace iovecs when commands are submitted. Target-core completes those commands asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while an in-flight command still retains response iovecs translated through the old table. If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command completion can write the response to an unrelated userspace object. Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device ioctl. This waits for in-flight commands that can still use the old response iovecs before the ioctl returns.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93783", "url": "https://ubuntu.com/security/CVE-2026-93783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr and dereferences hdr->addr and hdr->ctrl without validating skb->len first. A truncated frame with skb->len less than the minimum header size causes an out-of-bounds read of uninitialized memory. Additionally, a zero-length frame causes skb->len-- to underflow to UINT_MAX, making skb_tail_pointer() read far past the buffer. Commit 23882b828c3c (\"Bluetooth: RFCOMM: validate skb length in MCC handlers\") fixed the same class of missing-length-check bugs in the MCC sub-handlers, but the top-level rfcomm_recv_frame() was left unfixed. KMSAN reports: BUG: KMSAN: uninit-value in rfcomm_run ... Uninit was created at: __alloc_skb+0x474/0xb60 vhci_write+0xe9/0x870 Fix this by rejecting frames smaller than sizeof(struct rfcomm_hdr) + 1 (the minimum frame must have a 3-byte header and a 1-byte FCS).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93784", "url": "https://ubuntu.com/security/CVE-2026-93784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie() The KASAN allocation trace shows that a malformed IE buffer is stored via SIOCSIWGENIE (cfg80211_wext_siwgenie()) without any validation. The crash trace shows that a subsequent SIOCSIWESSID triggers a connection attempt which calls cfg80211_sme_get_conn_ies() to process the stored IE buffer, causing: - An out-of-bounds read in skip_ie() which reads ies[pos+1] (the length byte) past the end of the 1-byte buffer. - An integer underflow in the memcpy size argument when offs returned by ieee80211_ie_split() exceeds ies_len, causing unsigned subtraction to wrap to SIZE_MAX and triggering a fortify panic. Fix this by validating the IE buffer in cfg80211_wext_siwgenie() before storing it. [drop unnecessary ie_len check, update commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93785", "url": "https://ubuntu.com/security/CVE-2026-93785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate idmap key payload length The cifs.idmap key type stores its payload length in key->datalen, which is limited to U16_MAX. Accepting a larger key payload truncates the recorded length and can make later users interpret the payload using inconsistent bounds. Reject oversized preparsed payloads before allocating or copying them. This keeps key->datalen consistent with the stored data for both inline and separately allocated idmap payloads.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93789", "url": "https://ubuntu.com/security/CVE-2026-93789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: bound aligned TLV advance in FW parser Validate ALIGN(tlv_len, 4) against remaining parser length before consuming bytes from the firmware image. This avoids length underflow on malformed TLVs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93795", "url": "https://ubuntu.com/security/CVE-2026-93795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix leaks and online flag on radix_tree_insert failure When radix_tree_insert() fails in blkg_create(), the error path has two issues: 1. blkg->online is set to true unconditionally, even when the blkg was never fully inserted. Move the assignment inside the success block. 2. The error path calls blkg_put() without first calling percpu_ref_kill(). Because the refcount is still in percpu mode, percpu_ref_put() only does this_cpu_sub() without checking for zero, so blkg_release() is never triggered. This permanently leaks the blkg memory, its percpu iostat, policy data, the parent blkg reference, and the cgroup css reference — the latter preventing the cgroup from ever being destroyed. Fix by replacing blkg_put() with percpu_ref_kill(), matching the pattern used in blkg_destroy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93797", "url": "https://ubuntu.com/security/CVE-2026-93797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix an off-by-1 boundary check Before looking at the 11th byte, check the length is big enough.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93798", "url": "https://ubuntu.com/security/CVE-2026-93798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix reloc root cleanup in merge_reloc_roots() If the root we got has zero root refs in its root item, we are resetting the root's ->reloc_root without using barriers like we do everywhere else. Sashiko complained about this while reviewing another patch, and it's correct (see the Link tag below). Also, we should not clear BTRFS_ROOT_DEAD_RELOC_TREE from the root unless the root points to the reloc root we have. Fix this by using clear_reloc_root(), which issues the memory barrier after setting the root's ->reloc_root to NULL and before clearing the bit BTRFS_ROOT_DEAD_RELOC_TREE from the root.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93800", "url": "https://ubuntu.com/security/CVE-2026-93800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol() If during relocation we fail in insert_dirty_subvol() because btrfs_update_reloc_root() returned an error, we will leave a root's reloc_root field pointing to a reloc root that was freed instead of NULL, resulting later in a use-after-free, or double free attempt during unmount. The sequence of steps is this: 1) During relocation the call to btrfs_update_reloc_root() in insert_dirty_subvol() fails, so insert_dirty_subvol() returns the error to merge_reloc_root() without adding the root to the list rc->dirty_subvol_roots; 2) Then merge_reloc_root() aborts the current transaction because insert_dirty_subvol() returned an error; 3) Up the call chain, merge_reloc_roots() gets the error, adds the reloc root for root X to the local reloc_roots list and jumps to the 'out' label, where it calls free_reloc_roots() to free all the reloc roots in the local reloc_roots list. This frees the reloc root for root X; 4) We go up the call chain to relocate_block_group() which calls clean_dirty_subvols() to go over dirty roots and set their ->reloc_root field to NULL, but root X is not in the dirty_subvol_roots list, so its ->reloc_root still points to a reloc root; 5) Relocation finishes, with an error and a transaction abort, but the ->reloc_root field for root X still points to the reloc root that was freed in step 3; 6) When unmounting the fs we end up calling: btrfs_free_fs_roots() btrfs_drop_and_free_fs_root() --> calls btrfs_put_root() against root X's ->reloc_root which is not NULL and points to the already freed reloc root in step 4 above Resulting in a use-after-free to a double free attempt. Syzbot reported this with the following dmesg/syslog: [ 106.004389][ T5339] BTRFS error (device loop0 state A): Transaction aborted (error -5) [ 106.014266][ T5339] BTRFS: error (device loop0 state A) in merge_reloc_root:1655: errno=-5 IO failure [ 106.021891][ T1061] BTRFS error (device loop0 state A): error while writing out transaction: -5 [ 106.026964][ T1061] BTRFS warning (device loop0 state A): Skipping commit of aborted transaction. [ 106.033807][ T5340] BTRFS error (device loop0 state A): bdev /dev/loop0 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 [ 106.039265][ T1061] BTRFS: error (device loop0 state A) in cleanup_transaction:2067: errno=-5 IO failure [ 106.044382][ T5339] BTRFS info (device loop0 state EA): forced readonly [ 106.074329][ T5339] BTRFS: error (device loop0 state EA) in merge_reloc_roots:1887: errno=-5 IO failure [ 106.081004][ T5356] BTRFS info (device loop0 state EA): scrub: started on devid 1 [ 106.085611][ T5339] BTRFS info (device loop0 state EA): balance: ended with status: -30 [ 106.089517][ T5356] BTRFS info (device loop0 state EA): scrub: not finished on devid 1 with status: -30 [ 106.662365][ T5338] BTRFS info (device loop0 state EA): last unmount of filesystem 3a375e4e-b156-4d76-a2ad-16e198ce1409 [ 106.682946][ T5338] ================================================================== [ 106.686574][ T5338] BUG: KASAN: slab-use-after-free in btrfs_put_root+0x2f/0x250 [ 106.690090][ T5338] Write of size 4 at addr ffff88803f978630 by task syz.0.0/5338 [ 106.693173][ T5338] [ 106.694279][ T5338] CPU: 0 UID: 0 PID: 5338 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) [ 106.694293][ T5338] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 106.694300][ T5338] Call Trace: [ 106.694308][ T5338] [ 106.694314][ T5338] dump_stack_lvl+0xe8/0x150 [ 106.694331][ T5338] print_address_description+0x55/0x1e0 [ 106.694343][ T5338] ? btrfs_put_root+0x2f/0x250 [ 106.694358][ T5338] print_report+0x58/0x70 [ 106. ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93802", "url": "https://ubuntu.com/security/CVE-2026-93802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: validate beacon length before fixed buffer copy rsi_prepare_beacon() copies the mac80211 beacon frame after FRAME_DESC_SZ into a management skb whose usable tailroom may be smaller than MAX_MGMT_PKT_SIZE after alignment. Validate the beacon length against the actual tailroom before the copy and skb_put(). Leave ownership of the management skb with the caller on error, matching the existing rsi_send_beacon() cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93803", "url": "https://ubuntu.com/security/CVE-2026-93803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libipw: fix key index receive bound checks libipw_rx() reads skb->data[hdrlen + 3] to extract the WEP key index in both the software-decrypt key selection path and the hardware-decrypted IV/ICV strip path. In both places the existing guard only checks skb->len >= hdrlen + 3, which proves bytes up to hdrlen + 2 but not the byte at hdrlen + 3. Require hdrlen + 4 bytes before reading that item in both paths. This is a local source-boundary check only; it does not change the key index semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93805", "url": "https://ubuntu.com/security/CVE-2026-93805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate rx/tx MLME callback frame lengths before access cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints before rejecting frames shorter than the frame-control field. After that, they only require len >= 2 before dispatching into subtype handlers that assume their fixed fields are present. The frames that trip this are not shorter than 2 bytes; they are short relative to their subtype. mwifiex is a concrete in-tree example on the length side: mwifiex_process_mgmt_packet() only requires a 4-address ieee80211_hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and removing addr4, pkt_len can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARN_ON(len < 2) does not fire on such a frame, and cfg80211_process_deauth() then reads u.deauth.reason_code as a two-byte access starting at offset 24, immediately past the 24-byte buffer. Add a frame-control length gate, then validate each subtype's minimum frame size in an if/else-if chain that mirrors the dispatch logic. Trace only after the frame is known to be well-formed. Side effects of this change: - The WARN_ON(len < 2) is dropped. It only guarded the frame_control read, never the subtype fixed fields, and it does not fire on the frames that actually trigger the out-of-bounds read (which are >= 2). The len >= 2 check is kept as the guard before dereferencing frame_control, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93807", "url": "https://ubuntu.com/security/CVE-2026-93807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers rsi_hal_load_key() copies tx_mic_key and rx_mic_key from data[16] and data[24] whenever key data is present. Those offsets are only part of the 32-byte TKIP key layout. Shorter keys used by other ciphers, such as CCMP, do not provide those bytes, so the unconditional copies can read past the supplied key buffer. Only copy the MIC keys for TKIP, and reject malformed TKIP keys that are shorter than the expected 32-byte layout. [drop useless length check]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93808", "url": "https://ubuntu.com/security/CVE-2026-93808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: caiaq: validate EP1 reply lengths usb_ep1_command_reply_dispatch() uses buf[0] as a command byte and then reads command-specific fixed items from the same URB buffer. Several paths use buf + 1, buf[1], buf[2], or buf + 3 without first proving that urb->actual_length contains those bytes. Add per-command length checks, use a payload length derived from the bytes after the command byte for the control-state copy, and reject short analog input payloads before the input helper reads fixed offsets from the EP1 reply.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93811", "url": "https://ubuntu.com/security/CVE-2026-93811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling 1. When ndr_decode_v4_ntacl() fails, the code jumped to free_n_data which only freed n.data, skipping kfree(acl.sd_buf) and leaking the buffer. Zero-initialize struct xattr_ntacl acl, reorder error labels to out_free to release acl.sd_buf on all error paths. 2. if (acl.sd_size < sizeof(struct smb_ntsd)) is true, original code returned success without freeing sd_buf and left stale *pntsd. Set rc = -EINVAL before jumping to out_free to return error code and free buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93812", "url": "https://ubuntu.com/security/CVE-2026-93812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr ndr_encode_v4_ntacl() allocates sd_ndr.data via kzalloc() at entry. If any subsequent ndr_write_*() call returns error during encoding, the allocated sd_ndr.data won't be freed and causes memory leak. Move kfree(sd_ndr.data) into out label to ensure the buffer gets released on all success and error return paths.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93813", "url": "https://ubuntu.com/security/CVE-2026-93813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tree-checker: validate INODE_REF's namelen [BUG] A crafted btrfs image can trigger the following crash: BUG: unable to handle page fault for address: ffffd1dc42884000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page CPU: 9 UID: 0 PID: 1034 Comm: poc Not tainted 7.1.0-rc4-custom+ #383 PREEMPT(full) 46af0a92938a63be7132e0dfd71e62327c51d5c2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:memcpy+0xc/0x10 Call Trace: read_extent_buffer+0xe4/0x100 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] btrfs_get_name+0x15e/0x1e0 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] reconnect_path+0x165/0x390 exportfs_decode_fh_raw+0x337/0x400 ? drop_caches_sysctl_handler+0xb0/0xb0 ---[ end trace 0000000000000000 ]--- RIP: 0010:memcpy+0xc/0x10 Kernel panic - not syncing: Fatal exception [CAUSE] TThe crafted image has the following corrupted INODE_REF item: item 9 key (258 INODE_REF 257) itemoff 11544 itemsize 4106 \tindex 2 namelen 4096 name: d\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000 The itemsize matches the namelen, but the namelen is 4096, way larger than normal name length limit (BTRFS_NAME_LEN, 255). Meanwhile the memory of the @name is only 255 byte sized, this will cause out-of-boundary access, and cause the above crash. [FIX] Add extra namelen verification for INODE_REF, just like what we have done in ROOT_REF checks. Now the crafted image can be rejected gracefully: BTRFS critical (device dm-2): corrupt leaf: root=5 block=30572544 slot=14 ino=259, invalid inode ref name length, has 4096 expect [1, 255] BTRFS error (device dm-2): read time tree block corruption detected on logical 30572544 mirror 2 [ Rebase, add a Link: tag, add an simple cause analyze ]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93815", "url": "https://ubuntu.com/security/CVE-2026-93815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: au1000: move free_irq out of the close-time spinlocked section au1000_close() calls free_irq() while aup->lock is still held with spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ descriptor request mutex, so it does not belong inside the close-time spinlocked section. This was found by our static analysis tool and then confirmed by manual review of the in-tree au1000_close() .ndo_stop path. The reviewed path keeps aup->lock held across the MAC reset, queue stop and free_irq(dev->irq, dev). A directed runtime validation kept that ndo_stop carrier and the same free_irq(dev->irq, dev) operation under the driver lock. Lockdep reported \"BUG: sleeping function called from invalid context\" and \"Invalid wait context\" while free_irq() was taking desc->request_mutex, with au1000_close() and free_irq() on the stack. Drop aup->lock before freeing the IRQ. The protected close-time work still stops the device and queue before IRQ teardown, but the sleepable IRQ core path now runs outside the spinlocked section.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93816", "url": "https://ubuntu.com/security/CVE-2026-93816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate inline dentry name lengths before conversion Inline dentry conversion copies names out of the inline dentry area before checking that each recorded name length fits in the available filename slots. A corrupted image can therefore make the conversion path read past the inline filename storage while building the regular dentry block. Validate each inline dentry name length against the inline filename area before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93819", "url": "https://ubuntu.com/security/CVE-2026-93819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93820", "url": "https://ubuntu.com/security/CVE-2026-93820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rockchip: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93821", "url": "https://ubuntu.com/security/CVE-2026-93821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93822", "url": "https://ubuntu.com/security/CVE-2026-93822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: iproc: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93825", "url": "https://ubuntu.com/security/CVE-2026-93825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: Add NULL check for spi_get_device_id() in spi_get_device_match_data() Prevent NULL pointer dereference when spi_get_device_id() returns NULL, which can happen when using driver_override without matching SPI ID entry.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93830", "url": "https://ubuntu.com/security/CVE-2026-93830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac2: disable RBUE in default RX interrupt mask Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97407", "url": "https://ubuntu.com/security/CVE-2026-97407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in set_fmt rockchip_pdm_set_fmt() calls pm_runtime_get_sync() before accessing hardware registers, but ignores its return value. If the runtime resume fails, the function continues to perform register accesses while the device state is undefined. Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() and return early on failure to avoid unpowered register accesses.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97408", "url": "https://ubuntu.com/security/CVE-2026-97408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate connectionless PSM length Connectionless L2CAP frames carry a two-byte PSM at the start of the payload. l2cap_recv_frame() currently reads that PSM unconditionally after validating only the outer L2CAP length. A malformed connectionless frame with a zero- or one-byte payload can therefore make the parser read beyond the advertised skb payload and use tailroom bytes as part of the PSM. A VHCI-backed QEMU reproducer injected a one-byte connectionless payload and reached the unchecked read. Reject connectionless frames that cannot contain the PSM before reading or pulling it. This preserves all valid connectionless frames while dropping only structurally incomplete packets.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97411", "url": "https://ubuntu.com/security/CVE-2026-97411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ibm: emac: mal: fix potential system hang in mal_remove() napi_disable() is not idempotent and calling it on an already-disabled or unenabled NAPI context will cause the kernel to spin indefinitely waiting for the NAPI_STATE_SCHED bit to clear. In mal_remove(), napi_disable() is called unconditionally. If no MACs were registered, NAPI was never enabled. Also, if they were registered but subsequently unregistered, NAPI was already disabled in mal_unregister_commac(). In either case, calling napi_disable() causes the kernel to hang upon module removal. Fix this by only calling napi_disable() in mal_remove() if the commac list is not empty (which implies NAPI is enabled).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97413", "url": "https://ubuntu.com/security/CVE-2026-97413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Fix integer underflow in process_read and process_write usr_len is read from a network-supplied message field (le16_to_cpu) and used to compute data_len = off - usr_len without validating that usr_len <= off. A malicious RDMA client can send usr_len > off causing an integer underflow, resulting in data_len wrapping to a huge size_t value which is then passed to the rdma_ev callback as a memory length, leading to out-of-bounds memory access. Fix by reading and validating usr_len <= off before rtrs_srv_get_ops_ids() in both process_read() and process_write(), ensuring the early return path acquires no reference and has no resource leak.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97416", "url": "https://ubuntu.com/security/CVE-2026-97416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: balance: fix potential bg lookup failure in btrfs_may_alloc_data_chunk() [BUG] Running btrfs balance can trigger a null-ptr-deref before relocating a data chunk when metadata corruption leaves a chunk in the chunk tree without a corresponding block group in the in-memory cache: KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] RIP: 0010:btrfs_may_alloc_data_chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601 Call Trace: __btrfs_balance fs/btrfs/volumes.c:4217 [inline] btrfs_balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604 btrfs_ioctl_balance fs/btrfs/ioctl.c:3577 [inline] btrfs_ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313 ... [CAUSE] __btrfs_balance() iterates the on-disk chunk tree and passes the chunk logical bytenr to btrfs_may_alloc_data_chunk() before relocating a data chunk. That helper then queries the in-memory block group cache: cache = btrfs_lookup_block_group(fs_info, chunk_offset); chunk_type = cache->flags; /* cache may be NULL */ A corrupt image can contain a chunk item whose matching block group item is missing, so no block group is ever inserted into the cache. In that case btrfs_lookup_block_group() returns NULL. The code only guards this with ASSERT(cache), which becomes a no-op when CONFIG_BTRFS_ASSERT is disabled. The subsequent dereference of cache->flags therefore crashes the kernel. [FIX] Add a NULL check after btrfs_lookup_block_group() in btrfs_may_alloc_data_chunk() and print and error message for clarity.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97417", "url": "https://ubuntu.com/security/CVE-2026-97417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack() The timestamp-only fast path dereferences the option stream as *(__be32 *)ptr, which assumes 4-byte alignment that the TCP option stream does not guarantee. Use get_unaligned_be32() instead, which reads the value safely and already returns host byte order, so the htonl() on the comparison constant can be dropped. This matches the existing get_unaligned_be32() use later in the same function.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97418", "url": "https://ubuntu.com/security/CVE-2026-97418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es18xx: check control allocation before private data setup snd_es18xx_mixer() creates controls with snd_ctl_new1() and then stores bookkeeping pointers or sets private_free before calling snd_ctl_add(). snd_ctl_new1() can return NULL on allocation failure, so those writes can dereference a NULL control pointer. Check the returned control pointers before using them and return -ENOMEM on allocation failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97419", "url": "https://ubuntu.com/security/CVE-2026-97419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: broadcast netlink notifications in the device's net namespace The HSR generic netlink family sets .netnsok = true. HSR devices can live in network namespaces other than init_net. Two async notifiers broadcast events with genlmsg_multicast(). They are hsr_nl_ringerror() and hsr_nl_nodedown(). That helper delivers only on the default genl socket in init_net. So the events always land in init_net. The network namespace of the device does not matter. This has two effects. A listener in the device's own namespace never sees its own ring error and node down events. A privileged listener in init_net receives events from HSR devices in other namespaces. The payload carries the peer node MAC (HSR_A_NODE_ADDR) and the slave port ifindex (HSR_A_IFINDEX). Switch both callers to genlmsg_multicast_netns(). Other families with .netnsok = true already do this. Examples are gtp, ovpn, team, batman-adv, netdev-genl, ethtool and handshake. hsr_nl_ringerror() already has the slave port. It uses dev_net(port->dev). hsr_nl_nodedown() takes the namespace from the master port via hsr_port_get_hsr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97420", "url": "https://ubuntu.com/security/CVE-2026-97420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: NUL-terminate replaced sysctl value When writing to sysctls, proc_sys_call_handler() guarantees that the buffer passed to proc handlers is NUL-terminated. If bpf_sysctl_set_new_value() replaces the pending sysctl value, it can hand a replacement buffer directly to proc handlers. However, the helper currently copies only buf_len bytes into that buffer without appending a NUL terminator, leaving downstream parsers vulnerable to out-of-bounds access. Fix this by appending a '\\0' after the replaced value to restore the expected sysctl semantics. Since the helper already rejects buf_len greater than PAGE_SIZE - 1, there is always room for the extra byte. Reproduced in a QEMU x86_64 guest booted with KASAN while exercising the sysctl replacement path with a cgroup/sysctl BPF program. The reproducer targets `/proc/sys/net/core/flow_limit_cpu_bitmap`, fills the original user write buffer with non-zero bytes, and overrides the sysctl value so the replacement buffer lacks a terminating NUL. Under that setup, the pre-fix kernel reported: BUG: KASAN: slab-out-of-bounds in strnchrnul+0x72/0x90 Read of size 1 at addr ffff88800de57000 by task repro_patch3/66 CPU: 0 UID: 0 PID: 66 Comm: repro_patch3 Not tainted 7.1.0-rc3-00269-g8370ca1f87cc #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? strnchrnul+0x72/0x90 ? strnchrnul+0x72/0x90 kasan_report+0xca/0x100 ? strnchrnul+0x72/0x90 strnchrnul+0x72/0x90 bitmap_parse+0x37/0x2e0 flow_limit_cpu_sysctl+0xc6/0x840 ? __pfx_flow_limit_cpu_sysctl+0x10/0x10 ? __kvmalloc_node_noprof+0x5ba/0x870 proc_sys_call_handler+0x31d/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? selinux_file_permission+0x39f/0x500 ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... The buggy address is located 0 bytes to the right of allocated 4096-byte region [ffff88800de56000, ffff88800de57000) With this fix applied, rerunning the same sysctl-targeted path yields no corresponding KASAN reports.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97421", "url": "https://ubuntu.com/security/CVE-2026-97421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz() Several corner cases, especially important on 32 bits: - umem->iova is u64, the function argument should pass in u64 or iova will be truncated - Check that the length is not too large for the iova - Check that lengths > 4G don't overflow the GENMASK", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97430", "url": "https://ubuntu.com/security/CVE-2026-97430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: Prevent queuing new commands if xhci is inaccessible Refuse to queue a new command on the command ring if xHC is marked inaccessible with the HCD_FLAG_HW_ACCESSIBLE. HCD_FLAG_HW_ACCESSIBLE is set and cleared in suspend and resume. Also print a warning if xhci is being suspended with commands still pending on the command ring.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97434", "url": "https://ubuntu.com/security/CVE-2026-97434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: fix handling of NAPI on the remove path All the NAPI instances for a DPSW device are attached to the first switch port's net_device but shared by all ports. The NAPI instances get disabled only once the last port goes down. This causes an issue on the .remove() path where each port is unregistered and freed one at a time, causing the NAPI instances to be deleted even though they are not disabled. In order to avoid this, split up the unregister_netdev() calls from the free_netdev() so that we make sure all ports go down before we attempt a deletion of NAPI instances. Also, make the netif_napi_del() explicit as it is on the .probe() path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97435", "url": "https://ubuntu.com/security/CVE-2026-97435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: flower: reject cross-chip redirect dsa_port_from_netdev() may return a valid port from a different switch chip. Programming another chip's port index into the local hardware causes redirection to the wrong port, or an out-of-bounds access if the index exceeds the local chip's port count. Apply a minimal fix that adds a check to catch this case and adjusts the extack message. When cls->common.skip_sw is not set, the operation could instead redirect to the upstream port and let the software or upstream switch(es) handle the forward, but that is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97436", "url": "https://ubuntu.com/security/CVE-2026-97436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: rework FDB management on the bridge leave path On bridge leave, the dpaa2_switch_port_set_fdb() function always allocates a new FDB for the port which is becoming standalone. In case no FDB is found, then the port leaving a bridge will continue to use the current one. The above logic does not cover the case in which there are multiple bridges which have ports from the same DPSW instance. In this case, when the last port leaves bridge #1, it finds an unused FDB to switch to, but the old FDB is not marked as unused. Since the number of FDBs is equal to the number of DPSW interfaces, this will eventually lead to multiple ports sharing the same FDB. Fix this by changing how we are managing the FDBs on the leave path. Instead of directly allocating a new FDB, first verify if the current port is the last one to leave a bridge. If this is the case, then continue to use the current FDB and only allocate another FDB if there are other ports remaining in the bridge.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97437", "url": "https://ubuntu.com/security/CVE-2026-97437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e() The bounds check in ntfs_dir_emit() compares fname->name_len (a character count) against e->size (a byte count) without accounting for the 2-byte-per-character UTF-16LE encoding or the ATTR_FILE_NAME header size: if (fname->name_len + sizeof(struct NTFS_DE) > le16_to_cpu(e->size)) This computes: name_len + 16 > e_size The correct check must account for the ATTR_FILE_NAME header (66 bytes before the name) and the UTF-16LE character size (2 bytes each): sizeof(NTFS_DE) + offsetof(ATTR_FILE_NAME, name) + name_len * sizeof(short) > e_size Which computes: 16 + 66 + name_len * 2 > e_size The correct calculation already exists as fname_full_size() in ntfs.h and is used in cmp_fnames(), namei.c, and fslog.c, but was not used in the readdir path. A crafted NTFS image with an index entry containing a small e->size but large fname->name_len bypasses the current check, causing ntfs_utf16_to_nls() to read past the entry boundary. Additionally, add a key_size validation in hdr_find_e() to ensure the declared key_size does not exceed the available entry data, preventing comparison functions from reading past entry boundaries on the lookup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97438", "url": "https://ubuntu.com/security/CVE-2026-97438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate index entry key bounds [BUG] A malformed NTFS directory index entry can advertise a key_size larger than the bytes actually present in its NTFS_DE payload. Directory lookup then passes that malformed key to cmp_fnames(), which can read past the end of the kmalloc'ed index buffer. BUG: KASAN: slab-out-of-bounds in fname_full_size fs/ntfs3/ntfs.h:590 [inline] BUG: KASAN: slab-out-of-bounds in cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 Read of size 1 at addr ffff88801c313018 by task syz.6.3365/9279 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 __asan_report_load1_noabort+0x14/0x30 mm/kasan/report_generic.c:378 fname_full_size fs/ntfs3/ntfs.h:590 [inline] cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 hdr_find_e.isra.0+0x3ed/0x670 fs/ntfs3/index.c:762 indx_find+0x4b5/0x900 fs/ntfs3/index.c:1186 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... Allocated by task 9279: kasan_save_stack+0x39/0x70 mm/kasan/common.c:56 kasan_save_track+0x14/0x40 mm/kasan/common.c:77 kasan_save_alloc_info+0x37/0x60 mm/kasan/generic.c:573 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0xc3/0xd0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __do_kmalloc_node mm/slub.c:5650 [inline] __kmalloc_noprof+0x2bd/0x900 mm/slub.c:5662 kmalloc_noprof include/linux/slab.h:961 [inline] indx_read+0x41d/0xad0 fs/ntfs3/index.c:1059 indx_find+0x447/0x900 fs/ntfs3/index.c:1179 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... [CAUSE] The index-header validators only validated INDEX_HDR-level geometry. They did not walk each NTFS_DE to verify entry alignment, subnode layout, or that key_size fit inside the entry payload. They also allowed a last sentinel entry to carry a non-zero key_size. [FIX] Walk every NTFS_DE in ntfs3's index-header validators and reject entries with invalid layout, mismatched subnode state, oversized key_size, or non-zero sentinel keys before lookup or log replay can consume them.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97439", "url": "https://ubuntu.com/security/CVE-2026-97439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib [BUG] A corrupted ntfs3 image can hit a NULL function pointer call in generic_perform_write() after toggling system.ntfs_attrib and then overwriting system.dos_attrib on the same file. BUG: kernel NULL pointer dereference, address: 0000000000000000 \\#PF: supervisor instruction fetch in kernel mode \\#PF: error_code(0x0010) - not-present page PGD bed5067 P4D bed5067 PUD 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffff88801025f988 EFLAGS: 00010246 Call Trace: generic_perform_write+0x409/0x8c0 mm/filemap.c:4255 __generic_file_write_iter+0x1bb/0x200 mm/filemap.c:4372 ntfs_file_write_iter+0xcd9/0x1c20 fs/ntfs3/file.c:1253 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x63b/0xf70 fs/read_write.c:686 ksys_write+0x133/0x250 fs/read_write.c:738 __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x77/0xc0 fs/read_write.c:746 ... [CAUSE] system.ntfs_attrib updates ATTR_DATA flags via ni_new_attr_flags() and switches i_mapping->a_ops to ntfs_aops_cmpr when FILE_ATTRIBUTE_COMPRESSED is set. system.dos_attrib then overwrites ni->std_fa from a one-byte DOS attribute value, clearing the compression bit without updating ATTR_DATA or the mapping operations. Old buffered writes use is_compressed(ni) to choose __generic_file_write_iter(). That leaves generic_perform_write() calling a NULL write_begin callback from ntfs_aops_cmpr. [FIX] Treat system.dos_attrib as a low-byte DOS attribute update and preserve the existing non-DOS attribute bits in ni->std_fa. This keeps compressed and sparse state consistent with ATTR_DATA and the mapping operations while keeping the existing DOS attribute semantics intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97440", "url": "https://ubuntu.com/security/CVE-2026-97440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix node refcount leak on ctrl packet alloc failure qrtr_send_resume_tx() calls qrtr_node_lookup() which takes a reference on the returned node. If the subsequent call to qrtr_alloc_ctrl_packet() fails due to memory allocation failure, the function returns -ENOMEM without calling qrtr_node_release() to release the node reference. Add qrtr_node_release(node) before returning on the allocation failure path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97441", "url": "https://ubuntu.com/security/CVE-2026-97441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: ahci: fail probe if BAR too small for claimed ports When an AHCI controller is disabled in BIOS, its HOST_CAP register may contain a bogus value, e.g. 0xFFFFFFFF. Since CAP.NP (Number of Ports) is a zeroes based 5-bit register field, a value of 0x1f means 32 ports. If CAP.NP claims more ports than can physically fit within the mapped BAR region, accessing port registers beyond the BAR boundary causes a kernel panic. Add validation in ahci_init_one() to check that the BAR size is sufficient for the number of ports claimed in CAP.NP. The check calculates the required MMIO size as: required_size = 0x100 (global registers) + max_ports * 0x80 If required_size exceeds the actual BAR size, the probe fails with -ENODEV, preventing the panic and providing a clear error message. [cassel: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97443", "url": "https://ubuntu.com/security/CVE-2026-97443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/ftrace: Fix WARNING in __unregister_ftrace_function perf_ftrace_function_unregister() unconditionally calls unregister_ftrace_function() without checking whether the ftrace_ops was ever successfully registered. This triggers a WARN_ON in __unregister_ftrace_function() when the ops doesn't have FTRACE_OPS_FL_ENABLED set. This can happen during perf_event_alloc() error cleanup when perf_trace_destroy() is called via __free_event() on an event whose ftrace_ops registration failed or was already torn down by perf_try_init_event()'s err_destroy path. The call path is: perf_event_alloc() error cleanup -> __free_event() -> event->destroy() [tp_perf_event_destroy] -> perf_trace_destroy() -> perf_trace_event_close() -> TRACE_REG_PERF_CLOSE -> perf_ftrace_function_unregister() -> unregister_ftrace_function() -> __unregister_ftrace_function() -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to unregister. If the ops is not enabled, just free the filter and return success.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97444", "url": "https://ubuntu.com/security/CVE-2026-97444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in two places Add boundary checks in acpi_ps_get_next_namestring() and acpi_ps_peek_opcode() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97445", "url": "https://ubuntu.com/security/CVE-2026-97445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources() Enhance buffer validation in acpi_ut_walk_aml_resources() to prevent buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97446", "url": "https://ubuntu.com/security/CVE-2026-97446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package() acpi_ns_custom_package() unconditionally dereferences the first element of the package to read the _BIX version number, without checking for NULL: if ((*Elements)->Common.Type != ACPI_TYPE_INTEGER) When firmware returns a _BIX package whose first element is an unresolvable reference, ACPICA evaluates that entry to NULL. acpi_ns_remove_null_elements() does not strip NULL entries for ACPI_PTYPE_CUSTOM packages (fixed-position format would break if elements were shifted), so acpi_ns_custom_package() sees the NULL and causes a crash. Add a NULL check for the first element (version field) before dereferencing it. The caller then receives AE_AML_OPERAND_TYPE instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97448", "url": "https://ubuntu.com/security/CVE-2026-97448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add validation for node in acpi_ns_build_normalized_path() Add validation for node in acpi_ns_build_normalized_path() to prevent use-after-free vulnerabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97449", "url": "https://ubuntu.com/security/CVE-2026-97449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add package limit checks in parser functions Add package limit checks in parser functions to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97450", "url": "https://ubuntu.com/security/CVE-2026-97450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate handler object type in two places ACPICA: validate handler object type in acpi_ev_has_default_handler() and acpi_ev_find_region_handler().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97451", "url": "https://ubuntu.com/security/CVE-2026-97451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op) Add overflow check for Index + Length to prevent integer overflow when calculating the truncation length. This prevents negative size parameter being passed to memcpy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97452", "url": "https://ubuntu.com/security/CVE-2026-97452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Prevent adding invalid references Prevent adding references for local, argument, and debug objects in acpi_ut_copy_simple_object().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97453", "url": "https://ubuntu.com/security/CVE-2026-97453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate byte_count in acpi_ps_get_next_package_length() Validate package length reading in acpi_ps_get_next_package_length().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97454", "url": "https://ubuntu.com/security/CVE-2026-97454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in acpi_ps_get_next_field() Add boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97455", "url": "https://ubuntu.com/security/CVE-2026-97455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix use-after-free in acpi_ds_terminate_control_method() Fix use-after-free issue in acpi_ds_terminate_control_method() by clearing references to method locals and arguments.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97456", "url": "https://ubuntu.com/security/CVE-2026-97456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix condition check in acpi_ps_parse_loop() Fix condition check for AML_ELSE_OP in acpi_ps_parse_loop() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97472", "url": "https://ubuntu.com/security/CVE-2026-97472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: fix temp address generation after prefix deprecation When a router temporarily deprecates an IPv6 prefix (either by sending a Router Advertisement with Preferred Lifetime = 0 or by letting the lifetime expire) and later restores it, the kernel permanently loses its ability to generate temporary privacy addresses (RFC 8981) for that prefix. This happens because the address worker attempts to generate a replacement temporary address when the current one nears expiration. As the base prefix is deprecated already, the generation fails after marking the temporary address as already having spawned a replacement (ifp->regen_count++). When the router eventually restores the prefix, the temporary address becomes active again. However, once it naturally expires, the address worker sees this temporary address already tried to generate one and skips the regeneration. Fix the issue by resetting the regen_count check of the latest temp address generated for the prefix updated by the incoming RA.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97475", "url": "https://ubuntu.com/security/CVE-2026-97475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tegra/soctherma: Switch to devm cooling device registration Use devm_thermal_of_cooling_device_register() to simplify resource management and avoid manual cleanup in error paths. As a side effect this change has the benefit of solving an existing issue. Before, the function tegra_soctherm_remove() only called debugfs_remove_recursive() and never called thermal_cooling_device_unregister() for any of the cooling devices registered here. After the driver removal, the thermal framework's cdev list would still hold references to thermal_cooling_device objects whose devdata pointer (ts) pointed to memory already freed by the platform device's devm cleanup. With this change, the cooling device is unregistered when the driver is removed, thus fixing the issue above.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97476", "url": "https://ubuntu.com/security/CVE-2026-97476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: filter RDS_INFO_* getsockopt by caller's netns The RDS_INFO_* family of getsockopt(2) options reads several file-scope global lists that are not per-netns: rds_sock_info / rds6_sock_info, rds_sock_inc_info / rds6_sock_inc_info -> rds_sock_list rds_tcp_tc_info / rds6_tcp_tc_info -> rds_tcp_tc_list rds_conn_info / rds6_conn_info, rds_conn_message_info_cmn (for the *_SEND_MESSAGES and *_RETRANS_MESSAGES variants), rds_for_each_conn_info (for RDS_INFO_IB_CONNECTIONS) -> rds_conn_hash[] The handlers do not filter by the caller's network namespace. rds_info_getsockopt() has no netns or capable() check, and rds_create() has no capable() check, so AF_RDS is reachable from an unprivileged user namespace. As a result, an unprivileged caller in a fresh user_ns plus netns can read the bound address and sock inode of every RDS socket on the host, the peer address of incoming messages on every RDS socket on the host, the peer address and TCP sequence numbers of every rds-tcp connection on the host, and the peer address and RDS sequence numbers of every RDS connection on the host. The rds-tcp transport is reachable from a non-initial netns (see rds_set_transport()), so a one-shot init_net gate at rds_info_getsockopt() would deny legitimate per-netns visibility to rds-tcp callers. Instead, filter at each handler by comparing the netns of the caller's socket to the netns of the list entry, or to rds_conn_net(conn) for connection paths. Only copy entries whose netns matches the caller. Counters (RDS_INFO_COUNTERS) are aggregate statistics and remain global. Reproducer (KASAN VM, rds and rds_tcp loaded): an AF_RDS socket binds 127.0.0.1:4242 in init_net as root. A child process enters a fresh user_ns plus netns and opens AF_RDS there, then calls getsockopt(SOL_RDS, RDS_INFO_SOCKETS). Before this change, the child sees the init_net socket. After this change, the child sees zero entries. Drop the rds_sock_count, rds_tcp_tc_count, and rds6_tcp_tc_count globals. v2 used them for the size precheck and lens->nr; v3 replaced the precheck with a per-ns count from a first pass over the list, so the globals have no remaining readers. The matching increments and decrements in rds_create()/rds_destroy_sock() and rds_tcp_set_callbacks()/rds_tcp_restore_callbacks() go away with them. Reported by the kernel test robot under clang W=1.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97481", "url": "https://ubuntu.com/security/CVE-2026-97481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix possible ISR soft lockup There are rare cases in which the host gets stuck in the ISR because it is flooded with messages during the startup phase. The reason for the soft lockup in the ISR is the missing FIFO error IRQ (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers the IRQ immediately again. Fix this by adding a check for the FIFOE status and clearing the FIFO if no data is ready (DR). This behavior was observed on an AM62L device which uses the OMAP 8250 driver. Fix it for all 8250 drivers, since the OMAP driver's special IRQ setup handling may trigger this behavior more frequently, but it is not ensured that other 8250 drivers aren't affected.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97482", "url": "https://ubuntu.com/security/CVE-2026-97482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET log goku_irq() handles a number of bus events under a single ep0 path. It already guards the gadget driver suspend/resume callbacks against a NULL ->driver: \tif (dev->gadget.speed != USB_SPEED_UNKNOWN \t\t\t&& dev->driver \t\t\t&& dev->driver->resume) { \t\tspin_unlock(&dev->lock); \t\tdev->driver->resume(&dev->gadget); \t\t... \t} but the very next branch unconditionally dereferences dev->driver when an INT_USBRESET arrives: \tif (stat & INT_USBRESET) { \t\tACK(INT_USBRESET); \t\tINFO(dev, \"USB reset done, gadget %s\\n\", \t\t\tdev->driver->driver.name); \t} If the controller raises INT_USBRESET before any gadget driver has been bound (or after one has been unbound), dev->driver is NULL and the printk dereferences NULL. smatch flags the inconsistency: drivers/usb/gadget/udc/goku_udc.c:1618 goku_irq() error: we previously assumed 'dev->driver' could be null (see line 1607) Fall back to a placeholder when the gadget driver is not bound. No functional change while a gadget driver is bound.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97483", "url": "https://ubuntu.com/security/CVE-2026-97483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: hcd: fix possible deadlock in rh control transfers >From within the SCSI error handler memory allocations must not trigger IO. Handling errors in UAS and the storage driver may involve resetting a device. The thread doing the reset itself relies on VM magic. However, that is insufficient, as resetting a device involves resuming it. Resumption as well as resetting involves conrol transfers to the parent of the device to be reset. That may be a root hub. Hence usbcore must heed the flags passed to usb_submit_urb() processing control transfers to root hubs. The problem exist since the storage driver has been merged.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97484", "url": "https://ubuntu.com/security/CVE-2026-97484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vhci_hcd: fix NULL deref in status_show_vhci platform_get_drvdata() can return NULL if a VHCI host controller's probe failed (e.g. due to USB bus number exhaustion). status_show_vhci() checked for a NULL pdev but not for a NULL hcd returned by platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not return NULL - it returns a pointer offset of 0x260, causing a NULL pointer dereference when that value is subsequently dereferenced. Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move status_show_not_ready() above status_show_vhci() to make it callable from the new error path without a forward declaration.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97485", "url": "https://ubuntu.com/security/CVE-2026-97485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: omfs: handle set_blocksize failures omfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97486", "url": "https://ubuntu.com/security/CVE-2026-97486", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hpfs: handle set_blocksize failures hpfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97487", "url": "https://ubuntu.com/security/CVE-2026-97487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: handle set_blocksize failures jfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97488", "url": "https://ubuntu.com/security/CVE-2026-97488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qnx4: handle set_blocksize failures qnx4 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97489", "url": "https://ubuntu.com/security/CVE-2026-97489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bfs: handle set_blocksize failures bfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the \tBUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97490", "url": "https://ubuntu.com/security/CVE-2026-97490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: affs: handle set_blocksize failures affs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97491", "url": "https://ubuntu.com/security/CVE-2026-97491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Don't sleep inside rds_ib_conn_path_shutdown New rds rdma self tests exposed a hang when tearing down the ib network configs. This is caused by the shutdown worker thread sleeping on the wait_event call, which blocks other work items in the queue. Fix this by changing wait_event to wait_event timeout, and looping until the wait check succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97492", "url": "https://ubuntu.com/security/CVE-2026-97492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed In case reconfiguration of NAN fails, we call ieee80211_handle_reconfig_failure, that marks all interfaces as not in the driver. Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces is called to destroy all the interfaces. If we have any other interface but the NAN one, for example a BSS station, then when its state (links, stations) will be removed, we won't tell the driver about this, because we will think that the interfaces are not in the driver, and then drivers might remain with dangling pointers to objects like stations and links (at least for iwlwifi this is the case). ieee80211_handle_reconfig_failure is meant to be called after we cleaned up the state in the driver, there is no reason to call it for NAN reconfiguration failure. Fix the code to just warn in such a case, as we do in other error paths in reconfig where it is too complicated to rewind.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97502", "url": "https://ubuntu.com/security/CVE-2026-97502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: avoid NULL deref of host->data in IRQ handler mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL: if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; } So we may legitimately reach the rest of the handler with host->data == NULL (and therefore data == NULL). The DATDNE branch already guards against this with an explicit \"if (data != NULL)\" check, but the subsequent TOUTRD (\"read data timeout\") and CRCWR/CRCRD (\"data CRC error\") branches dereference data unconditionally: if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); } if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... } If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this: drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914) Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch. No functional change for callers where data is non-NULL, which is the only case in which these branches did meaningful work before this change.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97506", "url": "https://ubuntu.com/security/CVE-2026-97506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ixp4xx - fix buffer chain unwind on allocation failure chainup_buffers() builds a linked list of buffer descriptors for a scatterlist. If dma_pool_alloc() fails while constructing the list, the current code sets buf to NULL and later dereferences it unconditionally at the end of the function: buf->next = NULL; buf->phys_next = 0; This can lead to a null-pointer dereference on allocation failure. If the failure happens after part of the descriptor chain has already been allocated and DMA-mapped, the partially constructed chain also needs to be released. Fix this by terminating the partially constructed chain on allocation failure and letting the callers unwind it via their existing cleanup paths. Also fix ablk_perform() to preserve the hook pointers before checking for failure, so partially built chains can be freed correctly.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97507", "url": "https://ubuntu.com/security/CVE-2026-97507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dm1105: fix missing error check for dma_alloc_coherent The return value of dm1105_dma_map(), which handles DMA memory allocation, is ignored in dm1105_hw_init(). If dma_alloc_coherent() fails, the driver will proceed using a NULL pointer for DMA transfers, leading to a kernel oops or invalid hardware access. Fix this by checking the return value and propagating -ENOMEM on failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97508", "url": "https://ubuntu.com/security/CVE-2026-97508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Set tb->root_switch to NULL when domain is stopped Similarly what we do with the firmware connection manager. This makes tb_xdp_handle_request() return error to the remote host. However, we need to make sure we keep the uuid alive so that we can reply until the whole domain is released.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97510", "url": "https://ubuntu.com/security/CVE-2026-97510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Release request if tb_cfg_request() fails in __tb_xdomain_response() If tb_cfg_request() fails setting up the request (for example the control channel is shut down already) it returns an error without calling the callback. To avoid leaking that memory, call tb_cfg_request_put() if tb_cfg_request() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-90053", "url": "https://ubuntu.com/security/CVE-2026-90053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_htb: limit htb_classify inner-class filter hops htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent. The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification. htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90054", "url": "https://ubuntu.com/security/CVE-2026-90054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix corruption of urgent data on multi-segment retransmit On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: \t/* tcp_write_xmit() */ \tlimit = mss_now; \tif (tso_segs > 1 && !tcp_urg_mode(tp)) \t\tlimit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: \t/* __tcp_retransmit_skb() */ \tlen = cur_mss * segs;\t\t/* segs > 1, no urg_mode check */ \t... \t/* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: \tseg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) \tseg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) \tseg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90055", "url": "https://ubuntu.com/security/CVE-2026-90055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90056", "url": "https://ubuntu.com/security/CVE-2026-90056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: only stop PTP if it was initialized fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90058", "url": "https://ubuntu.com/security/CVE-2026-90058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai. Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted. Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90062", "url": "https://ubuntu.com/security/CVE-2026-90062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: move hardware offload step after building the chain blob Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90063", "url": "https://ubuntu.com/security/CVE-2026-90063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90067", "url": "https://ubuntu.com/security/CVE-2026-90067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: validate banner payload length When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (`server_feat` and `server_req_feat`). Therefore, `payload_len` must be at least 16 bytes. Fix this by adding a check in `process_banner_prefix()` to reject a `payload_len` smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90068", "url": "https://ubuntu.com/security/CVE-2026-90068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix off-by-one check on the second enum channel The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80x_mux_values. The core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which defaults off.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-93245", "url": "https://ubuntu.com/security/CVE-2026-93245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: policy_int make sure list heads are initialized before fail path If profile create fails before policy_init is complete the list heads are not properly initialized causing profile_free() sanity checks to trigger the following splat. AppArmor WARN aa_policy_destroy: (((!list_empty(&policy->profiles) && (&policy->profiles)->prev != ((void *) 0x122 + (0xdead000000000000UL))))): WARNING: security/apparmor/lib.c:509 at aa_policy_destroy+0x164/0x1b0 security/apparmor/lib.c:509, CPU#0: syz.0.17/5541 Modules linked in: CPU: 0 UID: 0 PID: 5541 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:aa_policy_destroy+0x16b/0x1b0 security/apparmor/lib.c:509 Code: 85 ed 7e 4d e8 96 bc 37 fd 5b 41 5c 41 5e 41 5f 5d e9 19 27 4e 07 cc e8 83 bc 37 fd 48 8d 3d 0c f0 d3 0b 48 c7 c6 a4 eb 38 8e <67> 48 0f b9 3a e9 04 ff ff ff e8 66 bc 37 fd 48 8d 3d ff ef d3 0b RSP: 0018:ffffc9000345eaa0 EFLAGS: 00010293 RAX: ffffffff848f530d RBX: ffff88803f734800 RCX: ffff88801af2a580 RDX: 0000000000000000 RSI: ffffffff8e38eba4 RDI: ffffffff90634320 RBP: 0000000000000000 R08: 0000000000000cc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d95913 R12: dead000000000122 R13: ffff88803f734800 R14: ffff88803f734828 R15: dffffc0000000000 FS: 00007f5f6a1836c0(0000) GS:ffff88808c519000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d02407b048 CR3: 0000000012aa9000 CR4: 0000000000352ef0 Call Trace: aa_free_profile+0x9d/0x9f0 security/apparmor/policy.c:334 aa_alloc_profile+0x1e4/0x3e0 security/apparmor/policy.c:416 unpack_profile security/apparmor/policy_unpack.c:1153 [inline] aa_unpack+0x17db/0x7430 security/apparmor/policy_unpack.c:1748 aa_replace_profiles+0x226/0x2a20 security/apparmor/policy.c:1183 policy_update+0x234/0x4a0 security/apparmor/apparmorfs.c:505 profile_load+0x1cb/0x320 security/apparmor/apparmorfs.c:522 vfs_write+0x296/0xba0 fs/read_write.c:685 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f6939e0d9 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:00007f5f6a183028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f5f69625fa0 RCX: 00007f5f6939e0d9 RDX: 0000000000000041 RSI: 0000200000000400 RDI: 0000000000000003 RBP: 00007f5f6a183090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f5f69626038 R14: 00007f5f69625fa0 R15: 00007ffe23725c18", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90070", "url": "https://ubuntu.com/security/CVE-2026-90070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Return zero on status read failure st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or error path instead of acting on an invalid status value. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90071", "url": "https://ubuntu.com/security/CVE-2026-90071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: restore skb->dev on the slave failure path teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90072", "url": "https://ubuntu.com/security/CVE-2026-90072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90073", "url": "https://ubuntu.com/security/CVE-2026-90073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare \"tc qdisc add ... hhf\" succeeds with a clamped quantum but \"tc qdisc add ... hhf limit 1000\" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90074", "url": "https://ubuntu.com/security/CVE-2026-90074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp default quantum to avoid signed overflow fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90075", "url": "https://ubuntu.com/security/CVE-2026-90075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_codel: clamp default quantum and mtu fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests \"*backlog <= params->mtu\"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memory_limit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double psched_mtu() call. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90078", "url": "https://ubuntu.com/security/CVE-2026-90078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: fix length calculations and avoid invalid header warnings syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act(): !skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55 There are a few issues in tcf_skbmod_act(): 1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets). Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90081", "url": "https://ubuntu.com/security/CVE-2026-90081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in rds_cong_map_updated() rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-89780", "url": "https://ubuntu.com/security/CVE-2026-89780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: restore skb->dev on deaggregated frames rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89789", "url": "https://ubuntu.com/security/CVE-2026-89789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets().", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90088", "url": "https://ubuntu.com/security/CVE-2026-90088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90102", "url": "https://ubuntu.com/security/CVE-2026-90102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: key the data server cache on the NFS version nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4. Two deviceids on one address with different ds_versions[0].version therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL. Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90103", "url": "https://ubuntu.com/security/CVE-2026-90103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix LAYOUTSTATS send buffer exhaustion encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that. ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for. The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held. Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90107", "url": "https://ubuntu.com/security/CVE-2026-90107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free pending qentry in smc_llc_flow_stop() before memset smc_llc_flow_stop() resets a flow struct with a blind memset: \tspin_lock_bh(&lgr->llc_flow_lock); \tmemset(flow, 0, sizeof(*flow)); \tflow->type = SMC_LLC_FLOW_NONE; \tspin_unlock_bh(&lgr->llc_flow_lock); If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object. A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct. Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90114", "url": "https://ubuntu.com/security/CVE-2026-90114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: Reject descending VLAN tunnel ranges A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90126", "url": "https://ubuntu.com/security/CVE-2026-90126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf8563: fix clock provider leak on unbind pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference. The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90128", "url": "https://ubuntu.com/security/CVE-2026-90128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: fix wrong list iterated in add_direct_chain error path In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89779", "url": "https://ubuntu.com/security/CVE-2026-89779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate ef->size covers the record's name and value When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to cover it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89781", "url": "https://ubuntu.com/security/CVE-2026-89781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read in read_log_rec_buf() read_log_rec_buf() copies a log record into a caller buffer starting at \tu32 off = lsn_to_page_off(log, lsn) + log->record_header_len; log->record_header_len (and log->data_off, used for the following pages) comes verbatim from the on-disk restart area and is only checked for 8-byte alignment in is_rst_area_valid(), so off can exceed log->page_size. \"tail = log->page_size - off\" then underflows and memcpy() reads past the page_size-sized buffer returned by read_log_page(), spilling adjacent slab memory into the replay buffer. This is reachable by mounting a crafted NTFS image: BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580 Read of size 64 at addr ffff88800a877ff8 by task exploit/127 read_log_rec_buf fs/ntfs3/fslog.c:2299 log_replay fs/ntfs3/fslog.c:4216 ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324 ntfs_fill_super fs/ntfs3/super.c:1392 get_tree_bdev_flags fs/super.c:1694 __x64_sys_mount fs/namespace.c:4360 The buggy address is located 4088 bytes to the right of the 4096-byte region [ffff88800a876000, ffff88800a877000) Reject an in-page offset outside the current page before the copy. [almaz.alexandrovich@paragon-software.com: replaced the >= sign with >]", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90140", "url": "https://ubuntu.com/security/CVE-2026-90140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cuse: wait for pending RCU callbacks on module exit Since commit 053fc4f755ad (\"fuse: fix UAF in rcu pathwalks\"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory: userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text! The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour). Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90141", "url": "https://ubuntu.com/security/CVE-2026-90141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix integer overflow in ftp helper port/address parsing ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16 (hport) and into unsigned char (p[]) without checking for overflow. A crafted FTP PASV/EPSV response with an over-long port or address octet wraps the value, so the helper configures the data connection with a truncated port/address. The netfilter conntrack FTP helper had the same defect, fixed in commit 2b413fc689ba (\"netfilter: nf_conntrack_ftp: avoid u16 overflows\"). Apply the equivalent fix here: widen the port accumulator to u32 and reject values above 65535, and reject address octets above 255.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90143", "url": "https://ubuntu.com/security/CVE-2026-90143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: kcm: Hold RCU read lock while running BPF parser kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser program. Hold the RCU read lock while running the program.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90151", "url": "https://ubuntu.com/security/CVE-2026-90151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: remove callback IDR entry on client allocation failure nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown. A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it. Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client. This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90157", "url": "https://ubuntu.com/security/CVE-2026-90157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative optlen in cgroup getsockopt hook A cgroup getsockopt BPF program can shrink ctx->optlen after the kernel getsockopt handler has run. The kernel-buffer variant, used by TCP_ZEROCOPY_RECEIVE, only rejects values larger than the original length. If BPF writes a negative optlen, that value is accepted and propagated back to the TCP getsockopt code. It can then be passed to copy_to_sockptr() as a size_t and trigger the hardened usercopy bytes > INT_MAX warning. Reject negative ctx.optlen in __cgroup_bpf_run_filter_getsockopt_kern(), matching the lower-bound validation already present in the sockptr-based getsockopt hook.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90160", "url": "https://ubuntu.com/security/CVE-2026-90160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lwt_bpf: Restore reserved headroom after xmit program ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output. That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise. On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb. Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90198", "url": "https://ubuntu.com/security/CVE-2026-90198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix use-after-free in snd_card_do_free() A use-after-free was detected in snd_card_do_free() when a sound card managed by devres is unbound while a user-space application still holds an open file descriptor. For managed cards, the memory is allocated using devres_alloc(), and its release function is set to __snd_card_release(), which calls snd_card_free(). When the device is unbound, the unbind thread calls snd_card_free(), which drops a reference to the card's device. If the user thread still has an open file descriptor, the reference count does not reach zero, and the unbind thread blocks on wait_for_completion(&released). When the user thread closes the file descriptor, it drops the final reference, invoking the device release callback release_card_device(), which calls snd_card_do_free(). snd_card_do_free() performs cleanup and calls complete(card->release_completion). This wakes up the unbind thread, which returns from snd_card_free() and __snd_card_release(). The devres core then immediately frees the memory block containing the snd_card structure. Meanwhile, the user thread continues execution in snd_card_do_free() and evaluates `if (!card->managed)`. It reads the `managed` boolean from the snd_card structure that was just freed by the unbind thread, triggering a KASAN use-after-free. Fix this by caching the value of card->managed in a local variable before calling complete(). This ensures that the card pointer is not dereferenced after the unbind thread has been woken up and potentially freed the card. BUG: KASAN: use-after-free in snd_card_do_free sound/core/init.c:604 [inline] BUG: KASAN: use-after-free in release_card_device+0x1ab/0x1b0 sound/core/init.c:153 Read of size 1 at addr ffff8881912ec909 by task syz-executor130/5857 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description+0x55/0x1e0 mm/kasan/report.c:378 print_report+0x58/0x70 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 snd_card_do_free sound/core/init.c:604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c:153 device_release+0xc4/0x1f0 drivers/base/core.c:-1 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x222/0x550 lib/kobject.c:737 snd_card_file_remove+0x331/0x390 sound/core/init.c:1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c:2986 __fput+0x418/0xa50 fs/file_table.c:512 fput_close_sync+0x11f/0x240 fs/file_table.c:617 __do_sys_close fs/open.c:1511 [inline] __se_sys_close fs/open.c:1496 [inline] __x64_sys_close+0x7e/0x110 fs/open.c:1496 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90202", "url": "https://ubuntu.com/security/CVE-2026-90202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers _base_release_memory_pools() unconditionally frees every ioc->pcie_sg_lookup[] entry, including ones the setup loop never allocated after a partial failure, causing a \"bad dma\" warning on debug kernels or a NULL pointer dereference otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90203", "url": "https://ubuntu.com/security/CVE-2026-90203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check block offset is not negative If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93252", "url": "https://ubuntu.com/security/CVE-2026-93252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix circular locking dependency in ocfs2_init_acl() A lockdep warning indicates a circular locking dependency between `&oi->ip_xattr_sem` and `&journal->j_trans_barrier`: WARNING: possible circular locking dependency detected is trying to acquire lock: (&oi->ip_xattr_sem){++++}-{4:4}, at: ocfs2_init_acl+0x2fd/0x7e0 fs/ocfs2/acl.c:367 but task is already holding lock: (&journal->j_trans_barrier){.+.+}-{4:4}, at: ocfs2_start_trans+0x3ab/0x700 fs/ocfs2/journal.c:369 The deadlock involves two code paths: Path 1 (setxattr) where `ocfs2_xattr_set()` acquires `ip_xattr_sem` (write) and then starts a transaction, which acquires `j_trans_barrier` (read); and Path 2 (mkdir/mknod) where `ocfs2_mknod()` starts a transaction (`j_trans_barrier` read) and then calls `ocfs2_init_acl()`, which attempts to acquire `ip_xattr_sem` (read) on the parent directory to retrieve the default ACL. Because rw_semaphores are subject to writer priority, a pending writer on `j_trans_barrier` (e.g., the journal commit thread) can cause Path 1 to block, while Path 2 is blocked waiting for Path 1 to release `ip_xattr_sem`. The patch fixes the lock ordering by precomputing the ACL state before starting the OCFS2 transaction, while preserving POSIX ACL storage semantics and the existing inode/security initialization order. By reading the parent directory's default ACL and preparing the new inode's ACLs outside the transaction, `ip_xattr_sem` is always acquired before `j_trans_barrier`. `struct ocfs2_acl_state` encapsulates the prepared ACL state, while `ocfs2_acl_init_prepare()` and `ocfs2_acl_init_release()` avoid code duplication between `ocfs2_mknod()` and `ocfs2_init_security_and_acl()`. `ocfs2_calc_xattr_init()` and `ocfs2_init_acl()` use this precomputed state, removing internal `ip_xattr_sem` acquisition and redundant disk reads. Additionally, remove the `ip_xattr_sem` acquisition from `ocfs2_xattr_set_handle()`. This function is only used while initializing a new inode that has not yet been inserted into the inode hash or attached to a dentry, meaning there is no risk of concurrent access and the lock is unnecessary.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90209", "url": "https://ubuntu.com/security/CVE-2026-90209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/debug: Fix deadlock during unregister Unregistering an s390dbf debug area while one of the associated debugfs files is being written to can cause a deadlock: $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs write debugfs_file_get() debug_unregister() mutex_lock(debug_mutex) debugfs_remove() wait for debugfs_file_put() debug_file_ops.write() debug_input() mutex_lock(debug_mutex) ==> DEADLOCK Fix this by splitting debug_unregister() into an s390dbf and debugfs part, and running only the s390dbf part with debug_mutex locked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90214", "url": "https://ubuntu.com/security/CVE-2026-90214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: fix stream_data leak on open error In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream. Free stream_data and clear the stream pointer on the error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90216", "url": "https://ubuntu.com/security/CVE-2026-90216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubi: Fix rollback for explicit UBI device numbers ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90218", "url": "https://ubuntu.com/security/CVE-2026-90218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix WARNING in res_to_rt syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via addr_handler() during asynchronous address resolution: \" WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ib_addr process_one_req RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c:624 process_one_work kernel/workqueue.c:3375 [inline] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c:3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 \" In addr_handler(), cma_acquire_dev_by_src_ip() is called to populate id_priv->cma_dev and bind the associated ib_device to id_priv->id.device. If cma_acquire_dev_by_src_ip() returns an error (non-zero status), the ID remains unassociated with any RDMA device. Previously, rdma_restrack_add(&id_priv->res) was invoked unconditionally even when cma_acquire_dev_by_src_ip() failed, passing a resource with a NULL dev pointer and triggering the WARN_ON assertion in res_to_rt(). Fix this by only adding the resource to restrack when acquiring the device succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90219", "url": "https://ubuntu.com/security/CVE-2026-90219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Free debugfs on registration failure c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev. Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90221", "url": "https://ubuntu.com/security/CVE-2026-90221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing nci_core_init_rsp_packet_v1() and nci_core_init_rsp_packet_v2() parse the CORE_INIT_RSP packet without validating that the skb contains enough data. A malformed response (e.g. injected via virtual_ncidev) can declare a large num_supported_rf_interfaces while providing insufficient data, causing reads of uninitialized slab memory. This is later used in nci_init_complete_req(), triggering a KMSAN uninit-value warning. Add skb length checks before accessing packet fields: - Validate the skb has at least 1 byte for the status field. - Validate the skb can hold the fixed-size header before parsing. - In v2, bounds-check each variable-length rf_interface entry and its extension parameters within the parsing loop. - In v1, verify the skb is large enough for both the variable-length rf_interfaces array and the trailing rsp_2 structure.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90222", "url": "https://ubuntu.com/security/CVE-2026-90222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: hold a reference to the request skb during send_frame __pn533_send_async() publishes the command and then calls dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame can be matched to this command: the I2C threaded IRQ runs pn533_recv_frame(), which queues cmd_complete_work, and pn533_send_async_complete() frees cmd->req with consume_skb(). On the I2C transport, pn533_i2c_send_frame() still dereferences the same skb after i2c_master_send() returns, so a completion that races the send can free the skb while the transport is still using it. The request skb is owned by the command object and may be freed by command completion at any time after dev->cmd is published, so the transport send path must not assume it stays alive. Hold a temporary reference to the request skb across the send_frame() call so the transport always sees a live skb even if completion races the send. Add a pn533_send_cmd_frame() helper and use it from all three send paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90223", "url": "https://ubuntu.com/security/CVE-2026-90223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound SNL TLV parsing to the skb and add length checks nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed: - For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made \"service_name_len = length - 1\" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90224", "url": "https://ubuntu.com/security/CVE-2026-90224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix double completion race in nci_data_exchange_complete nci_close_device() and nci_rx_work can both call nci_data_exchange_complete() concurrently. After commit 4527025d440ce8 (\"nfc: nci: fix circular locking dependency in nci_close_device\") moved flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock), rx_work is no longer serialized with the explicit completion call in the close path. Both callers read the non-NULL callback pointer and invoke rawsock_data_exchange_complete(), which calls sock_put() -- but only one sock_hold() was taken, so the second sock_put() underflows the refcount and frees the socket while it is still in use. Replace the bare clear_bit(NCI_DATA_EXCHANGE) with test_and_clear_bit() so that only the first caller proceeds to invoke the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90225", "url": "https://ubuntu.com/security/CVE-2026-90225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: read llcp_sock->local under the socket lock in getsockopt nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and then dereferenced the cached pointer inside the locked region. llcp_sock_bind() assigns and clears llcp_sock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on lock_sock(), and then dereference a freed nfc_llcp_local once bind() has unwound. Move the llcp_sock->local read and the NULL check inside the lock_sock(sk) region so bind() cannot mutate or free the pointer between the load and the use.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90226", "url": "https://ubuntu.com/security/CVE-2026-90226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: avoid userspace overflow on invalid optlen nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90228", "url": "https://ubuntu.com/security/CVE-2026-90228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() When a host issues an Identify command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89784", "url": "https://ubuntu.com/security/CVE-2026-89784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6 rpcb_register_inet4() and rpcb_register_inet6() store the result of rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL. rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROC_SET encode path: rpcb_register_call() -> rpc_call_sync() -> rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel. The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890) rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910) rpcauth_wrap_req_encode (net/sunrpc/auth.c:745) call_encode (net/sunrpc/clnt.c:1966) __rpc_execute (net/sunrpc/sched.c:952) rpc_run_task (net/sunrpc/clnt.c:1243) rpc_call_sync (net/sunrpc/clnt.c:1272) rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500) svc_generic_rpcbind_set nfsd_rpcbind_set svc_register svc_setup_socket svc_addsock write_ports nfsctl_transaction_write vfs_write The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFP_KERNEL kstrdup() in rpc_sockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check. Mirror that handling: bail out with -ENOMEM when rpc_sockaddr2uaddr() returns NULL, before the address is fed into the encoder.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90245", "url": "https://ubuntu.com/security/CVE-2026-90245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: kyro: Validate overlay viewport coordinates The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90248", "url": "https://ubuntu.com/security/CVE-2026-90248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: fix teardown of an adopted proto on insert-race loss In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90249", "url": "https://ubuntu.com/security/CVE-2026-90249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes The IIO core does not filter duplicate writes to the event enable attribute, so writing the same value twice invokes write_event_config() twice. Enabling twice leaks a runtime PM reference, preventing the device from ever suspending again; disabling twice underflows the usage count and triggers a \"Runtime PM usage count underflow\" warning. Bail out early when the requested state matches the current state. While at it, switch to pm_runtime_resume_and_get() so a failed resume is propagated to userspace instead of silently marking the event enabled.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90251", "url": "https://ubuntu.com/security/CVE-2026-90251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: \tif (skb->len < sizeof(*rp)) { \t\tbt_dev_err(hdev, \"MSFT supported features length mismatch\"); \t\tgoto failed; \t} evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so \tmsft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, \t\t\t\t GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes (\"skb->len=11 evt_prefix_len=255\", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with \"MSFT event prefix length mismatch\" and msft->evt_prefix is left unset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90257", "url": "https://ubuntu.com/security/CVE-2026-90257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: avoid OOB read of build info string The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read Build Information) and hands the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length. A backend that answers with status only leaves that pointer past the end of the received data, so the walk reads adjacent slab memory until it meets a NUL. Those bytes reach the kernel log and the firmware-info debugfs file. To fix this, print the string with a bounded \"%.*s\" limited to skb->len - 1. A short or unterminated response then prints as much as arrived instead of failing setup. This mirrors commit dd068ef04412 (\"Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()\"), which fixed the identical pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90274", "url": "https://ubuntu.com/security/CVE-2026-90274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: etm4x: fix underflow for usage of (nrseqstate - 1) According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR is implemented only when TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000. IOW, the number of usage in the initialisation or setting TRCSEQEVR with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000. Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR relevant fields setup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90281", "url": "https://ubuntu.com/security/CVE-2026-90281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend Runtime PM must be enabled before creating the PHY, since phy_create() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference. Take a runtime PM usage reference with pm_runtime_get_noresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90283", "url": "https://ubuntu.com/security/CVE-2026-90283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: release subpool on fill_super failure hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size mount options are specified. hugepage_new_subpool() may also reserve huge pages for min_size. If root dentry creation fails after the subpool is created, the failure path frees the subpool with kfree(). This bypasses hugepage_put_subpool() and can leave min_size reservations charged. Use hugepage_put_subpool() on the failure path, matching the normal put_super path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90284", "url": "https://ubuntu.com/security/CVE-2026-90284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: do not queue completed sysfs fallback requests fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to pending_fw_head. device_add() publishes the fallback loading interface, so a userspace helper which discovers the device by scanning sysfs can write 0 to the loading attribute and complete the request before it is queued as pending. In that interleaving firmware_loading_store() calls fw_state_done() while pending_list still points to itself, so it cannot remove an entry from pending_fw_head. The subsequent unconditional list_add() then queues an already-completed fw_priv. Once the request is released, pending_fw_head can retain a pointer to freed memory and the next fallback request can fault while validating the list. Only in-flight fallback requests need suspend or reboot abort handling. If the request is already DONE after device_add(), return success from the fallback path without sending another uevent, waiting again, or queueing it as pending. This preserves the invariant that pending_fw_head contains only active fallback requests.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90285", "url": "https://ubuntu.com/security/CVE-2026-90285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path qla2x00_sysfs_read_vpd() called ha->isp_ops->read_optrom() a second time after releasing optrom_mutex. The repeated read is redundant and, unlike the first, runs without optrom_mutex held, exposing flash access to concurrent optrom operations. Drop the duplicate call.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90286", "url": "https://ubuntu.com/security/CVE-2026-90286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx6: Use PFP on the compute queues too On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90290", "url": "https://ubuntu.com/security/CVE-2026-90290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Restore DAIF state on error Sashiko AI has reported that if swsusp_mte_save_tags() for some reason fails we return from swsusp_arch_suspend() with DAIF being masked - that is not what we'd expect. Restore the saved DAIF state before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93256", "url": "https://ubuntu.com/security/CVE-2026-93256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: mask DAIF before restoring hibernated kernel The arm64 hibernate code manages the exception masking in an unsound way, leading to potential crashes and/or warnings during resume. When a hibernation image is saved in `swsusp_arch_suspend()`, all DAIF exceptions are masked (by virtue of `local_daif_save()`), and the suspended image is saved assuming that all DAIF exceptions will remain masked when the image is restored. When a hibernation image is resumed by `swsusp_arch_resume()`, only interrupts are masked (by virtue of `local_irq_disable()` in `resume_target_kernel()`). When pseudo-NMI is enabled the DAIF.IF bits will be clear, and regardless of pseudo-NMI the DAIF.DA bits will be clear. This means that there are two problems: (1) It is possible to take Debug, SError, or pseudo-NMI exceptions during the resume process. This is unsafe, as during the resume process both the old ane new kernels will tranisently be in an inconsistent state, and swsusp_arch_suspend_exit() won't retain an executable mapping of any exception vectors. Any exception taken here will be fatal and silent. (2) When re-entering the resumed kernel, some DAIF bits will be clear unexpectedly. This permits Debug, SError, or pseudo-NMI exceptions to be taken for a short period while the resumed kernel is not yet in a consistent state. This is detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING. Avoid these issues by masking all DAIF exceptions during resume.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90292", "url": "https://ubuntu.com/security/CVE-2026-90292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix use-after-free in siw_accept() siw_accept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it. The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association. Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90293", "url": "https://ubuntu.com/security/CVE-2026-90293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: post the full-feature receive buffers after session registration isert_put_login_tx() posts the full-feature receive buffers before __transport_register_session() runs, so an initiator that does not wait for the final Login Response can still have a SCSI command executed against an se_session whose se_tpg is NULL - the same oops as the previous patch, at target_submit+0xbe. Post them from isert_get_rx_pdu(), which the previous patch already uses to send that response, and post them before that send: the receive queue is filled at the moment the initiator is told it may use it. Allocating there keeps the existing property that a memory allocation failure cannot happen once the final Login Response is on the wire. The receive queue is already empty between the final Login Request and isert_post_recvm(); this moves the second point later, from a median of 92 us to 172 us over 1200 logins. Only an initiator that sends before it has been told to can reach that window, and on IB and RoCE its send is retried there until the buffers appear - isert_rdma_accept() asks for rnr_retry_count = 7. iWARP has no RNR flow control, so there the same send terminates the connection instead. Measured over rxe, 400 login cycles per run, with an initiator that does not wait: an instrumented build counted no entries to isert_recv_done() before the buffers are posted in 10 runs, where that initiator oopsed 8 of 10 unpatched runs and 5 of 10 with only the previous patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90294", "url": "https://ubuntu.com/security/CVE-2026-90294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: delay the final Login Response until the session is registered isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90295", "url": "https://ubuntu.com/security/CVE-2026-90295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: \timx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), \t\t\t\t GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90296", "url": "https://ubuntu.com/security/CVE-2026-90296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix devres accumulation across driver rebind imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system. Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver(). That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release. Tested by rebinding the driver on qemu's mcimx6ul-evk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90297", "url": "https://ubuntu.com/security/CVE-2026-90297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: crtc: Propagate layer initialization error sun4i_crtc_init() returns plain NULL when layer initialization fails, while all its other error paths return an error pointer. The only caller, sun4i_tcon_bind(), checks the result with IS_ERR() and happily continues with tcon->crtc set to NULL. sun4i_rgb_init() and sun4i_lvds_init() then dereference it in drm_crtc_mask(), which oopses. Return the error pointer instead.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90298", "url": "https://ubuntu.com/security/CVE-2026-90298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: tcon: Drop TCON TOP device reference of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90302", "url": "https://ubuntu.com/security/CVE-2026-90302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: synchronize heartbeat callbacks with o2net teardown Patch series \"ocfs2: harden heartbeat teardown races\". This series fixes two OCFS2 heartbeat/o2net teardown races found by KASAN. This patch (of 2): Heartbeat callbacks stay registered while configfs local-node teardown enters o2net_stop_listening(). A node-down event can still run through o2net_disconnect_node() and o2net_set_nn_state() while teardown is destroying o2net_wq, so the later queue/flush operations can hit a dead workqueue. KASAN has caught this as a slab-use-after-free in __queue_work() with the call chain: KASAN slab-use-after-free in __queue_work+0x56/0xa90 Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __queue_work+0x56/0xa90 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __queue_delayed_work+0x58/0x1e0 queue_delayed_work_on+0xb4/0xc0 o2net_set_nn_state+0x467/0x840 o2net_disconnect_node+0x7b/0xe0 o2net_hb_node_down_cb+0x54/0x60 o2hb_run_event_list+0x236/0x2d0 o2hb_check_slot+0xad4/0xbc0 lock_release+0xc8/0x290 o2hb_check_slot+0x9ea/0xbc0 trace_hardirqs_on+0x18/0x130 o2hb_do_disk_heartbeat+0x646/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) __lock_acquire+0x466/0x2260 lockdep_hardirqs_on_prepare+0xea/0x1a0 ktime_get_with_offset+0xe9/0x230 o2hb_thread+0x14e/0x770 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 __switch_to+0x2e9/0x730 ret_from_fork_asm+0x1a/0x30 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x292/0x760 __alloc_workqueue+0x736/0xc60 alloc_workqueue_noprof+0xb1/0x110 o2net_start_listening+0xe5/0x430 o2nm_node_local_store+0x184/0x310 configfs_write_iter+0x18a/0x210 vfs_write+0x469/0x810 ksys_write+0xd2/0x170 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 rcu_core+0x4f4/0x1320 handle_softirqs+0x156/0x660 queue_delayed_work_on o2net_set_nn_state o2net_disconnect_node o2net_hb_node_down_cb o2hb_run_event_list Keep heartbeat callbacks registered so quorum state still tracks node state, but stop them from driving o2net reconnect/disconnect work once local teardown starts. Mark the transport offline before destroying o2net_wq, wait for any in-flight heartbeat callback to finish, and delay bring-up replay until the new local node is published through o2nm_this_node(). The replay also has to stay serialized with heartbeat callback delivery. Otherwise a live-node snapshot can be copied, a real hb_down callback can install -ENOTCONN for a peer, and the stale replay can call o2net_hb_node_up() for that same peer and queue reconnect work even though heartbeat is already down. The buggy scenario involves two paths, with each column showing the order within that path: local-node teardown: heartbeat node-down callback: 1. configfs local-off enters 1. o2hb_run_event_list() invokes o2net_stop_listening(). o2net_hb_node_down_cb(). 2. teardown heads for 2. the callback reaches destroy_workqueue(o2net_wq). o2net_disconnect_node() and o2net_set_nn_state(). 3. teardown destroys and NULLs 3. the callback flushes or queues o2net_wq. work through o2net_wq.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90303", "url": "https://ubuntu.com/security/CVE-2026-90303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults When CONFIG_DEBUG_USER=y, and cmdline \"user_debug=31\" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the \"oops\" state, acquiring a lock may risk a deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90307", "url": "https://ubuntu.com/security/CVE-2026-90307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it: BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8) Without KASAN the returned bytes are whatever is next in the slab. One run returned \".strtab\". rsp->data[3] in srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90314", "url": "https://ubuntu.com/security/CVE-2026-90314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression \"table_sz - offset - sizeof(*hdr)\", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90316", "url": "https://ubuntu.com/security/CVE-2026-90316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/omap: dsi: Do not copy isr table To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90318", "url": "https://ubuntu.com/security/CVE-2026-90318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: release buffer head after rebuilding parent fat_scan_logstart() leaves the matching directory entry's buffer head in sinfo.bh for the caller to release, just like fat_scan(). fat_rebuild_parent() uses the directory entry to rebuild the parent inode for the nostale_ro NFS export path, but does not release sinfo.bh after a successful scan. Release it once fat_build_inode() has consumed the directory entry data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90319", "url": "https://ubuntu.com/security/CVE-2026-90319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: clear mport->net when rio_add_net() fails rio_alloc_net() stores the newly allocated rio_net in mport->net before rio_scan_alloc_net() registers the device. If rio_add_net() fails, rio_scan_alloc_net() drops the device reference with put_device(), which releases the rio_net through the device release callback. However, mport->net is left pointing at the freed object. A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rio_net again. Clear mport->net in the rio_add_net() failure path, matching the cleanup done for the destID table allocation failure path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90327", "url": "https://ubuntu.com/security/CVE-2026-90327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: do not write beyond optlen in getsockopt pep_getsockopt() clamps the reported length to the caller's buffer with min_t(), but then stores the value with put_user(val, (int __user *) optval), which always writes sizeof(int) bytes. A getsockopt() call with an optlen smaller than sizeof(int) thus reports the clamped length yet writes a full int, one to three bytes past the user buffer. Write the value with copy_to_user() bounded by len, so at most optlen bytes are copied, matching the length reported back to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90329", "url": "https://ubuntu.com/security/CVE-2026-90329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: synchronize input before cleaning up a failed probe hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90334", "url": "https://ubuntu.com/security/CVE-2026-90334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: clear cdev pointer after cdev_add() failure tty_cdev_add() drops the cdev reference when cdev_add() fails, but leaves driver->cdevs[index] pointing to freed memory. tty_unregister_device() later passes that stale pointer to cdev_del(), causing a use-after-free. Clear the slot after dropping the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90341", "url": "https://ubuntu.com/security/CVE-2026-90341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: coreboot: Validate table bounds The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90348", "url": "https://ubuntu.com/security/CVE-2026-90348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90360", "url": "https://ubuntu.com/security/CVE-2026-90360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: use system_freezable_wq for init complete work schedule_delayed_work() uses system_wq, which is non-freezable, allowing regulator_init_complete_work to run concurrently with system suspend. This work fires ~30s after boot to disable unused regulators via I2C. When it races with PM suspend, the I2C adapter may already be suspended, triggering a -ESHUTDOWN warning in __i2c_transfer(): WARNING: ... at __i2c_transfer+0x36c/0x3c8 Call trace: __i2c_transfer i2c_transfer regmap_i2c_write _regmap_update_bits regulator_disable_regmap _regulator_do_disable regulator_late_cleanup regulator_init_complete_work_function process_one_work Switch to system_freezable_wq so the work is frozen before any device is suspended, eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90361", "url": "https://ubuntu.com/security/CVE-2026-90361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix leak in ath11k_service_ready_ext_event() Currently, during ath11k_service_ready_ext_event() processing, svc_rdy_ext.mac_phy_caps can be allocated during TLV parsing. This is a temporary allocation that is freed on the success path, but not on the error path. If parsing succeeds far enough to allocate mac_phy_caps and then fails on a later TLV, the allocation leaks. So free the allocation on the error path. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90362", "url": "https://ubuntu.com/security/CVE-2026-90362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Drop dev_pm_opp_set_rate(0) dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Drop the explicit call to it. Every call site of ops->link_clk_disable() is followed by pm_runtime_put(), so the power vote will be rescinded if deemed safe. Patchwork: https://patchwork.freedesktop.org/patch/742783/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90372", "url": "https://ubuntu.com/security/CVE-2026-90372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss If a peer's VHT/HE MCS map has no supported spatial stream (all fields 0x3), the loop exits with nss == 0 and the function returned (u8)-1 (255), which was then written into the firmware sta_rec_bf beamforming fields. Clamp the result to 0.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90378", "url": "https://ubuntu.com/security/CVE-2026-90378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt792x: Fix memory leak in SDIO TX path When tx_prepare_skb() returns an error in the SDIO TX path, the skb is not freed, leading to a memory leak. This can occur when zero-length frames (such as WNM NULL frames) are dropped to prevent potential hardware TX hangs. Fix this by properly releasing the skb with ieee80211_tx_status_ext() when tx_prepare_skb() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90382", "url": "https://ubuntu.com/security/CVE-2026-90382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set. Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf (\"mt76x2: remove some harmless WARN_ONs in tx status and rx path\") did for the neighboring rx and tx status paths. Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93261", "url": "https://ubuntu.com/security/CVE-2026-93261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/lockdep: Fix NULL pointer dereference in __lock_set_class() register_lock_class() can return NULL when the lock class pool is exhausted, graph_lock() fails, or key validation fails. However, __lock_set_class() uses the return value directly in pointer arithmetic without a NULL check: class = register_lock_class(lock, subclass, 0); hlock->class_idx = class - lock_classes; If class is NULL, this computes a wild offset that corrupts hlock->class_idx. The subsequent reacquire_held_locks() call will invoke hlock_class() with this corrupted index, leading to a NULL or out-of-bounds pointer dereference. Add the missing NULL check, consistent with how __lock_acquire() already handles this case at the same call site.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93283", "url": "https://ubuntu.com/security/CVE-2026-93283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix device_register() error path When device_register() fails in i3c_master_register_new_i3c_devs(), put_device() is called to drop the reference taken by device_register(). That drops the last reference, so the device's release callback i3c_device_release() runs and frees the i3c_device. Two problems follow from that: i3c_device_release() does WARN_ON(i3cdev->desc), so it warns because desc->dev->desc still points back at the descriptor. Clear it before calling put_device(). After put_device() frees the i3c_device, desc->dev is left pointing at freed memory, so clear desc->dev as well. That prevents, for example, i3c_master_unregister_i3c_devs() seeing desc->dev as non-NULL and dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90386", "url": "https://ubuntu.com/security/CVE-2026-90386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90388", "url": "https://ubuntu.com/security/CVE-2026-90388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Check atomic pool allocation result directly The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90391", "url": "https://ubuntu.com/security/CVE-2026-90391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone dmirror_fault() is called from the dmirror_read() and dmirror_write() retry loops after dmirror_do_read() or dmirror_do_write() finds a missing device page table entry. If the mirrored mm has already exited, mmget_not_zero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress. Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90393", "url": "https://ubuntu.com/security/CVE-2026-90393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF in bpf_netns_link_update_prog In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90394", "url": "https://ubuntu.com/security/CVE-2026-90394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sc2731_charger: cancel work on remove The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released. Set the platform drvdata used by remove, then cancel the work after unregistering the notifier. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90395", "url": "https://ubuntu.com/security/CVE-2026-90395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: isp1704_charger: cancel work on remove The USB notifier and initial VBUS detection can schedule isp->work. The remove path unregisters the notifier and power supply, but does not wait for queued or running work before tearing down the power supply state. Cancel the work after unregistering the notifier. Do this before unregistering the power supply. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93262", "url": "https://ubuntu.com/security/CVE-2026-93262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5-ppl: fix use-after-free in ppl_do_flush() The loop in ppl_do_flush() continues iterating after calling ppl_io_unit_finished(), touching io->pending_flushes and leading to a use-after-free. Add a break statement to stop the loop once io is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90403", "url": "https://ubuntu.com/security/CVE-2026-90403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix error path in rtl_pci_probe() In the last error path in rtl_pci_probe(), the cleanup functions are skipped due to a wrong goto label. Moreover, the successful call to rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to be reverted. Fix this issue by updating the labels and adding the relevant cleanup functions to the last error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90411", "url": "https://ubuntu.com/security/CVE-2026-90411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request __nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the rsp_iu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmd_iu unmapped and still marked the op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call .exit_request() when .init_request() fails, the cmd_iu mapping is leaked for every op whose rsp_iu mapping fails. Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and returns the error without marking the op idle, so it stays in the FCPOP_STATE_UNINIT state set by the initial memset().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90413", "url": "https://ubuntu.com/security/CVE-2026-90413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject login PDUs declaring more data than was received isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), \tpayload_length = ntoh24(login_req->dlength); \ttmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90414", "url": "https://ubuntu.com/security/CVE-2026-90414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject PDUs declaring more data than was received isert_recv_done() hands each received PDU to the opcode handlers without ever looking at wc->byte_len, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) - out of the fixed-size descriptor: isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len); Because the declared length is never checked against wc->byte_len, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer. Nothing upstream of isert closes this door: - __iscsit_check_dataout_hdr() bounds the inbound payload against conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check. - iscsi_set_connection_parameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsi_check_acceptor_state(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling. - isert never clamps the negotiated value to its own fixed receive descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated. The imm_data_len == data_len path is more than an over-read: it aliases the receive descriptor via sg_set_buf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated. Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN: BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 isert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout() (ib_isert.c:1160), inlined through isert_rx_opcode(). Validate wc->byte_len against the framing in isert_recv_done() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISER_HEADERS_LEN (commit 29e7b925ae6d (\"IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN\")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all. isert reads the data segment from a fixed offset: isert_get_data() returns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum against wc->byte_len bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything furth ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90415", "url": "https://ubuntu.com/security/CVE-2026-90415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: free STAG index when TPT entry write fails write_tpt_entry() allocates a new STAG index with c4iw_get_resource() and bumps stats.stag.cur before programming the entry. When write_adapter_mem() fails, it returns the error without releasing the index or reversing the statistic. No MR is inserted into rhp->mrs, so deregistration never reclaims it, leaking the index until device teardown. Record whether this call allocated the index and, on a failed write, return it to tpt_table and decrement stats.stag.cur. Key the rollback on both the write error and that flag, not the error alone: a non-reset update carries a caller-owned STAG that this call did not allocate and must not free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90416", "url": "https://ubuntu.com/security/CVE-2026-90416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed \"%d\" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as \"-2147483648\\n\" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with \"%u\" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90419", "url": "https://ubuntu.com/security/CVE-2026-90419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent out-of-bounds read in super root block parsing super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90420", "url": "https://ubuntu.com/security/CVE-2026-90420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix infinite loop in nilfs_clean_segments() syzbot reported a hung task in nilfs_transaction_begin(). This occurs because the cleaner ioctl falls into an infinite loop if nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device is remounted as read-only after an I/O error). Currently in nilfs_clean_segments(), if err is non-zero, it logs the error and sleeps but doesn't abort when it encounters a terminal error like -EROFS. This causes the thread to loop forever. Fix this by breaking out of the loop if nilfs_segctor_construct() returns -EROFS. This matches the behaviour in nilfs_segctor_write_out(), which also handles -EROFS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93264", "url": "https://ubuntu.com/security/CVE-2026-93264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Fix PBL chunk length computation On register MR, when creating the PBL, if it's an indirect PBL we create a chunk list to hold the PBL pages pointers. Each chunk is 4KB in size and can hold 510 addresses (EFA_PTRS_PER_CHUNK) and has a 12-byte control buffer at the end of it holding the next chunk's pointer and its length. If the PBL number of pages is a multiple of EFA_PTRS_PER_CHUNK, the calculated last chunk length is wrongly computed as 0, even though that chunk is fully populated with 510 real page pointers. This wrong length is used both to DMA map the chunk and is propagated to the device, causing the device to see the chunk as empty and reject the memory registration. Fix the calculation so it will be performed only if the number of pages isn't a multiple of EFA_PTRS_PER_CHUNK, if it is, its already handled in the above loop correctly. Also prevent out-of-bounds reach in the chunks array in such scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89782", "url": "https://ubuntu.com/security/CVE-2026-89782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject restart table growth beyond U16_MAX entries During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): \trt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90431", "url": "https://ubuntu.com/security/CVE-2026-90431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: Prevent crash handling to race with rproc_del() There's no synchronization between rproc_crash_handler_work() and rproc_del(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues. To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds. In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a \"deleting\" flag is introduced. This is similar to the RPROC_DELETE state that was introduced to ensure that \"start\" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the \"state\" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90434", "url": "https://ubuntu.com/security/CVE-2026-90434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: release zisofs block pointer buffer head zisofs_fill_pages() reads the compressed block pointer table. The error paths release the current buffer_head, the loop also releases the old buffer_head when it advances. However, the success path leaves the last buffer_head referenced. Release it before returning success.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90435", "url": "https://ubuntu.com/security/CVE-2026-90435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix integer overflow of user QP buffer size set_user_buf_size() computes the QP buffer size by left-shifting the user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers. A sufficiently large rq.wqe_cnt causes signed integer overflow, which is undefined behavior, and yields a small or negative buf_size, causing ib_umem_get() to map a buffer smaller than the hardware will actually write into. Replace the shifts and addition with check_shl_overflow() and check_add_overflow(), rejecting invalid user inputs. Moreover, guard the identical shift computing qp->sq.offset in _create_user_qp() before set_user_buf_size() is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92476", "url": "https://ubuntu.com/security/CVE-2026-92476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Initialize completion before requesting IRQ kmb_ocs_aes_probe() requests the device IRQ before initializing irq_completion. Once the handler is registered it can run immediately, and ocs_aes_irq_handler() unconditionally calls complete(). An interrupt in this window would therefore use an uninitialized completion. Initialize the completion before requesting the IRQ, as the sibling OCS HCU and ECC drivers already do.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89785", "url": "https://ubuntu.com/security/CVE-2026-89785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89787", "url": "https://ubuntu.com/security/CVE-2026-89787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check dir entry fits before reading the hash trailer in ext4_search_dir() For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4_DIRENT_HASHES()), at an offset derived from de->name_len. On the sb_no_casefold_compat_fallback() path ext4_match() reads that trailer, but ext4_search_dir()'s by-hand pre-check only tests de->name + de->name_len <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4_DIRENT_HASHES(de) lands past the block end, so ext4_match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object: BUG: KASAN: use-after-free in ext4_match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4_match (fs/ext4/namei.c:1435) ext4_search_dir (fs/ext4/namei.c:1470) __ext4_find_entry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4_lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filename_lookup (fs/namei.c:2842) vfs_statx (fs/stat.c:353) __do_sys_newfstatat (fs/stat.c:538) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4_match(). This is the same bound ext4_check_dir_entry() already enforces via ext4_dir_rec_len(), so no well-formed entry is rejected. The other caller, ext4_find_dest_de(), runs ext4_check_dir_entry() first and is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92494", "url": "https://ubuntu.com/security/CVE-2026-92494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix buffer_head leak in ext4_init_orphan_info ext4_init_orphan_info() reads orphan file blocks with ext4_bread() and stores the returned buffer_head in oi->of_binfo[i].ob_bh. If ext4_bread() succeeds but the orphan block magic or checksum validation fails, the function jumps to out_free. However, the old out_free loop starts releasing buffers from i - 1, so the current buffer_head at index i is skipped. This leaks the buffer_head reference obtained by ext4_bread() on the bad magic and bad checksum error paths. Fix this by tracking the number of successfully read buffer_heads and releasing exactly those buffer_heads on the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92496", "url": "https://ubuntu.com/security/CVE-2026-92496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx() Currently, in ath11k_wmi_tlv_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Add an upfront length check before dereferencing skb->data as a wmi_cmd_hdr. The check is placed before the trace_ath11k_wmi_event() call to preserve the existing trace semantics (tracing the full raw WMI event including the header), unlike the analogous ath12k fix which could use skb_pull_data() directly. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92498", "url": "https://ubuntu.com/security/CVE-2026-92498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: avoid buffer overreads in WMI event handlers The following WMI event handlers currently read from the event buffer without first verifying that the message was large enough to hold the expected event: ath6kl_wmi_scan_complete_rx() ath6kl_wmi_addba_req_event_rx() ath6kl_wmi_delba_req_event_rx() Add length checks to prevent overread.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92501", "url": "https://ubuntu.com/security/CVE-2026-92501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drain in-flight DIO before buffered write fallback generic/746 started failing intermittently on ext3 (no-extent inodes). The test triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO. Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied, post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback) ----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared() iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async) dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0, 8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range() iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages() invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO) This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92504", "url": "https://ubuntu.com/security/CVE-2026-92504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int3400: clean up ODVP on probe failures evaluate_odvp() creates per-ODVP sysfs files before the thermal zone and later probe resources are registered. The current unwind path only calls cleanup_odvp() from the late sysfs failure path, so failures after evaluate_odvp() but before that label, including thermal_tripless_zone_device_register() failures, leave the ODVP files and storage behind. Move the ODVP cleanup to the common ART/TRT unwind path so every failure after evaluate_odvp() releases the ODVP state. Also clear the cached ODVP pointers in cleanup_odvp(), because evaluate_odvp() can already call it for partial setup failures while probe continues.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92508", "url": "https://ubuntu.com/security/CVE-2026-92508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_free_cq() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93268", "url": "https://ubuntu.com/security/CVE-2026-93268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: skip extra isize expansion during mount to prevent deadlock ext4_try_to_expand_extra_isize() is called from __ext4_mark_inode_dirty() while holding an active jbd2 handle. During mount (!SB_ACTIVE), the expand path may move xattrs to external blocks and release ea_inodes via iput(). When !SB_ACTIVE, iput() calls write_inode_now() which acquires s_writepages_rwsem, creating a circular lock dependency: s_writepages_rwsem --> jbd2_handle --> xattr_sem --> s_writepages_rwsem This can be triggered via: ext4_process_orphan() -> ext4_truncate() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() or: ext4_evict_inode() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() Skip expansion when !SB_ACTIVE. This is a minor loss of functionality (extra isize won't grow for these inodes during mount), which e2fsck can resolve later if needed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89786", "url": "https://ubuntu.com/security/CVE-2026-89786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bounds read in ext4_read_inline_dir() ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: \tdir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic \".\" and \"..\" land at their block-dir offsets. A dirent is formed at \"dir_buf + pos - extra_offset\", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92521", "url": "https://ubuntu.com/security/CVE-2026-92521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92522", "url": "https://ubuntu.com/security/CVE-2026-92522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: validate MADT IOAPIC entry bounds The IOAPIC hotplug lookup parses both MADT and _MAT records directly. The MADT walk previously used a subtable's declared length to advance the cursor after only locating a generic header. The _MAT path likewise passed a generic header to the IOAPIC helper. Validate that a current record has a complete generic header, that its declared length is contained in the available record range, and that a typed IOAPIC record contains the full fixed IOAPIC body before reading its fields. Use the same relation for both MADT and _MAT provider paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92524", "url": "https://ubuntu.com/security/CVE-2026-92524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc() When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93037", "url": "https://ubuntu.com/security/CVE-2026-93037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Propagate sdma_txinit_ahg() errors set_txreq_header_ahg() ignores the return value of sdma_txinit_ahg(). If sdma_txinit_ahg() fails, it returns before initializing tx->txreq. However, set_txreq_header_ahg() ignores the error and returns the AHG change count, causing the caller to continue processing the request as though initialization had succeeded. Propagate sdma_txinit_ahg() failures to the caller and abort request processing when initialization fails. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93039", "url": "https://ubuntu.com/security/CVE-2026-93039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: Keep link pointers valid on realloc failure meson_card_reallocate_links() grows the DAI link and private data arrays with two consecutive krealloc() calls and updates the owner pointers only after both calls have succeeded. A successful krealloc() may move the data: it frees the old block and returns a new one. When that happens for the link array and the second krealloc() then fails, card->dai_link still points to the block that krealloc() already freed, and the error path frees the new block too. The probe error path then calls meson_card_clean_references(), which dereferences card->dai_link and kfree()s it again, resulting in a use-after-free and a double free. Commit card->dai_link and card->num_links right after the first krealloc() succeeds, so the pointer always refers to a valid allocation that meson_card_clean_references() can walk and free. krealloc() with __GFP_ZERO zero-initializes the added entries, so walking them on the error path is safe. With both failure paths reduced to a plain return, drop the goto labels and the error message.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93040", "url": "https://ubuntu.com/security/CVE-2026-93040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize channel state checks pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent. For example, pause() can observe EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93041", "url": "https://ubuntu.com/security/CVE-2026-93041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize abort state updates dw_edma_abort_interrupt() drops vc.lock before changing request and status. issue_pending() can acquire the lock in that small window, observe the old busy state, and skip starting queued descriptors. Then the abort handler overwrites the channel status as idle, leaving the new descriptors stranded for good. Keep descriptor completion and the state transition in the same critical section.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93046", "url": "https://ubuntu.com/security/CVE-2026-93046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: software node: Fix software_node_get_reference_args() with index -1 The bounds check for the index passed to software_node_get_reference_args() was failing when passed UINT_MAX, this in turn would lead to an out of bound access in the property array. Fix the bound check to also cover the UINT_MAX case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93048", "url": "https://ubuntu.com/security/CVE-2026-93048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior. Commit 5daa7b21496a (\"mtd: prepare partition add and del functions for ioctl requests\") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e (\"mtd: add a flags for partitions which should just leave smth. after them\") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value. With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers: WARN_ON((!mtd->erasesize || !master->_erase) && \t\t!(mtd->flags & MTD_NO_ERASE)) in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the \"out of reach\" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error. Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93049", "url": "https://ubuntu.com/security/CVE-2026-93049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdswap: Avoid freeing registered blktrans device twice In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice. add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev. The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89777", "url": "https://ubuntu.com/security/CVE-2026-89777", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio_msi_cap_len() lazily allocates the per-device MSI permission table: \tvdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); \tif (!vdev->msi_perm) \t\treturn -ENOMEM; \tret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); \tif (ret) { \t\tkfree(vdev->msi_perm); \t\treturn ret;\t\t/* vdev->msi_perm left dangling */ \t} When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at \"if (vdev->msi_perm) return len;\" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93051", "url": "https://ubuntu.com/security/CVE-2026-93051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ad525x_dpot: use driver core groups for sysfs files ad_dpot_probe() creates per-RDAC sysfs files manually and then optionally creates the command sysfs group. This leaves probe responsible for rolling back partial sysfs state and makes remove responsible for matching every file that probe created. Move the device attributes into driver core dev_groups for the I2C and SPI drivers and use an is_visible() callback to expose only the attributes supported by the probed device. With this shape, the driver core creates the sysfs files only after probe succeeds and removes them before the remove callback frees the driver data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93052", "url": "https://ubuntu.com/security/CVE-2026-93052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: bcm-vk: Use acquire/release for msgq_inited bcm_vk_sync_msgq() fills the message queue information and then sets msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the message queues and their cached queue information. atomic_set()/atomic_read() do not order those accesses. A reader can see msgq_inited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate. Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the gate and does not publish queue state to readers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93053", "url": "https://ubuntu.com/security/CVE-2026-93053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: speakup: keyhelp: guard letter_offsets possible out-of-range indexing help_init() builds letter_offsets[] by using the first byte of each function name as an index via `(start & 31) - 1`. If function_names are overridden from sysfs (root) with a name starting outside [a–z], the index underflows or exceeds the array, leading to OOB write. Function names can be overridden with the following commands as root: modprobe speakup_soft echo \"0 _bad\" > /sys/accessibility/speakup/i18n/function_names # then press Insert+2 on /dev/tty This fix checks the first letter in help_init(), and if it is not in the [a–z] range the function returns an error to the caller. Eventually this error is propagated to drivers/accessibility/speakup/main.c:2217, which causes a bleep sound.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93054", "url": "https://ubuntu.com/security/CVE-2026-93054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same \"device gone\" state as normal uio_unregister_device().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93055", "url": "https://ubuntu.com/security/CVE-2026-93055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: UDF symlink pathComponent header OOB read udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93056", "url": "https://ubuntu.com/security/CVE-2026-93056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: remove broken string configfs attributes The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for the fn_play, fn_cap, and fn_cntl string options. The store function contains an inverted null check on the kstrndup() return value. This means every write attempt returns -ENOMEM on success and dereferences a NULL pointer on allocation failure. The attributes have been broken and unused for many years. Remove the UAC1_STR_ATTRIBUTE macro and the three attributes it generated. The internal defaults (FILE_PCM_PLAYBACK, FILE_PCM_CAPTURE, FILE_CONTROL) set in f_audio_alloc_inst() are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93061", "url": "https://ubuntu.com/security/CVE-2026-93061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Avoid stack over-read in debug output helpers host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93067", "url": "https://ubuntu.com/security/CVE-2026-93067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clamps an AUX read to the payload limit: \tsize_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: \tif (size) \t\tsize = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 (\"drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer\").", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93271", "url": "https://ubuntu.com/security/CVE-2026-93271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate ath11k can receive HT/VHT/HE frames whose reported MCS is above the maximum that can be expressed in the corresponding mac80211 rate space (e.g. an HE frame reported with MCS 12, while HE tops out at MCS 11). The frame itself is valid and decodes correctly, but for such a frame ath11k_dp_rx_h_rate() leaves rx_status->rate_idx set to the out-of-range value and never assigns rx_status->encoding, so it stays RX_ENC_LEGACY from the ath11k_dp_rx_h_ppdu() initialization. Once that frame reaches mac80211 it trips the rate sanity check and the frame is dropped with a splat: ath11k_pci 0000:03:00.0: Received with invalid mcs in HE mode 12 WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:5433 ieee80211_rx_list+0xb0a/0xe90 [mac80211] Dropping the frame would discard otherwise valid data, so instead cap the reported MCS to the maximum the rate space can express and deliver the frame. Set rx_status->encoding before the range check and assign rate_idx from the capped value, so a frame with an out-of-range MCS no longer leaves partial or bogus rate metadata behind. Also downgrade the logging level since they are not treated as invalid frames now. The only loss is that such a frame is reported as the capped MCS in the rx rate statistics. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93095", "url": "https://ubuntu.com/security/CVE-2026-93095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: validate thread record before delete key rebuild hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93098", "url": "https://ubuntu.com/security/CVE-2026-93098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: glink: fix deadlock in endpoint destroy during driver detach During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89778", "url": "https://ubuntu.com/security/CVE-2026-89778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: fix out-of-bounds page array access on empty zisofs block zisofs_uncompress_block()'s empty-block fast path returns pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the decompression path which returns bytes produced relative to poffset. zisofs_fill_pages() uses that return to advance its page cursor, so when the zisofs block size is below PAGE_SIZE and a sub-page block leaves poffset partway into a page, a following empty block over-counts and advances pages[] one element past its end, after which \"if (poffset && *pages)\" reads pages[1] out of bounds. rock.c only rejects a block-size shift > 17, so a crafted \"ZF\" Rock Ridge record can set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a compressed file on such a mounted ISO9660 image. Return the byte count relative to poffset and zero only [poffset, PAGE_SIZE) of the first page, matching the decompression path. The page-aligned case (poffset == 0) is unaffected. BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290) Read of size 8 at addr ffff88800f5eac48 by task exploit/142 zisofs_read_folio (fs/isofs/compress.c:290) read_pages (mm/readahead.c:184) ... filemap_read (mm/filemap.c:2814) vfs_read (fs/read_write.c:574) __x64_sys_pread64 (fs/read_write.c:769) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address is located 0 bytes to the right of the allocated 8-byte region in the kmalloc-8 cache", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93102", "url": "https://ubuntu.com/security/CVE-2026-93102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Free RX data on late probe failure hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning. If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears down the device data without calling hfi1_free_rx(). This leaks netdev_rx and its dummy netdev. Free the RX support after IB unregistration and before postinit_cleanup(), as done on normal device removal.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93103", "url": "https://ubuntu.com/security/CVE-2026-93103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89783", "url": "https://ubuntu.com/security/CVE-2026-89783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use \"sp->len >= XFRM_MAX_DEPTH\", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]'", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93108", "url": "https://ubuntu.com/security/CVE-2026-93108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ipoib: Drain RCU callbacks during module teardown IPoIB reclamation completions can be signaled from inside an RCU callback. Teardown can wake before the callback returns and unload ib_ipoib while its code is still executing. Client registration failure can also remove already-added devices and queue callbacks. Wait after client and workqueue teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93109", "url": "https://ubuntu.com/security/CVE-2026-93109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Drain RCU callbacks during module teardown devx_free_subscription() can remain queued after the last DevX event file drops its module reference or an auxiliary driver detaches its devices. mlx5_ib can then unload before the callback runs. Registration error unwind has the same risk because driver registration can attach existing devices before failing. Wait after all drivers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93110", "url": "https://ubuntu.com/security/CVE-2026-93110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Wait for RCU callbacks before unloading ib_core put_gid_ndev() is queued with call_rcu() and implemented in ib_core. Stopping the workqueues does not drain callbacks already queued, so RCU could invoke it after the module code has been unloaded. synchronize_rcu() does not wait for callbacks. Wait for them after all producers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93114", "url": "https://ubuntu.com/security/CVE-2026-93114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/surface: acpi-notify: Check ACPI companion before use Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 (\"ACPI: driver: Check ACPI_COMPANION() against NULL during probe\") does for the core ACPI platform drivers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93115", "url": "https://ubuntu.com/security/CVE-2026-93115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93120", "url": "https://ubuntu.com/security/CVE-2026-93120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93130", "url": "https://ubuntu.com/security/CVE-2026-93130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix resource leak on module load failure We need to properly clean up the SMBIOS request and the privacy driver when the module load fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93131", "url": "https://ubuntu.com/security/CVE-2026-93131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-privacy: Fix race condition Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93138", "url": "https://ubuntu.com/security/CVE-2026-93138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire(). Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93140", "url": "https://ubuntu.com/security/CVE-2026-93140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 (\"udf: Mark LVID buffer as uptodate before marking it dirty\"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline] vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline] __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93141", "url": "https://ubuntu.com/security/CVE-2026-93141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: r8a66597: avoid double free of ep0_req in probe error path If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL. Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once. Issue found using a prototype static analysis tool and confirmed by code review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93145", "url": "https://ubuntu.com/security/CVE-2026-93145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister() gdsc_unregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pm_genpd_remove() on the individual generic_pm_domain structures registered by gdsc_init(): \tvoid gdsc_unregister(struct gdsc_desc *desc) \t{ \t\tstruct device *dev = desc->dev; \t\tsize_t num = desc->num; \t\tgdsc_pm_subdomain_remove(desc, num); \t\tof_genpd_del_provider(dev->of_node); \t} That leaves dangling entries on the global gpd_list. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdsc_init() will end up trying to re-register a name that is still in the list and pm_genpd_init() returns -EEXIST. While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh of_genpd_get_from_provider() call racing with the teardown could attach to a domain that is mid-removal. Iterate the scs[] array and pm_genpd_remove() each registered domain after the subdomain links are torn down. The regulators stay devm- managed (devm_regulator_get_optional() in gdsc_register()), so the release happens automatically when the underlying device is unbound; just the genpd accounting needs to be undone explicitly.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93278", "url": "https://ubuntu.com/security/CVE-2026-93278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown cvm_oct_rx_shutdown calls free_irq and netif_napi_del without disabling the napi instance first. As the free_irq only waits for completion of hard interrupt handlers, the napi poll function could still be active. If cvm_oct_remove proceeds to free the plat structure (which holds the NAPI instances), the active poll function will access freed memory, resulting in a use-after-free crash.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93279", "url": "https://ubuntu.com/security/CVE-2026-93279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown The TX cleanup tasklet can be scheduled by the watchdog IRQ handler to execute cvm_oct_tx_do_cleanup. There can be a pending tasklet in the queue which might run after the cvm_oct_remove() frees net_device structures, causing a use-after-free in cvm_oct_tx_do_cleanup() as it iterates cvm_oct_device[] which is an array of netdevice pointers. Add tasklet_kill() after free_irq() to ensure the tasklet is no longer scheduled or running before teardown proceeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93280", "url": "https://ubuntu.com/security/CVE-2026-93280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: greybus: audio: bound the topology section sizes against the fetched size gb_audio_gb_get_topology() fetches a topology blob of a module-supplied size, and gbaudio_tplg_parse_data() then walks it by adding the module-supplied size_dais, size_controls and size_widgets fields to form the control, widget and route section offsets. Those le32 sizes are never checked against the fetched blob, so a module reporting a small topology size but large section sizes makes the offsets point past the allocation, and parsing reads out of bounds. Reject a topology whose section sizes do not fit within the fetched size before it is parsed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93151", "url": "https://ubuntu.com/security/CVE-2026-93151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: fix response resource leak on queue teardown When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm \"kworker/2:1H\", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 unreferenced object 0xffff88814bd05e80 (size 64): comm \"kworker/3:1H\", pid 148, jiffies 4295195428 backtrace (crc e35510cb): __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources() that frees up the RDMA read/write context and the request SGLs of such responses.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93158", "url": "https://ubuntu.com/security/CVE-2026-93158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul - stop probe if context pool creation fails sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool. Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93159", "url": "https://ubuntu.com/security/CVE-2026-93159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes. If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated work_data is not usable for producing RNG output and must not remain associated with the hwrng state. Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data. Fix this by freeing the pending work_data. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93160", "url": "https://ubuntu.com/security/CVE-2026-93160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-ecc - reject hardware ECDH without a public key The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm. atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93161", "url": "https://ubuntu.com/security/CVE-2026-93161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - clear AES key schedule from stack qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame. Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93165", "url": "https://ubuntu.com/security/CVE-2026-93165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Fix memory overread in ring handler `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93167", "url": "https://ubuntu.com/security/CVE-2026-93167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: csky: Fix a4/a5 restoration in syscall trace path The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93170", "url": "https://ubuntu.com/security/CVE-2026-93170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93177", "url": "https://ubuntu.com/security/CVE-2026-93177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup vddInd, vddciInd and mvddInd from VBIOS-parsed tables index into vddc, vddci and vddmem lookup tables without bounds checks across nine sites. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93178", "url": "https://ubuntu.com/security/CVE-2026-93178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93274", "url": "https://ubuntu.com/security/CVE-2026-93274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: bcm2835: Don't remove an unregistered GPIO chip If the devm_pinctrl_register() function fails, bcm2835_pinctrl_probe() calls gpiochip_remove() before gpiochip_add_data() has registered the GPIO chip. This means that upon failure the gpio_chip.gpiodev is NULL resulting in a null pointer dereference inside the gpiochip_remove() function. Remove the unnecessary function call to gpiochip_remove(). No GPIO cleanup is required because the GPIO chip has not yet been registered. Without this change there is potential for a kernel panic upon registration failure", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93183", "url": "https://ubuntu.com/security/CVE-2026-93183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/lima: call drm_mm_init() with a valid allocation range lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2: [ 1.736297] ------------[ cut here ]------------ [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931! [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.750697] Modules linked in: [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree) [ 1.769446] Workqueue: events_unbound deferred_probe_work_func [ 1.775261] PC is at drm_mm_init+0x9c/0xa4 [ 1.779339] LR is at lima_vm_create+0x144/0x17c [ ... ] Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93185", "url": "https://ubuntu.com/security/CVE-2026-93185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rt700-sdw: always drain jack work on remove rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93188", "url": "https://ubuntu.com/security/CVE-2026-93188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: bound device-supplied profile index kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93189", "url": "https://ubuntu.com/security/CVE-2026-93189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path (\"hwmon: prevent packets from going to driver for probe\", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93191", "url": "https://ubuntu.com/security/CVE-2026-93191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix incorrect task context in smack_msg_queue_msgrcv The smack_msg_queue_msgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task. In the msgsnd() syscall path, if a receiver is already waiting, the pipelined_send() optimization is used to push the message directly to the receiver task: ipc/msg.c`pipelined_send(): ` smp_store_release(&msr->r_msg, msg) In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->r_tsk, passed as the 'target' parameter): ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, target := msr->r_tsk,,) However, smack_msg_queue_msgrcv() ignores the 'target' and checks 'current': smack_msg_queue_msgrcv(…) ` smk_curacc_msq(isp, MAY_READWRITE); // current task 'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy. Test: 1) create a sysv message queue with label “foo” 2) echo \"bar foo r\" >/smack/load2 3) msgrcv(,,,0,MSG_NOERROR) in \"bar\"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a \"foo\"-labeled task: \"bar\"-labeled task gets the message. This patch fixes the issue by checking permission on the 'target' task instead of 'current'. (2008-02-04, Casey Schaufler)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2025-40123", "url": "https://ubuntu.com/security/CVE-2025-40123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce expected_attach_type for tailcall compatibility Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-89947", "url": "https://ubuntu.com/security/CVE-2026-89947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: meson: align gxbb_32k_clk_sel number of parents with actual count The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c (\"clk: amlogic: gxbb: drop non existing 32k clock parent\") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80671", "url": "https://ubuntu.com/security/CVE-2026-80671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf sched: Fix register_pid() overflow, strcpy, and BUG_ON register_pid() has several issues when processing untrusted perf.data: 1. Integer overflow: (pid + 1) * sizeof(struct task_desc *) can wrap to a small value on 32-bit systems when pid is large (e.g. 0x40000000), causing realloc to return a tiny buffer followed by out-of-bounds writes in the initialization loop. 2. Heap buffer overflow: strcpy(task->comm, comm) copies the untrusted comm string into a fixed 20-byte COMM_LEN buffer with no length check. 3. BUG_ON on allocation failure: perf.data is untrusted input, so allocation failures should be handled gracefully rather than killing the process. 4. Realloc of sched->tasks assigned directly back, leaking the old pointer on failure; nr_tasks incremented before the realloc, leaving corrupted state on failure. Cap pid at PID_MAX_LIMIT (4194304, matching the kernel's maximum on 64-bit), replace strcpy with strlcpy, guard against NULL comm, replace BUG_ON with NULL returns using safe realloc patterns, and add NULL checks in callers that dereference the result.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-93203", "url": "https://ubuntu.com/security/CVE-2026-93203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: avoid CRC corruption due to parallel claim add batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either * add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone But when the \"new\" claim code was running in parallel to the \"change backbone\" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the \"new\" claim code path: * CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point. * CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc. * CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc The CRC is then wrong for both: * claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs. To avoid this, split the functionality in clear separate parts: * new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back) * update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93204", "url": "https://ubuntu.com/security/CVE-2026-93204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: atomically update mac addresses When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2025-22039", "url": "https://ubuntu.com/security/CVE-2025-22039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix overflow in dacloffset bounds check The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl(). This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer. This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.", "cve_priority": "high", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-21651", "url": "https://ubuntu.com/security/CVE-2025-21651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: don't auto enable misc vector Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below: [ 16.324639] Call trace: [ 16.324641] __queue_delayed_work+0xb8/0xe0 [ 16.324643] mod_delayed_work_on+0x78/0xd0 [ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge] [ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge] [ 16.324666] __handle_irq_event_percpu+0x64/0x1e0 [ 16.324667] handle_irq_event+0x80/0x170 [ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc [ 16.324671] __handle_domain_irq+0x84/0xfc [ 16.324673] gic_handle_irq+0x88/0x2c0 [ 16.324674] el1_irq+0xb8/0x140 [ 16.324677] arch_cpu_idle+0x18/0x40 [ 16.324679] default_idle_call+0x5c/0x1bc [ 16.324682] cpuidle_idle_call+0x18c/0x1c4 [ 16.324684] do_idle+0x174/0x17c [ 16.324685] cpu_startup_entry+0x30/0x6c [ 16.324687] secondary_start_kernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]--- So don't auto enable misc vector when request irq..", "cve_priority": "low", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43088", "url": "https://ubuntu.com/security/CVE-2026-43088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: zero aligned sockaddr tail in PF_KEY exports PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE` Fix those paths by clearing only the aligned sockaddr tail after `pfkey_sockaddr_fill()`.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31420", "url": "https://ubuntu.com/security/CVE-2026-31420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: mrp: reject zero test interval to avoid OOM panic br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock. The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames. Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2025-22103", "url": "https://ubuntu.com/security/CVE-2025-22103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix NULL pointer dereference in l3mdev_l3_rcv When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-21649", "url": "https://ubuntu.com/security/CVE-2025-21649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is sent on HIP08 devices Currently, HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL. But the tx process would still try to set hardware time stamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash. [ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge] [ 128.292938] sp : ffff800059b93140 [ 128.297200] x29: ffff800059b93140 x28: 0000000000003280 [ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080 [ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001 [ 128.315969] x23: 0000000000000000 x22: 0000000000000194 [ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000 [ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000 [ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24 [ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000 [ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368 [ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02 [ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0 [ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000 [ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff [ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294 [ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080 [ 128.390626] Call trace: [ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3] [ 128.405468] xmit_one.constprop.0+0xc4/0x200 [ 128.410600] dev_hard_start_xmit+0x54/0xf0 [ 128.415556] sch_direct_xmit+0xe8/0x634 [ 128.420246] __dev_queue_xmit+0x224/0xc70 [ 128.425101] dev_queue_xmit+0x1c/0x40 [ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch] [ 128.435409] do_output+0x60/0x17c [openvswitch] [ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch] [ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch] [ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch] [ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch] [ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch] [ 128.471460] xmit_one.constprop.0+0xc4/0x200 [ 128.476561] dev_hard_start_xmit+0x54/0xf0 [ 128.481489] __dev_queue_xmit+0x968/0xc70 [ 128.486330] dev_queue_xmit+0x1c/0x40 [ 128.490856] ip_finish_output2+0x250/0x570 [ 128.495810] __ip_finish_output+0x170/0x1e0 [ 128.500832] ip_finish_output+0x3c/0xf0 [ 128.505504] ip_output+0xbc/0x160 [ 128.509654] ip_send_skb+0x58/0xd4 [ 128.513892] udp_send_skb+0x12c/0x354 [ 128.518387] udp_sendmsg+0x7a8/0x9c0 [ 128.522793] inet_sendmsg+0x4c/0x8c [ 128.527116] __sock_sendmsg+0x48/0x80 [ 128.531609] __sys_sendto+0x124/0x164 [ 128.536099] __arm64_sys_sendto+0x30/0x5c [ 128.540935] invoke_syscall+0x50/0x130 [ 128.545508] el0_svc_common.constprop.0+0x10c/0x124 [ 128.551205] do_el0_svc+0x34/0xdc [ 128.555347] el0_svc+0x20/0x30 [ 128.559227] el0_sync_handler+0xb8/0xc0 [ 128.563883] el0_sync+0x160/0x180", "cve_priority": "medium", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2023-52676", "url": "https://ubuntu.com/security/CVE-2023-52676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Guard stack limits against 32bit overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904", "cve_priority": "high", "cve_public_date": "2024-05-17 15:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "low", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-90015", "url": "https://ubuntu.com/security/CVE-2026-90015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89816", "url": "https://ubuntu.com/security/CVE-2026-89816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used Commit 1c6ceeee6ebb (\"drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits\") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93234", "url": "https://ubuntu.com/security/CVE-2026-93234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: validate TV mode names before creating enum property The GUD protocol returns TV mode names as fixed-size GUD_CONNECTOR_TV_MODE_NAME_LEN entries and requires each name to be NUL-terminated. gud_connector_add_tv_mode() currently passes each fixed-size entry directly to drm_mode_create_tv_properties_legacy(), which eventually reaches drm_property_add_enum() and strlen(). If a device returns an entry without a terminating NUL byte, strlen() reads past the end of the slot and can run beyond the allocated buffer, triggering an out-of-bounds read. Validate that each returned TV mode name contains a NUL terminator within its fixed-size slot before passing it to the DRM property code. If a malformed entry is found, reject the device response with -EIO. This fixes the out-of-bounds read without changing the handling of valid devices, and avoids silently truncating malformed protocol data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89817", "url": "https://ubuntu.com/security/CVE-2026-89817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: NUL-terminate TV mode names read from the device gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89821", "url": "https://ubuntu.com/security/CVE-2026-89821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid divide-by-zero in __is_lut_linear() __is_lut_linear() computes the expected value of each entry with \texpected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89823", "url": "https://ubuntu.com/security/CVE-2026-89823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: fix race between partial drm_dev_register() failure and ioctl If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89843", "url": "https://ubuntu.com/security/CVE-2026-89843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89845", "url": "https://ubuntu.com/security/CVE-2026-89845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89846", "url": "https://ubuntu.com/security/CVE-2026-89846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: \tif (IS_FWI2_CAPABLE(ha)) { \t\tsense_data += rsp_info_len; \t\tpar_sense_len -= rsp_info_len; \t} rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): \tif (sense_len > par_sense_len) \t\tsense_len = par_sense_len; \tmemcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89847", "url": "https://ubuntu.com/security/CVE-2026-89847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid double completion in async IOCB timeout qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates \"if (sp->comp) complete(sp->comp)\"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93242", "url": "https://ubuntu.com/security/CVE-2026-93242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb() qla24xx_process_response_queue() advances ring_ptr past the head IOCB before dispatching, so by the time __qla_consume_iocb() runs, ring_ptr already points at the first continuation IOCB. The function however looped purex->entry_count times starting at ring_ptr. As entry_count includes the head, this consumed one entry too many: it stamped RESPONSE_PROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked. Mark the head processed and account for it, then consume only the entry_count - 1 continuation IOCBs, matching __qla_copy_purex_to_buffer().", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89849", "url": "https://ubuntu.com/security/CVE-2026-89849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path qla2x00_status_entry() filters out non-TYPE_SRB entries and the SRB_NVME_CMD, SRB_BIDI_CMD and SRB_TM_CMD types, then falls through to a SCSI fast path that assumes the command is an SRB_SCSI_CMD. The first thing on that path, qla_chk_edif_rx_sa_delete_pending(), and the subsequent handling both evaluate GET_CMD_SP(sp), i.e. sp->u.scmd.cmd. The srb u union overlays the SCSI command pointer with other command layouts (bsg_job, iocb_cmd). If firmware delivers an unexpected STATUS_TYPE IOCB for a non-SCSI handle, sp->u.scmd.cmd can read as a non-NULL garbage pointer, bypassing the NULL checks in qla_chk_edif_rx_sa_delete_pending() and at the cp == NULL test, and leading to a wild pointer dereference. Reject any SRB whose type is not SRB_SCSI_CMD before entering the fast path. The outstanding_cmds slot is left untouched so a genuinely non-SCSI command still completes through its proper handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89850", "url": "https://ubuntu.com/security/CVE-2026-89850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Don't query firmware state while chip is down qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89851", "url": "https://ubuntu.com/security/CVE-2026-89851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace enable parsing in debugfs qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as \"disable\" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89852", "url": "https://ubuntu.com/security/CVE-2026-89852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89853", "url": "https://ubuntu.com/security/CVE-2026-89853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89854", "url": "https://ubuntu.com/security/CVE-2026-89854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix cs84xx use-after-free on host teardown qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89855", "url": "https://ubuntu.com/security/CVE-2026-89855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize flash version read in reset handler The \"update cache versions without reset\" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89856", "url": "https://ubuntu.com/security/CVE-2026-89856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as \"ha->max_req_queues = ha->msix_count - 1\" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent \"ha->max_req_queues--\" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following \"ha->req_q_map[0] = req\" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89858", "url": "https://ubuntu.com/security/CVE-2026-89858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89861", "url": "https://ubuntu.com/security/CVE-2026-89861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89863", "url": "https://ubuntu.com/security/CVE-2026-89863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check qla_chk_edif_rx_sa_delete_pending() obtains the SCSI command via GET_CMD_SP(sp) and immediately dereferences cmd->sc_data_direction. That command pointer can be NULL: the firmware may post a status completion for a command that has already been returned or aborted. The caller qla2x00_status_entry() acknowledges this on the very same status path, re-fetching GET_CMD_SP(sp) and bailing out with the \"Command already returned\" message when it is NULL -- but that check runs only after qla_chk_edif_rx_sa_delete_pending() has already dereferenced the pointer, so a NULL cmd crashes the kernel in interrupt context. Return early when cmd is NULL, before touching cmd->sc_data_direction.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89864", "url": "https://ubuntu.com/security/CVE-2026-89864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: \tstruct qla_i2c_access { \t\tuint16_t device, offset, option, length; \t\tuint8_t buffer[0x40]; \t} __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89865", "url": "https://ubuntu.com/security/CVE-2026-89865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: \tif (len == 1) \t\topt |= BIT_0; \tif (opt & BIT_0) \t\tlen = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89871", "url": "https://ubuntu.com/security/CVE-2026-89871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89872", "url": "https://ubuntu.com/security/CVE-2026-89872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. [Sakari Ailus: Fix subject prefix and coding style a little.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89876", "url": "https://ubuntu.com/security/CVE-2026-89876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tda18250: fix possible integer overflow Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89878", "url": "https://ubuntu.com/security/CVE-2026-89878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: check firmware size before reading trailing marker s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89879", "url": "https://ubuntu.com/security/CVE-2026-89879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: bound JPEG frame size before copying into the buffer s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: \tpayload = le32_to_cpu(pdword[3]); \tif (payload > vc->req_image_size)\t/* payload is checked ... */ \t\treturn -EINVAL; \tvc->pkt_size = payload; \tvc->jpg_size = le32_to_cpu(pdword[4]);\t/* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89880", "url": "https://ubuntu.com/security/CVE-2026-89880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89881", "url": "https://ubuntu.com/security/CVE-2026-89881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89883", "url": "https://ubuntu.com/security/CVE-2026-89883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: sunxi-cir: Unregister rc device on probe failure After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93236", "url": "https://ubuntu.com/security/CVE-2026-93236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common When VIDIOC_TRY_FMT is called with an unsupported pixel format on the OUTPUT queue, vdec_try_fmt_common() falls back to V4L2_PIX_FMT_MPEG2. However, if a distro has locally patched MPEG2 support out (as it has been broken for some time) the platform format table does not contain MPEG2 so find_format() returns NULL and the subsequent dereference of fmt_out->max_width triggers a NULL pointer dereference. Fix this by falling back to the first format in the platform's format array instead of hardcoding V4L2_PIX_FMT_MPEG2. This is always valid since every platform defines at least one format.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89887", "url": "https://ubuntu.com/security/CVE-2026-89887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov7740: fix use-after-destroy in remove The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89888", "url": "https://ubuntu.com/security/CVE-2026-89888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov02a10: fix endpoint parsing use-after-free The ov02a10_check_hwcfg() function calls fwnode_handle_put(ep) immediately after allocating and parsing the endpoint. However, it subsequently calls fwnode_property_read_u32() using the same 'ep' handle, leading to a potential use-after-free. Additionally, reading the optional 'ovti,mipi-clock-voltage' property used to overwrite the 'ret' variable. If the property was missing, 'ret' would become negative, and this failure code would be incorrectly returned at the end of the function, causing probe to fail entirely. Fix the use-after-free by moving fwnode_property_read_u32() before the endpoint is parsed and freed. Avoid the error leak by not assigning the result of fwnode_property_read_u32() to 'ret'.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89890", "url": "https://ubuntu.com/security/CVE-2026-89890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: go7007: defer the ALSA v4l2 put until card release go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89891", "url": "https://ubuntu.com/security/CVE-2026-89891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free of dev_next->devlist on disconnect When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 (\"USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89892", "url": "https://ubuntu.com/security/CVE-2026-89892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: defer audio-only extension registration The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89893", "url": "https://ubuntu.com/security/CVE-2026-89893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: cancel NetUP CI work before teardown netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89894", "url": "https://ubuntu.com/security/CVE-2026-89894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: reject geometry changes while the VBI queue is busy vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: \toffset = lines_completed * (dev->width << 1) + ...; \tif (dma_q->current_field == 2) \t\toffset += dev->width * 2 * dma_q->lines_per_field; \tmemcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89895", "url": "https://ubuntu.com/security/CVE-2026-89895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cobalt: Avoid freeing ALSA private data twice snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89896", "url": "https://ubuntu.com/security/CVE-2026-89896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: fix memory leak in cedrus_init_ctrls() In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89897", "url": "https://ubuntu.com/security/CVE-2026-89897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: Serialize exclusive follower delivery cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89901", "url": "https://ubuntu.com/security/CVE-2026-89901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89923", "url": "https://ubuntu.com/security/CVE-2026-89923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Free guest debug data on vcpu destroy kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89924", "url": "https://ubuntu.com/security/CVE-2026-89924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix old_data leak in guest debug error path __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89925", "url": "https://ubuntu.com/security/CVE-2026-89925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory leak in guest debug handling bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89926", "url": "https://ubuntu.com/security/CVE-2026-89926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix length check __import_wp_info() struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: \twp_info->len = bp_data->len; \t[...] \tif (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) \t\treturn -EINVAL; \twp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89927", "url": "https://ubuntu.com/security/CVE-2026-89927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89930", "url": "https://ubuntu.com/security/CVE-2026-89930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter KVM services local TLB flushes on \"full\" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89932", "url": "https://ubuntu.com/security/CVE-2026-89932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always flush vpid02 on first use Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89936", "url": "https://ubuntu.com/security/CVE-2026-89936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: dac: m62332: Fix regulator reference count imbalance m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89937", "url": "https://ubuntu.com/security/CVE-2026-89937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sgp30: Handle IAQ thread creation failure kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89939", "url": "https://ubuntu.com/security/CVE-2026-89939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89945", "url": "https://ubuntu.com/security/CVE-2026-89945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l34: drain threaded IRQ before runtime suspend cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89946", "url": "https://ubuntu.com/security/CVE-2026-89946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89948", "url": "https://ubuntu.com/security/CVE-2026-89948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89949", "url": "https://ubuntu.com/security/CVE-2026-89949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89951", "url": "https://ubuntu.com/security/CVE-2026-89951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix stale receive device on merged fragments Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89952", "url": "https://ubuntu.com/security/CVE-2026-89952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89953", "url": "https://ubuntu.com/security/CVE-2026-89953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89954", "url": "https://ubuntu.com/security/CVE-2026-89954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: afs: validate v2 image info bounds The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89964", "url": "https://ubuntu.com/security/CVE-2026-89964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: eisa: Fix infinite loop when parsing invalid IRQ value When an invalid value is passed via the \"eisa_irq_edge=\" kernel command line parameter (e.g. \"eisa_irq_edge=16,5\"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89965", "url": "https://ubuntu.com/security/CVE-2026-89965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: reject an arena whose nfree is below the lane count The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89968", "url": "https://ubuntu.com/security/CVE-2026-89968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: reject unsolicited H2CData PDUs nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the \"list_add double add\" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89969", "url": "https://ubuntu.com/security/CVE-2026-89969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as \tqueue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89973", "url": "https://ubuntu.com/security/CVE-2026-89973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: check the data direction of a C2HData PDU nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89979", "url": "https://ubuntu.com/security/CVE-2026-89979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race between non-atomic ops and trigger-start We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89980", "url": "https://ubuntu.com/security/CVE-2026-89980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: harmony: initialize locks before requesting IRQ snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89982", "url": "https://ubuntu.com/security/CVE-2026-89982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89983", "url": "https://ubuntu.com/security/CVE-2026-89983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89984", "url": "https://ubuntu.com/security/CVE-2026-89984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \\ \t./perf bench syscall basic --loop 1000 | \\ \t./perf script -i - --fields brstack|tr ' ' '\\n'| \\ \tgrep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89989", "url": "https://ubuntu.com/security/CVE-2026-89989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89993", "url": "https://ubuntu.com/security/CVE-2026-89993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Initialize IRQ data before requesting IRQs dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89997", "url": "https://ubuntu.com/security/CVE-2026-89997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix resume-vs-remove race If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89999", "url": "https://ubuntu.com/security/CVE-2026-89999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: validate report length in wacom_intuos_pro2_bt_irq wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: \twacom_intuos_pro2_bt_pen(wacom); \tif (type == INTUOSP2_BT || type == INTUOSP2S_BT) { \t\twacom_intuos_pro2_bt_touch(wacom); \t\twacom_intuos_pro2_bt_pad(wacom); \t\twacom_intuos_pro2_bt_battery(wacom); \t} else { \t\twacom_intuos_gen3_bt_pad(wacom); \t\twacom_intuos_gen3_bt_battery(wacom); \t} Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] \t(the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT (\"gen3\"): wacom_intuos_gen3_bt_battery() reads data[45], \tso the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 (\"HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq\") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90000", "url": "https://ubuntu.com/security/CVE-2026-90000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: rmi: fix OOB access with undersized RMI reports The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: \tdata->input_report_size = hid_report_len(input_report); \tdata->output_report_size = hid_report_len(output_report); \talloc_size = data->output_report_size + data->input_report_size; \tdata->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); \tdata->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly \"this probe validated the reports\"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90007", "url": "https://ubuntu.com/security/CVE-2026-90007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Use rollback index when freeing MSI-X vectors pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90011", "url": "https://ubuntu.com/security/CVE-2026-90011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where \tpadding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90017", "url": "https://ubuntu.com/security/CVE-2026-90017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: \tconst u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); \t... \tc = frame_body[0]; \t... \ta = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90018", "url": "https://ubuntu.com/security/CVE-2026-90018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: \tif (attr_ptr + 4 > wps_ie + wps_ielen) \t\tbreak; \tu16 attr_id = get_unaligned_be16(attr_ptr); \tu16 attr_data_len = get_unaligned_be16(attr_ptr + 2); \tu16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: \tmemcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack \"u8 sr\"/\"u8 selected_registrar\" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The \"attr_ptr + 4 > wps_ie + wps_ielen\" header check above was added by commit 1463ca3ec6601 (\"staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()\"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90019", "url": "https://ubuntu.com/security/CVE-2026-90019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: fix null pointer dereference in usb_put_function_instance() usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90020", "url": "https://ubuntu.com/security/CVE-2026-90020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90025", "url": "https://ubuntu.com/security/CVE-2026-90025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix OOB altmode array index The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90031", "url": "https://ubuntu.com/security/CVE-2026-90031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90032", "url": "https://ubuntu.com/security/CVE-2026-90032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: usbtv: keep device alive while ALSA card exists The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90033", "url": "https://ubuntu.com/security/CVE-2026-90033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90034", "url": "https://ubuntu.com/security/CVE-2026-90034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2025-38097", "url": "https://ubuntu.com/security/CVE-2025-38097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: remove encap socket caching to avoid reference leak The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used \"recently\", but it's a lot more complex than just not caching the socket.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2026-89515", "url": "https://ubuntu.com/security/CVE-2026-89515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables() During fuzz testing, the following issue was discovered: BUG: KMSAN: uninit-value in __dma_map_sg_attrs+0x217/0x310 __dma_map_sg_attrs+0x217/0x310 dma_map_sg_attrs+0x4a/0x70 ata_qc_issue+0x9f8/0x1420 __ata_scsi_queuecmd+0x1657/0x1740 ata_scsi_queuecmd+0x79a/0x920 scsi_queue_rq+0x4472/0x4f40 blk_mq_dispatch_rq_list+0x1cca/0x3ee0 __blk_mq_sched_dispatch_requests+0x458/0x630 blk_mq_sched_dispatch_requests+0x15b/0x340 __blk_mq_run_hw_queue+0xe5/0x250 __blk_mq_delay_run_hw_queue+0x138/0x780 blk_mq_run_hw_queue+0x4bb/0x7e0 blk_mq_sched_insert_request+0x2a7/0x4c0 blk_execute_rq+0x497/0x8a0 sg_io+0xbe0/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Uninit was created at: __alloc_pages+0x5c0/0xc80 alloc_pages+0xe0e/0x1050 blk_rq_map_user_iov+0x2b77/0x6100 blk_rq_map_user_io+0x2fa/0x4d0 sg_io+0xad6/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Bytes 14-15 of 16 are uninitialized Memory access of size 16 starts at ffff88800cbdb000 When processing the last unaligned element of the scatterlist, it is supplemented with missing bytes in the amount of pad_len. These bytes remain uninitialized, which leads to a problem. Extend last_sg->length by pad_len first, then use sg_zero_buffer() to zero those pad_len bytes. sg_zero_buffer() uses sg_miter internally, which correctly handles sg entries spanning multiple pages and padding that crosses a page boundary. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80689", "url": "https://ubuntu.com/security/CVE-2026-80689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions mmio_trace_rw() and mmio_trace_mapping() retrieve mmio_trace_array into tr and pass it to __trace_mmiotrace_rw() and __trace_mmiotrace_map(). If these functions are invoked while mmio_trace_array is NULL (e.g. before initialization or after disabled), accessing tr->array_buffer.buffer will result in a NULL pointer dereference crash. Fix this by adding an explicit NULL check for tr at the beginning of __trace_mmiotrace_rw() and __trace_mmiotrace_map().", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80888", "url": "https://ubuntu.com/security/CVE-2026-80888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: drop dma_buf reference on foreign-fd prime import ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-80912", "url": "https://ubuntu.com/security/CVE-2026-80912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: reject an unclaimed class value in security_get_classes() security_get_classes() sizes an array by p_classes.nprim and fills it at value - 1, so a class value the policy never defines leaves a NULL. sel_make_classes() passes every entry to sel_make_dir(), reaching the same d_alloc_name() dereference as the permission array. The class symbol table is allowed to be sparse (policydb_class_isvalid() exists to absorb that), but this getter builds its own array straight from the hash table and has no such predicate. Fail the lookup when a value went unclaimed instead of handing out the NULL. Conforming policies define every class they declare and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-89595", "url": "https://ubuntu.com/security/CVE-2026-89595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix stale object mask after concurrent mark updates When a mark gets a new event bit, fanotify and inotify may avoid recalculating the object mask if the cached aggregate already contains that bit. This is racy with a recalculation triggered by a concurrent update to another mark on the same connector. The concurrent scan can read the mark before the new bit is added, while the updater reads the old aggregate before that scan publishes its result. The updater then skips recalculation and the scan publishes a mask without the bit, leaving the object mask stale after both updates complete. This can be reproduced with two fanotify groups watching the same inode: one thread removes FAN_MODIFY from one existing mark while another thread adds FAN_MODIFY to the other mark. After both fanotify_mark() calls return, writes can fail to produce FAN_MODIFY for the group whose mark now contains the bit. This was reproduced on an unmodified v6.12.95 kernel. The equivalent inotify interleaving loses IN_MODIFY events. For normal fanotify additions, recalculate whenever the raw mark mask changes. The normal mask is not cleared asynchronously, so an unchanged addition cannot introduce missing interest. Always recalculate ignore-mask updates because FS_MODIFY handling may clear the ignore mask without taking mark->lock, making snapshot comparisons unreliable. Always recalculate after updating an existing inotify watch. Its replace path temporarily sets mark->mask to zero, so a concurrent scan can observe zero even when the old and final masks are equal. Assigning the replacement mask directly would avoid the transient zero, but existing-watch updates are infrequent, so unconditional recalculation is simpler.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89603", "url": "https://ubuntu.com/security/CVE-2026-89603", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-74378", "url": "https://ubuntu.com/security/CVE-2026-74378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe get_srq_wqe() reads wqe->dma.num_sge from the shared receive queue buffer, which is mapped into userspace. It validates num_sge against max_sge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify num_sge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe. Read num_sge into a local variable and use it for both the bounds check and the size calculation.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-89488", "url": "https://ubuntu.com/security/CVE-2026-89488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix CT limit teardown use-after-free Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state. An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down. Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists. Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization. The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90049", "url": "https://ubuntu.com/security/CVE-2026-90049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80977", "url": "https://ubuntu.com/security/CVE-2026-80977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't touch shared zerocopy state in skb_tx_error() skb_tx_error() completes the zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone shares, while the caller only owns the reference it is about to drop. Through a clone it tells the producer its pages are free and drops SKBFL_SHARED_FRAG for an skb that is still in flight. Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC: clone_execute() sends a skb_clone() into ovs_dp_process_packet() while do_execute_actions() keeps forwarding the original, and skb_clone() does not privatise the frags here -- skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN. A flow miss on the clone then strips the marker from the packet still being forwarded, and a later local ESP delivery decrypts in place over frags it does not own privately. Skip it for a cloned skb. Nothing is lost: skb_release_data() clears the zerocopy state once the last reference to the shared data goes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80928", "url": "https://ubuntu.com/security/CVE-2026-80928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix cred UAF in smack_file_send_sigiotask() When inspecting the credentials of another task, objective credentials (->real_cred, accessed with __task_cred()) must always be used. Accessing ->cred on a non-current task is forbidden unless that task is being created or destroyed; a task is allowed to change its own ->cred pointer with no synchronization, and changing ->cred should only affect the current syscall. smack_file_send_sigiotask() was accessing both sets of credentials: First tsk->cred, then __task_cred(tsk). Fix it, always access the objective credentials here. I have tested that this bug can lead to a KASAN-reported UAF of struct cred in smack_file_send_sigiotask(), and that this fix prevents the race.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-93222", "url": "https://ubuntu.com/security/CVE-2026-93222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: avoid shared siginfo namespace rewrites send_signal_locked() rewrites sender ids for the target namespace. Group sends reuse the same siginfo, so one recipient can affect the next. Copy the siginfo before changing it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-80930", "url": "https://ubuntu.com/security/CVE-2026-80930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80931", "url": "https://ubuntu.com/security/CVE-2026-80931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: ds28e17: reject an oversize length on an I2C block read w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the device. The downstream slave puts a length byte in buf[0]. The driver then reads that many bytes into buf[1] with w1_f19_i2c_read(). buf[0] is controlled by the device and can be 0 to 255. w1_f19_i2c_read() only rejects a zero count. The caller buffer is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read run past it, up to about 222 bytes out of bounds. The SMBus core does check buf[0] against I2C_SMBUS_BLOCK_MAX. That check runs after master_xfer returns. By then the write is already done. i2c-algo-bit rejects an oversize length before it copies, and returns -EPROTO. Reject a length above I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites, the same way i2c-algo-bit does.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80932", "url": "https://ubuntu.com/security/CVE-2026-80932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: flush works in dependency order virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work. In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it. KASAN reported: BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80938", "url": "https://ubuntu.com/security/CVE-2026-80938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex mt7615_suspend() acquired the mt76 mutex and then called cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the same mutex via mt7615_mutex_acquire() at the top of the worker, so if mac_work is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against. Flush scan_work and mac_work before taking the mutex, matching the suspend paths in mt7921 and mt7925. scan_work only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps mac_work from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80941", "url": "https://ubuntu.com/security/CVE-2026-80941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb() The skb passed to the rtw_hci_tx_write() is expected to be freed when the function fails, but the error path in rtw_txq_push_skb() does not free the skb before returning. This can lead to a memory leak in rtw_txq_push() where a dequeued skb is passed to rtw_txq_push_skb().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80944", "url": "https://ubuntu.com/security/CVE-2026-80944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Detach sync cmd buffer on interrupted wait mwifiex synchronous commands keep the caller-provided data buffer in cmd_node->data_buf. Several callers pass stack-allocated objects there. If wait_event_interruptible_timeout() is interrupted, the caller can return and release that stack object while the firmware command is still the current command. A late firmware response then reaches the normal response handler, which can copy data through cmd_node->data_buf into the stale stack address. This fixes a stack corruption observed during repeated association and disassociation cycles. The panic trace showed the command wait being interrupted immediately before a bad pointer dereference: cmd_wait_q terminated: -512 Unable to handle kernel paging request at virtual address 002c583837384662 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted ... Tainted: [M]=MACHINE_CHECK The fault address decodes as little-endian ASCII: 0x002c583837384662 -> \"bF878X,\\0\" which is a fragment of the VERSION_EXT firmware string exposed as debugfs \"verext\": w8997o-V4, RF878X, FP92, 16.92.21.p153.7 The same runs also showed corrupted control data containing: 0x2400372e333531 -> \"153.7\\0$\" which is the tail of the same VERSION_EXT string. This points at a late VERSION_EXT response writing through a stale stack-backed data_buf after the interrupted wait returned. After cancelling pending commands on an interrupted or timed-out wait, detach the caller-owned data buffer from the still-current command. This preserves the existing command cancellation behaviour while preventing a late response from writing through a pointer whose lifetime ended with the waiting caller. Tested on an i.MX8MP board using an 88W8997.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80949", "url": "https://ubuntu.com/security/CVE-2026-80949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() The memory allocated for buf is not freed in some of the error paths in brcmf_sdio_read_control(). Fix that by adding vfree() calls. [arend: rework as suggested by Johannes]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80951", "url": "https://ubuntu.com/security/CVE-2026-80951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: bound IBI payload to the requested max_payload_len svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into the IBI slot. The loop is bounded by the hardware FIFO size (SVC_I3C_FIFO_SIZE), not by the slot size. slot->data points into the IBI pool, which i3c_generic_ibi_alloc_pool() sizes at max_payload_len per slot. svc_i3c_master_request_ibi() only rejects a max_payload_len larger than SVC_I3C_FIFO_SIZE, so a driver can request a smaller one. mctp-i3c requests 1. Each readsb() then copies the controller RXCOUNT bytes (up to 31) with no check against the slot size. A device that sends more bytes than the slot holds writes past slot->data, an out-of-bounds write into the IBI pool. Bound the loop by dev->ibi->max_payload_len and clamp each read to the space left in the slot, the same way dw-i3c does. A device can still send more than the requested payload. Flush the leftover bytes from the RX FIFO so they do not leak into the next transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80952", "url": "https://ubuntu.com/security/CVE-2026-80952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix info leak and UAF in device unregister path i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During device_unregister(), device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct i3c_device_info, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind. Keep desc valid until device_unregister() has completed. Since device_unregister() drops the device reference and may free the device, take an extra reference with get_device() before unregistering. Clear desc afterwards and release the extra reference with put_device(). This preserves the release-time invariant that desc must be NULL while avoiding both the information leak and a potential use-after-free from writing desc after the device has been released.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80963", "url": "https://ubuntu.com/security/CVE-2026-80963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-stats: fix a crash if allocation of per-cpu data fails If \"dm_kvzalloc(percpu_alloc_size, cpu_to_node(cpu))\" fails, the code jumps to the \"out\" label and calls dm_stat_free. dm_stat_free does \"for_each_possible_cpu(cpu) { dm_kvfree(s->stat_percpu[cpu][0].histogram, s->histogram_alloc_size);\", which crashes with NULL pointer dereference if s->stat_percpu[cpu] is NULL. This commit fixes the bug by testing s->stat_percpu[cpu] for NULL before using it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80964", "url": "https://ubuntu.com/security/CVE-2026-80964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: virmidi: Check card index validity at probe virmidi driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80965", "url": "https://ubuntu.com/security/CVE-2026-80965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: serial-u16550: Check card index validity at probe serial-u16550 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80966", "url": "https://ubuntu.com/security/CVE-2026-80966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: portman2x4: Check card index validity at probe Although portman2x4 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80967", "url": "https://ubuntu.com/security/CVE-2026-80967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcxhr: initialize mutexes before requesting threaded IRQ pcxhr_probe() requests pcxhr_threaded_irq() before initializing mgr->lock, even though the threaded handler takes that mutex. Initialize the manager locks before request_threaded_irq() so an early interrupt cannot run against uninitialized mutex state during probe.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80968", "url": "https://ubuntu.com/security/CVE-2026-80968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mts64: Check card index validity at probe Although mts64 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80969", "url": "https://ubuntu.com/security/CVE-2026-80969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mpu401: Check card index validity at probe mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80971", "url": "https://ubuntu.com/security/CVE-2026-80971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: clear the URB pointers on disconnect bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind: \tusb_kill_urb(bcd2k->midi_out_urb); \tusb_kill_urb(bcd2k->midi_in_urb); \tusb_free_urb(bcd2k->midi_out_urb); \tusb_free_urb(bcd2k->midi_in_urb); The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core: \tbcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE; \t... \tret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC); usb_kill_urb() does not stop a later submission either, so a submit that races the disconnect can requeue the URB after it has been reaped. midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits it from the completion handler. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000] Write of size 4 at addr ffff00001827d388 by task bpoc/168 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 Freed by task 168: usb_free_urb bcd2000_disconnect [snd_bcd2000] BUG: KASAN: slab-use-after-free in usb_submit_urb Read of size 8 at addr ffff00001827d3b8 by task bpoc/168 Clear both pointers after freeing and test them on the paths that can still run. Poison the URBs before freeing them: usb_poison_urb() waits for a running completion handler and rejects any later submission, so after it returns the input path is quiesced and only the rawmidi trigger path can still reach bcd2000_midi_send(). No unpoison is needed; the URBs are freed on the next line. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80972", "url": "https://ubuntu.com/security/CVE-2026-80972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Check card index validity at probe aloop driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80973", "url": "https://ubuntu.com/security/CVE-2026-80973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: bound the MIDI event length from the device usb6fire_comm_receiver_handler() forwards a MIDI event using a length byte the device supplies, with no bound and no check that the transfer delivered that many bytes: \tif (!urb->status) { \t\tif (rt->receiver_buffer[0] == 0x10) /* midi in event */ \t\t\tif (midi_rt) \t\t\t\tmidi_rt->in_received(midi_rt, \t\t\t\t\t\trt->receiver_buffer + 2, \t\t\t\t\t\trt->receiver_buffer[1]); \t} receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the device chooses, so a device that answers with 0x10 and a length of 0xFF makes snd_rawmidi_receive() read 255 bytes starting two bytes into a 64-byte object. The bytes past the buffer are handed to userspace through the rawmidi read path. urb->actual_length is not consulted either, so a short transfer leaves both the type byte and the length byte at their previous values and the handler acts on stale data. The receiver URB is submitted from usb6fire_comm_init() at probe, so the read happens on plug with no user action; forwarding to userspace also needs a MIDI input substream open, since usb6fire_midi_in_received() only calls snd_rawmidi_receive() when rt->in is set. KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device: BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive Read of size 255 at addr ffff000009f64682 by task bash/183 __asan_memcpy snd_rawmidi_receive usb6fire_midi_in_received [snd_usb_6fire] usb6fire_comm_receiver_handler [snd_usb_6fire] Allocated by task 11: usb6fire_comm_init [snd_usb_6fire] usb6fire_chip_probe [snd_usb_6fire] The buggy address is located 2 bytes inside of allocated 64-byte region [ffff000009f64680, ffff000009f646c0) Reject the event when the length exceeds the bytes that follow the header, and require the transfer to have delivered the header plus that many bytes. The receiver URB is submitted with a 64-byte transfer_buffer_length, so a genuine device cannot deliver an event longer than those 62 bytes and nothing valid is dropped. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80976", "url": "https://ubuntu.com/security/CVE-2026-80976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: reset IP6CB after IPv6 decapsulation decap_and_validate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags. End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet. The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports: BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu ip6_protocol_deliver_rcu+0x1118/0x1450 ip6_input_finish+0x11b/0x240 seg6_local_input_core+0xed/0x2e0 lwtunnel_input+0x1e9/0x4e0 ipv6_rthdr_rcv+0x525f/0x6c50 ip6_protocol_deliver_rcu+0xcb7/0x1450 Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field. Use IP6CB(skb)->iif rather than skb->skb_iif because VRF processing can replace skb_iif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKB_L3SLAVE for the same reason.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80978", "url": "https://ubuntu.com/security/CVE-2026-80978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap advertised IP tunnel headroom IP tunnel devices derive their advertised needed_headroom from lower output devices. A stack of user-created devices can make the derived value larger than the 16-bit skb header offsets can represent. Once IP output reserves it, skb head expansion can wrap those offsets. The runtime transmit path already caps a growing needed_headroom at 512. Apply the same cap when tunnel configuration publishes needed_headroom derived from a lower output device. Capping the advertised value is safe: IP tunnel transmit still expands the skb when a packet needs more headroom. A nonsensical stacked configuration can therefore incur an extra reallocation, but it cannot publish an unbounded reservation to upper layers.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80983", "url": "https://ubuntu.com/security/CVE-2026-80983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket refcount leak in smc_switch_conns() smc_switch_conns() takes a reference on the SMC socket before dropping lgr->conns_lock, so the connection stays alive while the CDC slot is fetched: sock_hold(&smc->sk); read_unlock_bh(&lgr->conns_lock); /* pre-fetch buffer outside of send_lock, might sleep */ rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend); if (rc) goto err_out; The err_out label only drops the wr_tx link reference, so this early exit returns without the matching sock_put(). The second error exit is not affected, because sock_put() has already run by then. A leaked sk_refcnt means the smc_sock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down. smc_cdc_get_free_slot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smc_switch_conns() run in the first place. Restructure so there is a single sock_put() covering both outcomes, instead of adding a second one to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80987", "url": "https://ubuntu.com/security/CVE-2026-80987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Reject oversized TX buffers ntb_process_tx() handles an oversized buffer by calling tx_handler() with a NULL data pointer and returning success. ntb_netdev therefore neither frees the skb in its completion callback nor takes its enqueue error path, leaking it. Reject oversized buffers in ntb_transport_tx_enqueue() before acquiring a queue entry and return -EMSGSIZE. The caller retains ownership of the buffer, and the preceding netdev patch frees the skb when enqueue returns this permanent error.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80988", "url": "https://ubuntu.com/security/CVE-2026-80988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Fail TX enqueue when the QP link is down Commit f195a1a6fe41 (\"ntb: Drop packets when qp link is down\") meant to make ntb_transport_tx_enqueue() drop packets submitted while the QP link is down, but it only returns 0 without consuming the packet. Zero means success by this function's contract, so ntb_netdev reports NETDEV_TX_OK and forgets the skb: nothing queued it, nothing frees it, and it leaks, one skb for every transmit racing a link-down. Return -ENOLINK instead, restoring the contract that a non-zero return leaves the buffer owned by the caller. With the preceding patch, ntb_netdev frees the skb on non-retryable enqueue failures and returns NETDEV_TX_OK, so a packet racing with link-down is dropped without leaking or entering a busy retry loop.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80994", "url": "https://ubuntu.com/security/CVE-2026-80994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix flow mask use-after-free on flow deletion The commit in the Fixes tag below made so flow->mask free is scheduled via RCU right after it is removed from the flow table. The pointer stays in the flow structure and it can be accessible while in the same RCU critical section. This is done to avoid requiring ovs_mutex for the ovs_flow_free(). However, while removing the flow during processing of CMD_DEL, we do not take RCU read lock before the removal, and ovs_flow_cmd_fill_info() uses the flow->mask pointer afterwards. The RCU read lock is taken, but it's already late at that point. The comment on that line acknowledges that the lock is cosmetic and doesn't serve a real purpose. This leads to use-after-free if the RCU grace period passes between removal and the filling. It is a short race window, but it is there and can lead to a real crash in case memory allocation for the info takes a bit longer: BUG: KASAN: slab-use-after-free in __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 BUG: KASAN: slab-use-after-free in ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 Read of size 4 at addr ffff88801ee89970 by task ovs_flow_del_ec/9487 Call Trace: __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c:930 ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c:1467 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Allocated by task 9487: mask_alloc net/openvswitch/flow_table.c:967 flow_mask_insert net/openvswitch/flow_table.c:1012 ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c:1084 ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c:1086 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Freed by task 9485: rcu_free_sheaf+0x1e/0x100 mm/slub.c:5978 rcu_do_batch kernel/rcu/tree.c:2645 rcu_core+0x59c/0x10c0 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9a0 kernel/softirq.c:622 ... instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 ovs_flow_tbl_remove() must be called after the ovs_flow_cmd_fill_info() to avoid this race. This also helps with cleaning up the forced cast and the cosmetic RCU read lock. Before the commit in the Fixes tag the order did not matter as long as the flow object itself was not freed. A wider RCU critical section could be another option, but we have a GFP_KERNEL allocation in the way. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-32042.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81000", "url": "https://ubuntu.com/security/CVE-2026-81000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tun: bound receive headroom tun_get_user() uses tun->align both as skb headroom and when choosing how much packet data to keep linear. OVS can propagate an oversized headroom request from another port to TUN or TAP. When align is larger than the usable space in a one-page skb head, SKB_MAX_HEAD(align) underflows and the result becomes negative when stored in good_linear. That value later wraps when assigned to the size_t linear variable, and tun_alloc_skb() can place skb->data outside the allocated head. Bound the headroom stored by TUN to the one-page skb-head budget and the largest non-sentinel 16-bit skb header offset. Leave one linear byte for raw TUN and a complete Ethernet header for TAP, including NET_IP_ALIGN. Also pull the raw-TUN protocol byte and the TAP Ethernet header before accessing them, so these checks remain safe for nonlinear skbs supplied by other allocation paths.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81001", "url": "https://ubuntu.com/security/CVE-2026-81001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: fix use-after-free in sl_sync() slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor. priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop: \t/* Snapshot list, allow later requests */ \tlist_replace_init(&net_todo_list, &list); \t__rtnl_unlock(); \t... \t\tif (dev->priv_destructor) \t\t\tdev->priv_destructor(dev);\t/* slip_devs[i] = NULL */ \t\tif (dev->needs_free_netdev) \t\t\tfree_netdev(dev); \t\t... \t\t/* Free network device */ \t\tkobject_put(&dev->dev.kobj); So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed */ sl = netdev_priv(dev) if (sl->tty || sl->leased) /* use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860 Commit e58c19124189 (\"slip: Fix use-after-free Read in slip_open\") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it. Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: the ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81002", "url": "https://ubuntu.com/security/CVE-2026-81002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xdp: fix zero-copy frame layout xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page and advertises PAGE_SIZE as its frame size. It allows the copied frame to occupy the page tail needed by skb_shared_info and records zero headroom even when metadata separates the frame header from packet data. An AF_XDP zero-copy packet redirected through cpumap can therefore make the skb overlap skb_shared_info or place it beyond the allocated page. Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result. BUG: KASAN: slab-out-of-bounds in skb_gro_receive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skb_gro_receive (net/core/gro.c:174) udp_gro_receive (net/ipv4/udp_offload.c:812) inet_gro_receive (net/ipv4/af_inet.c:1539) dev_gro_receive (net/core/gro.c:515) gro_receive_skb (net/core/gro.c:633) cpu_map_kthread_run (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Kernel panic - not syncing: KASAN: panic_on_warn set ...", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81003", "url": "https://ubuntu.com/security/CVE-2026-81003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: filter frames in afiucv_hs_rcv() by ingress device afiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-byte name fields in the transport header alone. No check is made against the net_device the frame arrived on. This can cause a frame arriving on any netdev to be delivered to an AF_IUCV socket. Three problems follow. First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL. iucv_sock_bind() takes the classic path whenever the requested userid matches iucv_userid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucv_hs_callback_syn() for such a match inherits hs_dev = NULL and transport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable. Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections Third, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() calls sk_alloc(&init_net, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAP_NET_RAW capability valid within that namespace can send a raw ETH_P_AF_IUCV frame on its own lo device and have it matched against init_net sockets. Fix all three by skipping any socket whose hs_dev does not match the ingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hs_dev is always a device in init_net (iucv_sock_bind() scans for_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket. Note that AF_IUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81005", "url": "https://ubuntu.com/security/CVE-2026-81005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: si: Fix NULL pointer dereference after failed registration try_smi_init() allocates new_smi->si_sm and later calls ipmi_register_smi_mod(), which maps to ipmi_add_smi(). During ipmi_add_smi(), the upper IPMI message handler obtains the initial BMC device information through __bmc_get_device_id(). This can fail if the BMC does not return a successful response to the Get Device ID command. When the BMC returns a nonzero completion code, the device-id helper retries the command and eventually returns -EIO if the device ID still cannot be fetched. On this failure path, ipmi_add_smi() logs \"Unable to get the device id\" and goes to out_err_started, where it invokes the lower driver's shutdown callback. try_smi_init() then logs the returned registration failure: ipmi_si IPI0001:00: IPMI message handler: Unable to get the device id: -5 ipmi_si IPI0001:00: Unable to register device: error -5 For ipmi_si, the shutdown callback is shutdown_smi(), which cleans up the SI state machine data, frees smi_info->si_sm, and sets smi_info->si_sm and smi_info->intf to NULL. However, intf->in_shutdown is not set on this failed-registration rollback path. Therefore, the asynchronous redo_bmc_reg work item can still retry BMC device-id probing after the lower driver has already cleared its SI state machine data. In the observed case, that retry path reached start_next_msg(), which passed the NULL smi_info->si_sm pointer to the selected KCS state machine handler: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Workqueue: events redo_bmc_reg [ipmi_msghandler] RIP: start_kcs_transaction+0x2c/0x190 [ipmi_si] Call Trace: start_next_msg+0x50/0x80 [ipmi_si] check_start_timer_thread.part.9+0x3b/0x50 [ipmi_si] sender+0x69/0x80 [ipmi_si] i_ipmi_request+0x2ac/0x9d0 [ipmi_msghandler] __get_device_id.isra.29+0xaa/0x180 [ipmi_msghandler] __bmc_get_device_id+0xef/0x950 [ipmi_msghandler] redo_bmc_reg+0x52/0x60 [ipmi_msghandler] process_one_work+0x1a7/0x360 Set intf->in_shutdown on the out_err_started path before invoking the lower driver's shutdown callback. This prevents later redo_bmc_reg retries from using an interface whose lower driver state has been cleaned up, and applies the same shutdown state to other IPMI interfaces as well.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81007", "url": "https://ubuntu.com/security/CVE-2026-81007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: validate write message length ipmb_write() read message fields before validating the length byte. A zero or short write can read uninitialized stack bytes. A length smaller than the SMBus header underflows the block write length. Require a non-empty buffer and the minimum IPMB request length. Also require the length byte plus payload before parsing the message.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81008", "url": "https://ubuntu.com/security/CVE-2026-81008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: interconnect: Fix use after free in icc_get() and of_icc_get_by_index() In of_icc_get_by_index() and icc_get(), if the dynamic allocation for path->name fails via kasprintf(), the error handling path directly calls kfree(path) to free the path object and returns an error. However, prior to this point, path_find() calls path_init(), which already links the path's requests into the req_list of the respective interconnect nodes via hlist_add_head(). Directly invoking kfree(path) leaves dangling pointers in the hlist. A subsequent call to icc_get() or icc_set_bw() will traverse or modify these corrupted lists, triggering a slab use afterfree. KASAN report showing the vulnerability when reproducing via debugfs: BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0 Fix this by replacing kfree(path) with the proper teardown function, icc_put(path), which safely removes the requests from the req_list using hlist_del() and drops the provider usage references before freeing the memory. Additionally, in icc_get(), ensure that the icc_lock mutex is released prior to calling icc_put(path) to avoid a deadlock, as icc_put() internally acquires the same lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81017", "url": "https://ubuntu.com/security/CVE-2026-81017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Bound the EC-reported sensor number Each EC FIFO event carries an 8-bit sensor number (in->sensor_num). cros_ec_sensorhub_ring_handler() validates the FIFO event count, the per-read count and the ring bound, but not the sensor number, which cros_ec_sensor_ring_process_event() then uses unchecked to index sensorhub->batch_state[] - allocated with only sensorhub->sensor_num entries. A sensor number of sensor_num or larger is an out-of-bounds read and write of batch_state[]. Validate the sensor number in the ring handler, where each event is read from the EC, and drop a malformed event before it is used.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89440", "url": "https://ubuntu.com/security/CVE-2026-89440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: via-sdmmc: stop card-detect handling on probe failure request_irq() registers the SD card-detect interrupt and the probe enables it before mmc_add_host() runs. If mmc_add_host() fails, the error path only unmaps the registers and returns: the interrupt stays registered, so the handler keeps running against the host once it is freed. via_sdc_isr() dereferences sdhost and its MMIO base and schedules carddet_work, which via_sdc_card_detect() also runs against freed memory through its container_of() dereference. Add a probe-error path that disables and frees the interrupt and cancels carddet_work before unmapping. carddet_work can re-enable the device interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it again after cancelling the work. This issue was found by an in-house static analysis tool and confirmed by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89444", "url": "https://ubuntu.com/security/CVE-2026-89444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer set_attribute() populates the security area of the BIOS attribute request buffer with the current admin password via populate_security_buffer(), then dumps the whole request buffer with print_hex_dump_bytes(). This can expose the plaintext admin password in the kernel log. The same issue was fixed for the password attribute path by commit d1a196e0a6dc (\"platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data\"). Remove the remaining dump from the BIOS attribute path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93206", "url": "https://ubuntu.com/security/CVE-2026-93206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/proc: Use file_ns_capable() when checking config space read access proc_bus_pci_read() decides how much of the config space is readable based on capable(CAP_SYS_ADMIN), which checks the credentials of the task calling read(), not the credentials of the process that opened the file. The sysfs equivalent, pci_read_config(), has checked the credentials of the opening process since commit de139a339395 (\"pci: check caps from sysfs file open to read device dependent config space\"), so a privileged process can open the config space file and pass the file descriptor to an unprivileged process (for example, a process running a KVM guest with an assigned device), which can then read the entire config space. The check was subsequently routed through the LSM framework in commit 47970b1b2aa6 (\"pci: use security_capable() when checking capablities during config space read\") and converted to the dedicated helper in commit ab0fa82b2df9 (\"pci-sysfs: use proper file capability helper function\"). Thus, the two interfaces check the same capability against different credentials. Checking the credentials of the task calling read() makes the outcome depend on who reads rather than who opened, so the restriction is bypassed whenever a more privileged process reads through the descriptor. Checking the credentials recorded in file->f_cred settles the decision at open() time and ties it to the file, where it cannot change with the caller. Use file_ns_capable() to check CAP_SYS_ADMIN against the credentials in effect when the file was opened, bringing the procfs interface in line with the sysfs behaviour. As a result, a file descriptor opened by a privileged process and passed to an unprivileged one now allows the entire config space to be read through procfs, matching sysfs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89456", "url": "https://ubuntu.com/security/CVE-2026-89456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Propagate partial completion length across ERP recovery dasd_default_erp_postaction() copies the timing and device state from the finished ERP request back to the original request but drops proc_bytes. A request that was partially completed, an ESE read of a not-yet-allocated track returns fewer bytes than requested, and then recovered through the ERP chain loses its partial-completion length. __dasd_cleanup_cqr() then sees proc_bytes == 0 and completes the whole request instead of requeueing the remainder, silently returning zeroed data for the part that was never read. Carry proc_bytes over to the original request like the other per-request state.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89457", "url": "https://ubuntu.com/security/CVE-2026-89457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Guard sysfs discipline callbacks against unallocated private data Several sysfs show/store handlers call a discipline callback that dereferences device->private, either directly or through the DASD_DEFINE_ATTR() macro. During dasd_generic_set_online() the discipline is assigned before check_device() allocates device->private, so an unprivileged read of one of these world-readable attributes in that window dereferences a NULL pointer and panics. Guard the dereference inside each callback that actually touches device->private.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89458", "url": "https://ubuntu.com/security/CVE-2026-89458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Do not complete a failed ESE read as successful dasd_int_handler() completes an NRF read of an unallocated ESE track by calling ese_read() and unconditionally marking the request DASD_CQR_SUCCESS. dasd_eckd_ese_read() can return an error before it has zeroed the destination buffer: a failed sense-data parse or a current track outside the requested range both return early, leaving the destination pages untouched. The request is still completed successfully, so the block layer is handed stale / uninitialized memory instead of zeros. Check the ese_read() return value and fail the request through the normal error path instead of forcing DASD_CQR_SUCCESS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89461", "url": "https://ubuntu.com/security/CVE-2026-89461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: synchronize work cancellation on suspend max17040_work() requeues itself after every poll. cancel_delayed_work() only cancels a pending instance and does not wait for a callback that is already running. If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns. Use cancel_delayed_work_sync() to ensure polling is quiesced before suspend completes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89463", "url": "https://ubuntu.com/security/CVE-2026-89463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ucs1002: fix use-after-free on remove ucs1002 has no remove callback, so unbind runs entirely through devm. The alert IRQ handler queues the health_poll delayed work, and the work reschedules itself while the chip reports a bad-health condition. devm frees the alert IRQ, which only synchronizes the handler; it does not cancel the delayed work, which can then run after devm frees the driver data and dereference it. Register health_poll with devm_delayed_work_autocancel() before the alert IRQ is requested. devm then frees the IRQ before cancelling the work, so the handler can no longer queue it and the work is cancelled before the driver data is freed. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89464", "url": "https://ubuntu.com/security/CVE-2026-89464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: twl4030_charger: cancel workers via devm bci is devm-allocated. Two workers (bci->work and bci->current_worker) dereference it. twl4030_bci_remove() disables charging and masks interrupts. It cancels neither worker. A worker pending at remove() can run after devm frees bci. The USB transceiver comes from devm_usb_get_phy_by_node(). devm unregisters its notifier only after remove() returns. A cancel_work_sync() in remove() can then race a notifier reschedule. devm_work_autocancel() and devm_delayed_work_autocancel() avoid that. They cancel the workers during devm release, before bci is freed. The current_worker is registered first, since devm will cancel in reverse order and bci->work can reschedule current_worker. [Move comment about order into the commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89469", "url": "https://ubuntu.com/security/CVE-2026-89469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: lp8727: fix use-after-free in lp8727_release_irq() lp8727_isr_func(), the threaded IRQ handler, is the only caller that arms pchg->work via schedule_delayed_work(). lp8727_release_irq() currently cancels the work before freeing the IRQ, so an IRQ delivered in between can re-arm the work through the threaded handler. After .remove returns the devm layer frees pchg while lp8727_delayed_func() may still run and dereference it. Free the IRQ first so the threaded handler is quiesced and can no longer queue work, then cancel the delayed work to drain the final generation. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89470", "url": "https://ubuntu.com/security/CVE-2026-89470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS Currently the cros_usbpd-charger driver probe iterates based on raw charger port count returned by the embedded controller. The only check is against the number of USB PD ports which the embedded controller also defines. A malicious embedded controller could return an inaccurate port count (up to 255) resulting in an out of bounds write and subsequent memory corruption. Update helper functions in cros_usbpd-charger to limit port counts to EC_USB_PD_MAX_PORTS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89471", "url": "https://ubuntu.com/security/CVE-2026-89471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd-charger: bound the EC-reported port count cros_usbpd_charger_probe() reads two port counts from the EC and uses one of them, num_charger_ports, as the loop bound when populating a fixed-size array: \tstruct port_data *ports[EC_USB_PD_MAX_PORTS];\t/* 8 entries */ \t... \tfor (i = 0; i < charger->num_charger_ports; i++) \t\tcharger->ports[charger->num_registered_psy++] = port; Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports (from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The only validation is a sanity check that compares the two EC-reported values against each other: \tif (num_charger_ports < num_usbpd_ports || \t num_charger_ports > num_usbpd_ports + 1) \t\treturn -EPROTO; It never checks either count against EC_USB_PD_MAX_PORTS, the size of the ports[] array. A malfunctioning, malicious or compromised EC that reports num_usbpd_ports == num_charger_ports == N for any N > 8 (for example both 255) passes this check, and the loop then writes N pointers into the 8-entry ports[] array embedded in the devm_kzalloc()'d charger_data, overflowing it by up to 255 - 8 = 247 entries (~1976 bytes): a slab out-of-bounds write. Reject a port count larger than the ports[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89474", "url": "https://ubuntu.com/security/CVE-2026-89474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: drain usb_work before freeing the charger The USB-PHY notifier queues usb_work, whose handler calls power_supply_changed(bq->charger). The reset devm action only unregisters the notifier and was registered before the power supplies, so devm frees bq->charger on unwind before the action runs; a usb_work still queued can then dereference it. Register the reset action after the power supplies, so it unregisters the notifiers and drains usb_work before the supplies are released. Initialize usb_work and obtain the PHY references before registering the notifiers, so the worker cannot run before the supplies exist. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89475", "url": "https://ubuntu.com/security/CVE-2026-89475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq24257: fix use-after-free on remove The STAT-pin interrupt is devm-managed, so it stays armed until the devm cleanup that runs after remove() returns. remove() cancels bq->iilimit_setup_work while the threaded handler can still fire; that handler reschedules the work and dereferences bq, so the work runs against freed memory once devm frees bq. Make the delayed work device-managed with devm_delayed_work_autocancel(), registered before the interrupt request. The devm cleanup then releases the interrupt first, so the handler can no longer reschedule the work, and cancels the work before bq is freed. The explicit cancel_delayed_work_sync() in remove() is no longer needed and is dropped. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89476", "url": "https://ubuntu.com/security/CVE-2026-89476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix stream->outcnt underflow on duplicate RECONF responses A cached RECONF chunk may contain more than one request parameter. A duplicate response can therefore find and process the same ADD_OUT request again while another parameter is still outstanding, rolling back outcnt twice and possibly underflowing it. Track outstanding request types as bits and clear each bit after its first response. Later responses for the same request are then ignored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89477", "url": "https://ubuntu.com/security/CVE-2026-89477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix NULL deref on untransmitted RECONF completion sctp_process_strreset_outreq(), sctp_process_strreset_addstrm_out() and sctp_process_strreset_resp() complete a pending stream reconfiguration request by stopping the reconf timer on the transport it was sent on: \tt = asoc->strreset_chunk->transport; \tif (timer_delete(&t->reconf_timer)) \t\tsctp_transport_put(t); chunk->transport is assigned by __sctp_packet_append_chunk() when the chunk is appended to an outbound packet, and sctp_outq_flush_ctrl() arms the reconf timer at that same point. A request already published in asoc->strreset_chunk but not yet transmitted has neither, so completing it dereferences NULL. Two ways to get there. sctp_send_asconf_del_ip() sets asoc->src_out_of_asoc_ok without sending anything when the address being removed is the association's last one, and sctp_outq_flush_ctrl() then leaves every non-ASCONF control chunk queued; as only sctp_process_asconf_ack() clears that flag, it persists. An unprivileged process that removes such an address and then asks for a stream reset panics the kernel from softirq. A peer needs neither ASCONF nor local help: sctp_cmd_interpreter() uncorks the outqueue only once the whole packet has been processed, so a reply built while walking a RECONF chunk stays untransmitted for the rest of that walk, and one RECONF chunk carrying [Incoming SSN Reset Request, Outgoing SSN Reset Request, Response] -- or two RECONF chunks in one packet -- reaches the same dereference. KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef] RIP: 0010:timer_delete+0x67/0x110 Call Trace: sctp_process_strreset_addstrm_out (net/sctp/stream.c:832) sctp_sf_do_reconf (net/sctp/sm_statefuns.c:4212) sctp_do_sm (net/sctp/sm_sideeffect.c:1172) sctp_assoc_bh_rcv (net/sctp/associola.c:1044) sctp_rcv (net/sctp/input.c:243) ip_local_deliver (net/ipv4/ip_input.c:262) process_backlog (net/core/dev.c:6680) A response can only acknowledge a request that was actually sent, so do not match asoc->strreset_chunk while chunk->transport is NULL. Guarding the lookup covers all three completion sites.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89478", "url": "https://ubuntu.com/security/CVE-2026-89478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: drop a chunk if its transport was removed sctp_rcv() resolves the transport once per packet and leaves it in chunk->transport. The lookup reference, or the one sctp_add_backlog() takes if the socket is owned by userspace, keeps it around until the chunk has been processed. An authenticated ASCONF DEL-IP can remove it in the meantime. sctp_assoc_rm_peer() takes the transport out of the association and calls sctp_transport_free(), which tags it dead and drops the reference the association held. There is a window on both paths: the packet can sit on the socket backlog, and on the direct path the lookup completes before bh_lock_sock(). The DATA chunk in that packet puts the removed transport back into asoc->peer.last_data_from. Once the packet is done that reference goes away and the transport is freed by RCU, so the next delayed SACK carries the pointer into the SACK chunk and sctp_outq_select_transport() reads the freed transport's state. Drop the chunk in sctp_inq_push(), next to the existing rcvr->dead check. Both paths reach it with the association's socket lock held. The peer retransmits it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89479", "url": "https://ubuntu.com/security/CVE-2026-89479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stop processing a packet once its association is deleted sctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference. A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(), so the association and its transports are freed. The endpoint loop has no counterpart to the asoc->base.dead check in sctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed transport and is then passed to sctp_do_sm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context. The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctp_inq_free() releases the chunk on the association receive path. sctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89480", "url": "https://ubuntu.com/security/CVE-2026-89480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: reject a read that transferred too few bytes nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above. A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target. Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89482", "url": "https://ubuntu.com/security/CVE-2026-89482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone Commit 25e5cb780e62 (\"nvme-tcp: fix possible crash in write_zeroes processing\") established that blk_rq_payload_bytes() must not be read without first checking blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight, because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now tests the same two.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89483", "url": "https://ubuntu.com/security/CVE-2026-89483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: zero the discard fallback page nvme_setup_discard() always maps sizeof(struct nvme_dsm_range) * NVME_DSM_MAX_RANGES = 4096 bytes as the DSM payload however many ranges the command declares, because some devices ignore the 'Number of Ranges' field - the Fixes: commit records two that read past the declared ranges. A single-range discard fills only the first 16 bytes. Normally the buffer comes from kzalloc() and the other 4080 bytes are zero. When that allocation fails the code falls back to the per-controller ctrl->discard_page, which nvme_init_ctrl() obtains with alloc_page(GFP_KERNEL) and nothing ever zeroes, so those 4080 bytes are whatever the page last held and are handed to the controller. Reaching it requires the kzalloc(GFP_ATOMIC | __GFP_NOWARN) to fail, that is memory pressure; it is not remotely triggerable. Failing the allocation under KMSAN reproduces it, with the leaked tail full of vmemmap struct page pointers. The extent in the report is a partial transfer of the payload, not the whole 4096 bytes; the 16-byte boundary in it is the one declared range: [ 11.991601] BUG: KMSAN: uninit-value in dma_map_phys+0x14c8/0x1900 [ 11.991969] dma_map_phys+0x14c8/0x1900 [ 11.992220] dma_map_page_attrs+0xcf/0x130 [ 11.992485] e1000_xmit_frame+0x4099/0x6d10 [ 11.992768] dev_hard_start_xmit+0x22f/0xa80 [ 11.993068] sch_direct_xmit+0x35c/0xcb0 [ 11.993315] __dev_queue_xmit+0x1ee5/0x5eb0 [ 11.993608] ip_finish_output2+0x1903/0x1c30 [ 11.993881] ip_finish_output+0x288/0x870 [ 11.994125] ip_output+0x15e/0x400 [ 11.994365] __ip_queue_xmit+0x1e85/0x1fb0 [ 11.994639] ip_queue_xmit+0x60/0x80 [ 11.994899] __tcp_transmit_skb+0x4e71/0x5fa0 [ 11.995210] tcp_write_xmit+0x3a36/0x9160 [ 11.995533] __tcp_push_pending_frames+0xc5/0x3c0 [ 11.995854] tcp_push+0x7dc/0x840 [ 11.996076] tcp_sendmsg_locked+0x766c/0x8400 [ 11.996371] tcp_sendmsg+0x4b/0x90 [ 11.996572] inet_sendmsg+0x134/0x2a0 [ 11.996823] __sock_sendmsg+0x265/0x360 [ 11.997076] sock_sendmsg+0x100/0x1e0 [ 11.997293] nvme_tcp_try_send+0x196f/0x6370 [ 11.997605] nvme_tcp_queue_rq+0x1d54/0x20b0 [ 11.997882] blk_mq_dispatch_rq_list+0x5ee/0x2e50 [ 11.998175] __blk_mq_sched_dispatch_requests+0x16dc/0x24a0 [ 11.998539] blk_mq_sched_dispatch_requests+0x11b/0x2c0 [ 11.998865] blk_mq_run_work_fn+0x13b/0x280 [ 11.999146] process_scheduled_works+0x966/0x1ad0 [ 11.999465] worker_thread+0xe44/0x1480 [ 11.999709] kthread+0x53b/0x600 [ 11.999927] ret_from_fork+0x29f/0x7c0 [ 12.000191] ret_from_fork_asm+0x1a/0x30 [ 12.000460] [ 12.000558] Uninit was created at: [ 12.000788] __alloc_frozen_pages_noprof+0x8bf/0xd30 [ 12.001096] alloc_pages_mpol+0x1d0/0x5f0 [ 12.001326] alloc_pages_noprof+0x102/0x290 [ 12.001627] nvme_init_ctrl+0x5a3/0x9f0 [ 12.001891] nvme_tcp_create_ctrl+0xd75/0x19b0 [ 12.002170] nvmf_dev_write+0x4c68/0x4fd0 [ 12.002426] vfs_write+0x587/0x1a10 [ 12.002636] __x64_sys_write+0x207/0x4f0 [ 12.002874] x64_sys_call+0x2ff0/0x3ea0 [ 12.003123] do_syscall_64+0x147/0x3b0 [ 12.003400] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 12.003680] [ 12.003777] Bytes 16-2843 of 2844 are uninitialized [ 12.004068] Memory access of size 2844 starts at ffff888109f82000 [ 12.004412] [ 12.004530] CPU: 0 UID: 0 PID: 101 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMECTL-gf5098b6bae76 #1 PREEMPT(lazy) [ 12.005127] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 12.005762] Workqueue: kblockd blk_mq_run_work_fn [ 12.006073] ===================================================== Allocate the page with __GFP_ZERO. The single allocation site covers every use of it: bytes no discard has written stay zero, and bytes one did write hold that controller's own range list, which it has already been sent.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89485", "url": "https://ubuntu.com/security/CVE-2026-89485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: pin next file across nlm_inspect_file lock-drop nlm_traverse_files() pins the current file with f_count++ across a mutex_unlock for nlm_inspect_file(), but nothing pins the saved next pointer. A concurrent nlm_release_file() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step. Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock. Always call nlm_file_release() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlm_file_inuse(), which does a live walk of the inode lock list, rather than the cached f_locks field, so skipped files that never ran nlm_inspect_file() are evaluated correctly. Because every file in a hash bucket is now pinned and released, files skipped by the is_failover_file predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89487", "url": "https://ubuntu.com/security/CVE-2026-89487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: only skb_tx_error() a packet we are about to drop queue_userspace_packet() borrows the packet skb -- it only copies it into a private netlink message (user_skb) and does not own it; on return do_execute_actions() keeps forwarding it through the flow's remaining actions. Its error path nevertheless calls skb_tx_error(skb), which via skb_zcopy_clear() does skb_shinfo(skb)->flags &= ~SKBFL_ALL_ZEROCOPY, stripping SKBFL_SHARED_FRAG from that live skb (skb_tx_error()'s kerneldoc says \"skb must be freed afterwards\"). For a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG is what makes esp_input() skb_cow_data() before in-place AEAD; once it is stripped a later local ESP-in-UDP delivery decrypts in place over pages the sender does not own -- an unprivileged page-cache write (the \"Fragnesia\" primitive). do_execute_actions() ignores output_userspace()'s return value, so any action after a failed USERSPACE upcall inherits the stripped skb. Move the skb_tx_error() to the flow-miss drop path - the \"default\" branch of ovs_dp_process_packet()'s switch(error), before kfree_skb(). The call has been here since commit 36d5fe6a0007 (\"core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors\") but was harmless until esp_input() began relying on SKBFL_SHARED_FRAG to gate in-place decrypt; only then did stripping it on a still-forwarded skb become a page-cache write primitive.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89489", "url": "https://ubuntu.com/security/CVE-2026-89489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openrisc: fix arbitrary kernel memory access via or1k_atomic syscall sys_or1k_atomic() (syscall 244 in the \"or1k\" ABI) takes two user pointers, v1 and v2, and swaps the words they point to in hand-written assembly. l.lwz r29,0(r4) l.lwz r27,0(r5) l.sw 0(r4),r27 l.sw 0(r5),r29 The pointers are not checked with access_ok(). The four memory accesses also have no exception table entries. A caller passes a kernel address as either pointer, and the syscall reads from and writes to it directly. This gives an unprivileged process a kernel read/write primitive. It overwrites kernel data such as the sys_call_table, gaining code execution in kernel context. Check both pointers before entering the critical section. Add fixups for the four memory accesses so faults on valid but unmapped user addresses return -EFAULT. [shorne@gmail.com: fix comment style]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89490", "url": "https://ubuntu.com/security/CVE-2026-89490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix readdir position truncation on 32-bit kernels In ocfs2_dir_foreach_blk_el(), the directory cookie position is rebuilt with \tctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset; `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask \t~(sb->s_blocksize - 1) is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB block size). In the AND expression with the 64-bit `ctx->pos`, that unsigned operand is zero-extended to 64 bits per the usual arithmetic conversions, yielding 0x00000000fffff000. The high 32 bits of `ctx->pos` are silently cleared, even though directory size is allowed to exceed 4 GiB. When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position is reset back into the first 4 GiB block, making the re-validation path re-enumerate already-returned dirents indefinitely. This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken for all non-inline directories, so a directory large enough to cross 4 GiB reaches it. This is the same class of bug that commit 3dce5bb82c97 (\"exfat: Fix bitwise operation having different size\") fixed in exfat, and the fix mirrors the equivalent ext4 fix in this series. Cast the operand to loff_t so the mask is 64-bit before the AND: \tctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89491", "url": "https://ubuntu.com/security/CVE-2026-89491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cluster: don't sleep while holding o2hb_live_lock in o2hb_region_pin() Patch series \"ocfs2: cluster: o2hb_region_pin() fixes\", v2. This series fixes three related issues in o2hb_region_pin(), all are from the original implementation in commit: 58a3158a5d17 (\"ocfs2/cluster: Pin/unpin o2hb regions\"): 1) It is called with o2hb_live_lock (a spinlock) held, but the underlying configfs_depend_item() sleeps (takes inode rwsem and pins the filesystem). This triggers BUG under CONFIG_DEBUG_ATOMIC_SLEEP. 2) When called from the configfs drop_item callback, it creates a lock order inversion: parent inode_lock -> configfs root inode_lock, which can deadlock against subsystem unregistration paths taking root -> parent. 3) If pinning fails partway through o2hb_region_inc_user(), the o2hb_dependent_users counter is leaked and partially-pinned regions are never released, leaving heartbeat regions unprotected on subsequent mounts. Patch 1 reworks o2hb_region_pin() to drop o2hb_live_lock across each sleeping configfs_depend_item() call, using a config_item reference to keep the region alive while unlocked. Patch 2 adds a from_callback parameter to select configfs_depend_item_unlocked() when called from configfs context, avoiding the inode_lock nesting. Patch 3 fixes the error path in o2hb_region_inc_user() to unpin and decrement the counter on failure. This patch (of 3): o2hb_region_pin() is always called with the o2hb_live_lock spinlock held (from o2hb_region_inc_user() and o2hb_heartbeat_group_drop_item()), but it calls o2nm_depend_item() -> configfs_depend_item(), which sleeps: it pins the configfs filesystem and takes the configfs root inode rwsem. Under CONFIG_DEBUG_ATOMIC_SLEEP this triggers: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c in_atomic(): 1, ... name: mount.ocfs2 down_write configfs_depend_item o2hb_region_pin o2hb_region_inc_user o2hb_register_callback dlm_register_domain_handlers ... ocfs2_dlm_init ocfs2_mount_volume ocfs2_fill_super Rework o2hb_region_pin() to pin one region at a time with the lock dropped across the sleeping call: under o2hb_live_lock find the next eligible region and take a config_item reference to keep it alive, drop the lock, call o2nm_depend_item(), then retake the lock and record the pin. The config_item_put() is done with the lock released as well, since o2hb_region_release() also acquires o2hb_live_lock and can sleep. The region list may change while unlocked, so the scan restarts from the top after each pin. Local heartbeat still pins only the matching region; global heartbeat pins all eligible regions. The unpin path is unaffected: configfs_undepend_item() only takes a spinlock and does not sleep.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89493", "url": "https://ubuntu.com/security/CVE-2026-89493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate rl_used against rl_count in refcount block validator ocfs2_find_refcount_rec_in_rl() walks the on-disk refcount record array with: \tfor (; i < le16_to_cpu(rb->rf_records.rl_used); i++) { \t\trec = &rb->rf_records.rl_recs[i]; \t\t... rl_recs[] lives in a single metadata block (4096 bytes on the common configuration), so its real capacity is fixed by ocfs2_refcount_recs_per_rb(sb) (247 records for a 4K block with the 16-byte ocfs2_refcount_rec). rl_used and rl_count are both read directly off disk by ocfs2_validate_refcount_block() and are never checked against that capacity, nor against each other, before any refcount/reflink/CoW operation walks the array. A crafted (or corrupted) refcount block with rl_used == 0xffff makes the loop above walk far past the end of the block, dereferencing rl_recs[i] for i up to 65534. The resulting index is then handed to the sibling ocfs2_insert_refcount_rec(), whose insert-shift does: \tif (index < le16_to_cpu(rf_list->rl_used)) \t\tmemmove(&rf_list->rl_recs[index + 1], \t\t\t&rf_list->rl_recs[index], \t\t\t(le16_to_cpu(rf_list->rl_used) - index) * \t\t\t sizeof(struct ocfs2_refcount_rec)); i.e. a memmove() of up to (0xffff - index) * 16 bytes (~1 MiB) from an offset already past the block. This is reachable from an ordinary reflink (FICLONE) against a crafted/corrupted ocfs2 image: attaching an extent whose cpos sorts past every real record in the leaf forces the lookup to run off the end instead of returning early on a match. The attacker model is local: CAP_SYS_ADMIN mounting a crafted or corrupted ocfs2 image, or a raw write to the block device backing an already-mounted ocfs2 filesystem. ocfs2_validate_refcount_block() already validates the block's ECC, signature, rf_blkno and rf_fs_generation, but never rl_count/rl_used against the block's actual on-disk capacity. This is the same class of gap that ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) already closes for the sibling extent-list header, which checks both the record capacity and the \"used\" bound before any code walks h_list.l_recs[]: \tif (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) { \t\trc = ocfs2_error(...); \t\tgoto bail; \t} \tif (le16_to_cpu(eb->h_list.l_next_free_rec) > \t le16_to_cpu(eb->h_list.l_count)) { \t\trc = ocfs2_error(...); \t\tgoto bail; \t} Add the equivalent pair of checks to ocfs2_validate_refcount_block(): reject a refcount block whose rl_count does not match the fixed per-block capacity returned by ocfs2_refcount_recs_per_rb(), and reject rl_used > rl_count. Both checks are skipped when OCFS2_REFCOUNT_TREE_FL is set, because in that case the same union bytes hold an ocfs2_extent_list (rf_list), not the refcount record list (rf_records) -- that layout is already validated separately by ocfs2_validate_extent_block() when the referenced extent block is read. This mirrors the existing \"!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)\" guard used elsewhere in this file (e.g. ocfs2_get_refcount_rec()) to decide whether rf_records or rf_list is the live member of the union. With this in place, a forged rl_used/rl_count is caught at block validation time (ocfs2_error()), consistent with every other corruption check in this function, instead of driving an out-of-bounds read in ocfs2_find_refcount_rec_in_rl() and a subsequent out-of-bounds memmove() in ocfs2_insert_refcount_rec(). Verified against a crafted image on a v6.19 KASAN (KASAN_GENERIC) build: replaying the same reflink (FICLONE) reliably hit a KASAN report in __ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() before this patch, and triggers no report once ocfs2_validate_refcount_block() rejects the forged rl_used/rl_count.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89494", "url": "https://ubuntu.com/security/CVE-2026-89494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate lengths in dlm_mig_lockres_handler A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres->ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain. Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres->lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len <= DLM_LOCKID_NAME_MAX, num_locks <= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89495", "url": "https://ubuntu.com/security/CVE-2026-89495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: bound namelen in dlm_migrate_request_handler Patch series \"ocfs2/dlm: bound peer-controlled lengths in the o2dlm\". The o2dlm receive handlers trust u8 length and count fields from the wire without bounding them, so a node in a DLM domain can corrupt or panic any other node with a malformed message. Three defects: - dlm_migrate_request_handler() passes migrate->namelen unchecked to dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an o2dlm_mle slab object: a heap out-of-bounds write of up to ~215 attacker-controlled bytes. - dlm_mig_lockres_handler() passes mres->lockname_len unchecked to dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname slab object: a heap out-of-bounds write of up to ~223 bytes. - the same handler trusts mres->num_locks without checking that the message is large enough to hold that many entries, so dlm_process_recovery_data() walks mres->ml[] past the kmalloc(data_len) copy and trips a BUG_ON (an out-of-bounds read ending in a panic). The other o2dlm receive handlers already reject an oversized name; the migration and recovery handlers have omitted it since the DLM was added (see the Fixes tags). Patch 1 bounds namelen; patch 2 validates lockname_len, num_locks, and the payload size. Conforming recovery and migration traffic is unaffected. o2net authenticates peers only by the DLM domain key, so any node that has joined the domain -- including a compromised or malicious member -- can send these messages. There is no local trigger; the attacker must already be a member of the cluster. Each sink was confirmed under KASAN with an out-of-tree module mirroring it exactly -- a kmem_cache/kmalloc of the real destination size, then the same unclamped memcpy/loop: slab-out-of-bounds Write for the two writes, Read for the recovery walk, and a panic. A userspace AddressSanitizer build faults identically under -m32 and -m64. Scrubbed logs are available on request. I reported this privately to security@kernel.org and the ocfs2 maintainers on 2026-06-20; with no response after the standard embargo period I am posting the fix publicly. I have no embargo requirement. This patch (of 2): A node receiving a DLM_MIGRATE_REQUEST message trusts the peer-supplied name length (migrate->namelen) without bounding it. dlm_init_mle() then copies that many bytes into the fixed DLM_LOCKID_NAME_MAX-byte mname[] array of an o2dlm_mle slab object, so a malformed message from a cluster peer overflows the slab object by up to ~215 bytes: a heap out-of-bounds write of attacker-controlled data, reachable by any node in the domain. Reject an oversized name, the way dlm_master_request_handler() and the other o2dlm receive handlers already do; the migration handler omits the check entirely. Conforming messages are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89496", "url": "https://ubuntu.com/security/CVE-2026-89496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: always run deallocs on copy-on-write completion Local fuzzing of 6.12.94 has found the following memory leak caused by doing 'copy_file_range()' within the same filesystem: unreferenced object 0xffff88812192c980 (size 32): comm \"syz.0.49\", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................ c0 c5 92 21 81 88 ff ff 00 02 00 00 00 06 00 00 ...!............ backtrace (crc 7068d63f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] ocfs2_find_per_slot_free_list fs/ocfs2/alloc.c:6618 [inline] ocfs2_cache_block_dealloc+0x155/0x4b0 fs/ocfs2/alloc.c:6786 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:944 [inline] direct_splice_actor+0x232/0x480 fs/splice.c:1167 splice_direct_to_actor+0x4b4/0xb60 fs/splice.c:1111 do_splice_direct_actor fs/splice.c:1210 [inline] do_splice_direct+0x10f/0x1c0 fs/splice.c:1236 do_sendfile+0x430/0xbf0 fs/read_write.c:1388 unreferenced object 0xffff88812192c5c0 (size 32): comm \"syz.0.49\", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 29 70 00 00 00 00 00 00 19 00 00 00 00 00 00 00 )p.............. backtrace (crc afec850f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ocfs2_cache_block_dealloc+0x25c/0x4b0 fs/ocfs2/alloc.c:6793 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:9 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89497", "url": "https://ubuntu.com/security/CVE-2026-89497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: skip leading spaces before parsing client debug masks orangefs_prepare_cdm_array() sizes each client debug keyword buffer with strcspn(cds_head, \" \"), but then parses the keyword with %s. The %s conversion skips leading whitespace, while strcspn() does not. If a client debug entry starts with a space, the allocation can be sized for an empty keyword while sscanf() copies the following non-empty token. This can write past the end of the allocated keyword buffer. Skip leading spaces before computing the keyword length so the allocation matches the string parsed by sscanf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89498", "url": "https://ubuntu.com/security/CVE-2026-89498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix double-free of trailer_buf on readdir copy failure On a readdir downcall, orangefs_devreq_write_iter() frees op->downcall.trailer_buf with vfree() when copy_from_iter_full() fails, but does not clear the pointer before goto Efault. The waiter in do_readdir() is then woken with a negative status and frees the same pointer again on its r < 0 path, causing a deterministic double-free. A client holding /dev/pvfs2-req triggers it by sending a readdir downcall whose declared trailer_size exceeds the bytes it supplies. Clear the pointer after freeing so the readdir-side vfree() becomes a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89504", "url": "https://ubuntu.com/security/CVE-2026-89504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: as3722_get_regulator_dt_data: fix premature of_node_put leaving dangling of_node pointer In as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a reference on np, which is then assigned to pdev->dev.of_node. The function immediately calls of_node_put(np), releasing the reference and leaving pdev->dev.of_node as a dangling pointer. Remove the of_node_put(np) call to let the device hold the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89508", "url": "https://ubuntu.com/security/CVE-2026-89508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Lock the handler in ucma_set_ib_path() ucma_set_ib_path() calls ucma_event_handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference: \tmutex_lock(&ctx->file->mut);\t\t\t/* file A */ \tlist_add_tail(&uevent->list, &ctx->file->event_list);\t/* file B */ \tmutex_unlock(&ctx->file->mut);\t\t\t/* file B */ \twake_up_interruptible(&ctx->file->poll_wait);\t/* file B */ A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION caller sleeps in mutex_lock(), so the list_add_tail() lands on file B's event_list while only file A's mutex is held, racing every other user of that list: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0 Read of size 8 at addr ffff888153c6a418 by task poc_corr/486 Call Trace: __list_add_valid_or_report+0x1aa/0x1c0 ucma_event_handler+0x1be/0xc00 ucma_set_ib_path+0x45e/0x710 ucma_set_option+0x32e/0x590 ucma_write+0x1f9/0x330 Allocated by task 505: ucma_write_cm_event+0x1a1/0x660 Freed by task 505: kfree+0x1da/0x4c0 ucma_get_event+0x5d5/0x7e0 The freed object is a ucma_event that another thread dequeued from file B's list under file B's mutex. File A's mut is left held on top of that, wedging its next writer in uninterruptible sleep. This path needs a bound and address-resolved cm_id, so it requires an RDMA device to be present. Take the handler lock around the call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89510", "url": "https://ubuntu.com/security/CVE-2026-89510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Cancel reg_work before freeing device on remove c4iw_uld_state_change() queues reg_work to register the RDMA device. c4iw_remove() can free ctx->dev while this work is pending or running, leaving c4iw_register_device() accessing the freed device. Cancel reg_work before removing the device. The registration work can tear down ctx->dev when registration fails, so do not unregister or deallocate it again in that case. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89511", "url": "https://ubuntu.com/security/CVE-2026-89511", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: Fix NULL pointer dereference in TPA fragment processing Under memory pressure, the qede driver encounters NULL pointer dereferences when processing TPA continuation fragments. Commit 8a8633978b84 (\"qede: Add build_skb() support.\") accidentally dropped the assignment of tpa_info->buffer.data in qede_tpa_start(). When memory pressure causes an SKB allocation failure in qede_tpa_start(), the driver sets tpa_start_fail = true and attempts to recycle the physical page later in qede_tpa_end() via qede_reuse_page(). However, because buffer.data was left uninitialized (NULL), qede_reuse_page() pushes a \"ghost\" BD (valid DMA mapping but NULL data pointer) back into the active Rx ring. The next time the hardware uses this ring slot, it passes a NULL page to qede_fill_frag_skb(), causing a kernel panic. Example crash from production system: BUG: unable to handle kernel NULL pointer dereference at 0x8 RIP: qede_fill_frag_skb+0x96/0x430 [qede] Call Trace: qede_rx_int+0xb06/0x1de0 qede_poll+0x2f4/0x6c0 __napi_poll+0x2d/0x130 Fix the root cause by restoring the tpa_info->buffer.data assignment in qede_tpa_start(), ensuring valid pages are correctly tracked and recycled. Additionally, update the stale comment for struct qede_agg_info::buffer to reflect its current usage.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89512", "url": "https://ubuntu.com/security/CVE-2026-89512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: scp: Fix device reference leak on failed lookup Make sure to drop the reference taken to the SCP device when attempting to look up its driver data before the driver has been bound. Note that holding a reference to a device does not prevent its driver data from going away.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89524", "url": "https://ubuntu.com/security/CVE-2026-89524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: clamp assoc request/response lengths before subtracting IE offsets ath6kl_cfg80211_connect_event() subtracts fixed IE offsets from assoc_req_len (-= 4) and assoc_resp_len (-= 6), both u8, with no lower bound. The aggregate check recently added to ath6kl_wmi_connect_event_rx() bounds the declared lengths from above (their sum must fit the received event), but an assoc request/response shorter than its fixed offset still underflows here: the u8 wraps to ~250, and cfg80211_connect_result() / cfg80211_roamed() then treat that wrapped value as the IE length and copy that many bytes out of the small assoc_info buffer to user space via nl80211, disclosing adjacent slab memory. Clamp both lengths to their offsets before subtracting. Found by 0sec (https://0sec.ai) using automated source analysis; the missing lower bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89525", "url": "https://ubuntu.com/security/CVE-2026-89525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: reject VAT indexes equal to the entry count UDF 1.50 virtual partition mapping uses the VAT as an array of physical block mappings. s_num_entries stores the number of entries in that array, not the highest valid index. The valid VAT indexes are therefore below s_num_entries. udf_get_pblock_virt15() currently rejects only indexes greater than s_num_entries. A crafted image can request index s_num_entries, pass the bounds check, and make the kernel read one entry past the allocated VAT table. Change the check to reject block >= s_num_entries, so the count is handled as an exclusive upper bound. A crafted UDF image reproduced this on origin/master commit 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53 with a KASAN slab-out-of-bounds report in udf_get_pblock_virt15(). Trail of Bits has a reproducer that triggers kernel panic demonstrating the bug, and can share it if needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89532", "url": "https://ubuntu.com/security/CVE-2026-89532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix pcl_for_each_segment for empty chunks When a parsed chunk list contains a chunk whose ch_segcount is zero, pcl_for_each_segment computes its inclusive upper bound as &chunk->ch_segments[ch_segcount - 1]. ch_segcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the ch_segments flex array. The loop body then walks unrelated memory at sizeof(struct svc_rdma_segment) stride until it faults. A zero-segcount chunk is reachable from the wire: xdr_check_write_chunk() only rejects segcount values greater than rc_maxpages, and pcl_alloc_write() links a freshly allocated chunk onto rc_write_pcl/rc_reply_pcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves ch_segcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svc_rdma_get_inv_rkey() iterates all four PCLs with pcl_for_each_segment and dereferences segment->rs_handle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault. xdr_check_write_list / xdr_check_reply_chunk pcl_alloc_write() chunk = pcl_alloc_chunk(...) /* ch_segcount = 0 */ list_add_tail(&chunk->ch_list, &pcl->cl_chunks) /* fill loop iterates zero times for wire segcount 0 */ svc_rdma_get_inv_rkey() pcl_for_each_chunk(rc_write_pcl) pcl_for_each_segment(segment, chunk) pos <= &ch_segments[0u - 1u] /* 0xFFFFFFFF */ segment->rs_handle /* OOB read -> GPF */ Fix by switching the macro to a half-open upper bound that uses ch_segcount directly. For ch_segcount == 0 the loop start equals the loop end and the body is skipped; for ch_segcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and net/sunrpc/xprtrdma/svc_rdma_rw.c remain correct under the new bound, so no caller changes are needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89533", "url": "https://ubuntu.com/security/CVE-2026-89533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix offset arithmetic in read_chunk_range svc_rdma_read_chunk_range() walks a Read chunk's segment list to build a sub-range starting at byte offset and spanning length bytes for a Position-Zero or Call chunk. Two arithmetic defects in the per-segment loop produce wrong DMA lengths and a u32 underflow: pcl_for_each_segment(segment, chunk) { if (offset > segment->rs_length) { offset -= segment->rs_length; continue; } dummy.rs_handle = segment->rs_handle; dummy.rs_length = min_t(u32, length, segment->rs_length) - offset; dummy.rs_offset = segment->rs_offset + offset; First, the skip predicate uses '>' instead of '>='. When offset equals the segment's full rs_length, the segment is fully consumed and should be skipped, but the loop falls through into the body. The resulting dummy.rs_length is min_t(u32, length, rs_length) - rs_length, which underflows to a near-UINT_MAX u32 when length is smaller than rs_length, or is zero otherwise. Second, the length formula subtracts offset from the min_t() result rather than from segment->rs_length before the cap. For offset > 0 the segment's residual is rs_length - offset, not rs_length, so the cap must be applied to the residual. With the current bracketing, whenever length is smaller than rs_length - offset the per-segment length becomes length - offset instead of length, silently dropping offset bytes from the rebuilt chunk. Combined with the boundary case above it also enables the u32 underflow path, which propagates a huge nr_bvec into svc_rdma_build_read_segment() and a multi-MiB kmalloc_array_node() in svc_rdma_get_rw_ctxt(). Additionally, svc_rdma_read_call_chunk() can invoke this function with length == 0 when the last Read chunk ends exactly at the end of the Call chunk. With the corrected >= predicate, every segment is skipped and the function returns the initial -EINVAL, rejecting a valid request. Return success immediately when length is zero. Also break out of the loop once length is fully consumed to avoid passing zero-length segments to svc_rdma_build_read_segment(). Fix by using '>=' so a fully-consumed segment is skipped, by moving '- offset' inside min_t() so the cap is applied to the segment's residual length, by returning success for zero-length requests, and by stopping iteration when the requested range has been consumed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89538", "url": "https://ubuntu.com/security/CVE-2026-89538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field gss_krb5_unwrap_v2() sets buf->len to a logical length, which can be much smaller than head[0].iov_len (the allocated receive-page capacity). It then calls xdr_buf_trim() with a trim length derived from the 16-bit \"extra count\" (ec) field in the Kerberos v2 token header. The ec field is authenticated by the post-decrypt memcmp() against the encrypted header copy, so a randomly-mutated value is rejected. However, any peer holding a valid GSS context can legitimately encrypt a token whose ec exceeds the plaintext length. Per RFC 4121, such a token is structurally malformed. Although xdr_buf_trim() now clamps the buf->len subtraction to avoid unsigned underflow, the buffer is still left in a semantically invalid state (zero length, inconsistent iov lengths) when ec is oversized. Reject these tokens before calling xdr_buf_trim(), giving callers a well-defined GSS_S_DEFECTIVE_TOKEN error and keeping the xdr_buf internally consistent. The wrapped blob begins at a nonzero offset -- both callers pass len as offset + opaque_len -- so buf->len still counts the offset bytes that precede the blob. Compare the trim length against the remaining wrapped segment, buf->len - offset, rather than the whole buffer; comparing against buf->len alone leaves an offset-wide window in which an oversized ec passes the test and xdr_buf_trim() cuts into the bytes ahead of the blob.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89540", "url": "https://ubuntu.com/security/CVE-2026-89540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: init gssp_lock before publishing proc entry create_use_gss_proxy_proc_entry() publishes /proc/net/rpc/use-gss-proxy via proc_create_data() before init_gssp_clnt() runs mutex_init() on sn->gssp_lock. Once the dentry is linked under proc_subdir_lock it is immediately reachable from userspace, so a write that lands in the window drives set_gssp_clnt() into mutex_lock() on a zero-initialized struct mutex. create_use_gss_proxy_proc_entry(net) proc_create_data(\"use-gss-proxy\", ...) /* dentry live */ init_gssp_clnt(sn) mutex_init(&sn->gssp_lock) /* too late */ write_gssp() set_gssp_clnt(net) mutex_lock(&sn->gssp_lock) /* uninitialized */ gssp_rpc_create(...) sn->gssp_clnt = clnt mutex_unlock(&sn->gssp_lock) The window spans only the two statements between proc_create_data() returning and init_gssp_clnt(), so a writer reaches it only if the registering thread is preempted there while another task is already opening the freshly published file. register_pernet_subsys() runs in preemptible context under pernet_ops_rwsem, so that preemption is possible, and the window widens on auth_rpcgss module load, when the proc entry is created for every live net namespace whose tasks are already running. A writer that wins the race locks a zero-filled struct mutex. On CONFIG_DEBUG_MUTEXES the missing magic value trips a \"lock used without init\" splat; on a production kernel the fast path acquires the lock via CMPXCHG(owner, 0, current). In the latter case a second writer that arrives before init_gssp_clnt() re-zeroes owner can enter set_gssp_clnt() concurrently, shut down the first writer's clnt while it is still in use, and leak the loser's clnt. Fix by initializing sn->gssp_lock in sunrpc_init_net() so its lifetime matches the sunrpc_net it lives in. sn->gssp_clnt is already NULL from the kzalloc that backs net_generic storage, so the lazy helper is no longer needed; drop init_gssp_clnt(), its prototype, and the call from create_use_gss_proxy_proc_entry(). sunrpc.ko is a build-time dependency of auth_rpcgss.ko, so sunrpc_init_net() has always run on every netns before any auth_gss pernet init can publish the proc entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89541", "url": "https://ubuntu.com/security/CVE-2026-89541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_unwrap_resp_priv length checks gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 (\"SUNRPC: svcauth_gss: enforce krb5 token minimum length\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89542", "url": "https://ubuntu.com/security/CVE-2026-89542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_krb5_unwrap_v2 against short tokens gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and ptr+6 before validating that the token is at least GSS_KRB5_TOK_HDR_LEN (16) bytes long, and its rotate_left() helper passes buf->len - base to xdr_buf_subsegment() without verifying that base <= buf->len. When a caller hands in a sub-16-byte token, or a token whose declared len leaves base past the end of the buffer, three distinct failures follow: gss_krb5_unwrap_v2(offset, len, buf) ptr = buf->head[0].iov_base + offset ec = *(ptr + 4) /* OOB read on short head */ rrc = *(ptr + 6) /* OOB read on short head */ rotate_left(offset + 16, buf, rrc) xdr_buf_subsegment(buf, &subbuf, base, buf->len - base) /* u32 wrap when base > len */ _rotate_left(&subbuf, shift) shift %= buf->len /* divide-by-zero when base == len */ After decryption, the cleanup arithmetic has the same shape: movelen = min_t(unsigned int, buf->head[0].iov_len, len); movelen -= offset + GSS_KRB5_TOK_HDR_LEN + headskip; BUG_ON(offset + GSS_KRB5_TOK_HDR_LEN + headskip + movelen > buf->head[0].iov_len); The BUG_ON re-adds the value just subtracted, so it reduces to min(A, B) > A and is permanently false; it cannot catch the unsigned underflow of movelen, which then drives a ~UINT_MAX-byte memmove(). Add four defense-in-depth guards inside the unwrap core so it is safe regardless of what its callers validate: - reject tokens with len - offset < GSS_KRB5_TOK_HDR_LEN before touching ptr+4/ptr+6; - bail from rotate_left() when buf->len <= base, covering both the underflow and zero-length cases; - return early from _rotate_left() when buf->len is zero, so the shift %= buf->len modulo cannot fault; - replace the dead BUG_ON with a live check that returns GSS_S_DEFECTIVE_TOKEN before the movelen subtraction.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89548", "url": "https://ubuntu.com/security/CVE-2026-89548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: always drain cache_cleaner before destroying a cache_detail sunrpc_destroy_cache_detail() only cancels the global cache_cleaner delayed_work when cache_list is empty. During per-netns teardown cache_list is never empty because init_net's caches remain registered, so the cancel never fires. After unlink, the caller proceeds to cache_destroy_net() which kfrees the cache_detail while cache_clean() may still hold a dangling pointer to it. The result is a use-after-free: cache_dequeue() takes cd->queue_lock on freed memory, and cache_put() dereferences cd->cache_put as a function pointer from freed slab. Drop the list_empty guard so that cancel_delayed_work_sync() always runs, ensuring any in-flight cache_clean() completes before the cache_detail is freed. Re-arm the cleaner afterwards if other caches are still registered.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89549", "url": "https://ubuntu.com/security/CVE-2026-89549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: route to a populated pool in svc_pool_for_cpu() svc_set_num_threads() spreads the requested threads evenly across the service's pools (base = nrservs / sv_nrpools). When a service runs fewer threads than it has pools -- e.g. an nfsd configured with fewer threads than the host has NUMA nodes while running in \"pernode\" or \"percpu\" mode -- the trailing pools are left with no threads at all. svc_xprt_enqueue() selects a pool from the CPU servicing the transport, queues the transport on that pool's sp_xprts, and only wakes a thread from the same pool. Each thread services exclusively its own pool, so a transport that lands on a threadless pool is enqueued on sp_xprts and never picked up: the connection hangs indefinitely. Have svc_pool_for_cpu() skip pools that currently have no threads, falling back to the next populated pool. This trades NUMA locality for a guarantee that the work is actually serviced. sp_nrthreads is only updated under the service mutex; the lockless read here is a best-effort routing hint, so annotate it with data_race().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89551", "url": "https://ubuntu.com/security/CVE-2026-89551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow xdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by walking the tail, pages, and head iovecs. Each per-section step uses min_t() so it never removes more bytes than that section holds, but the final accounting at the fix_len label subtracts the total bytes actually consumed from buf->len without any clamp: fix_len: buf->len -= (len - trim); When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches xdr_buf_trim() in exactly that state: buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip; buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip); xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip); buf->len is a small wire-derived value while the iov_lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder. Fix by clamping the decrement so buf->len bottoms out at zero: buf->len -= min_t(unsigned int, buf->len, len - trim); On the normal path where the iov_lens sum to buf->len, (len - trim) is always <= buf->len and the result is identical to before. No callers change behavior outside the underflow case.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89554", "url": "https://ubuntu.com/security/CVE-2026-89554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection. Restore subflow_req->local_id from the cookie entry, as done for the other fields.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89555", "url": "https://ubuntu.com/security/CVE-2026-89555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: reload header after pskb_may_pull() mpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop when an MPLS route has multiple nexthops. While walking the MPLS label stack, the hash routine caches hdr for the current label. After finding the bottom-of-stack label, it calls pskb_may_pull() before reading the inner IP header. If an skb is constructed with the inner IP header in nonlinear data and insufficient tailroom in the linear head, pskb_may_pull() calls pskb_expand_head() to replace the skb head and free the old one. This leaves hdr pointing to freed memory. The IPv6 path can invalidate hdr again when it performs a second pull for the larger header. The issue was found through static analysis. A reproducer sending a legal Geneve packet through a bareudp/MPLS multipath setup triggered the same KASAN report in 2 of 2 unpatched runs: BUG: KASAN: slab-use-after-free in mpls_select_multipath Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23 Call Trace: mpls_select_multipath mpls_forward __netif_receive_skb_list_core netif_receive_skb_list_internal napi_complete_done gro_cell_poll __napi_poll net_rx_action Freed by task 23: kfree pskb_expand_head __pskb_pull_tail mpls_select_multipath Reload hdr from the current skb head after each successful pull before deriving the inner IPv4 or IPv6 header pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89557", "url": "https://ubuntu.com/security/CVE-2026-89557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: do overflow check for sb->bblog_shift in super_1_load() In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 } bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c. Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller. This may avoid unnecessary check, make the badblocks API code more simple and elegant.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89559", "url": "https://ubuntu.com/security/CVE-2026-89559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Prevent integer overflow in __nd_label_validate() The on-media namespace index field nslot is a u32 read from the DIMM label storage area. __nd_label_validate() bounds it against the config area size, but sizeof_namespace_label() returns unsigned, so the product nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before the comparison. A crafted nslot passes the bound and is then used as the loop trip count in nd_label_data_init(), whose memset() walks off the end of the config_size buffer: an out-of-bounds write. The field is not trusted -- it comes from the medium, or from userspace via ND_CMD_SET_CONFIG_DATA. Evaluate the product in 64-bit so the bound check is exact; conforming labels are unaffected. The check was safe when introduced by commit 4a826c83db4e (\"libnvdimm: namespace indices: read and validate\"): it multiplied by sizeof(struct nd_namespace_label), a size_t, so on a 64-bit build the product did not wrap. Commit 564e871aa66f (\"libnvdimm, label: add v1.2 nvdimm label definitions\") narrowed it to 32 bits when the label size became a runtime value read via sizeof_namespace_label().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93226", "url": "https://ubuntu.com/security/CVE-2026-93226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU iterator to dump route exceptions rt6_nh_dump_exceptions() uses hlist_for_each_entry() to iterate over RCU-protected exception lists. The caller holds rcu_read_lock(), but does not hold rt6_exception_lock, so rt6_insert_exception() can concurrently add an entry with hlist_add_head_rcu(). KCSAN reports this race (irrelevant details omitted): ================================================================== BUG: KCSAN: data-race in rt6_insert_exception / rt6_nh_dump_exceptions write (marked) to 0xffff8a7c44c59620 of 8 bytes by interrupt on cpu 5: rt6_insert_exception+0x3bb/0x760 __ip6_rt_update_pmtu+0x4fe/0x750 ip6_sk_update_pmtu+0x19a/0x3b0 udpv6_err+0x3ff/0x800 icmpv6_notify+0x1e1/0x440 icmpv6_rcv+0x8c0/0xab0 ip6_protocol_deliver_rcu+0x616/0x840 ip6_input_finish+0xb9/0x160 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff8a7c44c59620 of 8 bytes by task 549 on cpu 14: rt6_nh_dump_exceptions+0xb3/0x260 rt6_dump_route+0x53e/0x5f0 fib6_dump_node+0x6d/0xf0 fib6_walk_continue+0x290/0x2d0 fib6_dump_table+0x28d/0x360 inet6_dump_fib+0x37d/0x620 rtnl_dumpit+0x7b/0xd0 netlink_dump+0x3ae/0x7e0 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f 4 locks held by dumper/549: ... #1: (rcu_read_lock){....}-{1:3}, at: inet6_dump_fib+0x88/0x620 #2: (&tb->tb6_lock){+.-.}-{3:3}, at: fib6_dump_table+0x1e9/0x360 #3: (rcu_read_lock){....}-{1:3}, at: rt6_dump_route+0x483/0x5f0 value changed: 0xffff8a7c44e05700 -> 0xffff8a7c45d60100 Reported by Kernel Concurrency Sanitizer on: CPU: 14 UID: 0 PID: 549 Comm: dumper Not tainted 7.2.0-rc7-virtme #38 PREEMPT(lazy) ... Use hlist_for_each_entry_rcu() to safely iterate over the exception list.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89562", "url": "https://ubuntu.com/security/CVE-2026-89562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: fix hardware header length for NBMA tunnels ip6gre_tnl_link_config_route() accumulates the lower device's hardware header length into dev->hard_header_len whenever header_ops is set. This is incorrect for both users of header_ops. ip6gretap and ip6erspan have a fixed Ethernet hardware header length. For an NBMA ip6gre tunnel, ip6gre_header() creates only the GRE header, the optional FOU or GUE header, and the outer IPv6 header. The lower device header is headroom needed later, not part of the tunnel device's hardware header. Keep the lower device header in needed_headroom. Set hard_header_len to the tunnel header length only for ARPHRD_IP6GRE devices with header_ops, and leave the fixed Ethernet header length unchanged for tap and erspan devices.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89563", "url": "https://ubuntu.com/security/CVE-2026-89563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit() ip6_tnl_xmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skb_realloc_headroom(), copies skb->sk ownership, consumes the original skb, and then continues processing with the replacement skb kept only in its local variable. That is safe only if the helper cannot fail afterwards. But this helper still has post-reallocation error exits. collect_md tunnels reject non-NONE encap after the replacement, and ip6_tnl_encap() can also fail later. In those cases the helper returns an error to its callers while the caller still only has the original skb pointer. Both ip6_tnl_start_xmit() and the IPv6 GRE paths free the caller skb on error, so they can end up freeing an skb that ip6_tnl_xmit() already consumed. Use skb_cow_head() instead. It provides the required headroom and writability without privately replacing the caller-owned skb, so later error returns cannot leave callers with a stale pointer. The Ethernet users, ip6gretap and ip6erspan, clear IFF_TX_SKB_SHARING and already call skb_cow_head() before entering ip6_tnl_xmit(). They do not rely on the removed skb_shared() reallocation. This also makes the IPv6 tunnel path consistent with ip_tunnel_xmit().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89569", "url": "https://ubuntu.com/security/CVE-2026-89569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: serialize security confirmation handling rfcomm_security_cfm() looks up a session on session_list and then walks its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown uses rfcomm_mutex, krfcommd can close and free the same session and DLCs concurrently: hci_rx_work krfcommd ----------- --------- rfcomm_session_get() rfcomm_lock() rfcomm_session_close() rfcomm_dlc_unlink() rfcomm_session_del() kfree(s) rfcomm_unlock() walk s->dlcs The callback can then read a freed session list head and touch freed DLCs while updating their flags or timers. Serialize the session lookup and DLC traversal in rfcomm_security_cfm() with rfcomm_mutex. This matches the existing RFCOMM session lifetime rules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink() from tearing the objects down while the callback is using them. KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440 Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89 Workqueue: hci0 hci_rx_work Call Trace: rfcomm_security_cfm+0x41c/0x440 hci_encrypt_cfm+0x139/0x590 hci_encrypt_change_evt+0x37b/0xc40 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 69: rfcomm_session_add+0x9e/0x2f0 rfcomm_run+0x44b/0x41e0 Freed by task 69: kfree+0x131/0x3c0 rfcomm_session_del+0x188/0x220 rfcomm_run+0x1985/0x41e0", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89573", "url": "https://ubuntu.com/security/CVE-2026-89573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm array: reject an array block whose value size is not the caller's array_block_check() can only compare the header against itself, so a block with value_size 4 and max_entries 1018 is internally consistent and passes. dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and the roots for both live in the superblock. Point the mappings root at a hint block and __load_mappings() walks it through an info whose value size is 8, so element_at() strides 8 bytes over 4-byte entries and reaches offset 8160 of a 4096-byte block. get_ablock() and __shadow_ablock() are the two places that hold the block and the caller at once. Reject there when the two value sizes disagree. Arrays only ever read their own blocks, so this fires on crafted metadata only.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89575", "url": "https://ubuntu.com/security/CVE-2026-89575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm raid1: reserve space for NUL-terminator in build_constructor_string() Reserve space for the termination NUL after the maximum 20 decimal digits of a long long value to avoid buffer overflow in sprintf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89576", "url": "https://ubuntu.com/security/CVE-2026-89576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-era: fix shadowed superblock leak on take-snap failure metadata_take_snap() bumps the live superblock refcount and then dm_tm_shadow_block() allocates a new block for the metadata snapshot. If the subsequent dm_sm_inc_block() of writeset_tree_root or era_array_root fails, the function only unlocks the clone and returns. The newly allocated shadow block is never returned to the metadata space map, so each failed take-snap permanently leaks one metadata block. Free the clone with dm_sm_dec_block() on those error paths, matching the final step of metadata_drop_snap().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89582", "url": "https://ubuntu.com/security/CVE-2026-89582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix double free in bnx2x_init_firmware() error path bnx2x_init_firmware() frees bp->init_ops, bp->init_data and bp->init_ops_offsets in its error path without setting them to NULL. The cleanup function bnx2x_release_firmware() frees the same three pointers unconditionally, so if init_firmware fails and release_firmware is later called (e.g. from __bnx2x_remove or through the function state machine), all three are freed a second time. Set each pointer to NULL after kfree() in the error path so that the subsequent kfree(NULL) in bnx2x_release_firmware() is a safe no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89585", "url": "https://ubuntu.com/security/CVE-2026-89585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: auxdisplay: charlcd: cancel backlight work on registration failure With CONFIG_CHARLCD_BL_FLASH, charlcd_init() schedules bl_work before charlcd_register() calls misc_register(). If registration fails, the caller frees the charlcd object while delayed work still contains its address. Add charlcd_deinit() to cancel the delayed work and turn the backlight off. Use it for both registration rollback and normal unregistration.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89586", "url": "https://ubuntu.com/security/CVE-2026-89586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes ata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the UNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command. The TRIM descriptor is built by ata_format_dsm_trim_descr() into the 2048-byte ata_scsi_rbuf staging buffer, and the number of bytes copied is compared against the logical sector size by the caller: \tsize = ata_format_dsm_trim_descr(scmd, trmax, block, n_block); \tif (size != len)\t\t/* len == sdp->sector_size */ \t\tgoto invalid_param_len; ata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE (2048). On a device whose logical sector size exceeds that (e.g. a 4Kn device, where sector_size == 4096) the function can never return more than 2048, while the caller expects it to return sector_size. The comparison therefore always fails, so every TRIM is rejected with \"Parameter list length error\" and WARN_ON() splats on each attempt. TRIM / discard is thus completely broken on such devices. The descriptor was incorrectly sized from the logical sector size. A DSM TRIM payload is a list of 512-byte pages, each holding up to ATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical sector size. The Block Limits VPD page already advertises a single such page as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical blocks), so the block layer never sends a request that needs more than one page. Emit exactly one 512-byte page, independent of the logical sector size, and transfer only that page (COUNT == 1). For a 512-byte-sector device this is unchanged; devices with larger logical sectors now work instead of failing every TRIM.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89594", "url": "https://ubuntu.com/security/CVE-2026-89594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device The OMAP SSI driver uses a synthetic HSI controller device allocated via hsi_alloc_controller(), which does not go through the normal OF/platform device initialization path. As a result, the embedded struct device does not have a DMA mask initialized by default. After recent DMA API hardening changes, dma_map_sg() and related helpers now require a valid dma_mask to be present, otherwise the driver may crash or trigger warnings when attempting DMA mapping operations. Fix this by explicitly initializing the DMA mask for the SSI controller device and setting a 32-bit DMA mask, which matches the hardware capabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89596", "url": "https://ubuntu.com/security/CVE-2026-89596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix off-by-one when saving/restoring non-PCI config space nv_suspend() and nv_resume() walk the non-PCI configuration space with \tfor (i = 0; i <= np->register_size/sizeof(u32); i++) which runs one iteration too many. saved_config_space is declared as \tu32 saved_config_space[NV_PCI_REGSZ_MAX/4]; and NV_PCI_REGSZ_VER3 is equal to NV_PCI_REGSZ_MAX (0x604), so on a VER3 device register_size/sizeof(u32) is exactly the array length and the last iteration addresses one element past the end. The element it lands on is np->name_rx[0..3]: saved_config_space[] is followed immediately by char name_rx[IFNAMSIZ + 3], and char needs no padding. Nothing observable is corrupted by that, because nv_request_irq() rewrites name_rx with sprintf() before it is ever passed to request_irq(). The bug is the out-of-bounds access itself, which UBSAN reports and which CONFIG_UBSAN_TRAP=y turns into a trap that aborts the running kernel code, plus an MMIO read and, on resume, an MMIO writel() to base + 0x604, one dword past the range the driver mapped: \tnp->base = ioremap(addr, np->register_size); VER1 and VER2 devices stay inside the array, but they too get the stray read and the stray write one dword past their own window. Caught by UBSAN on an Apple Macmini3,1 (MCP79) during a deep S3 cycle. The splat below is trimmed: the build path in the file name, the CPU and taint lines, the Workqueue line, the \"?\" hint frames, and the frames below device_suspend are all cut. The kernel was tainted, with an out-of-tree nouveau and CPU_OUT_OF_SPEC; forcedeth itself was the stock module. UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c:6225:25 index 385 is out of range for type 'u32 [385]' Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... Both loops are hit. UBSAN reports each source location only once per module load (__ubsan_handle_out_of_bounds() calls suppress_report(), which does test_and_set_bit(REPORTED_BIT, ...) on the struct source_location), so the two splats land in the first S3 cycle after the module is loaded and later cycles are silent even though the access still runs off the end every time. In that first cycle line 6225 is reported from pci_pm_suspend and line 6240 from pci_pm_resume. The same off-by-one was fixed in nv_get_regs() by commit ba9aa134287f (\"forcedeth: fix buffer overflow\") in 2012; these two loops were missed. The suspend and resume side was reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix, but the patch was attached rather than sent inline and the thread ended there. Use < instead of <=, which saves and restores exactly register_size bytes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89597", "url": "https://ubuntu.com/security/CVE-2026-89597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: unregister connector callback on init failure uvesafb_init() registers the v86d connector callback before registering the platform driver. If platform_driver_register() fails, the function returns the error directly and leaves the connector callback registered. The later platform-device failure path already unregisters the callback. Add the same cleanup before the final return when platform-driver registration fails. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89599", "url": "https://ubuntu.com/security/CVE-2026-89599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: panel-dsi-cm: initialize lock before registering display dsicm_probe() registers the display before initializing ddata->lock. Once omapdss_register_display() publishes the display, another consumer can reach a dsicm callback that takes this mutex while it is still uninitialized. Initialize the mutex before registering the display so the published callbacks always see a valid lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89605", "url": "https://ubuntu.com/security/CVE-2026-89605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: release message context on send failure ecryptfs_send_message_locked() moves a message context from the free list to the allocated list before sending the request to the userspace daemon. If ecryptfs_send_miscdev() fails, the context is left on the allocated list and cannot be reused. Move it back to the free list on failure and clear the caller's pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89606", "url": "https://ubuntu.com/security/CVE-2026-89606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject too-small tag 70 packets ecryptfs_parse_tag_70_packet() subtracts fixed metadata fields from the parsed packet body size to derive the encrypted filename size. A malformed packet with a body smaller than those fixed fields can underflow that size calculation. Reject tag 70 packets before the subtraction unless the body contains the signature, cipher code, and at least one byte of encrypted filename data.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89607", "url": "https://ubuntu.com/security/CVE-2026-89607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key() sets decrypted_key_size = encrypted_key_size and performs two out-of-bounds writes: 1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into decrypted_key[64] via scatterlist, overflowing into the parent ecryptfs_auth_tok struct. 2. memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes into crypt_stat->key[64], corrupting root_iv, keysig_list, and mutexes in ecryptfs_crypt_stat. Only AES-192 (cipher code 0x08) enables this because it sets crypt_stat->key_size = 24 independently of encrypted_key_size, allowing crypto_skcipher_setkey() to succeed while encrypted_key_size exceeds ECRYPTFS_MAX_KEY_BYTES. The PKI decryption path (parse_tag_65_packet) already validates decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path omits this check. Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also protects the 512-byte encrypted_key[] buffer, so the former 512-byte check is removed as redundant. [tyhicks: Adjust the code comment to refer to macros representing the buffer sizes rather than mentioning the buffer size values since they may change in the future]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89608", "url": "https://ubuntu.com/security/CVE-2026-89608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: pass packet set buffer size to parser ecryptfs_parse_packet_set() receives a pointer into the file header, but it calculates the remaining packet buffer size from PAGE_SIZE - 8. For version 1 headers the packet set starts later in the header, so this can overstate the available buffer. Pass the actual packet set buffer length from the caller and calculate per-packet limits from the remaining bytes in that buffer. Recompute the remaining length after consuming a tag 3 packet before parsing the following tag 11 packet.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89609", "url": "https://ubuntu.com/security/CVE-2026-89609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: hold msg ctx list lock when cleaning daemon queue ecryptfs_exorcise_daemon() drops queued messages from a dying daemon without holding ecryptfs_msg_ctx_lists_mux, but ecryptfs_msg_ctx_alloc_to_free() requires that lock. Take the list lock while moving the queued contexts back to the free list to avoid racing with other global msg ctx list users.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89615", "url": "https://ubuntu.com/security/CVE-2026-89615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound page_lcns[] index by the log record The copy_lcns loop and the redo shorten loop index page_lcns[] at j + i, where i runs up to the log record's lcns_follow. That count is checked only against the record's own length, not the target entry, so check_dp_table() (which validates the entry's lcns_follow) does not cover it: the copy_lcns entry may even be freshly allocated after that check, and find_dp() bounds j but not i. A crafted record thus overflows page_lcns[] of an otherwise valid entry. Add dp_range_ok() and reject, before each loop, any record whose run does not fit the entry. These are the only two page_lcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded. [almaz.alexandrovich@paragon-software.com: original patch contained changes to the problem already handled, applied partly]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89616", "url": "https://ubuntu.com/security/CVE-2026-89616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame() ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target pages and then trusts decompress_lznt()'s return value: unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem, frame_size); if ((ssize_t)unc_size < 0) err = unc_size; else if (!unc_size || unc_size > frame_size) err = -EINVAL; decompress_lznt() stops as soon as the compressed stream is exhausted (e.g. a zero chunk header) and returns the number of bytes it actually wrote, which may be far less than frame_size. The bytes between unc_size and frame_size are never written. The only memset() that follows zeroes the region beyond i_valid; when the frame lies entirely within the file's valid size that memset() does not run, so the gap retains whatever was in the just-vmapped pages. All pages are then marked uptodate and returned to userspace, disclosing uninitialized (recently-freed) kernel page memory. A crafted compressed file whose stream decompresses to only a few bytes leaks the remainder of every frame on a plain read(2), which is enough to recover kernel pointers and defeat KASLR. Zero the [unc_size, frame_size) tail immediately after a successful LZNT decompress so the remainder reads back as zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89617", "url": "https://ubuntu.com/security/CVE-2026-89617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate dirty page table on log replay Each DIR_PAGE_ENTRY ends in a page_lcns[] array whose length is the on-disk lcns_follow field. check_rstbl() validates the table bookkeeping but never checks that this array fits in the entry, so a crafted lcns_follow lets the v0->v1 conversion memmove and later replay passes run off the entry. Add check_dp_table() to reject, right after check_rstbl(), any entry larger than its size claims via struct_size() (the same expression used to allocate these entries, so the check is overflow-safe by construction). All consumers can then trust lcns_follow as the real capacity. This covers every page_lcns[] access whose index is bounded by the entry itself (the conversion memmove, the HotFix store via find_dp(), and the self-bounded scan loops). Accesses whose index comes from the log record need a separate bound and are handled in a follow-up patch.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89621", "url": "https://ubuntu.com/security/CVE-2026-89621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: mcp2221: validate report size in mcp2221_raw_event() mcp2221_raw_event() never validates the size of incoming HID reports. In the MCP2221_I2C_GET_DATA path it trusts the device-supplied data[3] as the copy length without checking that 4 + data[3] bytes actually exist in the received report. A malicious or misbehaving USB device can send a short report with a large data[3], causing the memcpy to read past the valid report data in the HID transfer buffer and leak uninitialized kernel memory back to userspace through the I2C/SMBus read path. Add a minimum size check at entry and validate that the source range fits within the received report before the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89626", "url": "https://ubuntu.com/security/CVE-2026-89626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix field sysfs group cleanup on failure hid_sensor_custom_add_attributes() creates one sysfs group for each custom sensor field. If sysfs_create_group() fails after some groups have already been created, the function returns the error without removing the previously created groups. Add a local unwind path to remove the groups that were already created. With enable_sensor exposed only after the field attributes are ready, this path can free sensor_inst->fields without leaving enable_sensor able to access pointers into that array.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89627", "url": "https://ubuntu.com/security/CVE-2026-89627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: free buffered reports when destroying device roccat_report_event() duplicates each report with kmemdup() and stores the allocation in a circular-buffer slot. The allocation is released only when that slot is reused. The device destruction paths free struct roccat_device without releasing reports still stored in cbuf[]. This makes those allocations unreachable and leaks up to ROCCAT_CBUF_SIZE report buffers per device. Add a small destructor that frees every buffered report before freeing the device, and use it in both paths that can destroy a registered device.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89628", "url": "https://ubuntu.com/security/CVE-2026-89628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: picolcd: clamp eeprom debugfs read to bytes actually received picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte supplied by the device in its REPORT_EE_DATA reply -- clamped only to the caller's read() count: \tret = resp->raw_data[2]; \tif (ret > s) \t\tret = s; \tif (copy_to_user(u, resp->raw_data+3, ret)) It never checks resp->raw_size, the number of bytes picolcd_raw_event() actually copied into the 64-byte raw_data[] of the kmalloc'd struct picolcd_pending. A device (or a spoofed picoLCD) returning a length byte of 0xff, read with a count >= 255, makes copy_to_user() read past raw_data[] into adjacent slab memory and return it to userspace through the debugfs \"eeprom\" file: \tBUG: KASAN: slab-out-of-bounds in _copy_to_user \tRead of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd] The debug-dump path in the same file already validates the device length byte against the received size before trusting it; this read does not. The file is created S_IRUSR (root-only) and a crafted device is needed, so it is neither unprivileged- nor remotely-triggerable. Clamp the copy length to resp->raw_size - 3 (the payload actually received, minus the 3-byte header), floored at 0 for short replies.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89643", "url": "https://ubuntu.com/security/CVE-2026-89643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: avoid dropping live tree ref on fsnotify rule autoremove audit_del_rule() is used for both netlink deletion templates and internal fsnotify autoremove. The former passes a parsed template which owns a temporary tree reference; the latter passes the installed entry itself. The unconditional audit_put_tree() at the end of audit_del_rule() assumes the template case. For mixed AUDIT_DIR plus AUDIT_EXE rules, an fsnotify autoremove event therefore drops the installed rule's live tree reference. Repeating this across rules sharing the same tree can free the tree while another rule still references it, and a later autoremove dereferences the freed pathname while comparing rules. Move the temporary-tree put to audit_rule_change(), the caller that owns deletion templates. Keep it in the AUDIT_DEL_RULE cleanup so both successful deletion and -ENOENT still release the parser-owned tree. [PM: dropped unnecessary comment for line length reasons]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89649", "url": "https://ubuntu.com/security/CVE-2026-89649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound xattr value length in __build_xattrs() __build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare \"p += len\" and no ceph_decode_need() check that \"len\" bytes remain in the blob. For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob. The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space. Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89650", "url": "https://ubuntu.com/security/CVE-2026-89650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound num_export_targets array for mds info v2/v3 ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from each per-mds info record and advances the decode cursor by num_export_targets * sizeof(u32) without first checking that many bytes remain. The only upper-bound check that catches a runaway cursor (*p > info_end) is gated on info_v >= 4, because info_end is left NULL for info_v 2 and 3. When the monitor sends an MDS map whose per-mds info version is 2 or 3 with an oversized num_export_targets, the cursor moves past the message front buffer and the later export-targets loop calls the unchecked ceph_decode_32() on out-of-bounds memory. A kernel client processes CEPH_MSG_MDS_MAP from its monitor session (net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an on-path attacker on an unsigned/unencrypted messenger session, can therefore drive an out-of-bounds read in the client kernel; on x86_64 with KASAN it is reported as a slab-out-of-bounds read in ceph_mdsmap_decode(). The decoded values land in the internal info->export_targets[] array, so the consequence is a kernel out-of-bounds read, not an information leak to the attacker. Impact: a malicious or compromised Ceph monitor sending an MDS map with a per-mds info version of 2 or 3 and an oversized num_export_targets field triggers an out-of-bounds read in the CephFS client kernel. Add a ceph_decode_need() for the export-targets array before advancing the cursor, so the bound is enforced for every info_v >= 2, not only info_v >= 4. This mirrors the count-then-need idiom already used for m_data_pg_pools later in the same function. Compute the export-targets byte count with size_mul() and reuse that checked length when advancing the cursor, so the attacker-controlled num_export_targets multiplication fails closed on overflow rather than relying on the later kcalloc() guard.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89653", "url": "https://ubuntu.com/security/CVE-2026-89653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode MDSMap export_targets entries are monitor controlled. check_new_map() uses each entry as a bit number in a fixed stack bitmap, so a rank outside the protocol namespace can make set_bit() write past the end of the array. Reject ranks outside CEPH_MAX_MDS while decoding the map. Do not validate against possible_max_rank here because maps may legitimately reference ranks beyond a temporarily reduced max_mds.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89655", "url": "https://ubuntu.com/security/CVE-2026-89655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock list_for_each_entry() iterates ci->i_cap_flush_list but drops i_ceph_lock to send cap messages. During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid <= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock. When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next on freed memory. The race timeline: __kick_flushing_caps() handle_cap_flush_ack() ----------------------- ----------------------- holds i_ceph_lock <--- iterates to cf (tid=10) prepares FLUSH message drops i_ceph_lock <--- __send_cap() ── FLUSH(tid=10) \t MDS sends FLUSH_ACK(tid=10) ---> acquires i_ceph_lock cf->tid(10) <= flush_tid(10), detaches cf from i_cap_flush_list drops i_ceph_lock ceph_free_cap_flush(cf) <- frees it! acquires i_ceph_lock <--- for-loop advances: cf = list_next_entry(cf, i_list) -- UAF on freed cf->i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS may respond with FLUSH_ACK quickly enough that handle_cap_flush_ack() frees cf before __kick_flushing_caps can finish the iteration. Fix by converting to a manual while loop: save the next pointer under i_ceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89656", "url": "https://ubuntu.com/security/CVE-2026-89656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject buckets with mismatched CRUSH ids crush_decode() stores bucket data by array slot, and the mapper later derives the per-bucket workspace index from the decoded bucket id. A malformed map can therefore make one bucket reuse another bucket's workspace by encoding an id different from -1 - slot. For uniform buckets, the second replica selection expands the source bucket's permutation into that aliased workspace buffer. If the source bucket is larger than the aliased bucket, the write runs past the smaller permutation array and can escape the kvmalloc'd CRUSH workspace. KASAN reports a slab OOB write of 4 bytes in bucket_perm_choose(). Reject buckets whose encoded id does not match their array slot. Valid CRUSH maps already use the canonical negative id corresponding to the bucket slot, so this restores the invariant expected by work->work[-1 - in->id] without changing valid map behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89662", "url": "https://ubuntu.com/security/CVE-2026-89662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent lock owner use-after-free during client teardown __destroy_client() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on cl_ownerstr_hashtbl. client_has_state() does not count a bare owner, so DESTROY_CLIENTID can reach __destroy_client() with such owners present. __destroy_client() then walks the table, calling remove_blocked_locks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flc_owner. The per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently of client state. The two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks(). nfsd4_release_lockowner() holds a reference across the same call; __destroy_client() does not. Hold cl_lock across the walk, taking a reference and unhashing each owner, then drop it before remove_blocked_locks() and nfs4_put_stateowner(), which take blocked_locks_lock and cl_lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89663", "url": "https://ubuntu.com/security/CVE-2026-89663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: revoke copy-notify stateids before dropping their reference Copy-notify stateids live in the s2s_cp_stateids IDR and on their parent stid's sc_cp_list, pinned by a single membership reference. _free_cpntf_state_locked() only unlinks an entry once its refcount reaches zero, so any revoke path that runs while a concurrent find_cpntf_state()/manage_cpntf_state() holder has elevated cs_count drops the reference without unlinking, leaving the entry discoverable with its membership reference already consumed. A second revoke or a laundromat tick then frees it while the reader still holds the pointer -- a KASAN-detectable use-after-free at the reader's nfs4_put_cpntf_state(). This affected all three revoke paths: - The parent-stid drain (nfs4_free_cpntf_statelist()) repeatedly called _free_cpntf_state_locked() on the first list entry; a holder that had bumped cs_count made it return early, so the next iteration re-decremented and burned the holder's reference. - OFFLOAD_CANCEL (manage_cpntf_state()) and laundromat expiry likewise used _free_cpntf_state_locked() and could drop 2->1 without unlinking. Add revoke_cpntf_state_locked(), which unhashes the entry from the IDR and sc_cp_list first (deferring the final free to any holder), and use it from all three revoke paths. The drain now walks with list_for_each_entry_safe() and revokes each entry unconditionally, so it terminates in one pass per entry regardless of cs_count. The unhash is gated on !list_empty(&cps->cp_list); the idr_remove() gate matters because idr_alloc_cyclic() may have recycled the so_id by then. Keep _free_cpntf_state_locked() for the reference-holder put path only, where a concurrent revoke may already have unlinked the entry (its list_del_init() then a no-op).", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89665", "url": "https://ubuntu.com/security/CVE-2026-89665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE The NFSv2 sattr decoder converts the wire useconds to nanoseconds in svcxdr_decode_sattr(): \tiap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC; tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds value such as 4294968 wraps to tv_nsec == 704. The corruption therefore happens during decode, before any proc function can inspect the value, and a later range check on tv_nsec would see an in-range result and accept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply. NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return for a malformed time argument, and the check cannot move to the proc function the way the v3/v4 nsec range checks do. Guard the raw useconds before the multiplication and reject values greater than 1000000. useconds == 1000000 is kept: it is the Sun convention for \"set to the current server time\", and the in-tree Linux NFSv2 client emits it in both the atime and the mtime field for a plain touch / utimes(file, NULL) (see encode_sattr() and xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000 would turn that common operation into a hard decode failure for both SETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap on ILP32, so the Sun convention value passes through safely. Only genuinely out-of-range values (> 1000000) are rejected. The atime and mtime guards are therefore symmetric. The decoder only applied the Sun convention in the mtime block, which clears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a client puts 1000000 in the atime field but not in the mtime field, the atime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET set, so the bogus value reached the filesystem. Apply the convention in the atime block as well, clearing ATTR_ATIME_SET so the server uses its current time and ignores the value. Only ATTR_ATIME_SET is cleared there. The mtime block keeps its existing behavior, where 1000000 means \"set both atime and mtime to now\". [ cel: various tweaks, addenda, and clean-ups ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89669", "url": "https://ubuntu.com/security/CVE-2026-89669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: initialize copy-notify stateid before publishing it nfsd4_copy_notify() finished initializing the cpntf state after nfs4_alloc_init_cpntf_state() had already linked it into the s2s_cp_stateids IDR and the parent's sc_cp_list, with cs_count == 1 (the membership reference) and none held for the caller. A racing OFFLOAD_CANCEL (crafted cl_id == nn->s2s_cp_cl_id plus the guessable so_id) could reach manage_cpntf_state() and free the entry, turning the caller's subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid writes into use-after-free. The owning clientid was also only recorded after publication, so it could not gate an ownership check in that window. Record cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state() before nfs4_init_cp_state() publishes the entry, and return it with an extra reference. The caller reads the stateid under that reference and drops it with nfs4_put_cpntf_state(); on a late error the laundromat reaps the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89673", "url": "https://ubuntu.com/security/CVE-2026-89673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo nfsd4_ff_encode_getdeviceinfo() computes the da_addr_body reservation as 16 + netid_len + addr_len, but the subsequent xdr_encode_opaque() calls emit 8 + round_up(netid_len, 4) + round_up(addr_len, 4) bytes. The mismatch means the declared da_addr_body length exceeds the actual encoded data by 2-8 bytes on every flexfile GETDEVICEINFO reply, leaking stale reply-page content to the client and mis-aligning the subsequent version list decode. Use xdr_align_size() for each string length to match what xdr_encode_opaque() actually writes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89674", "url": "https://ubuntu.com/security/CVE-2026-89674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client: - fh_len doesn't account for XDR padding on the file handle data - uid and gid lengths use \"8 + len\" but xdr_encode_opaque() actually writes \"4 + xdr_align_size(len)\" bytes - ds_len omits the flags and stats_collect_hint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client. Fix this by breaking out every encoded field explicitly in the ds_len calculation, using xdr_align_size() for all variable-length opaque fields, and correcting the header constants.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89684", "url": "https://ubuntu.com/security/CVE-2026-89684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix cpntf publish race in nfs4_init_cp_state nfs4_alloc_init_cpntf_state() published the new cpntf entry into the s2s_cp_stateids IDR (with cs_type set) in one s2s_cp_lock section, then took the lock again to list_add() it onto p_stid->sc_cp_list. In the gap the entry is reachable by so_id but cp_list is still {NULL,NULL} from kzalloc. A racing OFFLOAD_CANCEL (so_id is echoed to the client as cnr_stateid, so any NFSv4.2 client can drive it) reaches manage_cpntf_state() -> _free_cpntf_state_locked() and does list_del() on the zeroed list_head, oopsing the server. Fold the cs_type assignment and the list_add() into the same critical section as idr_alloc_cyclic(), so a concurrent lookup either misses the entry or sees a fully linked cp_list. INIT_LIST_HEAD() the entry after allocation and switch _free_cpntf_state_locked() to list_del_init() so a stale unlink is a no-op. nfs4_init_copy_state() passes NULL p_stid and skips the list_add, preserving NFS4_COPY_STID semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89694", "url": "https://ubuntu.com/security/CVE-2026-89694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: check client ownership when cancelling a copy-notify stateid On the OFFLOAD_CANCEL path (clp != NULL), manage_cpntf_state() freed the target cpntf state without checking ownership. The lookup key st->si_opaque.so_id is allocated cyclically (guessable) and the embedded clientid is the fixed per-net nn->s2s_cp_cl_id, so any authenticated NFSv4.2 client could cancel and free another client's copy-notify stateid. Compare the creating clientid recorded in state->cp_p_clid against the requesting client's cl_clientid and return nfserr_bad_stateid on a mismatch instead of freeing the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89696", "url": "https://ubuntu.com/security/CVE-2026-89696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref When CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return success with fh_dentry and fh_export both NULL if fh_verify() returns nfserr_stale and putfh->no_verify is true. The NFSD4_FH_FOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserr_nofilehandle check -- it does not prevent subsequent ops from running with a NULL fh_dentry. A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes check_if_stalefh_allowed() to set no_verify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fh_want_write() which dereferences fh_export->ex_path.mnt without calling fh_verify() first, causing a NULL pointer dereference in the nfsd kthread. Fix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set and fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow) and ops with ALLOWED_WITHOUT_FH (which don't need a resolved filehandle) may proceed. All other ops receive nfserr_stale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERR_STALE returned at that point.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89697", "url": "https://ubuntu.com/security/CVE-2026-89697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: add fh_want_write() for early-verified SETATTR in nfsd_proc_setattr() The BOTH_TIME_SET branch calls fh_verify() early so setattr_prepare() can inspect the dentry. This causes nfsd_setattr() to skip fh_want_write(), so notify_change() runs without a mount write reference. Add the missing fh_want_write() call after the early fh_verify().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89699", "url": "https://ubuntu.com/security/CVE-2026-89699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: validate symlink target length in NFSv4 CREATE nfsd4_decode_create() accepts an unbounded cr_datalen from the wire for NF4LNK symlink targets, allowing a client to force a kmalloc of up to the maximum RPC payload size (several MiB) per COMPOUND op that persists until compound teardown. The VFS rejects oversized targets with ENAMETOOLONG, but the allocation has already occurred. Reject cr_datalen == 0 early with nfserr_inval and cr_datalen greater than NFS4_MAXPATHLEN (PATH_MAX) with nfserr_nametoolong to bound the allocation.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89704", "url": "https://ubuntu.com/security/CVE-2026-89704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: sample writeback error cursor before async COPY loop _nfsd_copy_file_range() samples dst->f_wb_err into \"since\" after the copy loop, then uses it to detect writeback errors via filemap_check_wb_err() once vfs_fsync_range() returns. Because the nfsd_file cache reuses a single struct file across requests targeting the same inode, a concurrent COMMIT or stable WRITE on dst advances dst->f_wb_err to the current mapping->wb_err via file_check_and_advance_wb_err() during its own vfs_fsync_range(). If that advancement lands between the writeback error appearing in mapping->wb_err and the COPY worker sampling \"since\", the worker captures the already-advanced cursor, errseq_check() sees cur == since and returns zero, and NFSD4_COPY_F_COMMITTED is set even though writeback failed. CB_OFFLOAD then encodes wr_stable_how = FILE_SYNC4, the client treats the copied data as durable, and the failure becomes silent data loss. Sample since once at the start of the function. The cursor then reflects state in effect before this COPY issues any writes, and filemap_check_wb_err() detects any error that occurs during the copy regardless of which thread first observes it. This matches the pattern used by nfsd_vfs_write() and nfsd4_clone_file_range().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89706", "url": "https://ubuntu.com/security/CVE-2026-89706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: Reset write verifier when async COPY writeback fails Async COPY captures nn->writeverf at request time and reports it to the client via CB_OFFLOAD after the worker kthread completes. When the post-copy vfs_fsync_range() or filemap_check_wb_err() in _nfsd_copy_file_range() reports an error, the worker correctly leaves NFSD4_COPY_F_COMMITTED clear so that CB_OFFLOAD encodes wr_stable_how as NFS_UNSTABLE, but the server's write verifier is not rotated. A client that receives NFS_UNSTABLE in CB_OFFLOAD follows up with COMMIT to make the copied data durable. With the verifier unchanged, COMMIT returns the same value the client just received via CB_OFFLOAD, and the client concludes the copy is durable -- silently dropping the data whose writeback in fact failed. This violates the UNSTABLE+COMMIT durability contract (RFC 7862 section 15.1, RFC 8881 section 18.32) and matches the bug just fixed in nfsd_vfs_write() and nfsd_commit(). Rotate nn->writeverf at the writeback-failure site. The async COPY worker has no svc_rqst, so commit_reset_write_verifier() is not available here; calling nfsd_reset_write_verifier() directly mirrors the trace-less reset already used by nfsd_file_check_write_error() for the same purpose. Filter out -EAGAIN and -ESTALE, matching commit_reset_write_verifier(), since neither indicates a durable-storage failure.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89710", "url": "https://ubuntu.com/security/CVE-2026-89710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget path When the server returns a new layout stateid while a valid one is still held, pnfs_layout_process() calls pnfs_mark_matching_lsegs_return() on the on-stack free_me list and jumps to out_forget. Segments whose reference count drops to zero are unlinked from lo->plh_segs and moved to free_me by mark_lseg_invalid(); for an idle cached segment the layout header holds the only reference, so this happens on the first decrement. out_forget never drains free_me -- only the success path calls pnfs_free_lseg_list(). Commit 814b84971388 (\"pNFS/NFSv4: Fix a layout segment leak in pnfs_layout_process()\") added the drain; commit 08bd8dbe8882 (\"pNFS/NFSv4: Try to return invalid layout in pnfs_layout_process()\") removed it while switching the destination to lo->plh_return_segs, which is drained elsewhere. Commit fb700ef02676 (\"NFSv4.1: Simplify layout return in pnfs_layout_process()\") switched the destination back to free_me without restoring the drain. Restore the pnfs_free_lseg_list() call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89711", "url": "https://ubuntu.com/security/CVE-2026-89711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check The header for commit e75b23f9e323 (\"nfsd: check d_can_lookup in fh_verify of directories\") details the assumption that justified adding the WARN_ON_ONCE to nfsd_mode_check(), that assumption is invalid (in the case of NFS reexport). When NFSD exports an NFS filesystem it is very possible for nfsd_mode_check() to encounter a @dentry that doesn't have i_op->lookup (see nfs_fhget()'s NFS_ATTR_FATTR_MOUNTPOINT and NFS_ATTR_FATTR_V4_REFERRAL handling, and d_flags_for_inode()). So remove nfsd_mode_check()'s WARN_ON_ONCE(). The nfserr_notdir return on that branch must stay. It guards the subsequent lookup_one_unlocked() -> __lookup_slow() path, which calls inode->i_op->lookup() with no NULL check, so returning nfserr_notdir is what keeps a client LOOKUP into such a @dentry from dereferencing a NULL method pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89712", "url": "https://ubuntu.com/security/CVE-2026-89712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock nfsd4_ssc_expire_umount() walks nn->nfsd_ssc_mount_list with list_for_each_entry_safe(ni, tmp, ...). For each expired entry it sets nsui_busy = true, drops nfsd_ssc_lock to run mntput() on the source vfsmount, then reacquires the lock to list_del + kfree the entry and continue iterating via the macro's saved tmp pointer. The nsui_busy flag protects the current ni from concurrent nfsd4_ssc_setup_dul() finders during the lock-drop window, but it does not pin tmp. Another nfsd RPC thread that fails its source- server mount and reaches nfsd4_ssc_cancel_dul() will, during that same window, take nfsd_ssc_lock, list_del + kfree its own ssc_umount item, and release the lock. If that item is the saved tmp of the expire walk, the next iteration dereferences a freed nfsd4_ssc_umount_item. Restart the walk from the head after the mntput() unlock window so no saved next pointer survives the lock-drop. The list is bounded by the number of active inter-server source mounts (typically small) and the expire delayed-work runs periodically rather than per-IO, so the restart is cheap.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89720", "url": "https://ubuntu.com/security/CVE-2026-89720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: fix out-of-bounds read in signature length check ubifs_sb_verify_signature() bounds the on-disk ubifs_sig_node->len field before handing the signature payload to verify_pkcs7_signature(), but the check has the wrong sign: \tif (le32_to_cpu(signode->len) > snod->len + sizeof(struct ubifs_sig_node)) The signature bytes start sizeof(struct ubifs_sig_node) (UBIFS_SIG_NODE_SZ, 64 bytes) into the node, so the payload is at most \tsnod->len - sizeof(struct ubifs_sig_node) bytes long. Adding the header size instead of subtracting it accepts a declared length up to 2 * UBIFS_SIG_NODE_SZ larger than the node actually holds -- past the end of c->sbuf, which is vmalloc(c->leb_size). verify_pkcs7_signature() -> pkcs7_parse_message() -> asn1_ber_decoder() is then handed that inflated length and reads beyond the allocation while walking the DER headers. The node length comes straight from the mounted image, so a crafted signed UBIFS image reaches this via ubifs_read_superblock() before the signature is cryptographically checked. snod->len is guaranteed to be >= UBIFS_SIG_NODE_SZ by the node scanner (c->ranges[UBIFS_SIG_NODE].min_len == UBIFS_SIG_NODE_SZ), so the corrected subtraction cannot underflow. Legitimately signed images are unaffected: a correct superblock never declares a signature longer than the node it is embedded in.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93213", "url": "https://ubuntu.com/security/CVE-2026-93213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: of: fix out-of-bounds read in of_alias_scan() stem parser The stem parser tests isdigit(*(end - 1)) before checking end > start and so reads one byte before the property name when the name is empty or all digits. Check the bound first.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89723", "url": "https://ubuntu.com/security/CVE-2026-89723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after truncation Shuangpeng Bai reported that KASAN detected a slab-out-of-bounds error in nilfs_direct_propagate() during testing. Analysis revealed that after truncating a file, a node block immediately below the B-tree root was not deleted. Instead, it remained in the B-tree node cache in a dirty state. The log writer subsequently detected this block and incorrectly invoked nilfs_direct_propagate() on it, which is designed to handle only data blocks in direct mapping. B-tree nodes in the cache are managed by virtual block numbers, and their logical keys typically exceed the range expected by direct mapping. Consequently, processing such a node as a direct mapping entry triggers a slab-out-of-bounds access. The root cause is that when a B-tree mapping collapses into a direct mapping during truncation, an intermediate node block pointed to by the root node is left behind as garbage instead of being explicitly deleted. This resolves the issue by adding a nilfs_btree_discard() operation to delete the remaining intermediate node block during the conversion. A 'deform' flag is added to the bop_delete interface to explicitly signal that the deletion is part of a mapping transformation. This allows the B-tree mapping implementation to perform the necessary cleanup and discarding of the residual node structure that would be otherwise be left orphaned after the transition.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89724", "url": "https://ubuntu.com/security/CVE-2026-89724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vicodec: fix out-of-bounds write in FWHT encoder vidioc_s_fmt_vid_out() sizes the encoder CAPTURE buffer from the compressed descriptor pixfmt_fwht, whose sizeimage_mult is 3: coded_w * coded_h * 3 + sizeof(struct fwht_cframe_hdr). fwht_encode_frame() encodes one plane per component, and an incompressible plane takes the FWHT_FRAME_UNENCODED path in encode_plane(), copying the plane verbatim. For a 4-component pixel format all four planes are full resolution (width_div == height_div == 1), so a frame that forces every plane through the unencoded fallback writes sizeof(struct fwht_cframe_hdr) + 4 * coded_w * coded_h bytes, overrunning the plane by coded_w * coded_h, which can result in corruption of adjacent kernel heap memory. Bump pixfmt_fwht.sizeimage_mult from 3 to 4, matching the largest components_num among the supported raw formats, so the capture buffer is always large enough for the unencoded fallback.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89725", "url": "https://ubuntu.com/security/CVE-2026-89725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: stm32: prevent out-of-bounds write on RX overflow stm32_rx_done() appends each received CEC byte to rx_msg.msg[] using rx_msg.len as the write index, incrementing it on every RXBR (receive-byte-ready) interrupt without checking it against the buffer size: \tcec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF; rx_msg.msg[] is a fixed CEC_MAX_MSG_SIZE (16) byte array in struct cec_msg, and rx_msg.len is only reset on RXACKE/RXOVR or after a completed message (RXEND). The number of bytes received before RXEND is decided by the remote CEC device (it sets EOM), not by the driver. A peer that keeps sending bytes without ending the message drives RXBR repeatedly, pushing rx_msg.len past 16 and writing peer-controlled bytes out of bounds into the surrounding memory. This is reachable in normal operation once the driver has probed and receiving is enabled, from the IRQ thread, without any local privilege. The length check in the CEC core runs on the consumer side, after the byte has been stored, so it does not prevent the overflow. Bound the index in the driver before the store, as the other platform CEC drivers already do (e.g. tegra_cec), dropping the excess bytes of an overlong frame. Found by static analysis tool CodeQL.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89726", "url": "https://ubuntu.com/security/CVE-2026-89726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen() Patch series \"lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()\", v2. This series fixes an off-by-one out-of-bounds read in ucs2_strnlen(). The first patch is the real fix, the second patch comes as a bonus and fixes the code indentation. This patch (of 2): ucs2_strnlen() checks the current character before checking whether the caller-provided maximum length has been reached. If the input is not NUL-terminated within that bound, the loop can read one ucs2_char_t past the limit. Test the length before dereferencing to prevent an off-by-one out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89729", "url": "https://ubuntu.com/security/CVE-2026-89729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature sensor_hub_get_feature() clamps its return value to the caller's buffer size, but the copy loop still copies field->report_size / 8 bytes for each report value. A malicious HID descriptor can advertise a large feature field size while an IIO caller supplies a small stack buffer, such as a single s32, causing an out-of-bounds write. HID core stores parsed report values in __s32 slots and clamps extracted values to 32 bits. Reject feature fields that require more than one slot per value, guard the total byte count calculation, and clamp each per-value copy to the remaining caller buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89730", "url": "https://ubuntu.com/security/CVE-2026-89730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write The trailing byte path in altera_cvp_send_block() dereferences a u32 pointer even when only 1-3 bytes remain in the input buffer. If the buffer ends at a page or scatterlist boundary, this can read past the valid image data and fault. Copy the remaining bytes into a zero-initialized u32 before writing the final word so only valid bytes are read from the input buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89732", "url": "https://ubuntu.com/security/CVE-2026-89732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Prevent deadlock during ep0 read loop Currently, ffs_ep0_read() holds ffs->mutex when it prepares to go to sleep waiting for an event. When no setup events are pending, it calls wait_event_interruptible_exclusive_locked_irq() with the mutex still held. The wait macro deliberately drops the waitqueue spinlock before sleeping but does not drop the mutex. If a userspace daemon is polling ep0 via read() and the gadget is asynchronously torn down via configfs (e.g., echo \"\" > UDC), a deadlock can occur: 1. The configfs teardown calls functionfs_unbind(), which queues a FUNCTIONFS_UNBIND event. 2. The daemon wakes up, consumes the event, and drops the mutex. 3. However, if the daemon loops and immediately issues another read() before exiting, it reacquires ffs->mutex and again goes into an interruptible sleep. 4. Meanwhile, functionfs_unbind() continues execution and attempts to acquire ffs->mutex to tear down ep0req. 5. The kernel deadlocks because the configfs thread is stuck in an uninterruptible sleep waiting for the mutex, while the userspace daemon is in an interruptible sleep holding the mutex forever because no more events will arrive. To fix this, we drop both the waitqueue spinlock and ffs->mutex before going to sleep, and use wait_event_interruptible_exclusive() instead. Upon waking up, we jump back to the `retry` label to safely reacquire the mutex and re-evaluate the state machine. By not sleeping with ffs->mutex held, we natively decouple gadget teardowns (which require the mutex) from userspace polling.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89733", "url": "https://ubuntu.com/security/CVE-2026-89733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and uvc_function_unbind() In uvc_function_bind() error path, we use usb_ep_free_request which uses uvc->control_req but does not set it to NULL afterwards. Thus, uvc->control_req is a dangling pointer causing a UAF. Also we do not set the uvc->control_buf pointer to NULL after freeing it, which is another dangling pointer. Fix it by setting uvc->control_req to NULL after we run usb_ep_free_request() and uvc->control_buf to NULL after kfree. Do the same for uvc_function_unbind().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93214", "url": "https://ubuntu.com/security/CVE-2026-93214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: fix deadlock in usbg_make_tpg() usbg_make_tpg() held dep_lock while calling configfs_depend_item_unlocked(), which acquires the configfs root inode lock when operating across subsystems. This creates a circular lock dependency with configfs_rmdir(): dep_lock -> configfs root inode lock -> su_mutex -> dep_lock In usbg_make_tpg(), dep_lock only serialized the read of opts->ready, which is a monotonic flag that transitions from false to true exactly once (in tcm_set_name()) and never reverts. Remove dep_lock from usbg_make_tpg() entirely and use READ_ONCE/WRITE_ONCE to access opts->ready locklessly instead.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89736", "url": "https://ubuntu.com/security/CVE-2026-89736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: Fix use-after-free on sound card disconnect g_audio_cleanup() invokes snd_card_free_when_closed() to initiate sound card teardown and immediately frees the underlying struct snd_uac_chip context. However, snd_card_free_when_closed() returns asynchronously while ALSA control elements (kctls) remain open in userspace. When userspace control applications access or close these open file descriptors, kctl callbacks attempt to dereference kctl->private_data pointing to &uac->c_prm or &uac->p_prm within the freed uac structure, resulting in a use-after-free (UAF) memory corruption. Fix this issue by deferring the destruction of struct snd_uac_chip until all references to the ALSA sound card are released. Register a custom card->private_free callback (u_audio_card_free) during g_audio_setup() that frees uac and its associated playback/capture request and ring buffers only when the sound card reference count drops to zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89741", "url": "https://ubuntu.com/security/CVE-2026-89741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"media: v4l2-dev: fix error handling in __video_register_device()\" This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a. The intentions of that patch were good, but it doesn't work. The idea is that if device_register fails, you have to do a put_device to let the ref counter release resources. However, the V4L2 API says that if video_register_device() fails, then you have to call video_device_release(), which kfree()s the video_device struct. But the put_device() will already have freed the struct, so you end up in a double-free scenario. There is not really a good way of fixing this without breaking video_register_device() into two parts, one that initializes everything, and one that does the actual device_register, and then converting all V4L2 drivers to this new model. That is a massive job, and it is very unlikely that device_register will fail. So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89742", "url": "https://ubuntu.com/security/CVE-2026-89742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: mport_cdev: fix use-after-free in dma_req_free() dma_req_free() acquires buf_mutex through req->map, drops the mapping reference with kref_put(), and then dereferences req->map again to unlock the mutex. If kref_put() drops the last reference, mport_release_mapping() frees the mapping, and the subsequent mutex_unlock() dereferences a freed object. This is a use-after-free. Fix this by caching map and md before kref_put(), clearing req->map while holding buf_mutex, and using the cached md for mutex unlocking. The bug is reachable from userspace via the RapidIO mport character device interface.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89749", "url": "https://ubuntu.com/security/CVE-2026-89749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix crash passing ERR_PTR to kthread_stop() event_test_stuff() calls kthread_run() and unconditionally passes the returned task_struct pointer to kthread_stop(). kthread_run() returns an error pointer such as ERR_PTR(-ENOMEM) when kthread creation fails, for example under memory pressure during the boot-time event self-test. kthread_stop() then dereferences the invalid pointer, crashing the kernel. Check the result of kthread_run() before passing it to kthread_stop(). Use WARN_ON() so that a failure to create the self-test thread does not go unnoticed, matching the ring-buffer self-test fix in commit 91542863abad (\"ring-buffer: Fix crash passing ERR_PTR to kthread_stop()\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89752", "url": "https://ubuntu.com/security/CVE-2026-89752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: memcg: stop reclaim when a limit update is superseded kernfs serializes file operations only per open file, so separate open files can update the same memory.high or memory.max file concurrently. Both handlers store the new limit before synchronous reclaim, but continue to use the writer's local target in the reclaim loop. If another writer raises or removes the limit, the first writer can continue reclaiming toward a stale target. For memory.max, this can leave the writer looping indefinitely once reclaim retries are exhausted. The OOM path sees sufficient margin under the current limit and returns true without killing, while the writer still compares usage against its stale target and records another OOM event. Check the current limit at the start of each reclaim iteration and stop if it no longer matches the writer's target. Reproducer: Populate a cgroup with anonymous memory and disable swapping. Lower memory.max from one open file, then restore it to \"max\" through another open file after the new limit becomes visible. Without the patch, the first writer remains blocked and repeatedly increments the OOM event counter. With the patch, it returns normally. This was not motivated by a reported production workload. We found it through automated randomized testing for our cgroup observability work and reduced it to the reproducer above.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89753", "url": "https://ubuntu.com/security/CVE-2026-89753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: \t0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 \ttask:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89765", "url": "https://ubuntu.com/security/CVE-2026-89765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers/itimer: Zero-init old itimerval before copy to userspace On native sparc64, struct __kernel_old_timeval contains a four-byte hole after tv_usec because tv_sec is 64-bit while __kernel_suseconds_t is 32-bit. put_itimerval() fills only the named fields in a stack-allocated __kernel_old_itimerval and copies the entire object to userspace, so getitimer() can expose the two padding holes. Zero-initialize the aggregate before assigning the fields so implicit padding is deterministic before it crosses the user/kernel boundary.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93219", "url": "https://ubuntu.com/security/CVE-2026-93219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/timer-sun4i: Advertise a real minimum delta sun4i_clkevt_next_event() compensates for the timer stop/start synchronization delay by programming evt - TIMER_SYNC_TICKS into the hardware interval register. The clockevent device currently advertises TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed to call set_next_event() with evt == TIMER_SYNC_TICKS. That programs a zero-tick interval. With oneshot/highres/nohz timer operation this can leave the next event stuck, which was observed as a boot hang on Allwinner D1 after the clockevents core started reusing forced minimum-delta events. Advertise one extra tick instead, so the smallest event accepted by the core still programs at least one hardware tick after the synchronization compensation.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-23191", "url": "https://ubuntu.com/security/CVE-2026-23191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix racy access at PCM trigger The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers. For addressing the UAF, this patch changes two things: - It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.", "cve_priority": "high", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-80824", "url": "https://ubuntu.com/security/CVE-2026-80824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbfs: fix use-after-free of usb_device in usbdev_release() usbdev_release() drops its reference to the struct usb_device before draining the list of completed async URBs, but that drain path reads back through the same object: free_async() calls dec_usb_memory_use_count() for any URB whose buffer came from the usbfs mmap() region, and its first statement is bus_to_hcd(ps->dev->bus). After a disconnect the usbfs reference can be the last one, in which case usb_put_dev() frees the device and the subsequent loop reads offset 80 of freed memory and uses the result as a struct usb_hcd *, which hcd_buffer_free_pages() then dereferences. This is reachable by an unprivileged process that has read/write access to a /dev/bus/usb node: mmap() the fd, submit one URB with a buffer inside the mapping, wait for the device to be unplugged, then munmap() and close(). It reproduces on every attempt rather than being a race, because a live MAP_SHARED vma holds a reference on the struct file, so usbdev_release() cannot run until the last vma is gone and the freeing branch of dec_usb_memory_use_count() is always taken. BUG: KASAN: slab-use-after-free in dec_usb_memory_use_count+0x3ae/0x410 Read of size 8 at addr ffff8880122ee050 by task poc/769 CPU: 1 UID: 1000 PID: 769 Comm: poc Tainted: G B 6.12.94 #3 Call Trace: dec_usb_memory_use_count+0x3ae/0x410 free_async+0x2aa/0x4f0 usbdev_release+0x375/0x460 __fput+0x3ea/0xb50 __x64_sys_close+0x86/0x100 Allocated by task 11: usb_alloc_dev+0x55/0xd90 hub_event+0x2524/0x43d0 Freed by task 769: kfree+0x121/0x360 device_release+0xd2/0x280 usb_put_dev+0x23/0x30 usbdev_release+0x2d8/0x460 Release the device reference after the drain loop instead. Nothing between the two points requires it to have been dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80826", "url": "https://ubuntu.com/security/CVE-2026-80826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: c67x00: fix use-after-free in c67x00_add_iso_urb() When TD creation fails for the last packet of an isochronous URB, c67x00_add_iso_urb() gives the URB back before updating the endpoint scheduling state. c67x00_giveback_urb() frees the URB private data, and the completion callback may release the final URB reference. The following accesses to urbp->ep_data, urb->interval, and urbp->cnt can therefore use freed memory. Update next_frame and cnt before giving back the failed final packet, making the giveback the last operation that uses the URB and its private data.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80827", "url": "https://ubuntu.com/security/CVE-2026-80827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: option: fix slab OOB read in interrupt URB callback The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. [ johan: use dev_err(); split signals declaration and initialisation ]", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80828", "url": "https://ubuntu.com/security/CVE-2026-80828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Complete cleanup after system-resume errors A failed system resume can leave the card unusable until reboot. usb_audio_resume() jumps to err_out when snd_usb_pcm_resume() or snd_usb_mixer_resume() fails. The error path skips the out: block, which restores D0 and decrements chip->num_suspended_intf. The card stays in SNDRV_CTL_POWER_D3hot, so later control access blocks in snd_power_ref_and_wait(). USB core logs an interface resume callback error. It does not retry that callback, so a later callback cannot complete the skipped cleanup. usb_audio_suspend() increments num_suspended_intf before returning success. A system-resume callback must consume the system-suspend count even if a component resume fails. Otherwise, the stranded count skews later suspend and resume cycles. Do not apply this cleanup to runtime-resume errors. Runtime PM can retry -EAGAIN or -EBUSY without another suspend callback. The count must continue to describe that suspended interface. Other runtime-resume errors latch runtime_error in the PM core and do not cause an immediate callback retry. Both parts of the system-resume error path are longstanding. Commit 88a8516a2128a (\"ALSA: usbaudio: implement USB autosuspend\") introduced err_out past the D0 restore. Commit 862b2509d157c (\"ALSA: usb-audio: Fix inconsistent card PM state after resume\") later moved num_suspended_intf-- into the out: block. The error path now skips both operations. No third-party code is needed to reach the error path. snd_usb_mixer_resume() ends in snd_usb_mixer_activate(), which returns the result of usb_submit_urb() for devices that have a mixer status URB. Its mixer->private_resume hook can also fail through scarlett2_init_notify(). snd_usb_pcm_resume() issues a SET_CUR request to a UAC3 power domain. It can return -EPIPE or -EIO when the device stalls the request. Route a component error through out: only when system_suspend is nonzero. Continue to return runtime-resume errors through err_out. Later component resume stages remain skipped. The original error still reaches USB core. A later transfer can fail if the device did not recover. I reproduced the system-resume failure on an Audient iD14 MkI with an out-of-tree diagnostic mixer resume hook. An injected -EIO on the unpatched core left control readers in uninterruptible sleep in snd_power_ref_and_wait() until a reboot. With this patch, the same failure restored control access. A second system suspend and resume also succeeded after I disabled fault injection.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80829", "url": "https://ubuntu.com/security/CVE-2026-80829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output() snd_usbmidi_novation_output() lays out a two-byte header at transfer_buffer[0..1] and passes &transfer_buffer[2] together with a length of ep->max_transfer - 2 to snd_rawmidi_transmit(): \tcount = snd_rawmidi_transmit(ep->ports[0].substream, \t\t\t\t &transfer_buffer[2], \t\t\t\t ep->max_transfer - 2); ep->max_transfer comes from the output endpoint's wMaxPacketSize via usb_maxpacket(). A malformed or malicious device can advertise a bulk OUT endpoint with a wMaxPacketSize of 1 - the USB core only clamps this value downwards - so ep->max_transfer becomes 1 and the count argument becomes -1. snd_rawmidi_transmit() passes the negative count on to __snd_rawmidi_transmit_peek(), where \"if (count1 > count) count1 = count\" leaves count1 negative; get_aligned_size() keeps it negative for a byte-stream substream, so the following memcpy(buffer, ..., count1) runs with a (size_t)-1 length and writes far past the transfer buffer, which was allocated with usb_alloc_coherent(ep->max_transfer). This is the same class of bug that was fixed for snd_usbmidi_akai_output() in commit 0970274613fb (\"ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()\"); the novation output routine was left unguarded. Bail out when the endpoint cannot hold the two-byte header plus at least one payload byte.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80830", "url": "https://ubuntu.com/security/CVE-2026-80830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: Add lock to usb_wakeup_notification() Add a spin lock to usb_wakeup notification to prevent a race condition with dereferencing freed memory. This could be hit by the xHCI driver as it calls this function from an IRQ and could race with the hub_disconnect() function, which properly grabs this lock to protect the state of the device.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80921", "url": "https://ubuntu.com/security/CVE-2026-80921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: zero stale crypto bits When shadowing crypto access bits from a format0 apcb (crycb 0 or 1), the bits 64..255 are unchanged from whatever is in the vsie page in the crycb and thus in the apcb. This gives a nested guest potential access to a device no longer available. Zero out the remaining bits.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80831", "url": "https://ubuntu.com/security/CVE-2026-80831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: mxs-dcp - fix source scatterlist length access mxs_dcp_aes_block_crypt() uses sg_dma_len() without mapping the source scatterlist with dma_map_sg() first. Therefore, sg_dma_len() is invalid and could return zero or a stale DMA length, causing encryption and decryption to process the wrong number of bytes when CONFIG_NEED_SG_DMA_LENGTH=y. Use the original scatterlist length instead.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80832", "url": "https://ubuntu.com/security/CVE-2026-80832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qce - fix CCM AAD buffer underallocation The AAD buffer allocated in qce_aead_ccm_prepare_buf_assoclen() can be smaller than the length later programmed into the DMA scatterlist. The allocation size is currently calculated as: ALIGN(assoclen, 16) + MAX_CCM_ADATA_HEADER_LEN while the DMA length is set to: ALIGN(assoclen + adata_header_len, 16) Since ALIGN() does not distribute over addition, the allocation can be smaller than the DMA length. For example, when assoclen = 32 and adata_header_len = 2: allocation = ALIGN(32, 16) + 6 = 38 DMA length = ALIGN(32 + 2, 16) = 48 As a result, the QCE hardware can read beyond the allocated buffer while computing the CBC-MAC over the associated data. The extra bytes are folded into the authentication tag, resulting in an incorrect tag and causing CCM self-test failures such as: alg: aead: ccm-aes-qce encryption test failed (wrong result) on test vector 8 Fix the allocation by adding the maximum possible AAD header length before alignment: ALIGN(assoclen + MAX_CCM_ADATA_HEADER_LEN, 16) This guarantees that the allocated buffer is large enough for the fully padded AAD data for all supported header sizes.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80840", "url": "https://ubuntu.com/security/CVE-2026-80840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: seg6: clear IPv4 control block on IPIP decapsulation End.DX4 and End.DT4 decapsulate an IPv4 packet through decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), which normally clears IPCB before IPv4 interprets skb->cb. The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts. The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40. Both tcp_v4_save_options() and __ip_options_echo() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls __ip_options_echo(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte option-data area. Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced: BUG: KASAN: slab-out-of-bounds in __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm. Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80842", "url": "https://ubuntu.com/security/CVE-2026-80842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: fix use-after-free of a master VLAN's multicast context br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so once it is cleared under the lock no reader can arm the context again. For a master VLAN the handshake never runs. __vlan_del() clears BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so br_multicast_toggle_one_vlan(masterv, false) returns early on !br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is never taken. br_vlan_put_master() then drains the context in br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a reader still inside rcu_read_lock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no br_vlan_is_brentry() test and flips the flag under br->multicast_lock, so it is not affected. The reader is the bridge transmit path. For a master VLAN br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after br_multicast_ctx_deinit() has already stopped them. BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 Allocated by task 610: br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 Only test br_vlan_is_brentry() when enabling, like the br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before br_multicast_ctx_deinit() drains the context.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80843", "url": "https://ubuntu.com/security/CVE-2026-80843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix xfrm_state_construct() auth-trunc leak attach_auth_trunc() can allocate x->aalg while leaving x->props.aalgo at zero when the selected auth algorithm has no sadb_alg_id. One real case is cmac(aes). xfrm_state_construct() then treats !x->props.aalgo as \"no auth algorithm attached yet\" and calls attach_auth(). That overwrites x->aalg and loses the first allocation. Any later failure or teardown only frees the replacement pointer. Check whether x->aalg is already attached instead of inferring that state from x->props.aalgo.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80844", "url": "https://ubuntu.com/security/CVE-2026-80844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah6: validate routing header segments_left AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6_rearrange_rthdr() assumes that segments_left is not larger than the number of addresses described by the routing header's hdrlen field. That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segments_left value. With segments_left equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access. Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80846", "url": "https://ubuntu.com/security/CVE-2026-80846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: drop ESP-in-TCP packets with no ingress device ESP-in-TCP receives records through the TCP strparser. handle_esp() restores skb->dev from the saved skb_iif before passing the packet into the XFRM input path. Queued TCP data can be processed after the original ingress device has been removed, for example during veth or net namespace teardown. In that case dev_get_by_index_rcu() returns NULL. The XFRM IPv4 and IPv6 input paths both expect skb->dev to be valid while building the route lookup, so queued ESP-in-TCP data can dereference a NULL device. Drop the packet if the saved ingress device can no longer be resolved. Such a packet can no longer be routed through the normal XFRM receive path, and this preserves the existing behaviour for packets whose ingress device still exists.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80848", "url": "https://ubuntu.com/security/CVE-2026-80848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: fix UAF during close ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80854", "url": "https://ubuntu.com/security/CVE-2026-80854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: keep port count until LUN teardown completes tcm_usbg_drop_nexus() permits session removal once tpg_port_count reaches zero. However, usbg_port_unlink() currently decrements that count from the fabric_pre_unlink() callback, before core_dev_del_lun() waits for active se_lun references to drain. If removal of the last LUN races a nexus removal, the latter can observe a zero port count and call target_remove_session(). This frees sess_cmd_map while an in-flight struct usbg_cmd, including its work item, can still be accessed. Overlapping the last-LUN unlink with nexus removal reproduces this lifetime violation as a DEBUG_OBJECTS \"free active\" warning for usbg_cmd_work, followed by a target-core BUG/Oops. The generic target-core unlink path has no callback after core_dev_del_lun() completes. Add an optional fabric_post_unlink() callback and use it for the f_tcm port count. The count now remains nonzero until core_dev_del_lun() has finished draining active LUN references, preventing nexus removal from freeing the session during command completion.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80855", "url": "https://ubuntu.com/security/CVE-2026-80855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on open O_TRUNC DAX failure fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open(\"file\", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80856", "url": "https://ubuntu.com/security/CVE-2026-80856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on setattr writeback failure fuse_do_setattr() takes filemap_invalidate_lock() for a DAX truncate (fault_blocked = true) and releases it at the out:/error: labels. But when a writeback flush is also needed, a write_inode_now() failure returns directly and leaks the lock, so any later fault or truncate on the file stalls on the stale rwsem. For example, truncate(2) on a setuid file reaches fuse_do_setattr() with both ATTR_SIZE and ATTR_MODE set: truncate(2) └─ do_truncate() ├─ dentry_needs_remove_privs() # S_ISUID └─ notify_change() # KILL_SUID -> ATTR_MODE └─ fuse_setattr() # no killpriv: │ # ia_valid |= ATTR_MODE └─ fuse_do_setattr() ├─ filemap_invalidate_lock() # IS_DAX && is_truncate └─ write_inode_now() # is_wb && ATTR_MODE └─ if (err) # e.g. daemon -> -EIO return err # <- lock leaked Fix this by adding an unlock label that releases the lock before returning the error, and use it for the fuse_dax_break_layouts() failure path as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80923", "url": "https://ubuntu.com/security/CVE-2026-80923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: dbgtty: Fix unregister on tty_register_driver() failure If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80768", "url": "https://ubuntu.com/security/CVE-2026-80768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: ft260: fix stack-use-after-return write in I2C read race ft260_i2c_read() points dev->read_buf at a caller-supplied buffer (often an on-stack variable), arms a completion and waits up to five seconds for the device to return the data. The HID input callback ft260_raw_event() runs in the input/IRQ path, independent of the dev->lock mutex held by the read path, and copies the device-supplied payload into dev->read_buf after a plain NULL check. These two paths share read_buf, read_idx and read_len with no serialization. If the device delays its response until the read times out, ft260_i2c_read() resets the controller, clears read_buf and returns, unwinding the stack frame the buffer lived in. A response that arrives at that moment lets ft260_raw_event() pass the NULL check and then memcpy() the device-controlled payload into the now-freed stack location, a bounded but attacker-influenced stack-use-after-return write triggerable by malicious or malfunctioning hardware. Add a dedicated spinlock that serializes every access to read_buf, read_idx and read_len. ft260_raw_event() now holds it across the NULL check, the memcpy and the index update, while the read path takes it when arming and when clearing the buffer, so the teardown can no longer slip between the check and the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80766", "url": "https://ubuntu.com/security/CVE-2026-80766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: fix use-after-free of inrange_timer on remove uclogic_remove() cancels the pen in-range timer and then stops the device: \ttimer_delete_sync(&drvdata->inrange_timer); \thid_hw_stop(hdev); timer_delete_sync() only guarantees the timer is idle at that instant. uclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop() stops the transport several lines later, and every report with pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer: \tmod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); A report landing between the timer_delete_sync() call and the transport teardown in hid_hw_stop() re-arms inrange_timer after it was cancelled. uclogic_remove() then returns and the devm drvdata is freed, while hid_hw_stop() has already freed the input device drvdata->pen_input points at, so when the timer fires ~100 ms later uclogic_inrange_timeout() dereferences freed memory -- a use-after-free in timer-softirq context. Swapping the two calls is not a fix: stopping the device first frees drvdata->pen_input via hidinput_disconnect() while the timer may still be pending, so a timer already armed before removal fires on the freed input device in the window before timer_delete_sync() runs. Use timer_shutdown_sync() before hid_hw_stop() instead. It cancels the timer, waits for a running callback while pen_input is still valid, and prevents any further re-arming -- a later mod_timer() from an in-flight report is silently ignored -- so the timer is provably dead before hid_hw_stop() frees the inputs. This is the ordering the timer core documents for this \"timer re-armed from another path\" teardown case.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80789", "url": "https://ubuntu.com/security/CVE-2026-80789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: bound SGL data length before allocating command buffers nvmet_tcp_map_data() reads the host-controlled 32-bit sgl->length and, for the in-capsule offset descriptor (type 0x01), checks it against port->inline_data_size before use. Any other SGL descriptor type -- including the non-inline transport SGL data-block descriptor (type (NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, the type a real host uses for out-of-capsule writes) skips that check entirely and falls straight through to: \tcmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt); with len taken directly from the wire, unbounded up to 4 GiB. nvmet_req_init() only parses the command and never inspects sgl->length, and nvmet_check_transfer_len() -- the only other place transfer_len is validated -- runs later, from req->execute(), after the allocation has already happened. For a write command the target responds with an R2T and parks the command waiting for the host to send the data; if the host (or an unauthenticated peer that simply never follows up) never does, the sgl_alloc() buffer stays resident for the life of the command. NVMe/TCP has no mandatory authentication in the default configuration, so any peer able to reach the target portal and complete a Fabrics connect can drive this with a single crafted command, repeatable across queues and connections for amplification. This is unbounded kernel memory allocation triggered by a remote, effectively unauthenticated peer. Validate len against the same NVMET_TCP_MAXH2CDATA ceiling this file already uses to bound per-PDU H2C data, for every SGL descriptor type, before doing any allocation. This closes the gap for the non-inline descriptor while leaving the existing, tighter inline_data_size check in place for the in-capsule case. Runtime-verified on a v6.19 KASAN stand: with this bound in place, a crafted write command carrying an oversized non-inline SGL length is rejected before sgl_alloc() runs, where the same request previously drove an unbounded ~256 MiB kernel allocation (up to 4 GiB) that stayed resident pending an R2T the host never satisfies.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80783", "url": "https://ubuntu.com/security/CVE-2026-80783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event() magicmouse_raw_event() handles DOUBLE_REPORT_ID (0xf7) packets, which pack two touch reports into one, by splitting the packet and calling itself on each half. The only guard against runaway recursion is a \"size < 1\" check, which stops zero-sized calls but does not bound the recursion depth. A malicious HID device that matches this driver can send a report starting with DOUBLE_REPORT_ID and filled with the sequence [0xf7, 0x00]. Each level consumes two bytes and recurses on the remainder, so an incoming report of up to HID_MAX_BUFFER_SIZE (16 KiB) drives roughly 8000 nested calls. That easily exhausts the 16 KiB kernel stack, leading to a stack overflow: a panic with CONFIG_VMAP_STACK, or memory corruption without it. A double report only ever wraps two normal reports; it is never legitimately nested. Refuse to re-enter the DOUBLE_REPORT_ID case from a recursive call so the recursion depth is bounded to two, while all valid packets keep being parsed exactly as before.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80796", "url": "https://ubuntu.com/security/CVE-2026-80796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: add data_len bound checks to activation parameter extractors nci_extract_activation_params_iso_dep() and nci_extract_activation_params_nfc_dep() read an inner length byte from the NCI RF_INTF_ACTIVATED_NTF payload and use it to memcpy() into fixed kernel buffers, but neither function receives the caller-validated activation_params_len. A crafted NCI notification with activation_params_len=1 and an inner length byte of up to 20 (NFC-A) or 50 (NFC-B) causes memcpy() to read that many bytes past the one valid byte in the activation params region -- a slab out-of-bounds read of kernel memory adjacent to the NCI skb. The sibling nci_extract_rf_params_*() family was given equivalent protection by commit 571dcbeb8e63 (\"net: nfc: nci: Fix parameter validation for packet data\"), but the two activation parameter extractors were not updated at that time. Add a data_len parameter to both functions, guard against an empty region before consuming the inner length byte, decrement the remaining count after consuming it, and clamp the copy length to what is actually available. Update both call sites to pass ntf.activation_params_len, which is already validated against the skb at ntf.c:801.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80807", "url": "https://ubuntu.com/security/CVE-2026-80807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid block index in GC ioctl Syzbot reported list corruption caused by a double list_add_tail() call on bh->b_assoc_buffers within nilfs_lookup_dirty_data_buffers(). Analysis revealed that the root cause was the insertion of a page/folio with a page index of ULONG_MAX into the page cache via the GC ioctl. filemap_get_folios_tag(), called by nilfs_lookup_dirty_data_buffers(), repeatedly detects a dirty folio with a page index of ULONG_MAX due to index wrap-around, leading to duplicate processing of dirty buffers. As a preparatory step, the GC ioctl loads the page/folio of the block to be moved during GC and inserts it into the page cache based on information in the nilfs_vdesc structure passed as an argument. Normally, this does not cause issues because the user-space GC library configures the nilfs_vdesc structure properly. However, since there is no range check on the parameters determining the page index, a request with artificially crafted parameters -- such as those generated by Syzbot -- can result in a page/folio being inserted with a page index of ULONG_MAX, triggering the above problem. This resolves the issue by checking the ranges of 'vd_offset' and 'vd_vblocknr' in the nilfs_vdesc structure that determine the page index, thereby preventing the invalid page/folio insertions.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80916", "url": "https://ubuntu.com/security/CVE-2026-80916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcov: fix data corruption and race conditions on PREEMPT_RT syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area. On PREEMPT_RT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state. Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites. Note that while the temporary storage is now on a per-thread basis, the per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that kcov_remote_start() and kcov_remote_stop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state. It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when __init function of built-in module runs. But this patch also fixes crashing the kernel when vmalloc_node() in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in (1) doing vmalloc() in kcov_remote_start() despite !in_task() context (2) out-of-array-bounds access if (1) succeeded but kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE (3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes problems.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-43437", "url": "https://ubuntu.com/security/CVE-2026-43437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain() In the drain loop, the local variable 'runtime' is reassigned to a linked stream's runtime (runtime = s->runtime at line 2157). After releasing the stream lock at line 2169, the code accesses runtime->no_period_wakeup, runtime->rate, and runtime->buffer_size (lines 2170-2178) — all referencing the linked stream's runtime without any lock or refcount protecting its lifetime. A concurrent close() on the linked stream's fd triggers snd_pcm_release_substream() → snd_pcm_drop() → pcm_release_private() → snd_pcm_unlink() → snd_pcm_detach_substream() → kfree(runtime). No synchronization prevents kfree(runtime) from completing while the drain path dereferences the stale pointer. Fix by caching the needed runtime fields (no_period_wakeup, rate, buffer_size) into local variables while still holding the stream lock, and using the cached values after the lock is released.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-53089", "url": "https://ubuntu.com/security/CVE-2026-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in offloaded map/prog info fill When querying info for an offloaded BPF map or program, bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns() obtain the network namespace with get_net(dev_net(offmap->netdev)). However, the associated netdev's netns may be racing with teardown during netns destruction. If the netns refcount has already reached 0, get_net() performs a refcount_t increment on 0, triggering: refcount_t: addition on 0; use-after-free. Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains valid, they cannot prevent the netns refcount from reaching zero. Fix this by using maybe_get_net() instead of get_net(). maybe_get_net() uses refcount_inc_not_zero() and returns NULL if the refcount is already zero, which causes ns_get_path_cb() to fail and the caller to return -ENOENT -- the correct behavior when the netns is being destroyed.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2025-40102", "url": "https://ubuntu.com/security/CVE-2025-40102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000) Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-39925", "url": "https://ubuntu.com/security/CVE-2025-39925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: j1939: implement NETDEV_UNREGISTER notification handler syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 (\"can: j1939: move j1939_priv_put() into sk_destruct callback\") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on \"struct j1939_priv\" held by j1939_sk_bind() call prevents \"struct net_device\" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. [mkl: remove space in front of label]", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2024-58095", "url": "https://ubuntu.com/security/CVE-2024-58095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before txBeginAnon() call Added a read-only check before calling `txBeginAnon` in `extAlloc` and `extRecord`. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes. Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-58094", "url": "https://ubuntu.com/security/CVE-2024-58094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before truncation in jfs_truncate_nolock() Added a check for \"read-only\" mode in the `jfs_truncate_nolock` function to avoid errors related to writing to a read-only filesystem. Call stack: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) If the `isReadOnly(ip)` condition is triggered in `jfs_truncate_nolock`, the function execution will stop, and no further data modification will occur. Instead, the `xtTruncate` function will be called with the \"COMMIT_WMAP\" flag, preventing modifications in \"read-only\" mode.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-46754", "url": "https://ubuntu.com/security/CVE-2024-46754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Remove tst_run from lwt_seg6local_prog_ops. The syzbot reported that the lwt_seg6 related BPF ops can be invoked via bpf_test_run() without without entering input_action_end_bpf() first. Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a (\"ipv6: sr: Add seg6local action End.BPF\"). The reason is that the per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self test case but each BPF function expects it. Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.", "cve_priority": "low", "cve_public_date": "2024-09-18 08:15:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-80806", "url": "https://ubuntu.com/security/CVE-2026-80806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't enable DAX on new encrypted files Currently, when a new encrypted regular file is created, the call to ext4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made before EXT4_INODE_ENCRYPT is set. As a result, it can set S_DAX if the filesystem is mounted with \"-o dax=always\". EXT4_INODE_ENCRYPT then actually gets set a bit later in __ext4_new_inode(), when it calls fscrypt_set_context() which calls ext4_set_context(). ext4_set_context() sets EXT4_INODE_ENCRYPT and calls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too. This was intended to clear S_DAX as well. However, this was broken by commit 043546e46dc7 (\"fs/ext4: Only change S_DAX on inode load\"). This causes data written to the file to bypass encryption, also causing xfstests failures such as generic/548 (when \"-o dax=always\" is used). Fix this by simplifying the flow by making __ext4_new_inode() set EXT4_INODE_ENCRYPT earlier. This makes it take effect in ext4_set_inode_flags(inode, init=true), making S_DAX never be set. Similarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first place on new encrypted inodes. Then it doesn't need to be cleared. As a result of these simplifications, ext4_set_context() no longer needs to change inode flags or state when 'handle != NULL'. Remove that too.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80863", "url": "https://ubuntu.com/security/CVE-2026-80863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix OOB in free_rd_atomic_resources() free_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic. Updating max_dest_rd_atomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] BUG: KASAN: slab-out-of-bounds in rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 Write of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063 CPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xf7/0x600 mm/kasan/report.c:482 kasan_report+0xe4/0x120 mm/kasan/report.c:595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fefc75a70cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fefc8495018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd RDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007 RBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0 Allocated by task 11063: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5296 [inline] __kmalloc_noprof+0x32a/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:155 [inline] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_ma ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80590", "url": "https://ubuntu.com/security/CVE-2026-80590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 (\"net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list\") and by commit 9e4b7a99a03a (\"net: gso: fix panic on frag_list with mixed head alloc types\") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 (\"tun: Allow GSO using virtio_net_hdr\"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80765", "url": "https://ubuntu.com/security/CVE-2026-80765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: validate initial device info bounds The Hyper-V synthetic HID host supplies SYNTH_HID_INITIAL_DEVICE_INFO messages that contain a HID descriptor followed by the report descriptor bytes. mousevsc_on_receive_device_info() trusts bLength and wDescriptorLength without checking that the received packet contains both byte ranges. A malformed host or backend message can therefore make the guest read past the received VMBus packet while copying the report descriptor. Pass the received initial-device-info size into the parser and reject descriptor lengths that exceed the packet. Impact: A malicious Hyper-V host or backend can crash a guest by sending a short initial device-info message with an oversized HID report descriptor length.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80767", "url": "https://ubuntu.com/security/CVE-2026-80767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix use-after-free in enable_sensor enable_sensor_store() can call set_power_report_state(), which dereferences sensor_inst->power_state and sensor_inst->report_state. These pointers refer to entries in sensor_inst->fields. Create the field attributes before exposing the enable_sensor sysfs attribute, so enable_sensor cannot be accessed before the state it depends on has been initialized. On remove, delete enable_sensor before freeing the field attributes, so a concurrent sysfs write cannot dereference freed memory through power_state or report_state.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80918", "url": "https://ubuntu.com/security/CVE-2026-80918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix number/pointer type confusion on long items When fetch_item() is called by hid_scan_report() on an item with HID_ITEM_TAG_LONG, it stores a pointer to the item data in item->data.longdata instead of storing a value directly in item->data.{u8/u16/u32}. When item_udata() or item_sdata() encounters such an item, it incorrectly assumes that the item is in short format, and therefore returns the lower part of a kernel pointer reinterpreted as a number. When a HID device is connected whose descriptor contains a HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this causes the lower half of a kernel pointer to be printed into dmesg as a number, like this: hid (null): invalid report_size 107953555 To fix it, let item_udata() and item_sdata() verify that the item is in short format. Note that this bug only affects hid_scan_report(), while the main parsing pass hid_parse_collections() will always bail out when encountering a long item. Sidenote: There are currently no users of data.longdata; maybe we should just remove any parsing of long-format descriptors as a follow-up.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80889", "url": "https://ubuntu.com/security/CVE-2026-80889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix timer drain order, wakeup handling and tx_gen ordering This patch is a follow-up to commit cf070fe33bfb (\"can: isotp: serialize TX state transitions under so->rx_lock\") which addresses following sashiko-bot findings: - isotp_sendmsg(): drain so->txfrtimer first so a stale callback can't re-arm echotimer after the claim - isotp_release(): wake so->wait after forcing ISOTP_SHUTDOWN so a sleeping sendmsg() claim isn't stranded - isotp_sendmsg(): have both wait_event_interruptible() calls in isotp_sendmsg() also wake on ISOTP_SHUTDOWN and do not return claim to IDLE to avoid corrupting a concurrent isotp_release() process. - isotp_sendmsg(): handle potential claim of a new transfer when the wait_event_interruptible() call returns in CAN_ISOTP_WAIT_TX_DONE mode. Don't touch timers and states of the new transfer if a new thread incremented so->tx_gen before getting the lock at err_event_drop. - isotp_sendmsg(): handle a stuck can_send() and omit timer and state changes if a new transfer was claimed. wait_tx_done() returns the error recorded in so->tx_result[], tagged with the caller's own generation. - isotp_tx_timeout(): on a claimed timeout, record the ECOMM error for the timed-out transfer's own generation in so->tx_result[]; sk->sk_err is raised unconditionally, same as every other error path here. - isotp_tx_gen_done()/isotp_tx_timeout(): always read tx.state (acquire) before tx_gen - the reverse order let a weakly ordered CPU pair a fresh tx.state with a stale tx_gen/tx_result slot. - isotp_sendmsg(): wait_tx_done: drain sk_err via sock_error() once we have read the result from so->tx_result[], so an already-reported error doesn't stay latched for a later poll()/SO_ERROR. Also align the remaining lock-free so->tx.state/rx.state/cfecho accesses and use skb->hash as unique loopback echo frame indicator.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-46170", "url": "https://ubuntu.com/security/CVE-2026-46170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: free sk if last When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on \"itself\".", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46158", "url": "https://ubuntu.com/security/CVE-2026-46158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: always decrease sk refcount When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as \"unlikely\".", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-80555", "url": "https://ubuntu.com/security/CVE-2026-80555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Free all memory if cp_init() fails The routine cp_free() is called to unpin/free any memory once an I/O is completed successfully, or if cp_prefetch() fails. But if cp_init() fails, and cp->initialized is not enabled, the same routine cannot be used to free all the memory. An attempt to address this exists in ccwchain_handle_ccw(), where a single call to ccwchain_free() is made for the currently-processed CCW segment. But this will leak other segments (created as a result of a Transfer in Channel) that had been allocated as part of the same channel program. Address this by performing the cleanup outside of the recursive ccwchain_handle_ccw()/ccwchain_loop_tic() logic.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2025-68794", "url": "https://ubuntu.com/security/CVE-2025-68794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: adjust read range correctly for non-block-aligned positions iomap_adjust_read_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio. Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-80781", "url": "https://ubuntu.com/security/CVE-2026-80781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix OOB read of field->usage in hid_set_field() hid_set_field() hands field->usage + offset to hid_dump_input() before the guard that bounds offset: \thid_dump_input(field->report->device, field->usage + offset, value); \tif (offset >= field->report_count) { \t\thid_err(...); \t\treturn -1; \t} Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is allocated inline with the hid_field in hid_register_field() and holds field->maxusage entries, so an offset past it reads off the end of the kvzalloc()ed allocation and into a neighbouring object. Had the guard run first, offset < report_count <= maxusage would already have confined the pointer to the array. A caller supplies such an offset today. picolcd_fb_send_tile() validates only report->maxfield before issuing hid_set_field(report->field[0], 11 + i, ...) for i = 0..31, so its offsets are fixed at 11..42 and are never checked against the bound field. When the device registers that field with fewer usages, the framebuffer deferred-io work drives the read on every tile. KASAN reports a 4-byte slab-out-of-bounds read in hid_dump_input() below hid_set_field(), and the same boot logs \"offset (1) exceeds report_count (1)\" from the guard that runs only afterwards. Move the hid_dump_input() call below the guard. Because field->maxusage >= field->report_count, the guard then establishes that field->usage + offset lies inside the array before it is dereferenced, for every caller and without changing behaviour on the valid path. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80782", "url": "https://ubuntu.com/security/CVE-2026-80782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: do not keep a stale msc->input if no input is claimed magicmouse_input_mapping() caches the first hid_input's input_dev in msc->input while the report descriptor is parsed, and the rest of the driver treats a non-NULL msc->input as proof that an input device was registered. That does not hold on the hid-input error path. If hidinput_connect() fails -- for instance because input_register_device() returns an error -- it unwinds through hidinput_disconnect(), which frees every input_dev it created, including the one cached in msc->input. The failure does not abort the probe. hid_connect() only skips the claim: \tif ((connect_mask & HID_CONNECT_HIDINPUT) && !hidinput_connect(hdev, \t\t\t\tconnect_mask & HID_CONNECT_HIDINPUT_FORCE)) \t\thdev->claimed |= HID_CLAIMED_INPUT; and the \"device has no listeners\" bailout below it does not fire for this driver, which sets ->raw_event; on the USB Magic Mouse 2 / Magic Trackpad 2 paths hidraw and hiddev are claimed as well. hid_hw_start() therefore returns 0 and magicmouse_probe() continues with msc->input pointing at freed memory. Being non-NULL, it passes the \"input not registered\" check in probe and the NULL checks in ->raw_event and ->event, so the next input report dereferences freed memory. Clear msc->input when the HID core did not claim an input device, so the existing NULL checks cover this case as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-80583", "url": "https://ubuntu.com/security/CVE-2026-80583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses The \"DEC0 MODE\" to \"DEC7 MODE\" controls are enumerated, but tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 (\"ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type\") and commit 0ea5eff7c606 (\"ASoC: codecs: va-macro: fix accessing array out of bounds for enum type\"), but tx-macro was missed. On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value sanity check catches the 4 bytes written past the enumerated item and every read of these controls fails with -EINVAL: snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80587", "url": "https://ubuntu.com/security/CVE-2026-80587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid combining some incoming suboptions Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80547", "url": "https://ubuntu.com/security/CVE-2026-80547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Implement a crw lock Unlike the channel_program struct, which covers synchronous I/O submissions and asynchronous interrupts, the CRW region relies exclusively on asynchronous events coming from hardware. Implement a lock to manage the list of those payloads, to ensure they are read cohesively.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80548", "url": "https://ubuntu.com/security/CVE-2026-80548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Selectively expand io_mutex The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80552", "url": "https://ubuntu.com/security/CVE-2026-80552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure index for read/write regions are within range The introduction of the capability chain rightly clamped the region indexes to the range of the capabilities itself, but neglected to do so for the existing read/write regions which should also be enforced.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80788", "url": "https://ubuntu.com/security/CVE-2026-80788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations When fuzzing the nvme target code, I tripped a kernel warning in nvmet_tcp_map_data() because the length passed into the allocator is controlled by the remote initiator. A remote initiator that sends a command with an SGL claiming a huge number, can create a scatterlist and iovec allocation of over 1 million entries, which causes the backing kmalloc call to exceed MAX_PAGE_ORDER and then the page allocator will trip on a WARN_ON_ONCE_GFP() message: WARNING: mm/page_alloc.c:5280 __alloc_frozen_pages_noprof Workqueue: nvmet_tcp_wq nvmet_tcp_io_work ... sgl_alloc_order nvmet_tcp_map_data nvmet_tcp_try_recv_pdu As it's never good to trip a kernel warning remotely due to many systems having panic-on-warn enabled, let's silence it by just add GFP_NOWARN to the allocation flags.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80790", "url": "https://ubuntu.com/security/CVE-2026-80790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: fix invalid free in LS IOD error path nvmet_fc_alloc_ls_iodlist() advances iod while initializing the LS IOD array. If an rqstbuf allocation or response buffer DMA mapping fails, the unwind loop decrements iod past the start of the array. The final kfree(iod) therefore frees an address before the allocated object. This can be reproduced with nvme-fcloop and failslab by setting fail-nth to 6 before creating a target port. KASAN reports: BUG: KASAN: invalid-free in nvmet_fc_register_targetport Free of addr ffff88816cf8ff48 by task nvmet_fail_nth/9552 Free the original allocation base stored in tgtport->iod instead. With this fix applied, the same sysfs write with fail-nth=6 returns -ENOMEM without any KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80792", "url": "https://ubuntu.com/security/CVE-2026-80792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix use-after-free in ip6_finish_output2() ip6_finish_output2() caches a pointer to the IPv6 destination address (daddr) before invoking lwtunnel_xmit(). The LWT-BPF transmit path or other encapsulation operations within lwtunnel_xmit() can reallocate the skb head, freeing the memory that daddr points to. When lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, the function continues to use the stale daddr pointer to compute the nexthop and to look up or create the neighbour entry. This results in a use-after-free read, which can leak sensitive kernel data, pollute the neighbour table with arbitrary values, misdirect traffic, or crash the system. Fix this by re-fetching the IPv6 header and the destination address pointer after lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, ensuring that the subsequent nexthop computation and neighbour lookup operate on valid memory.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80793", "url": "https://ubuntu.com/security/CVE-2026-80793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: reject undersized MTUs in ip_do_fragment() ip_do_fragment() subtracts the IPv4 header length from the effective MTU and passes the resulting payload MTU to ip_frag_next(). If the effective MTU is smaller than hlen + 8, ip_frag_next() rounds the fragment payload length down to zero. The fragmentation state then never makes forward progress: state->left, state->ptr and state->offset stay unchanged while ip_do_fragment() keeps allocating and transmitting header-only fragments until the softlockup detector fires. This is reproducible with a route installed using \"mtu lock 20\", but it is also reproducible without route MTU lock, for example by forwarding a packet to a device whose MTU is 20. Fix it in ip_do_fragment() by rejecting mtu < hlen + 8 with -EMSGSIZE, matching the existing IPv6 fragmentation check.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80557", "url": "https://ubuntu.com/security/CVE-2026-80557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix OOB read in decode_watchers() via missing bounds check ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80794", "url": "https://ubuntu.com/security/CVE-2026-80794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix uninit-value in the RF discover/activated NTF handlers nci_rf_discover_ntf_packet() and nci_rf_intf_activated_ntf_packet() each parse a notification into an on-stack struct (nci_rf_discover_ntf / nci_rf_intf_activated_ntf) that is not initialised. The RF technology-specific parameters are only extracted when rf_tech_specific_params_len is non-zero, so a notification that reports a zero length leaves the rf_tech_specific_params union uninitialised - and both handlers then pass it to nci_add_new_protocol(), which reads it: - discover: nci_add_new_target() -> nci_add_new_protocol(); - activated: nci_target_auto_activated() -> nci_add_new_protocol(). nci_add_new_protocol() uses nfca_poll->nfcid1_len as both a branch condition and a memcpy() length and copies nfcid1/sens_res/sel_res into ndev->targets, which is later exposed to user space via NFC_CMD_GET_TARGET. BUG: KMSAN: uninit-value in nci_add_new_protocol+0x624/0x6c0 nci_add_new_protocol+0x624/0x6c0 nci_ntf_packet+0x25b2/0x3c30 nci_rx_work+0x318/0x5d0 process_scheduled_works+0x84b/0x17a0 worker_thread+0xc10/0x11b0 kthread+0x376/0x500 Local variable ntf.i created at: nci_ntf_packet+0xbc2/0x3c30 Zero-initialise both on-stack notifications so the union reads back as zero when no technology-specific parameters are present.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80795", "url": "https://ubuntu.com/security/CVE-2026-80795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix out-of-bounds write in nci_target_auto_activated() nci_target_auto_activated() appends a target to the fixed-size array ndev->targets[NCI_MAX_DISCOVERED_TARGETS] and increments ndev->n_targets without first checking the array is full; unlike its sibling nci_add_new_target(), which bails out when n_targets already equals NCI_MAX_DISCOVERED_TARGETS. ndev->n_targets is only cleared by nci_clear_target_list(), so an NFCC that repeatedly re-runs discovery (RF_DISCOVER_RSP, which re-enters NCI_DISCOVERY without clearing the target list) and reports an auto-activated target (RF_INTF_ACTIVATED_NTF) drives n_targets past the limit. The append then writes a struct nfc_target past the end of the array (a slab out-of-bounds write), and nfc_targets_found() goes on to walk the array with the inflated count: BUG: KASAN: slab-out-of-bounds in nci_add_new_protocol+0x94/0x2ac [nci] Write of size 2 at addr ffff0000c7299a18 by task kworker/u8:0/12 Workqueue: nfc0_nci_rx_wq nci_rx_work [nci] Call trace: nci_add_new_protocol+0x94/0x2ac [nci] nci_ntf_packet+0xddc/0x11a0 [nci] nci_rx_work+0x15c/0x1e0 [nci] process_one_work+0x2dc/0x500 worker_thread+0x240/0x460 kthread+0x1c0/0x1d0 ret_from_fork+0x10/0x20 The buggy address belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1024 bytes to the right of allocated 1560-byte region [ffff0000c7299000, ffff0000c7299618) Guard nci_target_auto_activated() with the same check used by nci_add_new_target().", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80823", "url": "https://ubuntu.com/security/CVE-2026-80823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: validate ATR_REQ length against the received frame st21nfca_tm_recv_atr_req() checks that the received ATR_REQ frame is at least ST21NFCA_ATR_REQ_MIN_SIZE and that the self-declared atr_req->length is at least sizeof(struct st21nfca_atr_req), but never checks that atr_req->length does not exceed the actual received length (skb->len). st21nfca_tm_send_atr_res() then trusts the declared length: \tgb_len = atr_req->length - sizeof(struct st21nfca_atr_req); \t... \tmemcpy(atr_res->gbi, atr_req->gbi, gb_len); so an RF peer that sends a short frame but sets atr_req->length larger than the frame makes gb_len exceed the general bytes actually present, and the memcpy reads out of bounds past the received skb. Those bytes are placed in the ATR_RES and sent back to the peer (kernel-memory disclosure to a proximity attacker); a larger declared length is an out-of-bounds read (DoS). Reject frames whose declared length exceeds the received length. The adjacent nfc_tm_activated() path in the same function already derives its general-bytes length from skb->len rather than the declared field. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80797", "url": "https://ubuntu.com/security/CVE-2026-80797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: purge fragmented skbs during cleanup pn53x_common_clean() purges resp_q before freeing the common PN533 state, but it leaves fragment_skb untouched. The fragmentation helpers queue transmit fragments there while sending large initiator or target-mode frames, and those skbs remain owned by the driver until they are sent or discarded. If the device is removed while fragments are still queued, the common cleanup path frees the PN533 state without releasing the queued fragment skbs, leaking them. Purge fragment_skb during cleanup alongside resp_q.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80798", "url": "https://ubuntu.com/security/CVE-2026-80798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: reject PDUs shorter than the LLCP header Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes before parsing it. nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/ nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a CONNECT or CC PDU then computes \ttlv_array_len = skb->len - LLCP_HEADER_SIZE; as a size_t and hands it to the TLV walk. When the frame is shorter than the header the subtraction wraps to a huge value and the walk runs far past the buffer, an out-of-bounds read. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Guard the common receive choke point __nfc_llcp_recv(), shared by both the target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so a short skb is dropped before the rx_work worker parses it. Use pskb_may_pull() rather than a skb->len test so the two header bytes are guaranteed to sit in the skb linear area even for a non-linear skb, matching how the sibling NCI and HCI receive paths validate their headers. Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on linux-next. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80799", "url": "https://ubuntu.com/security/CVE-2026-80799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain three related bugs in their TLV parsing loops: 1. 'offset' is declared u8 but tlv_array_len is u16. When TLV data advances offset past 255 it silently wraps to zero, causing infinite loops or double-processing of buffer data. 2. Before reading tlv[0] (type) and tlv[1] (length) there is no check that offset+2 <= tlv_array_len. A truncated TLV causes an OOB read of one byte past the buffer end. 3. After reading the length field, the value bytes are accessed without checking offset+2+length <= tlv_array_len. A crafted length=0xFF on a short buffer causes up to 255 bytes of OOB read past the buffer end. Both functions are reachable without authentication via nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes directly into nfc_llcp_parse_gb_tlv() with no additional validation. Fix all three issues by widening offset from u8 to u16 and adding bounds checks for both the TLV header and value field before each access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80800", "url": "https://ubuntu.com/security/CVE-2026-80800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound the connect_sn TLV walk to the skb Commit 27256cdb290e (\"nfc: llcp: bound SNL TLV parsing to the skb and add length checks\") fixed the unbounded TLV walk in nfc_llcp_recv_snl(), and commit d8bd2dedbde5 (\"nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers\") subsequently bounded nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv(). One sibling parser sharing the same pattern remains unbounded: nfc_llcp_connect_sn(). nfc_llcp_connect_sn() walks a TLV list, reading a two-byte header (type, length) followed by length bytes of value, without checking that the two header bytes or the declared length stay within the buffer. It returns a pointer to a service name of up to 255 bytes that may point past the end of the skb; it is subsequently consumed by memcmp() in nfc_llcp_sock_from_sn(). In addition tlv_array_len was computed as \"skb->len - LLCP_HEADER_SIZE\" in size_t, so a CONNECT/CC frame shorter than the LLCP header underflows to a huge length and the walk runs far past the buffer. nfc_llcp_connect_sn() is reachable from nfc_llcp_recv_connect() and nfc_llcp_recv_cc(), i.e. from received CONNECT and CC PDUs. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP, and the nfc_llcp_rx_skb() dispatcher applies no minimum-length guard. Walk the TLV list by pointer, bounded by skb_tail_pointer(skb), and validate each declared length before use, matching the approach already used for nfc_llcp_recv_snl(). Starting the walk at &skb->data[LLCP_HEADER_SIZE] against the tail pointer also removes the size_t underflow for short frames. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80801", "url": "https://ubuntu.com/security/CVE-2026-80801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: microread: validate target discovery payload lengths microread_target_discovered() parses target discovery payloads from skb->data according to the HCI gate. The fixed field offsets and UID copies were checked only against the destination nfc_target buffers, not against the actual skb length. Validate that each gate-specific payload contains the fixed fields and UID bytes before reading or copying them.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80802", "url": "https://ubuntu.com/security/CVE-2026-80802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: bound the device-reported read length and fix an skb leak fdp_nci_i2c_read() takes the next packet length from two device-supplied bytes and never validates it. The value is a u16 used as the i2c_master_recv() count into a 261-byte on-stack buffer: a malicious, counterfeit or malfunctioning controller (or an i2c bus interposer) can drive it far past the buffer for a stack out-of-bounds write that clobbers the canary and return address, or below the minimum frame size (directly, or by truncating the computed sum) so the header/LRC strip and the next length read run past a short receive. Reject a length outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD], as a corrupted packet already is, and force resynchronization. The same loop allocates one data skb per iteration and assumes a length packet followed by a data packet; a device that sends two data packets in one call leaks the first skb when the second allocation overwrites it. Free a previously allocated skb before allocating the next.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80803", "url": "https://ubuntu.com/security/CVE-2026-80803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: digital: clamp SENSF_RES length to the destination buffer digital_in_recv_sensf_res() memcpy()s resp->len bytes from a remote NFC-F device response into the NFC_SENSF_RES_MAXSIZE-byte target.sensf_res field without an upper-bound check. A nearby malicious NFC-F device can send an oversized SENSF_RES response to overflow the stack-local struct nfc_target. Clamp resp->len to NFC_SENSF_RES_MAXSIZE before the copy. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80536", "url": "https://ubuntu.com/security/CVE-2026-80536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: bounds-check buffer log item's dirty bitmap xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: \tmemcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), \t\titem->ri_buf[i].iov_base, \t\tnbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80553", "url": "https://ubuntu.com/security/CVE-2026-80553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Cancel existing workqueues The initialization of the io_work and crw_work workqueues begs the question of whether they should be un-initialized. Add the corresponding cleanup tags in _release_dev to ensure work isn't dispatched after the private struct is free'd.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74662", "url": "https://ubuntu.com/security/CVE-2026-74662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: publish queues before arming timer inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74666", "url": "https://ubuntu.com/security/CVE-2026-74666", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: synchronize pressure clearing with ring reconfiguration packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74663", "url": "https://ubuntu.com/security/CVE-2026-74663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: reject overly deep qdisc hierarchies Deep qdisc hierarchies can lead to excessive recursion in qdisc tree walkers and exhaust the kernel stack. The existing loop check does not cover the create-and-graft path, so a hierarchy can still be extended by creating a new child qdisc below an already deep parent. Store the hierarchy depth in struct Qdisc and update it when qdiscs are grafted. Reject new child qdiscs once the parent is already at the maximum allowed depth.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74668", "url": "https://ubuntu.com/security/CVE-2026-74668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in TX_RING send path tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative. Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb(). The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74582", "url": "https://ubuntu.com/security/CVE-2026-74582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in non-ring send paths packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-80737", "url": "https://ubuntu.com/security/CVE-2026-80737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: synchronize DMA teardown dmaengine_terminate_all() does not wait for a running callback, so the TX callback can still touch the TX buffer after it is freed. The RX poll timer reads the RX buffers without the port lock. Switch to dmaengine_terminate_sync() and delete the RX timer before freeing the buffers.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74626", "url": "https://ubuntu.com/security/CVE-2026-74626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_netdev: Preserve RX queue depth on allocation failure ntb_netdev_rx_handler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception. A retry path could refill the queue later, but ntb_netdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74637", "url": "https://ubuntu.com/security/CVE-2026-74637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix group leader use-after-free after sibling detach perf_group_detach() handles leader and sibling detach differently. When the group leader is detached, all siblings are promoted to singleton events and their group_leader pointer is reset to themselves. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. That is harmless when the sibling is being closed and freed immediately, as in the DETACH_DEAD path. It is not safe when the sibling is detached but kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the sibling is removed from the context, while its file descriptor can still keep it alive. A typical failing sequence is: - A group contains leader L and sibling S. - CPU hot-unplug detaches S with DETACH_GROUP, removing it from L->sibling_list but leaving S->group_leader == L. - L is later closed and freed. - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and dereferences the freed leader. This was reproduced by running the perf event fuzzer, CPU hotplug, and a stress workload concurrently: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT pc : perf_ioctl+0x34c/0xc68 x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908) Call trace: perf_ioctl+0x34c/0xc68 (P) __arm64_sys_ioctl+0xa0/0xf4 invoke_syscall+0x58/0xe4 el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x40/0xc0 el0t_64_sync_handler+0x68/0xdc el0t_64_sync+0x1c4/0x1c8 The fault happened in perf_ioctl(), where perf_event_for_each() follows the stale group_leader pointer and perf_event_for_each_child() then dereferences the freed leader's context. Fix the use-after-free by promoting the detached sibling to a singleton. Also fix __event_disable() cgroup accounting and event state change.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74647", "url": "https://ubuntu.com/security/CVE-2026-74647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Remove buffer from list prior to unmap operation fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74632", "url": "https://ubuntu.com/security/CVE-2026-74632", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix huge_zero_pfn race Patch series \"mm/huge_memory: fix huge_zero_pfn race\", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80562", "url": "https://ubuntu.com/security/CVE-2026-80562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: ml-ioh: use raw_spinlock_t for the register lock ioh_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irq_set_type callback additionally emits a dev_warn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same fix as commit a02b8950d619 (\"gpio: pch: use raw_spinlock_t for the register lock\"); this driver shares the same structure as gpio-pch.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80805", "url": "https://ubuntu.com/security/CVE-2026-80805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: validate attr entry pointer before field access xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen, valuelen) before checking if the entry pointer itself is within bounds. If nameidx is crafted to point near the end of the buffer, these field accesses can read out-of-bounds before the bounds check at name_end > buf_end is performed. Add explicit bounds checks for entry pointers before accessing their fields. Use offsetof() to check that the start of the flexible array member (nameval/name) is within bounds, which ensures all preceding fields are safe to access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80808", "url": "https://ubuntu.com/security/CVE-2026-80808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: stop retrying saturated xattr cache entries ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked. Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop. Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition. Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80809", "url": "https://ubuntu.com/security/CVE-2026-80809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix missing metadata reservation for large xattrs [BUG] lsetxattr() panics the kernel when setting a large xattr value on a fragmented filesystem where the file already has an external xattr block. [CAUSE] ocfs2_calc_xattr_set_need() never reserves metadata blocks for a new xattr value's extent tree when the file already has an external xattr block. The not_found path leaves meta_add at zero, so meta_ac is NULL when ocfs2_xattr_extend_allocation() runs. A new value root has room for a single extent record. On a fragmented filesystem, the allocator cannot satisfy the xattr value in one contiguous run, so each non-contiguous run requires its own extent record. When the value root's extent list is full and meta_ac is NULL, ocfs2_add_clusters_in_btree() returns RESTART_META, and ocfs2_xattr_extend_allocation() hits BUG_ON(why == RESTART_META). [FIX] The case where no xattr block exists yet already calls ocfs2_extend_meta_needed(&def_xv.xv.xr_list) to reserve value tree metadata. Add the same reservation to the case where an xattr block already exists, making the two cases consistent. Replace the BUG_ON with a -ENOSPC return so that if RESTART_META is returned despite the reservation, the error propagates to userspace instead of panicking the kernel.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80812", "url": "https://ubuntu.com/security/CVE-2026-80812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dummy: Check card index validity at probe snd_dummy_probe() blindly trusts that the given devptr->id value is within the proper card index range. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80814", "url": "https://ubuntu.com/security/CVE-2026-80814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rndis_host: add overflow check in rndis_rx_fixup() Add an overflow check to ensure that data_offset + data_len + 8 does not wrap, which would enable an OOB read of the USB data buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80819", "url": "https://ubuntu.com/security/CVE-2026-80819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept rfcomm_sock_recvmsg() completes a deferred setup by calling rfcomm_dlc_accept() without holding any RFCOMM lock: \tif (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { \t\trfcomm_dlc_accept(d); \t\treturn 0; \t} and rfcomm_dlc_accept() dereferences the session on its first line: \tstruct sock *sk = d->session->sock->sk; Every other path that touches d->session runs under rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). rfcomm_connect_ind() is even documented as \"called under rfcomm_lock()\". This call site is the only one that skips it. The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against teardown, since __rfcomm_dlc_close() returns early when it wins the test_and_clear. But rfcomm_recv_disc() forces the state first: \td->state = BT_CLOSED; \t__rfcomm_dlc_close(d, err); and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2. With the state already BT_CLOSED that switch does not match, the bit is never consulted, and __rfcomm_dlc_close() falls through to rfcomm_dlc_unlink(), which sets d->session = NULL. So a remote DISC on a deferred dlc clears the session while leaving RFCOMM_DEFER_SETUP set. The next recvmsg() then passes the test_and_clear and dereferences a NULL session. No timing window is needed: once the DISC has been processed, the dereference is unconditional. Give rfcomm_dlc_accept() the same shape as rfcomm_dlc_open() and rfcomm_dlc_close(): an exported wrapper that takes rfcomm_mutex and re-checks the session, around a __rfcomm_dlc_accept() that the two in-core callers, which already hold the mutex, keep using. Reproduced on a KASAN + PROVE_LOCKING kernel with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session, opens a dlc on a channel bound with BT_DEFER_SETUP, and sends DISC after the socket is accepted. recv() on the accepted socket then hits: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10 is the offset of sock in struct rfcomm_session. With this patch the same run completes with recv() returning 0 and no report, and lockdep stays quiet, confirming rfcomm_mutex is still taken before lock_sock on this path as it is on the thread side.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80917", "url": "https://ubuntu.com/security/CVE-2026-80917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems On 32-bit systems the config space is too large to ioremap in one go, so pci_ecam_create() maps each bus segment separately and relies on the ->add_bus callback (pci_ecam_add_bus) to populate the per-bus mapping in cfg->winp[]. pci_ecam_map_bus() then uses that mapping as the base for every config access. The generic ECAM ops (pci_generic_ecam_ops) already provide the ->add_bus and ->remove_bus callbacks, but the CAM (legacy) ops in pci-host-generic.c do not. As a result, on a 32-bit host using \"pci-host-cam-generic\" the per-bus mapping is never set up and the first config read dereferences a NULL base, crashing during bus enumeration: Unable to handle kernel NULL pointer dereference at virtual address 00000800 Oops [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 6.9.7+ #43 Hardware name: Digilent Nexys-Video-A7 RV32 (DT) epc : pci_generic_config_read+0x40/0xb0 ra : pci_generic_config_read+0x2c/0xb0 [] pci_generic_config_read+0x40/0xb0 [] pci_bus_read_config_dword+0x50/0xb0 [] pci_bus_generic_read_dev_vendor_id+0x3c/0x1ec [] pci_scan_single_device+0xa4/0x11c [] pci_scan_slot+0x9c/0x23c [] pci_scan_child_bus_extend+0x58/0x2f4 [] pci_scan_root_bus_bridge+0x64/0xe8 [] pci_host_probe+0x20/0xc8 [] pci_host_common_probe+0x144/0x1e4 Fix this by giving the CAM ops the same ->add_bus/->remove_bus callbacks. Since pci_ecam_add_bus() and pci_ecam_remove_bus() are static to ecam.c, move the CAM ops definition there as pci_generic_cam_ops (mirroring pci_generic_ecam_ops) and export it for pci-host-generic.c to reference. [mani: removed timestamp from log]", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1111.116 -proposed tracker (LP: #2170108)", "", " [ Ubuntu: 5.15.0-202.212 ]", "", " * jammy/linux: 5.15.0-202.212 -proposed tracker (LP: #2170970)", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603)", " - bus: fsl-mc: wait for the MC firmware to complete its boot", " - ALSA: usb-audio: Propagate write errors in generic mixer put callbacks", " - ima: return error early if file xattr cannot be changed", " - tee: optee: Allow MT_NORMAL_TAGGED shared memory", " - PCI: Stop setting cached power state to 'unknown' on unbind", " - hfsplus: fix issue of direct writes beyond end-of-file", " - wifi: mac80211: always allow transmitting null-data on TXQs", " - kcsan: Silence -Wmaybe-uninitialized when calling __kcsan_check_access()", " - bridge: Do not suppress ARP probes and DAD NS unconditionally", " - soundwire: validate DT compatible before parsing it", " - media: rc: mceusb: Add support for 04eb:e033", " - s390/cio: Purge based on the cdev's online status", " - thunderbolt: Keep the domain reference while processing hotplug", " - net: dsa: mv88e6xxx: fix number of g1 interrupts for 6320 family", " - net: dsa: mv88e6xxx: define .pot_clear() for 6321", " - net: dsa: mv88e6xxx: enable .rmu_disable() for 6320 family", " - media: em28xx-video: fix missing res_free() on init_usb_xfer failure", " - clk: renesas: cpg-mssr: Add number of clock cells check", " - ASoC: ti: omap3pandora: update board check to use DT compatible", " - mmc: core: Add validation for host-provided max_segs", " - drm/amd/display: Fix CRC open failure during active rendering", " - hfsplus: rework hfsplus_readdir() logic", " - drm/gud: Add RCade Display Adapter VID/PID pair", " - integrity: Check for NULL returned by asymmetric_key_public_key", " - scsi: pm8001: Reject firmware update in fatal error state", " - scsi: pm8001: Reject non-fatal dump when controller is crashed", " - crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y", " - crypto: atmel-ecc - add support for atecc608b", " - media: imon: Add iMON VFD HID OEM v1.2 key mappings", " - RDMA/mlx5: Use QP port when decoding responder CQEs", " - mailbox: Make mbox_send_message() return error code when tx fails", " - ALSA: usx2y: Drain pending US-428 pipe-4 output commands", " - 9p: invalidate readdir buffer on seek", " - arm64/daifflags: Make local_daif_*() helpers __always_inline", " - firmware: arm_scmi: Validate SENSOR_UPDATE payload size", " - firmware: arm_scmi: Validate BASE_ERROR_EVENT payload size", " - bitfield: wire __bf_shf to __builtin_ctzll", " - net: usb: qmi_wwan: add MeiG SRM813Q", " - net: bridge: remove stale rcu_barrier() in br_multicast_dev_del()", " - net/sched: sch_drr: make cl->quantum lockless", " - befs: handle set_blocksize failures", " - minix: handle set_blocksize failures", " - isofs: handle set_blocksize failures", " - usb: host: add ARCH_AIROHA in XHCI MTK dependency", " - char/nvram: Remove redundant nvram_mutex", " - netlabel: fix IPv6 unlabeled address add error handling", " - rds: annotate data-race around rs_seen_congestion", " - s390/zcore: Removed unused variables", " - clk: socfpga: agilex: implement l3_main_free_clk", " - drm/panel: simple: Add AM-1280800W8TZQW-T00H", " - mips: cps: Assemble jr.hb with an R2 ISA level", " - iio: adc: qcom-spmi-iadc: balance enable_irq_wake() on driver unbind", " - irqchip/gic-v4: Don't advertise VLPIs if no ITS is probed", " - ALSA: usb-audio: Add quirk for Novation Mininova", " - drm/amd/pm/si: Fix updating clock limits from power states", " - ACPICA: Improve argument parsing in acpi_ps_get_next_simple_arg()", " - hfs: rework hfsplus_readdir() logic", " - host1x: bus: Fix missing ops null check in error teardown", " - scripts: modpost: detect and report truncated buf_printf() output", " - ASoC: Intel: catpt: Complete coredump handling", " - soundwire: only handle alert events when the peripheral is attached", " - mmc: davinci: fix mmc_add_host order in probe", " - mmc: renesas_sdhi: Add OF entry for RZ/G2N SoC", " - mmc: renesas_sdhi: Add OF entry for RZ/G2E SoC", " - iio: accel: mma8452: switch to non-devm request_threaded_irq()", " - libbpf: Also reset {insn,data}_cur on realloc failure", " - net: ibm: emac: Reserve VLAN header in MJS limit", " - ASoC: codecs: pcm3168a: Drop CONFIG_PM-conditional preproc directive", " - ACPI: PCI: Clear _DEP dependencies after PCI root bridge attach", " - iommu/rockchip: disable fetch dte time limit", " - ASoC: codecs: rk3328: Use managed GPIO and clock helpers", " - ALSA: seq: oss: Reject reads that cannot fit the next event", " - dpaa2-switch: fix the error path in dpaa2_switch_rx()", " - clk: keystone: don't cache clock rate", " - ALSA: hda/realtek: Add quirk for ASUS VivoBook X509DAP", " - ipmi: si: Use platform_get_irq_optional() to retrieve interrupt", " - wifi: nl80211: Increase ie_len size to prevent truncated IEs in new peer", " notifications", " - RDMA/mlx5: Fix state and counter desync on loopback enable failure", " - net: cpsw_new: unregister devlink on port registration failure", " - xprtrdma: Add request-pool slack for delayed recycling", " - configfs_depend_prep(): pass configfs_dirent instead of dentry", " - platform/x86: dell-laptop: add Inspiron N5110 to touchpad LED quirk", " table", " - wifi: mt76: transform aspm_conf for pci_disable_link_state", " - btrfs: protect sb_write_pointer() with invalidate lock", " - hwmon: (adt7462) Add of_match_table to support devicetree", " - ata: libata-pmp: add JMicron JMS562 quirk", " - platform/x86: intel-hid: Add HP ProBook x360 440 G1 to", " button_array_table", " - sctp: Unwind address notifier registration on failure", " - PCI: Avoid SBR for Qualcomm WCN6855/WCN7850 WiFi, SDX62/SDX65 modems", " - dmaengine: dw-axi-dmac: fix PM for system sleep and channel alloc", " - hwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i", " - ASoC: rockchip: rockchip_pdm: Reorder clock enable sequence", " - ASoC: rockchip: spdif: Restore regcache cache-only mode on sync failure", " - sparc64: uprobes: add missing break", " - ptp: ocp: add shutdown callback", " - vsock: use sk_acceptq_is_full() helper in all transports", " - e1000e: limit endianness conversion to boundary words", " - net/sched: act_csum: don't mangle UDP tunnel GSO packets", " - i3c: mipi-i3c-hci: Tolerate i3c_master_add_i3c_dev_locked() failures in", " DAA", " - sparc: Disable compat support with LLD", " - fuse: set ff->flock only on success", " - scsi: bfa: Reduce kernel stack usage in", " bfa_fcs_lport_fdmi_build_portattr_block()", " - gpio: pisosr: Read \"ngpios\" as u32", " - ALSA: hda/conexant: Add pin config quirk for Lenovo IdeaPad Slim 5", " 16AKP10", " - leds: uleds: Return -EFAULT on copy_to_user() failure", " - leds: pca9532: Don't stop blinking for non-zero brightness", " - mfd: rsmu: Add 8a34002 support", " - ALSA: usb-audio: Add quirk for YAMAHA CDS3000", " - md/raid5: account discard IO", " - md/raid5: let stripe batch bm_seq comparison wrap-safe", " - rtc: aspeed: add AST2700 compatible", " - ksmbd: use connection ClientGUID for lease lookup", " - ksmbd: treat unnamed DATA stream as base file", " - ksmbd: apply create security descriptor first", " - ksmbd: break RH leases before delete-on-close", " - PCI/sysfs: Use kstrtobool() to parse the ROM attribute input", " - rtc: bq32000: add delay between RTC reads", " - fbdev: pm2fb: unwind WC setup on probe failure", " - drm/arm/malidp: use clk_bulk API in runtime PM resume and suspend", " - netfilter: nf_conntrack_expect: zero at allocation time", " - drm/arm/komeda: fix error handling for clk_prepare_enable() and callers", " - ksmbd: fix n.data memory leak in ksmbd_vfs_set_dos_attrib_xattr", " - xen/front-pgdir-shbuf: free grant reference head on errors", " - freevxfs: don't BUG() on unknown typed-extent type", " - xen/gntalloc: validate grant count before allocation", " - ksmbd: fix credit charge calculation for SMB2 QUERY_INFO", " - wifi: ralink: RT2X00: init EEPROM properly", " - wifi: mac80211: validate deauth frame length before reason access", " - wifi: libertas: reject short monitor TX frames", " - ksmbd: find bound sessions during reauthentication", " - ksmbd: mark invalid session responses as signed", " - ksmbd: validate SID namespace before mapping IDs", " - gpio: dwapb: Mask interrupts at hardware initialization", " - netfilter: ipset: mark the rcu locked areas properly", " - btrfs: only account delalloc bytes for regular file inodes in", " btrfs_getattr()", " - wifi: iwlwifi: mvm: fix sched scan IE sizing", " - arm64: fixmap: Allow 256K early_ioremap() at any offset", " - arm64: kprobes: Allow reentering kprobes while single-stepping", " - drm/amd/pm/si: Don't schedule thermal work when queue isn't initialized", " - ALSA: usb-audio: Add FIXED_RATE quirk for JBL Quantum650 Wireless", " - wifi: mwifiex: replace one-element arrays with flexible array members", " - regulator: core: clamp voltage constraints before applying apply_uV", " - wifi: mac80211_hwsim: reject undersized HWSIM_ATTR_TX_INFO", " - drm/gma500: return errors from Oaktrail HDMI I2C reads", " - phonet: check register_netdevice_notifier() error in", " phonet_device_init()", " - ALSA: hda/realtek: Add mute LED quirk for HP Laptop 14s-dr1xxx", " - ice: pass the return value of skb_checksum_help()", " - powerpc/pseries: Ensure vpa,slb_shadow & dtl are unregistered during", " crash", " - ALSA: usb-audio: Add quirk for Corsair Virtuoso (later revision)", " - ASoC: rt5645: Perform the initial jack detect at probe", " - clk: at91: pmc: #undef field_{get,prep}() before definition", " - Revert \"Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU\"", " - Revert \"Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU\"", " - ARM: 9484/1: enable interrupts when unhandled user faults are triggered", " - EDAC/igen6: Fix interleave boundary condition", " - EDAC/igen6: Fix channel selection hash", " - EDAC/igen6: Fix channel address decode for non-hash mode", " - drm/virtio: Fix a NULL vs ERR_PTR() bug in", " virtio_gpu_user_framebuffer_create()", " - selftests/cgroup: Fix cg_run_in_subcgroups ignoring arg parameter", " - net/sched: act_api: budget all shared attributes in notify skbs", " - net/sched: act_api: size the RTM_GETACTION reply from the actions", " - smb: client: transport: Fix debug printing in __release_mid()", " - net: amd-xgbe: discard rx packets with bad FCS", " - OPP: of: Fix potential multiplication overflow when calculating freq", " - Bluetooth: L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM", " - Bluetooth: hci_mrvl: Fix wrong return value check of", " wait_on_bit_timeout()", " - ASoC: ab8500: Reset the audio block before configuring it", " - ASoC: ab8500: Repair the DAPM capture graph", " - ASoC: ab8500: Update to modern clocking terminology", " - ASoC: ab8500: Correct digital interface format setup", " - ASoC: ab8500: Validate and program TDM slots correctly", " - tty: make tty_ldisc_ops::hangup return void", " - ppp: ppp_async: simplify tty disc_data access", " - ASoC: amd: renoir: fix disable_pdm_interrupts() to clear mask bits", " - btrfs: consolidate device_list_mutex in prepare_sprout to its parent", " - scsi: mpt3sas: Use irq_set_affinity_and_hint()", " - perf/core: Skip empty AUX records with only format flags", " - locking/lockdep: Introduce lock_sync()", " - locking/lockdep: Improve the deadlock scenario print for sync and read", " lock", " - lockdep: Add lock_set_cmp_fn() annotation", " - locking/lockdep: Invalidate stale class_cache entries for zapped classes", " - ASoC: ux500: Fix MSP stream lifecycle handling", " - ASoC: ux500: remove platform_data support", " - ASoC: ux500: Propagate MSP setup errors", " - ASoC: ux500: Correct MSP frame and bit clock setup", " - ASoC: ux500: Validate MSP DAI configuration", " - ASoC: ux500: remove stedma40 references", " - ASoC: ux500: Request the MSP MMIO resource", " - ASoC: ux500: Program the MSP FIFO watermarks", " - net/rds: use clear_bit_unlock() in release_refill()", " - net/rds: tcp: don't force RDS_CONN_RESETTING over a concurrent shutdown", " - net: stmmac: reconfigure RX packet parser table in stmmac_hw_setup()", " after reset", " - bonding: use skb_cow_head() in bond_do_alb_xmit() and rlb_arp_xmit()", " - powerpc/kexec_file: Use inclusive range checks in add_usable_mem()", " - net/mlx5e: Fix setting RS FEC after remapping", " - net/mlx5e: Fix ETS zero BW reporting when one TC holds 100%", " - net_sched: sch_fq_pie: implement lockless fq_pie_dump()", " - net/sched: pie: clamp psched_mtu in pie_drop_early", " - ASoC: bcm: bcm63xx: Publish the OF module aliases", " - ASoC: Intel: SST: Publish the PCI module aliases", " - netfilter: ip6_tables: set F_PROTO when proto value is nonzero", " - ASoC: mt6351: Publish the OF module alias", " - virtio-console: call scheduler when we free unused buffs", " - vdpa_sim_blk: use dev_dbg() to print errors", " - vdpa_sim_blk: make vdpasim_blk_check_range usable by other requests", " - virtio-pci: return IRQ_HANDLED after non-zero ISR", " - net: ipv6: Clamp to IP6_MAX_MTU in ip6_dst_mtu_maybe_forward", " - net: ethernet: cortina: Finish RX updates before NAPI completion", " - net: ethernet: cortina: No mapping is a dropped rx", " - net: ethernet: cortina: Count RX drops once per frame", " - net: ethernet: cortina: Count RX descriptors for freeq refill", " - watchdog: fix hrtimer start when pretimeout is zero", " - hwmon: (gpio-fan) take fan_data->lock in gpio_fan_shutdown()", " - hwmon: (aspeed-pwm-tacho) Propagate reset deassert errors", " - net: stmmac: optimize locking around PTP clock reads", " - net: sun4i-emac: fix missing of_node_put() for phy_node", " - octeontx2-af: fix PF/CGX debugfs PCI bus lookup", " - net/rds: Pass a pointer to virt_to_page()", " - scsi: target: iscsi: Handle abort for WRITE_PENDING cmds", " - Revert \"scsi: smartpqi: Fix AIO retry marker cleared by SCSI core", " between dispatches.\"", " - Revert \"scsi: smartpqi: Fix BUILD_BUG_ON() statements\"", " - Revert \"scsi: core: Register sysfs attributes earlier\"", " - Revert \"scsi: smartpqi: Capture controller reason codes\"", " - ALSA: ctxfi: Fix CA20K2 S/PDIF passthrough", " - dm/amdgpu: fix malformed link_settings debugfs output", " - watchdog: sunxi_wdt: preserve boot-enabled watchdog", " - tunnels: Drop stale dst when building an ICMP error for PMTUD", " - exec: do_close_on_exec() before taking exec_update_lock", " - net: hso: fix TIOCMIWAIT race", " - netfilter: report NLM_F_DUMP_FILTERED when all is filtered out", " - KVM: PPC: Book3S HV: Set irqfd->producer only on success", " - s390/qeth: allow bridgeport queries despite OS_MISMATCH", " - hwmon: (applesmc) fix key backlight workqueue leak on register failure", " - hwmon: (pmbus) Clear generic status alarms with CLEAR_FAULTS", " - media: hevc: add bounded tile-count helpers", " - media: v4l2-h264: Fix memcmp() size in B1 reference list comparison", " - mptcp: options: handle MPC data + csum reqd + no csum", " - Revert \"perf tests: Fix flakiness in BPF counters test on hybrid", " systems\"", " - [Config] remove CRYPTO_DEV_SUN8I_CE_PRNG", " - [Config] remove CRYPTO_DEV_SUN8I_SS_PRNG", " - netfilter: nft_set_pipapo_avx2: add missing vzeroupper", " - ARM: fix hash_name() fault", " - ARM: fix branch predictor hardening", " - ARM: ensure interrupts are enabled in __do_user_fault()", " - Bluetooth: L2CAP: Fix deadlock", " - Revert \"alpha: don't leak hardware-fabricated FP exception bits to user", " space\"", " - Revert \"alpha: fix ieee_swcr_to_fpcr setting FPCR_DNOD unconditionally\"", " - selftests/landlock: Add tests for whiteout object creation", " - sunvdc: fix -EIO issue due to lack of retries", " - Revert \"perf cs-etm: Avoid truncating AUX buffer sizes to int\"", " - Revert \"perf cs-etm: Flush thread stacks after decoder reset\"", " - media: video-i2c: fix buffer queue ordering", " - ipv6: Select best matching nexthop object in fib6_table_lookup()", " - ipv6: Honor oif when choosing nexthop for locally generated traffic", " - xfrm: propagate extack to all netlink doit handlers", " - xfrm: add extack to verify_sec_ctx_len", " - xfrm: add extack support to verify_newsa_info", " - xfrm: add extack to verify_one_alg, verify_auth_trunc, verify_aead", " - xfrm: avoid RCU warnings around the per-netns netlink socket", " - xfrm: fix compat ALLOCSPI request use-after-free", " - xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for", " xfrm_trans_reinject()", " - ARM: socfpga: select the PL310 erratum 753970 workaround", " - RDMA/siw: Introduce siw_cep_set_free_and_put", " - RDMA/siw: Cleanup siw_accept", " - RDMA/siw: Clear association under lock if siw_qp_modify fails in", " siw_accept", " - firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS", " - clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate", " - IB/iser: Align coding style across driver", " - IB/iser: Remove iser_reg_data_sg helper function", " - IB/iser: Use iser_fr_desc as registration context", " - IB/iser: reject a remote invalidation of an unregistered direction", " - scsi: target: iscsi: Rename iscsi_cmd to iscsit_cmd", " - IB/isert: wait for deferred control PDU completions before releasing the", " connection", " - RDMA/mad: Fix receive buffer leak when PKey enforcement fails", " - RDMA/irdma: Enforce local fence for IB_WR_REG_MR", " - RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted", " - dmaengine: sprd: Fix runtime PM reference leak in probe", " - wifi: virt_wifi: free skb when disconnected", " - wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path", " - wifi: libipw: reject too-short beacon and probe responses", " - wifi: libipw: reject too-short association responses", " - IB/IPoIB: Avoid restoring OPER_UP after multicast flush", " - wifi: cfg80211: check IP header size in cfg80211_classify8021d()", " - soundwire: cadence_master: wait and cancel cdns->work before clock stop", " - MIPS: Octeon: apply USB FDT fixups also when USB is modular", " - dma-coherent: Warn if OF reserved memory is beyond current coherent DMA", " mask", " - dma-coherent: report a failed reserved memory assignment", " - dmaengine: Fix device kref underflow in dma_chan_put()", " - dmaengine: fix use-after-free in dma_chan_put() and", " dma_release_channel()", " - dmaengine: wait for RCU readers before releasing dma_device", " - wifi: cfg80211: only group hidden BSSes with beacon entries", " - wifi: cfg80211: don't filter by BSS type when removing stale entries", " - wifi: mac80211: suppress chanctx warning for debugfs reset", " - wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown", " - wifi: mac80211: don't RCU-dereference the mesh CSA settings we just set", " - wifi: mac80211: don't access the TSF of a down interface", " - dmaengine: xilinx_dma: Fix hardware buffer descriptor reuse order", " - dmaengine: xilinx_dma: Fix hardware buffer descriptor chain after cyclic", " DMA", " - RDMA/siw: Bound fragmented header copies by the remaining length", " - netfilter: nft_nat: fully initialise new_addr in netmap setup", " - netfilter: flowtable: hold reference on ct until flow is released", " - drm: Fix drm_pending_vblank_event leak in error path for out_fence_ptr", " - keys: fix lost wakeup when reaping a dead key type", " - ALSA: pcm: set timer->private_data before registering the PCM timer", " - Input: trackpoint - fix the inertia attribute name in the ABI document", " - wifi: virt_wifi: don't transfer operstate before register", " - ALSA: hda: trace PCM open only after assigning a stream", " - btrfs: tree-checker: print dev extent offset in error message", " - drm/msm/dsi: correct byte intf clock rate for 14nm DSI PHY", " - drm/msm/dsi: round the byte clock rate after reparenting to the PHY PLL", " - seg6: set IPSKB_L3SLAVE from IP6SKB_L3SLAVE on IPIP decapsulation", " - net: fddi: skfp: fix NULL deref when setting the MAC address while down", " - wifi: brcmfmac: fix lost 802.1x TX completion wakeup", " - tcp: Don't call skb_clone_and_charge_r() for close()d listener in", " tcp_v6_do_rcv().", " - tcp: do not let tcp_rmem be set below 4096", " - dmaengine: mmp_pdma: fix wrong sg length in mmp_pdma_prep_slave_sg()", " - Bluetooth: btmtksdio: Fix PM runtime reference leak in shutdown", " - Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup", " - pppoatm: ensure a writable skb header and linear data", " - drop_monitor: synchronize tracepoint unregistration on error path", " - drop_monitor: fix out-of-bounds write in reset_per_cpu_data()", " - KVM: PPC: Book3S HV: fix secure device page leak on uv_page_in() failure", " - powerpc/iommu: Fix the overflow validation in iommu_tce_check_ioba", " - ASoC: ux500: Parenthesize MSP_{RX,TX}_CLKPOL_BIT() arguments", " - ASoC: hdmi-codec: Report a change when the channel status moves", " - net: netsec: fix device_node reference leak on phy_np", " - net: lock the socket in sock_gettstamp()", " - net: ethernet: cortina: Ack RX overrun interrupt correctly", " - net: mvpp2: prevent buffer overflow in page_pool allocation", " - Input: eeti_ts - publish the OF module alias", " - Input: xpad - add support for Victrix Pro BFG Controller", " - Input: xpad - add support for Azeron devices", " - Input: xpad - fix PDP Marvel Xbox 360 controller", " - ata: libahci: clear PxCLBU and PxFBU for AHCI_HFLAG_32BIT_ONLY", " - rds: ib: use rds_conn_drop() on protocol version mismatch", " - tcp: exclude old ACKs from tcp fast path", " - RDMA/ucma: Serialize join and leave on copy_to_user failure", " - RDMA/core: fix refcount bug in iwpm_get_nlmsg_request()", " - openvswitch: avoid reallocating confirmed conntrack labels", " - net: xfrm: reject unrepresentable espintcp transport headers", " - kselftest/arm64: Fix size of thread_data values for pthread_join()", " - arm64: percpu: Fix this_cpu_write() casting", " - arm64: percpu: Fix this_cpu_and() mask generation", " - Bluetooth: btusb: fix NXP IW610 composite device handling", " - dmaengine: sun6i: fix non-atomic read of DMA position registers", " - dmaengine: sun6i: fix undefined behaviour in sun6i_dma_tx_status", " - dmaengine: ti: k3-udma-glue: fix NULL dereference in", " k3_udma_glue_release_rx_chn()", " - ipv6: xfrm: use full sockets in local error paths", " - net: wwan: mhi_wwan_mbim: guard against a cyclic NDP chain", " - net: wwan: mhi_wwan_mbim: check skb_copy_bits() return value", " - net/sched: hhf: cap hh_flows_limit at change time", " - net/packet: clear RX owner on VNET header error", " - net/packet: avoid truncating TPACKET_V3 private size", " - keys: translate request_key_auth pid for the reading procfs instance", " - KEYS: trusted: Fix tpm2_load_cmd() boundary check", " - i2c: at91: release DMA channels on remove and probe error", " - i2c: imx: release DMA channels on probe error", " - IB/mlx4: Fix use-after-free on pkey sysfs registration failure", " - selinux: always fill AVC decision in avc_has_perm_noaudit()", " - mmc: core: Fix OF node reference leak on card add failure", " - mmc: mxcmmc: cancel data work and watchdog on remove", " - mmc: rtsx_pci_sdmmc: ignore broken write-protect on ThinkPad X260", " - mmc: sdhci-of-aspeed: Remove children before releasing SDC resources", " - mmc: sdio_uart: fix xmit_fifo leak when the port table is full", " - mmc: sh_mmcif: initialize IRQ-thread mutex before requesting interrupt", " - mmc: spi: reset bytes_xfered before retrying CRC failures", " - mmc: sdhci_am654: Reset command and data lines on failed tuning", " - Input: atkbd - skip deactivate for Xiaomi Redmi Book Pro 16 2026", " - Input: evdev - zero absinfo before partial copy in EVIOCSABS", " - Input: i8042 - add quirk for Acer Aspire Go 15 AG15-42P", " - Input: rmi_smbus - fix out-of-bounds read in rmi_smb_write_block()", " - Input: soc_button_array - fix MS Surface Pro 11 probe failure", " - Input: soc_button_array - check btns_desc->package.count", " - Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722)", " - Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound", " - Input: zero ff_effect before compat copy in input_ff_effect_from_user", " - hwmon: (pmbus/core) increase number of phases and add new mask", " - hwmon: (pmbus/tps53679) Fix TPS53676 phase page decoding", " - hwmon: (pmbus/tps53679) Select page 0 for single-page TPS53676", " - hwmon: (w83791d) remove fan/pwm 4-5 sysfs group on remove", " - hwmon: (w83793) release probe data through kref", " - watchdog: digicolor: Avoid division by zero", " - watchdog: msc313e: Fix premature reset during timeout update", " - watchdog: sp5100_tco: Fix pci_dev reference leak in sp5100_tco_init()", " - wifi: brcmsmac: fix UAF in brcms_free_timer()", " - wifi: iwlegacy: fix broadcast stations deallocation", " - wifi: libertas_tf: fix UAF in lbtf_free_adapter()", " - wifi: rsi: fix heap OOB write on key removal", " - wifi: wlcore: release runtime PM ref on regdomain config failure", " - wifi: wilc1000: fix out-of-bounds read in P2P public action frames", " - wifi: wilc1000: fix RX buffer OOB-write in wilc_wlan_handle_isr_ext()", " - wifi: p54: validate curve data length in the calibration curve", " converters", " - wifi: p54: require a full exp_if record in PDR_INTERFACE_LIST", " - wifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length", " - wifi: mwifiex: validate scan response extents", " - wifi: mwifiex: validate action frame fixed fields", " - wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver", " - drm/gud: fix out-of-bounds write in gud_plane_atomic_check()", " - drm/msm/adreno: fix autosuspend cleanup during teardown", " - drm/msm/hdmi_phy: fix runtime PM cleanup on probe failure", " - HID: logitech-hidpp: fix race condition when accessing stale stack", " pointer", " - spi: spi-zynqmp-gqspi: stop the controller on shutdown", " - spi: zynqmp-gqspi: Use devm_spi_alloc_host()", " - erofs: fix atomic context detection when !CONFIG_DEBUG_LOCK_ALLOC", " - HID: hyperv: streamline driver probe to avoid devres issues", " - bpf: Fix bpf_skb_change_tail wrt csum partial skbs", " - bpf: Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL", " - bpf: support access variable length array of integer type", " - bpf: Fix divide-by-zero in btf_struct_walk()", " - HID: elecom: fix bus type for M-XGL20DLBK", " - bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch()", " - bpf: Fix out-of-bounds read of rtt_min in sock_ops", " - HID: amd_sfh: Move common macros and structures", " - HID: amd_sfh: Validate PCI BAR size before mapping", " - squashfs: Add dictionary size range check to prevent shift-out-of-bounds", " - Bluetooth: SMP: reject Security Request over BR/EDR", " - Documentation: s390: correct spelling", " - docs: s390/pci: Improve and update PCI documentation", " - s390/pci/docs: Fix sriov_numvfs attribute name", " - s390/cio: Fix cio_update_schib() to not cache invalid schib", " - s390/cio: Check pmcw.dnv before pmcw.ena in I/O entry points", " - xsk: Use a 32-bit compare in xsk_map_gen_lookup", " - libbpf: Fix an error in 64bit relocation value computation", " - bpf: Restrict CO-RE poisoning to relocatable instructions", " - netfilter: flowtable: allow unidirectional rules", " - netfilter: flowtable: publish HW_DEAD after worker is done", " - netfilter: nfnetlink_queue: nfqnl_instance GFP_ATOMIC ->", " GFP_KERNEL_ACCOUNT allocation", " - netfilter: nfnetlink_queue: hold nfnl mutex in event notifier", " - netfilter: nft_synproxy: use the family-aware checksum helper", " - ipvs: revalidate ihl before icmp_send", " - ocfs2: make ocfs2_calc_xattr_init() return void", " - drm/nouveau/clk: fix list cursor use after loop in", " nvkm_clk_ustate_update", " - drm/nouveau/clk: don't clobber reclock status when restoring volt/fan", " - net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure", " - net: gue: reject invalid REMCSUM offsets", " - ip6_gre: Call ip6erspan_tunnel_unlink_md() in ip6erspan_changelink().", " - sctp: avoid livelock while updating retransmit path", " - net: usb: catc: bound the RX packet length in catc_rx_done()", " - net/sched: sch_hfsc: bound the classify inner-filter walk with a drift", " budget", " - drm/virtio: fix object leak when drm_gem_handle_create() fails", " - drm/virtio: fix object leak in virtio_gpu_resource_create_ioctl()", " - drm/virtio: fix object leaks in virtio_gpu_resource_create_blob_ioctl()", " - drm/virtio: release the GEM object on virtio_gpu_vram_create() errors", " - Bluetooth: bnep: fix out-of-bounds reads on short RX/TX frames and", " control fallthrough", " - Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame()", " - net: usb: sr9700: include receive overhead in the length check", " - tg3: clean up PHYLIB resources on probe failure", " - s390/debug: Do not register views for failed static debug areas", " - s390/debug: Fix NULL pointer dereference in debug_info_copy()", " - net: ethernet: ti: netcp: fix pm_runtime usage counter leak on error", " - bpf: Fix bpf_sock context code generation", " - bpf, sockmap: Reject max_entries > INT_MAX in sock_map_alloc", " - sctp: hold asoc or transport before mod_timer() in timer handlers", " - net: stmmac: selftests: Support running selftests on DSA conduits", " - net: stmmac: selftests: Check the dev->features for S-TAG offload", " testing", " - net: stmmac: selftests: Capture all packets for vlan checks", " - net: stmmac: Remove some unnecessary void pointers", " - net: stmmac: dwmac4: Use the correct bufzise when the len is exactly 8K", " - nfc: nfcmrvl: validate helper command length before pull", " - nfc: st21nfca: remove redundant assignment to variable i", " - nfc: st21nfca: validate received frame size", " - nfc: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm()", " - selftests: nci: Correct pthread_create return value check", " - nfc: llcp: Fix race condition in accept_queue lifecycle", " - selftests: nci: Fix uninitialized family ID on missing attribute", " - selftests/nci: Fix out-of-bounds store on thread join", " - nfc: virtual_ncidev: Add missing ioctl compat handler", " - nfc: llcp: fix sdreq TLV list leak on parse/alloc/send failure", " - nfc: st21nfca: validate ISO15693 inventory length", " - nfc: llcp: fix -ENOMEM on connect with zero-length service name", " - nfc: llcp: fix WKS SAP hijacking via prefix match in nfc_llcp_wks_sap()", " - nfc: llcp: fix slab-out-of-bounds reads when logging service names", " - nfc: pn533: fix OOB read in pn533_acr122_is_rx_frame_valid()", " - veth: manage XDP program pointers during channel resize", " - net: skbuff: fix pull-bound underflow in skb_checksum_setup_ipv6()", " - vrf: Stop corrupting skb->csum when capturing CHECKSUM_COMPLETE packets", " - net: bcmgenet: validate Ethernet address in bcmgenet_set_mac_addr", " - ip_gre: Reject enabling collect metadata through changelink", " - net: xps: reject an out of range traffic class", " - tcp: fix use-after-free of retransmit_skb_hint in tcp_send_synack()", " - net/smc: fix UAF on lgr list traversal in smcr_port_err()", " - tipc: Fix a data race on mon->peer_cnt in mon_timeout()", " - llc: fix skb UAF and leaks on llc_mac_hdr_init() failure", " - bridge: check llc_mac_hdr_init() return value in br_send_bpdu()", " - net/sched: sch_teql: fix shadowed err in __teql_resolve()", " - vlan: ensure sufficient headroom in vlan_dev_hard_header()", " - autofs: fix sbi->pipe file reference leak in autofs_kill_sb()", " - rculist: add list_splice_rcu() for private lists", " - KVM: x86/mmu: Use a bool for direct", " - KVM: x86/mmu: Stop passing \"direct\" to mmu_alloc_root()", " - KVM: MMU: update comment on the number of page role combinations", " - KVM: X86: Remove useless code to set role.gpte_is_8_bytes when", " role.direct", " - KVM: X86: Calculate quadrant when !role.gpte_is_8_bytes", " - KVM: X86: Rename gpte_is_8_bytes to has_4_byte_gpte and invert the", " direction", " - KVM: x86/mmu: Derive shadow MMU page role from parent", " - KVM: x86/mmu: Always pass 0 for @quadrant when gptes are 8 bytes", " - SAUCE: Revert \"KVM: x86: Fix shadow paging use-after-free due to", " unexpected role\"", " - KVM: x86/mmu: pull call to drop_large_spte() into __link_shadow_page()", " - KVM: x86: Fix shadow paging use-after-free due to unexpected role", " - x86/PCI: Disable enhanced atomics on AMD NBIO 7.7 and 7.11", " - tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers", " underflow", " - sctp: discard the rest of the packet on a stale-cookie error", " - af_packet: fix integer overflow in prb_calc_retire_blk_tmo()", " - fou: reject omitted FOU_ATTR_IPPROTO on FOU_ENCAP_DIRECT", " - workqueue: Fix NULL current_pwq deref in flush dependency check", " - writeback: report a Tasks-RCU quiescent state per cgwb drain pass", " - fsl/fman: Fix clk reference leak in read_dts_node()", " - ipv6: do not let ipv6_find_hdr() return an offset past the packet end", " - ipv6: sr: enforce exact attribute length for SEG6_ATTR_DST", " - gpio: arizona: Fix runtime PM leak in arizona_gpio_direction_out()", " - gpio: zynq: fix runtime PM leak on request error path", " - llc: reserve device headroom for allocated frames", " - rds: ib: Clear the sg list when mapping an MR fails", " - drm/nouveau: fix autosuspend cleanup during teardown", " - drm/nouveau: Fix bridge reference leak in nv1a_ram_new()", " - drm/nouveau: fix double-free in nvif_vmm_dtor", " - drm/nouveau: Fix gem reference leak in validate_init()", " - drm/nouveau: don't bump pin count on failed re-pin in", " nouveau_bo_pin_locked()", " - HID: alps: fix use-after-free on input2 registration failure", " - HID: quirks: add ALWAYS_POLL quirk for SDINNOVATION gaming keyboard", " - HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()", " - net/mlx5: Fix rev_entry reference leak in", " mlx5_tc_ct_shared_counter_get()", " - net/sched: reject IDR error pointers when deleting actions", " - net: arp: terminate device name before lookup", " - net: atl1: fix soft lockup on out-of-range cmb_tpd_next_to_clean read", " - net: hisilicon: hns_dsaf_mac: fix mdio device leak in", " hns_mac_register_phy()", " - net: openvswitch: conntrack: avoid modifying shared unconfirmed ct entry", " - net: atl1c: fix soft lockup on out-of-range tpd_cons read", " - net: atl1e: fix soft lockup on out-of-range hw_next_to_clean read", " - net: usb: cdc_mbim: add MeiG Smart SRM821 to ZLP whitelist", " - netfilter: ip6t_rpfilter: reject routes without inet6_dev", " - netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds read", " - nfc: fix use-after-free in nfc_get_local_general_bytes", " - nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc()", " - nfc: port100: reject frames whose declared length exceeds the received", " data", " - scsi: libiscsi_tcp: Check the data direction of a Data-In PDU", " - pinctrl: single: free the IRQ on domain creation failure", " - s390/cio: Fix NULL pointer dereference in ccw_device_get_util_str()", " - Bluetooth: hci_sock: validate event length before filtering", " - Bluetooth: hci_sock: reject out-of-range OCF values", " - Bluetooth: L2CAP: validate frame length before control and FCS access", " - Bluetooth: RFCOMM: fix NULL dereference of dlc->session in", " RFCOMM_CONNINFO", " - xfs: fix blockgc group quota scanning when usrquota isn't enforced", " - net: tls: fix silent data drop under pipe back-pressure", " - file: add fput() cleanup helper", " - eventpoll: use hlist_is_singular_node() in __ep_remove()", " - eventpoll: split __ep_remove()", " - eventpoll: kill __ep_remove()", " - eventpoll: drop vestigial __ prefix from ep_remove_{file,epi}()", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: move epi_fget() up", " - perf test: Change all remaining #!/bin/sh to #!/bin/bash", " - tools/thermal/tmon: Fix compilation warning for wrong format", " - lan78xx: Enable 125 MHz CLK configuration for LAN7801 if NO EEPROM is", " detected", " - lan78xx: Enable Auto Speed and Auto Duplex configuration for LAN7801 if", " NO EEPROM is detected", " - Linux 5.15.222", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2025-68190", " - drm/amdgpu/atom: Check kcalloc() for WS buffer in", " amdgpu_atom_execute_table_locked()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-46242", " - eventpoll: fix ep_remove struct eventpoll / struct file UAF", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2025-38349", " - eventpoll: don't decrement ep refcount while still holding the ep mutex", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2025-37964 -- to the 6.1, 6.6 and 6.12 trees ended up with two", " - x86/mm: Fix check/use ordering in switch_mm_irqs_off()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-80726", " - KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow", " page", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-46113", " - KVM: x86: Fix shadow paging use-after-free due to unexpected GFN", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-52988", " - netfilter: nf_tables: join hook list via splice_list_rcu() in commit", " phase", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2023-53231", " - erofs: Fix detection of atomic context", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2023-53707", " - drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2024-49568", " - net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal", " msg", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-89560", " - landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2024-41062", " - bluetooth/l2cap: sync sock recv cb and release", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2022-50406", " - iomap: iomap: fix memory corruption when recording errors during", " writeback", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97523", " - mptcp: close race between scheduler and state change", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97524", " - mptcp: avoid unneeded actions on subflow reset", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-80833", " - crypto: sun8i-ss - Remove crypto_rng interface", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-80834", " - crypto: sun8i-ce - Remove crypto_rng interface", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-74496", " - fou: Fix use-after-free in fou_create()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93286", " - net: appletalk: fix NULL pointer dereference in aarp_send_ddp()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93287", " - i2c: smbus: reject oversized block transfers in the common path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97931", " - ALSA: us122l: Prevent write upgrades for read mappings", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97568", " - mptcp: syncookies: remember the request backup flag", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97572", " - bnxt_en: Propagate RX ring init failures in bnxt_init_nic()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97573", " - bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97576", " - media: v4l2-ctrls: validate HEVC tile counts", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97582", " - hwmon: (gpio-fan) Fix use-after-free in alarm work", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97592", " - s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm", " algorithm", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97596", " - ipvs: reject invalid states in connection template sync records", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97598", " - ipv4: fib: bound automatic table ID allocation", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97601", " - ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97604", " - fbdev: vfb: defer cleanup until the last reference", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97608", " - netfilter: nf_log: unregister loggers before per-net teardown", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97611", " - net: openvswitch: fix use-after-free of the flow table mask array", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97612", " - net: mpls: clear inner_protocol when the last label is popped", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97899", " - drm/i915: Fix memory leak in query_perf_config_list()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97904", " - cpufreq: initialize policy rwsem before sysfs publication", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97905", " - cpufreq: zero-initialize policy cpumask before sysfs publication", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97909", " - ASoC: sti: initialize IRQ lock before requesting IRQ", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97910", " - ASoC: sprd: validate compress buffer sizes against fixed allocations", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97923", " - tracing: Free histogram the var ref when its initialization fails", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97926", " - ufs: validate cylinder group metadata before caching it", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97927", " - ufs: create the root dentry after loading cylinder metadata", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97930", " - ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97940", " - ipv6: fix fib6 walker UAF on seq stop", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97948", " - powerpc/eeh: Fix recursive locking on devices without EEH sensitive", " driver", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-74743", " - macvlan: inherit needed_headroom and needed_tailroom from lowerdev", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-89792", " - ksmbd: prevent out-of-bounds reads in share config responses", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97951", " - scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97952", " - sunvdc: unmap LDC cookies when the descriptor send fails", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97954", " - net/rds: fix tcp stream corruption with large pages", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97957", " - net: hinic: fix mailbox segment buffer overflow", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97958", " - net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain().", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97959", " - net/sched: cls_route: free emptied bucket on filter move", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97963", " - net: stmmac: initialize ptp_lock at probe time", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97964", " - ppp_synctty: ensure a writeable skb header", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97969", " - watchdog: msc313e: Fix clock leak and spurious timer in settimeout()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97970", " - watchdog: msc313e: Avoid division by zero", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97981", " - net: ethernet: cortina: Count dropped frames as NAPI work", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97982", " - net: ethernet: cortina: Fix budget accounting", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97991", " - vdpa_sim_blk: reject out-of-range sector starts", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97993", " - vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97995", " - virtio_console: do not free control-out buffers on remove", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97998", " - netfilter: nfnetlink_log: cope with concurrent instance destruction", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98006", " - ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98009", " - net/sched: ets: clamp quantum in parse and fallback paths", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98010", " - net/sched: drr: clamp quantum in change class", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98011", " - net/sched: hhf: clamp quantum in change and init paths", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98012", " - net/sched: sfq: clamp quantum in change path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98013", " - net/sched: fq_pie: clamp quantum in change path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98014", " - net/mlx5: E-Switch, prevent mc_list repopulation during vport disable", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98015", " - net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98016", " - net/mlx5e: Fix use-after-free race in sample_restore_put()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98022", " - net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98023", " - vxlan: reject dynamic fdb entries that reference a nexthop id", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98025", " - net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent", " partial_data heap overflow", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98027", " - net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer", " size", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98030", " - net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98031", " - nexthop: Initialize extack in remove_nh_grp_entry()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98063", " - bpf: Fix NULL-ptr-deref in btf_var_show()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98064", " - bpf: Fix NULL-ptr-deref when showing a void BTF type", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98066", " - ALSA: caiaq: Fix potential double-free at error path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98068", " - net/rds: don't let rds_conn_shutdown() consume a concurrent drop", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98069", " - net/rds: acquire the fastpath locks in rds_conn_shutdown()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98070", " - net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98071", " - net/rds: clear cp_flags bits individually in rds_conn_path_reset()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98072", " - net/rds: use wq_has_sleeper() in release_in_xmit()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98074", " - bonding: do not clear curr_active_slave prematurely when releasing all", " slaves", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98075", " - bpf: reject BPF_PSEUDO_FUNC reference to the main program", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98076", " - tracing/probes: Fix use-after-free on field name/type of events with", " multiple probes", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98077", " - netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98078", " - ipvs: fix reversed sequence option serialization", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98080", " - btrfs: do not force reloc root creation during qgroup_account_snapshot()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98088", " - scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in", " _base_assign_reply_queues()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98090", " - btrfs: restore active device pointers after failed sprout", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98091", " - btrfs: detach failed sprout device from transaction update list", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98094", " - staging: fbtft: make dirty_lock IRQ-safe", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98095", " - af_packet: Don't cast tpacket_hdr.tp_len to int in", " tpacket_parse_header().", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98096", " - ipv6: sr: restore network header before routing and forwarding", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98098", " - tipc: fix NULL deref in tipc_named_node_up() on empty publication list", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98108", " - Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98113", " - ksmbd: rate limit unmapped SID errors", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98116", " - ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98121", " - watchdog: msc313e: Fix NULL pointer dereference in PM callbacks", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98123", " - sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98130", " - sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98154", " - nvme-rdma: fix -EIO cleanup order in queue_rq", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98157", " - EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-89796", " - mm/damon/core: avoid infinite kdamond_merge_regions() internal loop", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98158", " - ppp_async: drop the errored frame instead of resetting its headroom", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93288", " - netfilter: nfnetlink_log: wait for rcu grace period before freeing", " pernet state", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93782", " - vhost-scsi: flush backend after device ioctls", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93783", " - Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93784", " - wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93785", " - cifs: validate idmap key payload length", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93789", " - wifi: iwlwifi: bound aligned TLV advance in FW parser", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93795", " - blk-cgroup: fix leaks and online flag on radix_tree_insert failure", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93797", " - wifi: iwlwifi: mvm: fix an off-by-1 boundary check", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93798", " - btrfs: fix reloc root cleanup in merge_reloc_roots()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93800", " - btrfs: fix use-after-free on reloc root after error in", " insert_dirty_subvol()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93802", " - wifi: rsi: validate beacon length before fixed buffer copy", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93803", " - wifi: libipw: fix key index receive bound checks", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93805", " - wifi: cfg80211: validate rx/tx MLME callback frame lengths before access", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93807", " - wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93808", " - ALSA: usb-audio: caiaq: validate EP1 reply lengths", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93811", " - ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93812", " - ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93813", " - btrfs: tree-checker: validate INODE_REF's namelen", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93815", " - net: au1000: move free_irq out of the close-time spinlocked section", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93816", " - f2fs: validate inline dentry name lengths before conversion", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93819", " - PCI: mediatek: Protect root bus removal with rescan lock", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93820", " - PCI: rockchip: Protect root bus removal with rescan lock", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93821", " - PCI: altera: Protect root bus removal with rescan lock", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93822", " - PCI: iproc: Protect root bus removal with rescan lock", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93825", " - spi: Add NULL check for spi_get_device_id() in", " spi_get_device_match_data()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93830", " - net: stmmac: xgmac2: disable RBUE in default RX interrupt mask", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97407", " - ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in", " set_fmt", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97408", " - Bluetooth: L2CAP: validate connectionless PSM length", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97411", " - net: ibm: emac: mal: fix potential system hang in mal_remove()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97413", " - RDMA/rtrs-srv: Fix integer underflow in process_read and process_write", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97416", " - btrfs: balance: fix potential bg lookup failure in", " btrfs_may_alloc_data_chunk()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97417", " - netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97418", " - ALSA: es18xx: check control allocation before private data setup", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97419", " - hsr: broadcast netlink notifications in the device's net namespace", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97420", " - bpf: NUL-terminate replaced sysctl value", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97421", " - RDMA/umem: Be careful about boundary conditions in", " ib_umem_find_best_pgsz()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97430", " - xhci: Prevent queuing new commands if xhci is inaccessible", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97434", " - dpaa2-switch: fix handling of NAPI on the remove path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97435", " - net: dsa: sja1105: flower: reject cross-chip redirect", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97436", " - dpaa2-switch: rework FDB management on the bridge leave path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97437", " - ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97438", " - fs/ntfs3: validate index entry key bounds", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97439", " - fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97440", " - net: qrtr: fix node refcount leak on ctrl packet alloc failure", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97441", " - ata: ahci: fail probe if BAR too small for claimed ports", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97443", " - perf/ftrace: Fix WARNING in __unregister_ftrace_function", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97444", " - ACPICA: add boundary checks in two places", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97445", " - ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97446", " - ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97448", " - ACPICA: Add validation for node in acpi_ns_build_normalized_path()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97449", " - ACPICA: Add package limit checks in parser functions", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97450", " - ACPICA: validate handler object type in two places", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97451", " - ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op)", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97452", " - ACPICA: Prevent adding invalid references", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97453", " - ACPICA: validate byte_count in acpi_ps_get_next_package_length()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97454", " - ACPICA: add boundary checks in acpi_ps_get_next_field()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97455", " - ACPICA: Fix use-after-free in acpi_ds_terminate_control_method()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97456", " - ACPICA: Fix condition check in acpi_ps_parse_loop()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97472", " - ipv6: addrconf: fix temp address generation after prefix deprecation", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97475", " - thermal/drivers/tegra/soctherma: Switch to devm cooling device", " registration", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97476", " - rds: filter RDS_INFO_* getsockopt by caller's netns", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97481", " - serial: 8250: fix possible ISR soft lockup", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97482", " - usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET", " log", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97483", " - usb: core: hcd: fix possible deadlock in rh control transfers", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97484", " - usbip: vhci_hcd: fix NULL deref in status_show_vhci", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97485", " - omfs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97486", " - hpfs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97487", " - jfs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97488", " - qnx4: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97489", " - bfs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97490", " - affs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97491", " - net/rds: Don't sleep inside rds_ib_conn_path_shutdown", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97492", " - wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not", " needed", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97502", " - mmc: davinci: avoid NULL deref of host->data in IRQ handler", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97506", " - crypto: ixp4xx - fix buffer chain unwind on allocation failure", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97507", " - media: dm1105: fix missing error check for dma_alloc_coherent", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97508", " - thunderbolt: Set tb->root_switch to NULL when domain is stopped", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97510", " - thunderbolt: Release request if tb_cfg_request() fails in", " __tb_xdomain_response()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726)", " - alpha: fix ieee_swcr_to_fpcr setting FPCR_DNOD unconditionally", " - alpha: don't leak hardware-fabricated FP exception bits to user space", " - include/linux/list.h: mark list_add and __list_add as __always_inline", " - tools/compiler: match glibc 2.42 definition of __attribute_const__", " - x86/insn-eval: Move assign_register() out of KVM as insn_assign_reg()", " - powerpc/powermac: fix OF node refcount", " - staging: greybus: hid: fix SET_REPORT return value", " - usb: dwc2: gadget: Exit partial power down state when changing USB pull-", " up", " - USB: phy: fsl-usb: fix missing static keywords", " - usb: gadget: snps_udc_plat: clean up PHY on probe deferral", " - NFSD: Encode only the status in NFS-ACL v2 GETACL error replies", " - NFSD: Fix off-by-one in DRC bucket pruning limit", " - nfsd: return NFS4ERR_NOTSUPP for unsupported netloc4 types", " - nfsd: add filehandle match check to nfsd4_delegreturn()", " - nfsd: fix version mismatch loops in nfsd_acl_init_request()", " - nfsd: reject reclaim LOCK after RECLAIM_COMPLETE", " - eCryptfs: bound the packet-length peek to the user buffer", " - ecryptfs: fix tag 11 packet exact-fit size check", " - ecryptfs: show filename encryption options", " - fat: restore original value when fat_ent_write failed", " - fbdev: pvr2fb: correct user pointer annotation and sentinel initializer", " - fpga: stratix10-soc: Fix SVC mailbox handling during reconfiguration", " - alpha/PCI: Fix I/O port accessor argument order in pci_legacy_write()", " - alpha: marvel: Fix irq_set_status_flags to use correct IRQ number", " - alpha: marvel: Fix lock ordering in init_io7_irqs()", " - Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU", " - Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU", " - cpufreq: schedutil: Fix rate limit overflow", " - Bluetooth: hci_bcm: fix usage_count leak when autosuspend_delay is", " negative", " - Bluetooth: hci_uart: Fix false success return in hci_uart_setup()", " - Bluetooth: hci_event: clear HCI_LE_ADV only on a created connection", " - Bluetooth: hci_h5: fix usage_count leak when autosuspend_delay is", " negative", " - Bluetooth: hci_intel: fix usage_count leak when autosuspend_delay is", " negative", " - SUNRPC: Guard svcauth_gss_release() dispatch on rq_auth_stat", " - staging: media: tegra-video: vi: fix probe failure on skipped last port", " - rpmsg: glink: smem: order FIFO read after availability check", " - regulator: max8998_pmic_dt_parse_pdata: of_node_put on reg_np after", " ownership transferred to rdata", " - ocfs2: cluster: avoid lock order inversion in o2hb_region_pin() from", " drop_item", " - ocfs2: cluster: fix o2hb_dependent_users leak on pin failure", " - hwmon: (max6621) fix negative temperature offset and crit readings", " - hwmon: (max6621) fix temperature clamp range", " - nvme: nvme-fc: Fix nvme_fc_create_hw_io_queues() queue deletion in error", " path", " - sctp: distinguish sequence zero from wildcard in reconf lookup", " - PCI: Fix 32-bit config write in Intel PCH Root Port MPC ACS quirk", " - PCI: meson: Fix GPIO state while requesting PERST#", " - PCI/sysfs: Avoid spurious runtime PM wakeup on config space accesses", " - PCI/proc: Avoid spurious runtime PM wakeup on config space accesses", " - iommu/vt-d: Fix no_iommu to disable platform opt-in", " - net: usb: qmi_wwan: add Telit Cinterion FE990D50 composition", " - net: openvswitch: fix nf_connlabels leak in ovs_ct_init", " - NTB: ntb_transport: Recycle TX entries before client callbacks", " - net: ntb_netdev: Avoid double-accounting netif_rx() drops", " - net: ntb_netdev: Count packets dropped on RX refill failure", " - PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip", " - arch_numa: avoid false positive fortify warning in", " setup_node_to_cpumask_map()", " - dm-switch: use WRITE_ONCE() in switch_region_table_write()", " - wifi: rtl818x: initialize eeprom_93cx6 struct to zero", " - taskstats: fix cpumask parsing cutting off the last character", " - timer: Keep debugobjects state consistent in migrate_timer_list()", " - udf: Fix i_lenExtents truncation on 32-bit kernels", " - platform/chrome: sensorhub: Fix dropped timestamp events and log spam", " - net: openvswitch: fix kernel-doc warnings in internal headers", " - selinux: avoid implicit conversions in services code", " - ALSA: seq: Fix port lock leak in deliver_to_subscribers()", " - net: ntb_netdev: Fix TX busy and drop handling", " - tracing/mmiotrace: Remove reference to unused per CPU data pointer", " - clk: qcom: gcc-mdm9607: Increase delay for USB PHY reset", " - usb: f_mass_storage: Bump local buffer size in fsg_common_create_luns()", " - thermal/drivers/imx: Disable clock on runtime resume failure", " - thermal/drivers/qoriq: Disable clock on resume failure", " - dmaengine: dw-edma: Complete descriptors before pausing", " - block: flag zoned disks with GENHD_FL_NO_PART", " - ata: ahci: work around lost interrupts on Marvell 88SE61xx", " - Input: aiptek - validate raw macro indices before updating state", " - Input: aiptek - switch to using dev_groups for driver-specific", " attributes", " - Revert \"irqchip/mbigen: Fix mbigen node address layout\"", " - parisc: Fix alignment of asm statements in head.S", " - batman-adv: bla: prevent CRC corruptions after claim flush", " - clk: qcom: gcc-msm8916: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: qcom: gcc-msm8939: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: qcom: gcc-mdm9607: Drop incorrect apss_tcu_clk_src", " - clk: qcom: gcc-mdm9607: Drop incorrect system_noc_bfdcd_clk_src", " - clk: qcom: gcc-mdm9607: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: qcom: gcc-mdm9607: Fix halt_reg for gcc_apss_axi_clk", " - clk: qcom: gcc-mdm9607: Drop incorrect BIMC PLL and related clocks", " - i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure", " - ASoC: fsl: mpc5200-i2s: Free DMA resources on probe failure", " - AsoC: intel: sst: fix PCI device reference leak on probe failure", " - ASoC: samsung: aries_audio_probe: double of_node_put due to direct", " assignment without of_node_get", " - iio: gyro: mpu3050: fix sign of raw angular velocity readings", " - iio: light: cm32181: return zero after writing calibscale", " - iio: light: gp2ap002: Disable regulators on resume failure", " - iio: srf04: fix pm_runtime handling on probe error path", " - iio: temperature: hid-sensor-temperature: switch to non-devm", " iio_device_register()", " - KVM: s390: Zero initialize irq in reinject_machine_check", " - KVM: s390: Restore sigset on error path", " - media: cec: meson: ao-cec-g12a: name the CEC core regmap to avoid", " debugfs clash", " - media: v4l2-ctrls: Allow unknown HDR10 white point and luminance", " - media: venus: fix payload size returned by parse_caps() and", " parse_alloc_mode()", " - media: venus: fix payload size calculation in parse_raw_formats()", " - media: vimc: fix pixel format lookup in enum_framesizes", " - scsi: qla2xxx: Fix Name Server logout detection on FWI2 adapters", " - scsi: qla2xxx: Check entry_status in qla24xx_modify_vp_config()", " - scsi: qla2xxx: Drop vport reference under lock in report ID acquisition", " - scsi: qla2xxx: Use coherent DMA buffer for D_Port diagnostics", " - f2fs: return symlink writeback errors", " - f2fs: reject overlapping move range after len expansion", " - f2fs: return writeback error from collapse range", " - f2fs: fix i_size when pinned fallocate partially fails", " - drm/bridge: dw-hdmi: fix i2c adapter leak on probe failure", " - drm/sun4i: fix refcount leak in sun4i_backend_init_sat()", " - drm/hibmc: Fix list of formats on the primary plane", " - drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value", " - drm/amdgpu: use AMDGPU_GPU_PAGE_SHIFT instead of PAGE_SHIFT", " - drm/nouveau: Use write-combined maps for coherent", " - mm/damon/core-kunit: check region count before testing in split_at()", " - mm/damon/vaddr: drop last same folio access check optimization", " - mm/damon/vaddr-kunit: check region count in three_regions test", " - mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of()", " - firmware: stratix10-svc: Add mutex in stratix10 memory management", " - drm/bridge: cdns-mhdp8546: Return an error pointer on allocation failure", " - Smack: fix W=1 build warnings", " - smack: simplify write handlers of sysfs entries", " - smack: deduplicate smackfs/{direct,mapped} file_operations", " - smack: restrict smackfs/{direct,mapped} values to 0-255", " - soc: samsung: exynos-pmu: fix of_node refcount leak in", " exynos_get_pmu_regmap()", " - media: cec-pin: Fix event FIFO ordering", " - clk: moxart: remove unused variables, fix refcount leak", " - clk: hisilicon: reset: Use devm_kzalloc to initialize", " hisi_reset_controller", " - ARM: imx: fix device_node refcount leak in imx_src_init()", " - ARM: imx: fix device_node refcount leaks in imx7_src_init()", " - clk: imx: scu: drop redundant init.ops variable assignment", " - perf/x86/intel/uncore: Keep PCI PMUs working when MMIO/MSR setup fails", " - media: keymaps: Remove obsolete RC_MAP_RC5_TV keymap define", " - media: keymaps: Remove obsolete RC_MAP_HAUPPAUGE_NEW keymap define", " - perf tests stat_bpf_counters: Fix usage of '==' to address shellcheck", " warning", " - perf test: raise limit to 20 percent for perf_stat_--bpf-counters_test", " - perf test bpf-counters: Add test for BPF event modifier", " - perf test stat_bpf_counter.sh: Stabilize the test results", " - perf test: Use sqrtloop workload to test bperf event", " - perf test: Fix perf stat --bpf-counters on hybrid machines", " - perf tests: Fix flakiness in BPF counters test on hybrid systems", " - bpftool: Update btf_dump__new() and perf_buffer__new_raw() calls", " - bpftool: Use libbpf_get_error() to check error", " - bpftool: Fix pretty print dump for maps without BTF loaded", " - tools/bpf/bpftool: Reset vmlinux BTF after map commands", " - bpftool: remove duplicate free_btf_vmlinux() definition", " - dmaengine: mediatek: mtk-uart-apdma: Return -ENOMEM on memory allocation", " failure", " - dmaengine: hisilicon: Return -ENOMEM on dynamic memory allocation in", " probe", " - soundwire: qcom: Fix port exhaustion check in stream_alloc_ports", " - iio: orientation: hid-sensor-rotation: Avoid race between callback setup", " and device exposure", " - selftests/rseq: Replace glibc-specific __GNUC_PREREQ with portable check", " - crypto: atmel-ecc - replace min_t with min", " - crypto: atmel-ecc - clean up and improve ECDH comments", " - crypto: sa2ul - Use the defined variable to clean code", " - nvmet-rdma: avoid circular locking dependency on install_queue()", " - nvmet-rdma: use sbitmap to replace rsp free list", " - nvmet-rdma: factor out response resource cleanup", " - bus: ti-sysc: Fix /chosen node reference leak", " - PM: sleep: Fix off-by-one in wakelocks number limit check", " - staging: greybus: audio: correct sscanf() return value check", " - staging: sm750fb: gate dualview dataflow using g_dualview", " - staging: fbtft: Use sysfs_emit_at() to print to sysfs file", " - netdev: reshuffle netif_napi_add() APIs to allow dropping weight", " - staging: switch to netif_napi_add_weight()", " - staging: octeon: fix free_irq dev_id mismatch in cvm_oct_rx_shutdown", " - staging: octeon: ethernet-mem: replace pr_warn with dev_warn in free", " functions", " - staging: octeon: replace pr_warn with dev_warn in fill and rx paths", " - staging: rtl8723bs: fix mismatched free of HalData in", " rtw_sdio_if1_init()", " - ALSA: via82xx: Remove unreachable branch in snd_via686_pcm_pointer()", " - selftests/bpf: Fix memory leak in msg_alloc_iov error path", " - selftests/bpf: Fix memory leak in msg_alloc_iov", " - irqchip/gic-v3-its: Fix memleak in its_probe_one()", " - selftests: timers: leap-a-day: Fix -w option and update usage comment", " - clocksource: Unregister subsystem on device registration failure", " - y2038: uapi: Use 64-bit __kernel_old_timespec::tv_nsec on x32", " - timekeeping: Account for monotonicity adjustment in ntp_error", " - clk: qcom: gdsc: propagate gdsc_check_status() errors from", " gdsc_poll_status", " - clk: qcom: gdsc: propagate gdsc_enable() failure for ALWAYS_ON domains", " - clk: qcom: gdsc: enable optional power domain support", " - clk: qcom: gdsc: Release pm subdomains in reverse add order", " - clk: qcom: gdsc: Capture pm_genpd_add_subdomain result code", " - efi: fix stale reference to efi_recover_from_page_fault()", " - iommu/mediatek-v1: Fix off-by-one in MT2701_LARB_NR_MAX", " - iommu/msm: Return -ENOMEM on memory allocation failure in probe", " - iommu/amd: Prevent SB IOAPIC from overriding IVRS validation errors", " - iommu/amd: Add support for Hygon family 18h model 4h IOAPIC", " - iommu/amd: Fix false positive in SB IOAPIC IVRS validation", " - leds: pca9532: Fix inverted GPIO output polarity", " - hwspinlock: propagate errno when registering single lock", " - usb: mtu3: allow system suspend during active gadget connection", " - usb: renesas_usbhs: Fix power-off ordering on unbind", " - drm/panel: samsung-s6d16d0: Power off on prepare failure", " - iio: accel: dmard09: Implement IIO_CHAN_INFO_SCALE", " - RDMA/core: Avoid flush_workqueue(system_unbound_wq) usage", " - RDMA/mlx4: Avoid flush_scheduled_work() usage", " - RDMA/mlx: Calling qp event handler in workqueue context", " - hwrng: ks-sa - access private data via struct hwrng", " - hwrng: ks-sa - Fix runtime PM cleanup on registration failure", " - ALSA: hpi: Check transport errors during HPI6000 adapter initialization", " - pmdomain: bcm: bcm2835: handle genpd provider registration errors", " - misc: rtsx_usb: avoid USB I/O in runtime autosuspend", " - RDMA/hfi1: Remove redundant PCI device ID validation", " - RDMA/hfi1: Create workqueues before device initialization", " - RDMA/hfi1: Stop flushing the global IB workqueue", " - RDMA/hfi1: Initialize debugfs after probe completes", " - fs/isofs: replace kmap() with kmap_local_page()", " - rpmsg: glink: Remove the rpmsg dev in close_ack", " - rpmsg: glink: remove duplicate code for rpmsg device remove", " - libnvdimm/labels: Bound the on-media label size before the shift", " - cpufreq: spear: Fix an IS_ERR() vs NULL bug in spear1340_set_cpu_rate()", " - irqdomain: Introduce irq_domain_free()", " - irqdomain: Introduce irq_domain_instantiate()", " - irqdomain: Handle additional domain flags in irq_domain_instantiate()", " - genirq/generic_chip: Introduce irq_domain_{alloc,remove}_generic_chips()", " - cpufreq: intel_pstate: Fix setting minimum P-state at init time", " - cpufreq: schedutil: Fix self-contradictory comment in", " sugov_iowait_apply()", " - remoteproc: qcom: Fix glink->node reference leak in", " qcom_add_glink_subdev", " - arm64: dts: qcom: sm8250: Use QMP property to control load state", " - arm64: dts: qcom: sm8250: remove mmcx regulator", " - arm64: dts: qcom: sm8250: Add camcc DT node", " - gpu: host1x: Fix offset calculation in trace_write_gather", " - crypto: sl3516 - drop invalid sg_dma_len checks before DMA mapping", " - ACPI: move from strlcpy() with unused retval to strscpy()", " - ACPI: processor: idle: Expand _LPI package sanity checks", " - tty: hvc: restrict HVC_DCC to ARMv6+ and ARM64", " - accessibility: speakup: Fix incorrect string length computation in", " report_char_chartab_status()", " - misc: rtsx: add missing write register handling", " - misc: ad525x_dpot: Make ad_dpot_remove() return void", " - ppdev: prevent overflow when setting port timeout", " - char: xilinx_hwicap: unregister class on init errors", " - perf ui hists: Fix uninitialized stack memory free on pstack allocation", " failure", " - driver core: soc: remove layering violation for the soc_bus", " - driver core: soc: Unregister bus on early device registration failure", " - dmaengine: dw-edma: Clear stale requests on termination", " - arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for", " PCIe", " - RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters", " - RDMA/srpt: Pass the mapped task attribute to target_init_cmd()", " - RDMA/nldev: Split nldev_stat_set_mode_doit out of nldev_stat_set_doit", " - RDMA/restrack: Fix typos in the comments", " - RDMA/core: Add driver APIs pre_destroy_cq() and post_destroy_cq()", " - iommu/arm-smmu: Add missing pm_runtime_disable() in", " qcom_iommu_device_probe", " - iommu/qcom: Remove sysfs device on probe failure path", " - iommu/qcom: Fix inverted fault report check in qcom_iommu_fault()", " - thermal: int340x_thermal: Consolidate priv->data_vault checks", " - wifi: ath11k: Correctly copy the hint BSSID in WMI scan request", " - ath11k: add trace log support", " - ARM: dts: allwinner: a10: Fix PMU interrupt", " - perf cs-etm: Flush thread stacks after decoder reset", " - perf cs-etm: Avoid truncating AUX buffer sizes to int", " - leds: pca9532: Fix phantom device registration on missing hardware", " - drm/tve200: add OF module alias for autoloading", " - netfilter: nf_nat_sip: rewind offset when NAT shrinks the packet", " - arm64: dts: rockchip: Add gru-scarlet-dumo board", " - arm64: dts: rockchip: Fix PCI node addresses on rk3399-gru", " - arm64: dts: rockchip: Fix Gru WLAN sideband interrupt", " - ARM: lpc32xx: only run SoC init on LPC32xx hardware", " - power: supply: sbs-battery: Use a per-device serial number buffer", " - crypto: keembay - publish OF module alias for OCS AES/SM4", " - w1: ds2482: Fix signedness bug in ds2482_w1_triplet()", " - remoteproc: Use unbounded workqueue for recovery work", " - remoteproc: core: Attach rproc asynchronously in rproc_add() path via", " schedule_work()", " - staging: rtl8723bs: use kfree_sensitive() for key material", " - arm64: dts: allwinner: sun50i-a64-pinephone: Fix mpu6050 mount matrix", " - clk: tegra: tegra124-emc: put EMC node on register failure", " - clk: palmas: Manage external-control prepare with devm", " - clk/x86: pmc_atom: add kasprintf return value check", " - scsi: core: Register sysfs attributes earlier", " - scsi: smartpqi: Fix AIO retry marker cleared by SCSI core between", " dispatches.", " - RDMA/mlx5: Send cong param changes to the resolved port mdev", " - bus: mhi: host: Flush the posted write after writing to", " MHI_SOC_RESET_REQ_OFFSET", " - selftests/zram: fix kernel_gte() for POSIX sh", " - power: supply: sc2731_charger: Convert to platform remove callback", " returning void", " - clk: qcom: Return expected ENOMEM error on dynamic allocation failure", " - misc: vmc_vmci: Fix potential memory leak in vmci_event_subscribe()", " - fanotify: report full event length for FIONREAD", " - wifi: mt76: mt7915: use little-endian for bss_info_ra wire fields", " - perf: arm_spe: Make wakeup range check overflow safe", " - perf machine: Guard against NULL strlist in machines__findnew()", " - perf machine: Use snprintf() for guestmount path construction", " - perf machine: Check snprintf truncation in machines__findnew()", " - perf machine: Don't abort guest map creation on first inaccessible dir", " - perf machine: Reset errno before strtol in guest kernel map creation", " - perf machine: Free scandir entries in guest kernel map creation", " - perf machine: Check snprintf truncation for guest kallsyms path", " - iommu/arm-smmu-v3: Convert to use atomic poll timeout", " - wifi: mac80211: send TWT teardown to peer after setup TX failure", " - wifi: zd1211rw: reject secondary interfaces to prevent conflicts", " - wifi: mac80211: skip unused probe response countdown offsets", " - firmware: google: Add bounds checks in coreboot_table_populate()", " - powerpc/smp: add NULL guard for cause_ipi in smp_muxed_ipi_message_pass", " - MIPS: ptrace: Fix syscall skipping via PTRACE_SYSCALL", " - serial: amba-pl011: unprepare console clock on unregister", " - HID: split apart hid_device_probe to make logic more apparent", " - HID: ensure timely release of driver-allocated resources", " - HID: i2c-hid: Switch i2c_hid_parse() to goto style error handling", " - HID: i2c-hid: Fix \"(null)\" output when reading report descriptor fails", " - HID: lg4ff: validate report length before fixed offsets", " - perf thread-stack: Fix heap buffer overflow on branch stack wrap copy", " - perf auxtrace: Fix queue grow overflow and old array leak", " - perf intel-pt: Fix off-by-one in auxtrace_info minimum size check", " - perf intel-bts: Fix off-by-one in auxtrace_info minimum size check", " - iio: light: tsl2772: fix ALS calibscale readback", " - iio: light: isl29028: return zero in write_raw() on success", " - iio: light: tsl2583: return zero in write_raw() on success", " - block/blk-stat: drain per-cpu callback stats over possible CPUs", " - block/blk-iocost: collect per-cpu latency stats over possible CPUs", " - block/kyber-iosched: flush per-cpu latency buckets over possible CPUs", " - lib/string: fix memchr_inv() for large ranges", " - pps: don't try to wait for negative timeouts in PPS_FETCH", " - pps: clients: gpio: Bypass edge's direction check when not needed", " - pps: pps-gpio: split IRQ handler into hardirq timestamper + threaded", " handler", " - pps-gpio: remove dead capture_clear code", " - PCI/sysfs: Add static PCI resource attribute macros", " - remoteproc: Move resource table data structure to its own header", " - remoteproc: use rsc_table_for_each_entry() in rproc_handle_resources()", " - scripts/tags.sh: improve compiled sources generation", " - scripts/tags.sh: Prevent binary files appearing in cscope.files", " - ocfs2: use bitmap API in fill_node_map", " - drm/sun4i: vi scaler: Fix coefficient selection", " - of: property: add missing kerneldoc for of_graph_get_endpoint_count()", " - of: property: use unsigned int return on of_graph_get_endpoint_count()", " - bitfield: Add less-checking __FIELD_{GET,PREP}()", " - bitfield: Add non-constant field_{prep,get}() helpers", " - drm/sun4i: tcon: Drop remote endpoint reference", " - drm/sun4i: dw-hdmi: Drop TCON TOP port reference", " - drm/sun4i: hdmi-phy: Fix H6 8-bit MPLL config at 594 MHz", " - RDMA/siw: Introduce siw_free_cm_id", " - mfd: rave-sp: validate received frame payload lengths", " - mfd: iqs62x: Reject zero-length firmware records", " - drm/amdgpu/gfx6: Fixup emit_cntxcntl()", " - ext4: fix spurious message about orphan cleanup on RO fs", " - phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table", " - perf trace-event: Fix buffer overflow in read_string()", " - drm/amdgpu/gfx6: Fixup emitting SWITCH_BUFFER packets", " - firmware_loader: Check fw_state_is_done in loading_store", " - pinctrl: rockchip: Reset the pin count when recalculating SoC data", " - soc: fsl: qe: check platform_driver_register() in qe_ic_of_init()", " - coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()", " - coresight: etm4x: Cleanup TRCIDR2 register accesses", " - coresight: etm4x: Cleanup TRCIDR3 register accesses", " - coresight: etm4x: Cleanup TRCIDR4 register accesses", " - coresight: etm4x: Cleanup TRCIDR5 register accesses", " - coresight: Change syncfreq to be a u8", " - regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handling", " - sched/fair: Check CPU capacity before comparing group types during load", " balance", " - Bluetooth: btusb: Fix BD_ADDR byte order in btusb_set_bdaddr_wcn6855()", " - perf trace-event: Fix integer truncation in do_read() and skip()", " - scsi: sd: Fix sd_done() sense handling condition", " - iio: light: gp2ap002: re-enable irq if runtime suspend fails", " - flow_offload: rename offload functions with offload instead of flow", " - arm64: dts: turris-mox: fix usb3 phys", " - ARM: dts: helios4: add vcc-supply to EEPROM", " - ARM: dts: helios4: add vcc-supply to GPIO expander", " - ARM: dts: helios4: add SATA regulator supplies", " - perf stat: Clear screen only if output file is a tty", " - perf stat: Fix evsel_list leak in cmd_stat", " - perf synthetic-events: Fix uninitialized pthread_join", " - perf synthetic-events: Fix divide by zero in", " perf_event__synthesize_threads", " - iommu/vt-d: Fix UCTP context table slot when copying root entries", " - m68k: Fix backtraces for non-running tasks", " - powerpc/configs: enable CONFIG_RAS to fix EDAC support", " - spi: sprd-adi: Fix probe succeeding without registering the controller", " - nfc: digital: Do not dump a NULL response in command completion", " - dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal", " - ASoC: pxa: Use devm_clk_get_optional() for extclk clock", " - ASoC: fsl-asoc-card: defer probe when the CPU DAI device is not ready", " - ubi: Fix repeated words in comments", " - ubi: fastmap: Use the bitmap API to allocate bitmaps", " - ubi: fastmap: Fix missed ec updating after erasing old fastmap data", " block", " - ubi: fastmap: erase_block: Get erase counter from wl_entry rather than", " flash", " - ubi: fastmap: Allocate memory with GFP_NOFS in ubi_update_fastmap", " - ubi: Replace erase_block() with sync_erase()", " - UBI: Preserve torture flag when rescheduling failed erasures", " - UBI: fastmap: Pass to_be_tortured when reusing old fastmap PEBs", " - ubi: fastmap: Add fastmap control support for 'UBI_IOCATT' ioctl", " - ubi: fastmap: Add fastmap control support for module parameter", " - ubi: Simplify bool conversion", " - ubi: fastmap: Wait until there are enough free PEBs before filling pools", " - ubi: fastmap: Fix lapsed wear leveling for first 64 PEBs", " - ubi: fastmap: Add module parameter to control reserving filling pool", " PEBs", " - UBI: fix two issues in the ubi.mtd MODULE_PARM_DESC", " - selfetests/bpf: Update vmtest.sh defaults", " - selfetests/bpf: Adapt vmtest.sh to s390 libbpf CI changes", " - bpf/docs: Update list of architectures supported.", " - selftests/bpf: Fix vmtest.sh getopts optstring", " - selftests/bpf: Limit URLS parsing logic to actual scope in vmtest", " - selftests/bpf: Support local rootfs image for vmtest", " - selftests/bpf: Add description for running vmtest on RV64", " - selftests/bpf: vmtest.sh: Preserve command quoting when running in the", " VM", " - spi: img-spfi: don't disable runtime PM on DMA deferred probe", " - power: supply: bd99954: Drop bad register fields", " - power: supply: bq27xxx: bq27520g4: fix REG_TTES address", " - power: supply: bq27xxx: bq28z610: fix invalid AverageEnergy address", " - power: supply: bq27xxx: bq27z561: fix invalid AverageEnergy address", " - xenbus: Unregister reboot notifier on init failure", " - clocksource/drivers/clps711x: Do not unmap clocksource MMIO", " - clocksource/drivers/armada: Unwind timer clock on init failure", " - x86/pkeys: Fix pkey_alloc() return value when pkeys are not supported", " - bpftool: Fix double close in map dump", " - tracing: Remove \"__attribute__()\" from the type field of event format", " - tracing: Have trace_event_update_all() only handle module that is", " loading", " - bpf: Fix pending_pos walk on 32-bit ring position wrap", " - crypto: hisilicon/sec2 - fix CCM algorithm long packet failure", " - perf dso: Guard close() against invalid fd in", " dso__decompress_kmodule_path()", " - perf dso: Guard against cache underflow on short reads in", " dso_cache__memcpy()", " - mailbox: rockchip: disable pclk on probe failure and unbind", " - hwmon: (emc1403) Add support for EMC1442", " - smb/server: preserve error status in smb2_handle_negotiate()", " - nfs: replace atomic bitops sequence with clear_and_wake_up_bit helper", " - nfs: refactor pNFS functions using clear_and_wake_up_bit", " - pppox: drain queued packets on channel handoff", " - hsr: Use a single struct for self_node.", " - net: hsr: Use full string description when opening HSR network device", " - net: bridge: vlan: fix inverted default vlan notification", " - ALSA: hda: Fix connection list comparison in proc output", " - 8139cp: fix Rx and Tx not being disabled in cp_suspend", " - platform/x86: dell-wmi-sysman: Fix instance ID bounds", " - vsock: use sock_error() to consume sk_err after a failed connect", " - bonding: initialize err for empty target lists", " - i3c: mipi-i3c-hci: Fix DAT/DCT entry sizes", " - i3c: mipi-i3c-hci: Fix number of DAT/DCT entries for HCI versions < 1.1", " - i3c: mipi-i3c-hci: Quieten initialization messages", " - i3c: mipi-i3c-hci: Switch PIO data allocation to devm_kzalloc()", " - i3c: mipi-i3c-hci: Refactor PIO register initialization", " - i3c: mipi-i3c-hci: Fix missing STAT_IBI_STATUS_THLD in PIO mode", " - virtio_balloon: disable indirect descriptors", " - prctl: fix PR_SET_MM_AUXV losing the forced AT_NULL terminator", " - ALSA: control: Use automatic cleanup of kfree()", " - RDMA/ucma: Allow path records to exactly fit the output buffer", " - net: thunderbolt: Count delivered packets in rx_packets and rx_bytes", " - forcedeth: stop the tx_timeout register dump past the requested window", " - net: ipa: report when the driver has been removed", " - net: ipa: Convert to platform remove callback returning void", " - net: ipa: balance runtime PM reference on remove error", " - nfs: move the nfs4_data_server_cache into struct nfs_net", " - scsi: qla2xxx: Fix an loop timeout test", " - Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX", " - octeontx2-af: Fix TL3/TL2 link config ENA clearing", " - cifs: fix clearing stats for fastest execution of each smb2 command", " - net: ip6_gre: Remove the unused function ip6gre_tnl_addr_conflict()", " - net_sched: sch_fq: struct sched_data reorg", " - net_sched: sch_fq: change how @inactive is tracked", " - net_sched: export pfifo_fast prio2band[]", " - net/sched: sch_codel: clamp default mtu to avoid disabling CoDel", " - tpm: st33zp24: Validate locality read result", " - apparmor: Replace sprintf/strcpy with scnprintf/strscpy in", " aa_policy_init", " - net: ethernet: sun4i-emac: Fix IRQ error handling", " - net: stmmac: selftests: Pass the IP proto mask in the TC selftest", " - netfilter: xt_cgroup: Make it independent from net_cls", " - netfilter: xt_HL: add pr_fmt and checkentry validation", " - netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited()", " - selftests: arm64: add hugetlb mte tests", " - selftests/arm64: Print missing MTE TAP headers", " - selftests/arm64: Treat KSM merge_across_nodes as optional", " - net: stmmac: selftests: Check multiple MMC counters", " - net: stmmac: dwmac1000: Account for the primary MAC address for UC", " filtering", " - net: stmmac: dwmac4: Account for the primary MAC address for UC", " filtering", " - net: stmmac: dwxgmac: Account for the primary MAC address for UC", " filtering", " - net: stmmac: selftests: Account for the UC filter list for filtering", " tests", " - nvme: target: rdma: fix ndev refcount leak on queue connect", " - clk: qcom: Drop mmcx gdsc supply for dispcc and videocc", " - RDMA/nldev: Check stat attribute before accessing it", " - HID: fix an error code in hid_check_device_match()", " - ALSA: control: Fix unannotated kfree() cleanup", " - Bluetooth: L2CAP: Fix send LE flow credits in ACL link", " - kselftest/arm64: mte: Skip the hugetlb tests if MTE not supported on", " such mappings", " - kselftest/arm64: mte: Use the correct naming for tag check modes in", " check_hugetlb_options.c", " - nvmet-rdma: fix queue leak when connect backlog is exceeded", " - clk: qcom: gdsc: Bump parent usage count when GDSC is found enabled", " - Linux 5.15.221", " - SAUCE: Revert \"bpftool: Update btf_dump__new() and", " perf_buffer__new_raw() calls\"", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90053", " - net/sched: sch_htb: limit htb_classify inner-class filter hops", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90054", " - tcp: fix corruption of urgent data on multi-segment retransmit", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90055", " - usb: atm: usbatm: fix invalid ci_range initialization", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90056", " - net: fec: only stop PTP if it was initialized", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90058", " - net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90062", " - netfilter: nf_tables: move hardware offload step after building the", " chain blob", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90063", " - virtio-net: Ensure that TCP packets don't overflow gso_segs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90067", " - libceph: validate banner payload length", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90068", " - ASoC: dapm: Fix off-by-one check on the second enum channel", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93245", " - apparmor: policy_int make sure list heads are initialized before fail", " path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90070", " - tpm: st33zp24: Return zero on status read failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90071", " - net/sched: sch_teql: restore skb->dev on the slave failure path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90072", " - net/sched: sfq: clamp quantum to avoid signed overflow soft lockup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90073", " - net/sched: hhf: clamp quantum before hhf_change() to avoid overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90074", " - net/sched: fq_pie: clamp default quantum to avoid signed overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90075", " - net/sched: fq_codel: clamp default quantum and mtu", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90078", " - net/sched: act_skbmod: fix length calculations and avoid invalid header", " warnings", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90081", " - net/rds: use wq_has_sleeper() in rds_cong_map_updated()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89780", " - net: qualcomm: rmnet: restore skb->dev on deaggregated frames", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89789", " - gtp: add synchronize_net() in gtp_newlink() error path to prevent use-", " after-free", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90088", " - Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite", " loop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90102", " - NFSv4/pnfs: key the data server cache on the NFS version", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90103", " - NFSv4.2: fix LAYOUTSTATS send buffer exhaustion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90107", " - net/smc: free pending qentry in smc_llc_flow_stop() before memset", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90114", " - net: bridge: Reject descending VLAN tunnel ranges", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90126", " - rtc: pcf8563: fix clock provider leak on unbind", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90128", " - vdpa/mlx5: fix wrong list iterated in add_direct_chain error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89779", " - fs/ntfs3: validate ef->size covers the record's name and value", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89781", " - fs/ntfs3: fix out-of-bounds read in read_log_rec_buf()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90140", " - cuse: wait for pending RCU callbacks on module exit", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90141", " - ipvs: fix integer overflow in ftp helper port/address parsing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90143", " - net: kcm: Hold RCU read lock while running BPF parser", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90151", " - NFSv4: remove callback IDR entry on client allocation failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90157", " - bpf: Reject negative optlen in cgroup getsockopt hook", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90160", " - lwt_bpf: Restore reserved headroom after xmit program", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90198", " - ALSA: core: Fix use-after-free in snd_card_do_free()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90202", " - scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90203", " - Squashfs: check block offset is not negative", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93252", " - ocfs2: fix circular locking dependency in ocfs2_init_acl()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90209", " - s390/debug: Fix deadlock during unregister", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90214", " - ASoC: xilinx: formatter_pcm: fix stream_data leak on open error", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90216", " - ubi: Fix rollback for explicit UBI device numbers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90218", " - RDMA/cma: Fix WARNING in res_to_rt", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90219", " - RDMA/cxgb4: Free debugfs on registration failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90221", " - nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90222", " - nfc: pn533: hold a reference to the request skb during send_frame", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90223", " - nfc: llcp: bound SNL TLV parsing to the skb and add length checks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90224", " - nfc: nci: fix double completion race in nci_data_exchange_complete", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90225", " - nfc: llcp: read llcp_sock->local under the socket lock in getsockopt", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90226", " - nfc: llcp: avoid userspace overflow on invalid optlen", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90228", " - nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89784", " - SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90245", " - fbdev: kyro: Validate overlay viewport coordinates", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90248", " - net/sched: cls_api: fix teardown of an adopted proto on insert-race loss", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90249", " - iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90251", " - Bluetooth: MSFT: validate evt_prefix_len against the response length", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90257", " - Bluetooth: virtio_bt: avoid OOB read of build info string", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90274", " - coresight: etm4x: fix underflow for usage of (nrseqstate - 1)", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90281", " - phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime", " suspend", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90283", " - hugetlbfs: release subpool on fill_super failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90284", " - firmware_loader: do not queue completed sysfs fallback requests", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90285", " - scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90286", " - drm/amdgpu/gfx6: Use PFP on the compute queues too", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90290", " - arm64: hibernate: Restore DAIF state on error", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93256", " - arm64: hibernate: mask DAIF before restoring hibernated kernel", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90292", " - RDMA/siw: Fix use-after-free in siw_accept()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90293", " - IB/isert: post the full-feature receive buffers after session", " registration", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90294", " - IB/isert: delay the final Login Response until the session is registered", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90295", " - cpufreq: imx6q: fix out-of-bounds write when probed more than once", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90296", " - cpufreq: imx6q: fix devres accumulation across driver rebind", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90297", " - drm/sun4i: crtc: Propagate layer initialization error", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90298", " - drm/sun4i: tcon: Drop TCON TOP device reference", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90302", " - ocfs2: synchronize heartbeat callbacks with o2net teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90303", " - ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user", " faults", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90307", " - RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90314", " - remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90316", " - drm/omap: dsi: Do not copy isr table", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90318", " - fat: release buffer head after rebuilding parent", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90319", " - rapidio: clear mport->net when rio_add_net() fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90327", " - phonet: pep: do not write beyond optlen in getsockopt", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90329", " - HID: synchronize input before cleaning up a failed probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90334", " - tty: clear cdev pointer after cdev_add() failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90341", " - firmware: coreboot: Validate table bounds", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90348", " - wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90360", " - regulator: core: use system_freezable_wq for init complete work", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90361", " - wifi: ath11k: fix leak in ath11k_service_ready_ext_event()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90362", " - drm/msm/dsi: Drop dev_pm_opp_set_rate(0)", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90372", " - wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90378", " - wifi: mt76: mt792x: Fix memory leak in SDIO TX path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90382", " - wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93261", " - locking/lockdep: Fix NULL pointer dereference in __lock_set_class()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93283", " - i3c: master: Fix device_register() error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90386", " - i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90388", " - iommu/dma: Check atomic pool allocation result directly", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90391", " - lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90393", " - bpf: Fix potential UAF in bpf_netns_link_update_prog", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90394", " - power: supply: sc2731_charger: cancel work on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90395", " - power: supply: isp1704_charger: cancel work on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93262", " - md/raid5-ppl: fix use-after-free in ppl_do_flush()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90403", " - wifi: rtlwifi: pci: fix error path in rtl_pci_probe()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90411", " - nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90413", " - IB/isert: reject login PDUs declaring more data than was received", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90414", " - IB/isert: reject PDUs declaring more data than was received", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90415", " - RDMA/cxgb4: free STAG index when TPT entry write fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90416", " - RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90419", " - nilfs2: prevent out-of-bounds read in super root block parsing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90420", " - nilfs2: fix infinite loop in nilfs_clean_segments()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93264", " - RDMA/efa: Fix PBL chunk length computation", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89782", " - fs/ntfs3: reject restart table growth beyond U16_MAX entries", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90431", " - remoteproc: Prevent crash handling to race with rproc_del()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90434", " - isofs: release zisofs block pointer buffer head", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90435", " - RDMA/mlx5: Fix integer overflow of user QP buffer size", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92476", " - crypto: keembay - Initialize completion before requesting IRQ", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89785", " - fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89787", " - ext4: check dir entry fits before reading the hash trailer in", " ext4_search_dir()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92494", " - ext4: fix buffer_head leak in ext4_init_orphan_info", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92496", " - wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92498", " - wifi: ath6kl: avoid buffer overreads in WMI event handlers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92501", " - ext4: drain in-flight DIO before buffered write fallback", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92504", " - thermal: intel: int3400: clean up ODVP on probe failures", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92508", " - RDMA/core: Fix potential use after free in ib_free_cq()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93268", " - ext4: skip extra isize expansion during mount to prevent deadlock", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89786", " - ext4: fix out-of-bounds read in ext4_read_inline_dir()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92521", " - ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92522", " - ACPI: processor: validate MADT IOAPIC entry bounds", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92524", " - irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93037", " - RDMA/hfi1: Propagate sdma_txinit_ahg() errors", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93039", " - ASoC: meson: Keep link pointers valid on realloc failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93040", " - dmaengine: dw-edma: Serialize channel state checks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93041", " - dmaengine: dw-edma: Serialize abort state updates", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93046", " - software node: Fix software_node_get_reference_args() with index -1", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93048", " - mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93049", " - mtd: mtdswap: Avoid freeing registered blktrans device twice", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89777", " - vfio/pci: clear vdev->msi_perm after freeing it on init failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93051", " - misc: ad525x_dpot: use driver core groups for sysfs files", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93052", " - misc: bcm-vk: Use acquire/release for msgq_inited", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93053", " - speakup: keyhelp: guard letter_offsets possible out-of-range indexing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93054", " - uio: Fix stale info pointer in failed registration path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93055", " - UDF symlink pathComponent header OOB read", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93056", " - usb: gadget: f_uac1_legacy: remove broken string configfs attributes", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93061", " - gpu: host1x: Avoid stack over-read in debug output helpers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93067", " - drm/bridge: tc358767: clamp the reported AUX read size to the request", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93271", " - wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93095", " - hfsplus: validate thread record before delete key rebuild", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93098", " - rpmsg: glink: fix deadlock in endpoint destroy during driver detach", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89778", " - isofs: fix out-of-bounds page array access on empty zisofs block", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93102", " - RDMA/hfi1: Free RX data on late probe failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93103", " - RDMA/hfi1: Preserve unit 0 on allocation failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89783", " - xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is", " full", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93108", " - RDMA/ipoib: Drain RCU callbacks during module teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93109", " - RDMA/mlx5: Drain RCU callbacks during module teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93110", " - RDMA/core: Wait for RCU callbacks before unloading ib_core", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93114", " - platform/surface: acpi-notify: Check ACPI companion before use", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93115", " - platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93120", " - usb: gadget: configfs: fix out-of-bounds read of qw_sign", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93130", " - platform/x86: dell-wmi-base: Fix resource leak on module load failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93131", " - platform/x86: dell-privacy: Fix race condition", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93138", " - bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93140", " - udf: Mark LVID buffer as uptodate before marking it dirty", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93141", " - usb: gadget: r8a66597: avoid double free of ep0_req in probe error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93145", " - clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93278", " - staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93279", " - staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93280", " - greybus: audio: bound the topology section sizes against the fetched", " size", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93151", " - nvmet-rdma: fix response resource leak on queue teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93158", " - crypto: sa2ul - stop probe if context pool creation fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93159", " - crypto: atmel-sha204a - fix heap info leak on I2C transfer failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93160", " - crypto: atmel-ecc - reject hardware ECDH without a public key", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93161", " - crypto: qat - clear AES key schedule from stack", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93165", " - platform/chrome: sensorhub: Fix memory overread in ring handler", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93167", " - csky: Fix a4/a5 restoration in syscall trace path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93170", " - dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and", " MCDMA interrupt handlers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93177", " - drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93178", " - drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93274", " - pinctrl: bcm2835: Don't remove an unregistered GPIO chip", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93183", " - drm/lima: call drm_mm_init() with a valid allocation range", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93185", " - ASoC: rt700-sdw: always drain jack work on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93188", " - HID: roccat: bound device-supplied profile index", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93189", " - HID: core: quiesce input in hid_hw_stop() to prevent use-after-free", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93191", " - smack: fix incorrect task context in smack_msg_queue_msgrcv", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-40123", " - bpf: Enforce expected_attach_type for tailcall compatibility", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89947", " - clk: meson: align gxbb_32k_clk_sel number of parents with actual count", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80671", " - perf sched: Fix register_pid() overflow, strcpy, and BUG_ON", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93203", " - batman-adv: bla: avoid CRC corruption due to parallel claim add", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93204", " - batman-adv: dat: atomically update mac addresses", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-52944", " - ksmbd: fix FSCTL permission bypass by adding a permission check for", " FSCTL_SET_SPARSE", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-22039", " - ksmbd: fix overflow in dacloffset bounds check", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-21651", " - net: hns3: don't auto enable misc vector", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-53078", " - bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-43088", " - net: af_key: zero aligned sockaddr tail in PF_KEY exports", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-31420", " - bridge: mrp: reject zero test interval to avoid OOM panic", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-22103", " - net: fix NULL pointer dereference in l3mdev_l3_rcv", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-21649", " - net: hns3: fix kernel crash when 1588 is sent on HIP08 devices", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2023-52676", " - bpf: Guard stack limits against 32bit overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2024-50017", " - x86/mm/ident_map: Use gbpages only where full GB page should be mapped.", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-74268", " - tcp: clear sock_ops cb flags before force-closing a child socket", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90015", " - xhci: fix lost bounce buffers on TDs spanning several ring segments", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89816", " - drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93234", " - drm/gud: validate TV mode names before creating enum property", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89817", " - drm/gud: NUL-terminate TV mode names read from the device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89821", " - drm/amd/display: avoid divide-by-zero in __is_lut_linear()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89823", " - drm: fix race between partial drm_dev_register() failure and ioctl", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89843", " - scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89845", " - scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89846", " - scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89847", " - scsi: qla2xxx: Avoid double completion in async IOCB timeout", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93242", " - scsi: qla2xxx: Fix response queue over-consumption in", " __qla_consume_iocb()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89849", " - scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89850", " - scsi: qla2xxx: Don't query firmware state while chip is down", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89851", " - scsi: qla2xxx: Fix FCE trace enable parsing in debugfs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89852", " - scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89853", " - scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89854", " - scsi: qla2xxx: Fix cs84xx use-after-free on host teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89855", " - scsi: qla2xxx: Serialize flash version read in reset handler", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89856", " - scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89858", " - scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89861", " - scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89863", " - scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89864", " - scsi: qla2xxx: Bound i2c->length in I2C bsg handlers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89865", " - scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89871", " - media: video-i2c: fix kthread error pointer left in kthread_vid_cap on", " failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89872", " - media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89876", " - media: tda18250: fix possible integer overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89878", " - media: s2255: check firmware size before reading trailing marker", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89879", " - media: s2255: bound JPEG frame size before copying into the buffer", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89880", " - media: rtl2832_sdr: release URBs and stream buffers on start_streaming()", " failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89881", " - media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix", " DMA leak", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89883", " - media: rc: sunxi-cir: Unregister rc device on probe failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93236", " - media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89887", " - media: i2c: ov7740: fix use-after-destroy in remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89888", " - media: i2c: ov02a10: fix endpoint parsing use-after-free", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89890", " - media: go7007: defer the ALSA v4l2 put until card release", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89891", " - media: em28xx: fix use-after-free of dev_next->devlist on disconnect", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89892", " - media: em28xx: defer audio-only extension registration", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89893", " - media: cx23885: cancel NetUP CI work before teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89894", " - media: cx231xx: reject geometry changes while the VBI queue is busy", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89895", " - media: cobalt: Avoid freeing ALSA private data twice", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89896", " - media: cedrus: fix memory leak in cedrus_init_ctrls()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89897", " - media: cec: Serialize exclusive follower delivery", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89901", " - media: airspy: use vb2_video_unregister_device() on disconnect to fix", " NULL deref", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89923", " - KVM: s390: Free guest debug data on vcpu destroy", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89924", " - KVM: s390: Fix old_data leak in guest debug error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89925", " - KVM: s390: Fix memory leak in guest debug handling", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89926", " - KVM: s390: Fix length check __import_wp_info()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89927", " - KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89930", " - KVM: nVMX: Service local TLB flushes on failed nested VM-Enter", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89932", " - KVM: nVMX: Always flush vpid02 on first use", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89936", " - iio: dac: m62332: Fix regulator reference count imbalance", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89937", " - iio: chemical: sgp30: Handle IAQ thread creation failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89939", " - iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89945", " - ASoC: cs35l34: drain threaded IRQ before runtime suspend", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89946", " - ASoC: cs35l33: drain threaded IRQ before runtime suspend", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89948", " - batman-adv: bla: fix freeing of claims on meshif deletion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89949", " - batman-adv: dat: avoid unaligned fault in IP extraction", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89951", " - batman-adv: fix stale receive device on merged fragments", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89952", " - mtd: rawnand: validate ONFI extended parameter page sections", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89953", " - mtd: mtdoops: free page bitmap when the backing MTD is removed", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89954", " - mtd: afs: validate v2 image info bounds", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89964", " - parisc: eisa: Fix infinite loop when parsing invalid IRQ value", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89965", " - nvdimm/btt: reject an arena whose nfree is below the lane count", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89968", " - nvmet-tcp: reject unsolicited H2CData PDUs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89969", " - nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89973", " - nvme-tcp: check the data direction of a C2HData PDU", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89979", " - ALSA: pcm: Fix race between non-atomic ops and trigger-start", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89980", " - ALSA: harmony: initialize locks before requesting IRQ", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89982", " - i2c: mux: Fix channel node leak on adapter add failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89983", " - i2c: core: fix debugfs UAF on adapter removal", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89984", " - perf/x86/intel: Fix kernel address leakages in LBR stack", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89989", " - ima: Check for ERR_PTR from dentry_path() in validate_hash_algo()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89993", " - dmaengine: dw-edma: Initialize IRQ data before requesting IRQs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89997", " - dm: fix resume-vs-remove race", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89999", " - HID: wacom: validate report length in wacom_intuos_pro2_bt_irq", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90000", " - HID: rmi: fix OOB access with undersized RMI reports", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90007", " - scsi: pm8001: Use rollback index when freeing MSI-X vectors", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90011", " - scsi: target: iscsi: Reserve a terminator byte for the login payload", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90017", " - staging: rtl8723bs: fix OOB read in rtw_action_frame_parse()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90018", " - staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90019", " - usb: gadget: fix null pointer dereference in usb_put_function_instance()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90020", " - USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90025", " - usb: typec: ucsi: displayport: Fix OOB altmode array index", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90031", " - usb-storage: ene_ub6250: fix race between scan work and probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90032", " - media: usbtv: keep device alive while ALSA card exists", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90033", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90034", " - usb: image: mdc800: change kmalloc() to kzalloc()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-38097", " - espintcp: remove encap socket caching to avoid reference leak", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89515", " - scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80689", " - tracing/mmiotrace: Add NULL check for mmio_trace_array in logging", " functions", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80888", " - drm/vmwgfx: drop dma_buf reference on foreign-fd prime import", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80912", " - selinux: reject an unclaimed class value in security_get_classes()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89595", " - fsnotify: Fix stale object mask after concurrent mark updates", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89603", " - entry: Fix seccomp bypass after ptrace with TSYNC", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-74378", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89488", " - openvswitch: Fix CT limit teardown use-after-free", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90049", " - net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80977", " - net: skbuff: don't touch shared zerocopy state in skb_tx_error()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80928", " - smack: fix cred UAF in smack_file_send_sigiotask()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93222", " - signal: avoid shared siginfo namespace rewrites", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80930", " - tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80931", " - w1: ds28e17: reject an oversize length on an I2C block read", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80932", " - vsock/virtio: flush works in dependency order", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80938", " - wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80941", " - wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80944", " - wifi: mwifiex: Detach sync cmd buffer on interrupted wait", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80949", " - wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80951", " - i3c: master: svc: bound IBI payload to the requested max_payload_len", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80952", " - i3c: master: Fix info leak and UAF in device unregister path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80963", " - dm-stats: fix a crash if allocation of per-cpu data fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80964", " - ALSA: virmidi: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80965", " - ALSA: serial-u16550: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80966", " - ALSA: portman2x4: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80967", " - ALSA: pcxhr: initialize mutexes before requesting threaded IRQ", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80968", " - ALSA: mts64: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80969", " - ALSA: mpu401: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80971", " - ALSA: bcd2000: clear the URB pointers on disconnect", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80972", " - ALSA: aloop: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80973", " - ALSA: 6fire: bound the MIDI event length from the device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80976", " - seg6: reset IP6CB after IPv6 decapsulation", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80978", " - net: cap advertised IP tunnel headroom", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80983", " - net/smc: fix socket refcount leak in smc_switch_conns()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80987", " - NTB: ntb_transport: Reject oversized TX buffers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80988", " - NTB: ntb_transport: Fail TX enqueue when the QP link is down", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80994", " - net: openvswitch: fix flow mask use-after-free on flow deletion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81000", " - net: tun: bound receive headroom", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81001", " - slip: fix use-after-free in sl_sync()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81002", " - xdp: fix zero-copy frame layout", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81003", " - net/iucv: filter frames in afiucv_hs_rcv() by ingress device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81005", " - ipmi: si: Fix NULL pointer dereference after failed registration", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81007", " - ipmi: ipmb: validate write message length", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81008", " - interconnect: Fix use after free in icc_get() and of_icc_get_by_index()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81017", " - platform/chrome: sensorhub: Bound the EC-reported sensor number", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89440", " - mmc: via-sdmmc: stop card-detect handling on probe failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89444", " - platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93206", " - PCI/proc: Use file_ns_capable() when checking config space read access", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89456", " - s390/dasd: Propagate partial completion length across ERP recovery", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89457", " - s390/dasd: Guard sysfs discipline callbacks against unallocated private", " data", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89458", " - s390/dasd: Do not complete a failed ESE read as successful", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89461", " - power: supply: max17040: synchronize work cancellation on suspend", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89463", " - power: supply: ucs1002: fix use-after-free on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89464", " - power: supply: twl4030_charger: cancel workers via devm", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89469", " - power: supply: lp8727: fix use-after-free in lp8727_release_irq()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89470", " - power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89471", " - power: supply: cros_usbpd-charger: bound the EC-reported port count", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89474", " - power: supply: bq256xx: drain usb_work before freeing the charger", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89475", " - power: supply: bq24257: fix use-after-free on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89476", " - sctp: fix stream->outcnt underflow on duplicate RECONF responses", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89477", " - sctp: fix NULL deref on untransmitted RECONF completion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89478", " - sctp: drop a chunk if its transport was removed", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89479", " - sctp: stop processing a packet once its association is deleted", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89480", " - nvme-tcp: reject a read that transferred too few bytes", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89482", " - nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89483", " - nvme: zero the discard fallback page", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89485", " - lockd: pin next file across nlm_inspect_file lock-drop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89487", " - openvswitch: only skb_tx_error() a packet we are about to drop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89489", " - openrisc: fix arbitrary kernel memory access via or1k_atomic syscall", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89490", " - ocfs2: fix readdir position truncation on 32-bit kernels", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89491", " - ocfs2: cluster: don't sleep while holding o2hb_live_lock in", " o2hb_region_pin()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89493", " - ocfs2: validate rl_used against rl_count in refcount block validator", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89494", " - ocfs2: validate lengths in dlm_mig_lockres_handler", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89495", " - ocfs2: bound namelen in dlm_migrate_request_handler", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89496", " - ocfs2: always run deallocs on copy-on-write completion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89497", " - orangefs: skip leading spaces before parsing client debug masks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89498", " - orangefs: fix double-free of trailer_buf on readdir copy failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89504", " - regulator: as3722_get_regulator_dt_data: fix premature of_node_put", " leaving dangling of_node pointer", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89508", " - RDMA/ucma: Lock the handler in ucma_set_ib_path()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89510", " - RDMA/cxgb4: Cancel reg_work before freeing device on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89511", " - qede: Fix NULL pointer dereference in TPA fragment processing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89512", " - remoteproc: scp: Fix device reference leak on failed lookup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89524", " - wifi: ath6kl: clamp assoc request/response lengths before subtracting IE", " offsets", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89525", " - udf: reject VAT indexes equal to the entry count", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89532", " - svcrdma: Fix pcl_for_each_segment for empty chunks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89533", " - svcrdma: Fix offset arithmetic in read_chunk_range", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89538", " - SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89540", " - sunrpc: init gssp_lock before publishing proc entry", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89541", " - SUNRPC: harden gss_unwrap_resp_priv length checks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89542", " - SUNRPC: harden gss_krb5_unwrap_v2 against short tokens", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89548", " - SUNRPC: always drain cache_cleaner before destroying a cache_detail", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89549", " - sunrpc: route to a populated pool in svc_pool_for_cpu()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89551", " - SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89554", " - mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89555", " - mpls: reload header after pskb_may_pull()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89557", " - md: do overflow check for sb->bblog_shift in super_1_load()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89559", " - libnvdimm/labels: Prevent integer overflow in __nd_label_validate()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93226", " - ipv6: use RCU iterator to dump route exceptions", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89562", " - ip6_gre: fix hardware header length for NBMA tunnels", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89563", " - ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89569", " - Bluetooth: RFCOMM: serialize security confirmation handling", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89573", " - dm array: reject an array block whose value size is not the caller's", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89575", " - dm raid1: reserve space for NUL-terminator in build_constructor_string()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89576", " - dm-era: fix shadowed superblock leak on take-snap failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89582", " - bnx2x: fix double free in bnx2x_init_firmware() error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89585", " - auxdisplay: charlcd: cancel backlight work on registration failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89586", " - ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89594", " - hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89596", " - forcedeth: fix off-by-one when saving/restoring non-PCI config space", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89597", " - fbdev: uvesafb: unregister connector callback on init failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89599", " - fbdev: omapfb: panel-dsi-cm: initialize lock before registering display", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89605", " - ecryptfs: release message context on send failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89606", " - ecryptfs: reject too-small tag 70 packets", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89607", " - ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89608", " - ecryptfs: pass packet set buffer size to parser", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89609", " - ecryptfs: hold msg ctx list lock when cleaning daemon queue", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89615", " - fs/ntfs3: bound page_lcns[] index by the log record", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89616", " - fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89617", " - fs/ntfs3: validate dirty page table on log replay", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89621", " - HID: mcp2221: validate report size in mcp2221_raw_event()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89626", " - HID: sensor: custom: Fix field sysfs group cleanup on failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89627", " - HID: roccat: free buffered reports when destroying device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89628", " - HID: picolcd: clamp eeprom debugfs read to bytes actually received", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89643", " - audit: avoid dropping live tree ref on fsnotify rule autoremove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89649", " - ceph: bound xattr value length in __build_xattrs()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89650", " - ceph: bound num_export_targets array for mds info v2/v3", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89653", " - ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89655", " - ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89656", " - libceph: reject buckets with mismatched CRUSH ids", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89662", " - NFSD: Prevent lock owner use-after-free during client teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89663", " - nfsd: revoke copy-notify stateids before dropping their reference", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89665", " - nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89669", " - nfsd: initialize copy-notify stateid before publishing it", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89673", " - nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89674", " - nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89684", " - nfsd: fix cpntf publish race in nfs4_init_cp_state", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89694", " - nfsd: check client ownership when cancelling a copy-notify stateid", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89696", " - nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89697", " - nfsd: add fh_want_write() for early-verified SETATTR in", " nfsd_proc_setattr()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89699", " - nfsd: validate symlink target length in NFSv4 CREATE", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89704", " - nfsd: sample writeback error cursor before async COPY loop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89706", " - nfsd: Reset write verifier when async COPY writeback fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89710", " - NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget", " path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89711", " - NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89712", " - NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89720", " - ubifs: fix out-of-bounds read in signature length check", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93213", " - of: fix out-of-bounds read in of_alias_scan() stem parser", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89723", " - nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after", " truncation", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89724", " - media: vicodec: fix out-of-bounds write in FWHT encoder", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89725", " - media: cec: stm32: prevent out-of-bounds write on RX overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89726", " - lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89729", " - HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89730", " - fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89732", " - usb: gadget: f_fs: Prevent deadlock during ep0 read loop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89733", " - usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and", " uvc_function_unbind()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93214", " - usb: gadget: f_tcm: fix deadlock in usbg_make_tpg()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89736", " - usb: gadget: u_audio: Fix use-after-free on sound card disconnect", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89741", " - Revert \"media: v4l2-dev: fix error handling in", " __video_register_device()\"", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89742", " - rapidio: mport_cdev: fix use-after-free in dma_req_free()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89749", " - tracing: Fix crash passing ERR_PTR to kthread_stop()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89752", " - mm: memcg: stop reclaim when a limit update is superseded", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89753", " - mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89765", " - timers/itimer: Zero-init old itimerval before copy to userspace", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93219", " - clocksource/drivers/timer-sun4i: Advertise a real minimum delta", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-23191", " - ALSA: aloop: Fix racy access at PCM trigger", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586)", " - io_uring/io-wq: fix worker accounting when canceling creation callbacks", " - can: j1939: add missing calls in NETDEV_UNREGISTER notification handler", " - can: j1939: make j1939_sk_bind() fail if device is no longer registered", " - Revert \"PM: sleep: Use complete() in device_pm_sleep_init()\"", " - smc: Use __sk_dst_get() and dst_dev_rcu() in smc_vlan_by_tcpsk().", " - selinux: switch two allocations to use kzalloc_objs()", " - ALSA: pcm: fix wait_time calculations", " - ASoC: tegra: Fix Master Volume Control", " - ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked", " streams", " - kcov: replace local_irq_save() with a local_lock_t", " - ext4: propagate errors from fast commit range replay", " - nilfs2: correct return value kernel-doc descriptions for ioctl functions", " - nvme: rename CDR/MORE/DNR to NVME_STATUS_*", " - HID: ft260: fix i2c probing for hwmon devices", " - HID: ft260: improve i2c write performance", " - HID: ft260: improve i2c large reads performance", " - HID: ft260: skip unexpected HID input reports", " - HID: ft260: wake up device from power saving mode", " - HID: ft260: missed NACK from busy device", " - HID: ft260: validate i2c input report length", " - HID: input: read battery capacity from its actual report offset", " - fpga: dfl: fme: add error handling", " - accessibility: speakup: unregister tty ldisc on later init failures", " - xhci: dbgtty: Fix unregister on tty_alloc_driver() failure", " - usb: usbtest: disable dynamic ID support", " - mm/swap: reject swapon() on filesystem-level encrypted files", " - crypto: atmel-tdes - use scatterlist length before DMA mapping", " - crypto: qce - Remove unsafe/deprecated algorithms", " - usb: core: Strengthen error handling in hub_hub_status()", " - USB: serial: spcp8x5: drop broken carrier detect support", " - Linux 5.15.220", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80824", " - usb: usbfs: fix use-after-free of usb_device in usbdev_release()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80826", " - USB: c67x00: fix use-after-free in c67x00_add_iso_urb()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80827", " - USB: serial: option: fix slab OOB read in interrupt URB callback", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80828", " - ALSA: usb-audio: Complete cleanup after system-resume errors", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80829", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80830", " - usb: core: Add lock to usb_wakeup_notification()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80921", " - KVM: s390: vsie: zero stale crypto bits", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80831", " - crypto: mxs-dcp - fix source scatterlist length access", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80832", " - crypto: qce - fix CCM AAD buffer underallocation", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80840", " - ipv6: seg6: clear IPv4 control block on IPIP decapsulation", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80842", " - net: bridge: mcast: fix use-after-free of a master VLAN's multicast", " context", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80843", " - xfrm: fix xfrm_state_construct() auth-trunc leak", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80844", " - xfrm: ah6: validate routing header segments_left", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80846", " - xfrm: drop ESP-in-TCP packets with no ingress device", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80848", " - xfrm: espintcp: fix UAF during close", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80854", " - usb: gadget: f_tcm: keep port count until LUN teardown completes", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80855", " - fuse: fix invalidate lock leak on open O_TRUNC DAX failure", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80856", " - fuse: fix invalidate lock leak on setattr writeback failure", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80923", " - xhci: dbgtty: Fix unregister on tty_register_driver() failure", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80768", " - HID: ft260: fix stack-use-after-return write in I2C read race", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80766", " - HID: uclogic: fix use-after-free of inrange_timer on remove", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80789", " - nvmet-tcp: bound SGL data length before allocating command buffers", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80783", " - HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80796", " - nfc: nci: add data_len bound checks to activation parameter extractors", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80807", " - nilfs2: reject invalid block index in GC ioctl", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80916", " - kcov: fix data corruption and race conditions on PREEMPT_RT", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-72323", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-43437", " - ALSA: pcm: fix use-after-free on linked stream runtime in", " snd_pcm_drain()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-53089", " - bpf: Fix use-after-free in offloaded map/prog info fill", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2025-40102", " - KVM: arm64: Prevent access to vCPU events before init", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2025-39925", " - can: j1939: implement NETDEV_UNREGISTER notification handler", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2024-58095", " - jfs: add check read-only before txBeginAnon() call", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2024-58094", " - jfs: add check read-only before truncation in jfs_truncate_nolock()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2024-46754", " - bpf: Remove tst_run from lwt_seg6local_prog_ops.", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-68476", " - ipvs: reload ip header after head reallocation", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80806", " - ext4: don't enable DAX on new encrypted files", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80863", " - RDMA/rxe: Fix OOB in free_rd_atomic_resources()", " * Jammy update: v5.15.219 upstream stable release (LP: #2168549)", " - Linux 5.15.219", " * Jammy update: v5.15.219 upstream stable release (LP: #2168549) //", " CVE-2026-80590", " - inet: frags: strip GSO state from fragments before reassembly", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525)", " - null_blk: fix UBSAN shift-out-of-bounds when zone_size is 0 or overflows", " - ext4: clear error before retrying inode xattr space fallback", " - misc: fastrpc: separate fastrpc device from channel context", " - misc: fastrpc: Rework fastrpc_req_munmap", " - perf/core: Fix child_total_time_enabled accounting bug at task exit", " - perf: Fix cgroup state vs ERROR", " - perf: Fix dangling cgroup pointer in cpuctx", " - nfc: nci: free destination parameters when closing a connection", " - drm/amdgpu: check ASPM on the dGPU host link", " - KVM: x86/mmu: Retry page fault if root is invalidated by memslot update", " - KVM: x86/mmu: Directly \"destroy\" PTE list when recycling rmaps", " - KVM: x86/mmu: Rename pte_list_{destroy,remove}() to show they zap SPTEs", " - KVM: x86/mmu: Document the \"rules\" for using host_pfn_mapping_level()", " - KVM: Rename mmu_notifier_* to mmu_invalidate_*", " - KVM: x86/mmu: Split out TDP MMU page fault handling", " - KVM: x86/mmu: Rename __direct_map() to direct_map()", " - HID: magicmouse: Prevent out-of-bounds (OOB) read during", " DOUBLE_REPORT_ID", " - KVM: x86: Retry page fault if MMU reload is pending and root has no sp", " - Input: atkbd - skip deactivate for HONOR FMB-P's internal keyboard", " - Input: atkbd - skip deactivate for HONOR ZQC-P", " - mptcp: pm: ADD_ADDR rtx: allow ID 0", " - mptcp: pm: fix data race in add_addr timer callback", " - can: use skb hash instead of private variable in headroom", " - Revert \"ALSA: aoa: Use guard() for mutex locks\"", " - Linux 5.15.218", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80765", " - HID: hyperv: validate initial device info bounds", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80767", " - HID: sensor: custom: Fix use-after-free in enable_sensor", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80918", " - HID: core: fix number/pointer type confusion on long items", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80889", " - can: isotp: fix timer drain order, wakeup handling and tx_gen ordering", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-46170", " - mptcp: pm: ADD_ADDR rtx: free sk if last", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-46158", " - mptcp: pm: ADD_ADDR rtx: always decrease sk refcount", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80555", " - s390/vfio_ccw: Free all memory if cp_init() fails", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2025-68794", " - iomap: adjust read range correctly for non-block-aligned positions", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-64581", " - xfrm: fix sk_dst_cache double-free in xfrm_user_policy()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80781", " - HID: core: fix OOB read of field->usage in hid_set_field()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80782", " - HID: magicmouse: do not keep a stale msc->input if no input is claimed", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80583", " - ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80587", " - mptcp: avoid combining some incoming suboptions", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80547", " - s390/vfio_ccw: Implement a crw lock", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80548", " - s390/vfio_ccw: Selectively expand io_mutex", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80552", " - s390/vfio_ccw: Ensure index for read/write regions are within range", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80788", " - nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80790", " - nvmet-fc: fix invalid free in LS IOD error path", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80792", " - ipv6: fix use-after-free in ip6_finish_output2()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80793", " - ipv4: reject undersized MTUs in ip_do_fragment()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80557", " - libceph: fix OOB read in decode_watchers() via missing bounds check", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80794", " - nfc: nci: fix uninit-value in the RF discover/activated NTF handlers", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80795", " - nfc: nci: fix out-of-bounds write in nci_target_auto_activated()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80823", " - nfc: st21nfca: validate ATR_REQ length against the received frame", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80797", " - nfc: pn533: purge fragmented skbs during cleanup", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80798", " - nfc: llcp: reject PDUs shorter than the LLCP header", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80799", " - nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80800", " - nfc: llcp: bound the connect_sn TLV walk to the skb", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80801", " - nfc: microread: validate target discovery payload lengths", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80802", " - nfc: fdp: bound the device-reported read length and fix an skb leak", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80803", " - nfc: digital: clamp SENSF_RES length to the destination buffer", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80536", " - xfs: bounds-check buffer log item's dirty bitmap", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80553", " - s390/vfio_ccw: Cancel existing workqueues", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74662", " - inet: frags: publish queues before arming timer", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74666", " - packet: synchronize pressure clearing with ring reconfiguration", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74663", " - net/sched: reject overly deep qdisc hierarchies", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74668", " - packet: use consistent hard_header_len in TX_RING send path", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74582", " - packet: use consistent hard_header_len in non-ring send paths", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80737", " - serial: amba-pl011: synchronize DMA teardown", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74626", " - NTB: ntb_netdev: Preserve RX queue depth on allocation failure", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74637", " - perf/core: Fix group leader use-after-free after sibling detach", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74647", " - misc: fastrpc: Remove buffer from list prior to unmap operation", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74632", " - mm/huge_memory: fix huge_zero_pfn race", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80562", " - gpio: ml-ioh: use raw_spinlock_t for the register lock", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80805", " - xfs: validate attr entry pointer before field access", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80808", " - ext4: stop retrying saturated xattr cache entries", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80809", " - ocfs2: fix missing metadata reservation for large xattrs", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80812", " - ALSA: dummy: Check card index validity at probe", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80814", " - rndis_host: add overflow check in rndis_rx_fixup()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80819", " - Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80917", " - PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems", " * Jammy update: v5.15.217 upstream stable release (LP: #2168510)", " - f2fs: fix UAF issue in f2fs_merge_page_bio()", " - media: mediatek: vcodec: Fix a resource leak related to the scp device", " in FW initialization", " - fscrypt: use the mount idmap for the owner check in", " fscrypt_ioctl_set_policy()", " - ipvs: separate destination availability state", " - selinux: require every boolean value to be defined", " - selinux: reject a class permission count below its inherited common", " - selinux: do not cancel a policy conversion that never started", " - mptcp: options: reset DSS fields in case of unexpected size", " - s390/qeth: validate user buffer length in SNMP and ARP query ioctls", " - ASoC: cs4265: sort the register default table", " - ASoC: codecs: lpass-wsa-macro: Fix enum kcontrol accesses", " - powerpc/pseries: pci - logic bug", " - Input: synaptics-rmi4 - fix F55 transmitter electrode count typo", " - Input: focaltech - fix array out-of-bounds in", " focaltech_process_rel_packet", " - Input: psxpad-spi - set driver data before use", " - Input: atkbd - skip deactivate for Xiaomi Book Pro 14's internal", " keyboard", " - Input: iforce - validate input packet lengths", " - powerpc/pseries: lparcfg - fix kbuf[] underflow", " - Input: synaptics-rmi4 - zero report size on F54 work error", " - Input: synaptics-rmi4 - bound the F54 report size to the allocated", " buffer", " - Input: synaptics-rmi4 - block s_input when F54 queue is busy", " - Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue", " - crypto: qce - fix error path in devm_qce_register_algs", " - libceph: fix multiple unsafe decodes in decode_locker()", " - ftrace: Fix off-by-one fentry site disable in ftrace_free_mem()", " - openrisc: signal: do not restore privileged SR bits on sigreturn", " - Input: sur40 - fix input device registration ordering", " - Input: sur40 - fix V4L error path cleanup", " - libceph: Avoid using invalid osd indices from primary_temp", " - ceph: fix MDS random selection readiness predicate", " - libceph: tolerate addrvecs with multiple entries of the same type", " - mmc: omap_hsmmc: fix busy_timeout overflow in ns conversion on 32-bit", " - mmc: sdhci: unmap the bounce buffer before device release", " - mmc: sdhci: make tuning_err a signed int", " - drm/radeon: fix autosuspend cleanup during teardown", " - s390/vfio_ccw: Fix out of bounds check on CCW array", " - drm/amdgpu: Reject UVD message with invalid number of h265 refs", " - drm/amdgpu: validate GEM_CREATE domain combinations", " - drm/amdgpu: Reject UVD message with dimensions above 4096", " - drm/amdgpu: Implement insert_end for VCE 3", " - drm/amdgpu: Fix UVD decode image min size calculation", " - xfs: fix ilock leak on error in xfs_dq_get_next_id", " - xfs: check v5 superblock features early", " - net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot", " - mm: do file ownership checks with the proper mount idmap", " - iommu/amd: Don't split flush for amd_iommu_domain_flush_all()", " - bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is", " uninitialized", " - udmabuf: Do not create malformed scatterlists", " - dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning", " - fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region()", " - Input: mms114 - fix touch indexing for MMS134S and MMS136", " - i2c: davinci: Unregister cpufreq notifier on probe failure", " - Input: mms114 - reject an oversized device packet size", " - ALSA: hda: conexant: Remove mic bias threshold override", " - VFS/audit: introduce kern_path_parent() for audit", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - audit: fix recursive locking deadlock in audit_dupe_exe()", " - ALSA: hda: Fix cached processing coefficient verbs", " - serial: max310x: replace bare use of 'unsigned' with 'unsigned int'", " (checkpatch)", " - serial: max310x: implement gpio_chip::get_direction()", " - rxrpc: serialize kernel accept preallocation with socket teardown", " - fbcon: Rename struct fbcon_ops to struct fbcon_par", " - fbcon: Use correct type for vc_resize() return value", " - tipc: restrict socket queue dumps in enqueue tracepoints", " - mlxsw: spectrum: On port enslavement to a LAG, join upper's bridges", " - mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()", " - vduse: Use fixed 4KB bounce pages for non-4KB page size", " - vduse: remove unused vaddr parameter of vduse_domain_free_coherent", " - vduse: take out allocations from vduse_dev_alloc_coherent", " - VDUSE: avoid leaking information to userspace", " - octeontx2-af: Fix APR entry mapping based on APR_LMT_CFG", " - octeontx2: Annotate mmio regions as __iomem", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - tcp: convert to dev_net_rcu()", " - net: dst: annotate data-races around dst->input", " - net: dst: annotate data-races around dst->output", " - net: dst: add four helpers to annotate data-races around dst->dev", " - ipv4: adopt dst_dev, skb_dst_dev and skb_dst_dev_net[_rcu]", " - netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst", " - ASoC: mediatek: mt8192-afe-pcm: Convert to devm_pm_runtime_enable()", " - ASoC: mediatek: mt8192-afe-pcm: Simplify with dev_err_probe()", " - ASoC: mediatek: Use common mtk_afe_pcm_platform with common probe cb", " - ASoC: mediatek: mt8192-afe-pcm: Simplify probe() with local dev variable", " - ASoC: mediatek: mt8192: Check runtime resume during probe", " - netfilter: nft_set_pipapo: use GFP_KERNEL for insertions", " - netfilter: nft_set_pipapo: move prove_locking helper around", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", " - netfilter: nft_set_pipapo: make pipapo_clone helper return NULL", " - netfilter: nft_set_pipapo: prepare walk function for on-demand clone", " - netfilter: nft_set_pipapo: merge deactivate helper into caller", " - netfilter: nft_set_pipapo: prepare pipapo_get helper for on-demand clone", " - netfilter: nft_set_pipapo: move cloning of match info to insert/removal", " path", " - netfilter: nft_set_pipapo: don't leak bad clone into future transaction", " - remoteproc: qcom: replace kstrdup with kstrndup", " - remoteproc: qcom: fix sparse warnings", " - remoteproc: qcom: pas: Adjust the phys addr wrt the mem region", " - remoteproc: qcom: Fix leak when custom dump_segments addition fails", " - lsm: use default hook return value in call_int_hook()", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - fs/ntfs3: Make ntfs_update_mftmirr return void", " - fs/ntfs3: Undo critial modificatins to keep directory consistency", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - net: thunderbolt: Fix frags[] overflow by bounding frame_count", " - mtd: spi-nor: Fix spi_nor_try_unlock_all()", " - mtd: spi-nor: swp: Improve locking user experience", " - dmaengine: dw-edma: Remove unused irq field in struct dw_edma_chip", " - dmaengine: dw-edma: Detach the private data and chip info structures", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - taskstats: fill_stats_for_tgid: use for_each_thread()", " - taskstats: retain dead thread stats in TGID queries", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - ksmbd: fix integer overflow in set_file_allocation_info()", " - i2c: imx: separate atomic, dma and non-dma use case", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", " - can/esd_usb2: Rename esd_usb2.c to esd_usb.c", " - [Config] Set CONFIG_CAN_ESD_USB=m", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - thunderbolt: Remove usage of the deprecated ida_simple_xx() API", " - thunderbolt: Update property.c function documentation", " - thunderbolt: Keep XDomain reference during the lifetime of a service", " - thunderbolt: Remove service debugfs entries during unregister", " - thunderbolt: Remove XDomain from the bus without holding tb->lock", " - thunderbolt: Prevent XDomain delayed work use-after-free on disconnect", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - ovl: use linked upper dentry in copy-up tmpfile", " - scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: make error counter atomic", " - firmware_loader: introduce __free() cleanup hanler", " - Input: ims-pcu - fix firmware leak in async update", " - mmc: vub300: fix use-after-free on disconnect", " - mmc: vub300: rename probe error labels", " - mmc: vub300: fix use-after-free on probe failure", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", " - net: Add helper function to parse netlink msg of ip_tunnel_encap", " - net: ipip: require CAP_NET_ADMIN in the device netns for changelink", " - net: ixp4xx_hss: fix duplicate HDLC netdev allocation", " - net/sched: act_ct: preserve tc_skb_cb across defragmentation", " - net: mana: Validate the packet length reported by the NIC", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", " - treewide: rename pinctrl_gpio_direction_output_new()", " - gpio: tegra: do not call pinctrl for GPIO direction", " - net/sched: taprio: avoid calling child->ops->dequeue(child) twice", " - net/sched: sch_taprio: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - bootconfig: do not put quotes on cmdline items unless necessary", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - espintcp: use sk_msg_free_partial to fix partial send", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - octeontx2-pf: fix SQB pointer leak on init failure", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", " - usb: gadget: f_tcm: synchronize delayed set_alt with teardown", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", " - dma-buf/drivers: make reserving a shared slot mandatory v4", " - drm/virtio: use uninterruptible resv lock for plane updates", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/tegra: fbdev: Remove offset into framebuffer memory", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/virtio: Return proper error codes instead of -1", " - drm/virtio: bound EDID block reads to the response buffer", " - media: aspeed: fix missing of_reserved_mem_device_release() on probe", " failure", " - drm/i915/vrr: require valid min/max vfreq for VRR", " - drm/i915/hdcp: check streams[] bounds before overflow", " - drm/i915/hdcp: require monotonically increasing seq_num_v", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: i2c: imx219: Drop IMX219_VTS_* macros", " - media: i2c: imx219: Correct the minimum vblanking value", " - media: i2c: imx219: Rename VTS to FRM_LENGTH", " - media: imx219: Fix maximum frame length in lines", " - wifi: ath6kl: fix use-after-free in aggr_reset_state()", " - media: v4l: async: Set owner for async sub-devices", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", " - ALSA: seq: close a re-opened queue timer in the destructor", " - wifi: brcmfmac: drain bus_reset work on device removal", " - serial: 8250_mid: Remove unneeded test for ->setup() presence", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " - wifi: brcmfmac: fix 43752 SDIO FWVID incorrectly labelled as Cypress", " (CYW)", " - wifi: brcmfmac: set F2 blocksize to 256 for BCM43752", " - sc16is7xx: Properly resume TX after stop", " - serial: sc16is7xx: Fill in rs485_supported", " - serial: sc16is7xx: remove obsolete out_thread label", " - serial: sc16is7xx: fix regression with GPIO configuration", " - serial: sc16is7xx: implement gpio get_direction() callback", " - mptcp: cleanup MPJ subflow list handling", " - mptcp: fix subflow accounting on close", " - mptcp: decrement subflows counter on failed passive join", " - sctp: avoid auth_enable sysctl UAF during netns teardown", " - ceph: avoid fs reclaim while using current->journal_info", " - libceph: Amend checking to fix `make W=1` build breakage", " - libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE", " - libceph: add doutc and *_client debug macros support", " - ceph: rename _to_client() to _to_fs_client()", " - ceph: print cluster fsid and client global_id in all debug logs", " - ceph: fix hanging __ceph_get_caps() with stale mds_wanted", " - libceph: fix two unsafe bare decodes in decode_lockers()", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", " - net/sched: serialize qdisc_rtab_list against concurrent get/put", " - ftrace: Add global mutex to serialize trace_parser access", " - super: fix emergency thaw deadlock on frozen block devices", " - ksmbd: rename smb2_get_msg to smb_get_msg", " - smb/server: fix minimum SMB1 PDU size", " - smb/server: fix minimum SMB2 PDU size", " - ksmbd: validate minimum PDU size for transform requests", " - mm/vmstat: fold stranded per-cpu node stats when a node comes online", " - ksmbd: conn lock to serialize smb2 negotiate", " - ksmbd: reject repeated SMB2 NEGOTIATE requests", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", " - igc: remove napi_synchronize() in igc_down()", " - net: pktgen: fix code style (WARNING: Block comments)", " - net: pktgen: fix proc entry use-after-free", " - scsi: sd: sd_zbc: Improve source code documentation", " - scsi: sd: sd_zbc: Use logical blocks as unit when querying zones", " - scsi: sd: sd_zbc: Introduce struct zoned_disk_info", " - scsi: sd: sd_zbc: Return early in sd_zbc_check_zoned_characteristics()", " - scsi: scsi_debug: Rename zone type constants", " - scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write", " - ice: fix VF interrupts cleanup", " - ice: fix memory leak in ice_lbtest_prepare_rings()", " - fsnotify: opt-in for permission events at file open time", " - fs: don't block write during exec on pre-content watched files", " - binfmt_misc: restore write access when removing an entry", " - i2c: imx: Fix slave registration race and error handling", " - i2c: bcm-iproc: remove printout on handled timeouts", " - i2c: iproc: reset bus after timeout if START_BUSY is stuck", " - can: gs_usb: gs_usb_receive_bulk_callback(): resubmit URB on skb", " allocation failure", " - jiffies: Define secs_to_jiffies()", " - ice: wait for reset completion in ice_resume()", " - drm/amd/pm: fix torn gpu metrics reads", " - sched/psi: Shut down rtpoll_timer in psi_cgroup_free()", " - mm/ptdump: always stabilise against page table freeing using init_mm", " - net: add a couple of helpers for iph tot_len", " - openvswitch: use skb_ip_totlen in conntrack", " - net: sched: use skb_ip_totlen and iph_totlen", " - openvswitch: move key and ovs_cb update out of handle_fragments", " - net/sched: act_ct: fix sk_buff leak when the header checks reject a", " packet", " - net: atlantic: free stranded TX buffers on ring deinit", " - net/smc: rdma write inline if qp has sufficient inline space", " - net: smc: fix splice entry lifetime imbalance in smc_rx_splice", " - arm64: tegra: Add EL2 virtual timer interrupt for Tegra194", " - crypto: ccm - Set rfc4309 maxauthsize from child", " - netfilter: ipset: fix refcount race between list:set GC and swap", " - netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort", " path", " - netfilter: flowtable: publish GC-visible tuple last", " - netfilter: ipset: fix list type element drift bug", " - net: packet: fix wrong transport_header when sending VLAN-tagged frame", " - ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers", " - af_packet: Don't send zero-byte data in tpacket_snd().", " - net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG", " - net/x25: fix use-after-free of the socket by its timers", " - binfmt_misc: use exe_file_deny_write_access() for the interpreter clone", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - drm/vmwgfx: Reserve fence slots on buffer objects in cotables", " - drm/virtio: Unlock reservations on dma_resv_reserve_fences() error", " - jiffies: Cast to unsigned long in secs_to_jiffies() conversion", " - ring-buffer: Remove jump to out label in ring_buffer_swap_cpu()", " - ring-buffer: Use current_context for safe per-CPU buffer swap", " - Linux 5.15.217", "" ], "package": "linux-kvm", "version": "5.15.0-1111.116", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2170108, 2170970, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168549, 2168549, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168510 ], "author": "Alessio Faina ", "date": "Fri, 16 Oct 2026 09:22:17 +0200" }, { "cves": [ { "cve": "CVE-2022-1205", "url": "https://ubuntu.com/security/CVE-2022-1205", "cve_description": "A NULL pointer dereference flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system.", "cve_priority": "high", "cve_public_date": "2022-08-31 16:15:00 UTC" }, { "cve": "CVE-2022-50303", "url": "https://ubuntu.com/security/CVE-2022-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix double release compute pasid If kfd_process_device_init_vm returns failure after vm is converted to compute vm and vm->pasid set to compute pasid, KFD will not take pdd->drm_file reference. As a result, drm close file handler maybe called to release the compute pasid before KFD process destroy worker to release the same pasid and set vm->pasid to zero, this generates below WARNING backtrace and NULL pointer access. Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step of kfd_process_device_init_vm, to ensure vm pasid is the original pasid if acquiring vm failed or is the compute pasid with pdd->drm_file reference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10", "cve_priority": "medium", "cve_public_date": "2025-09-15 15:15:00 UTC" }, { "cve": "CVE-2023-53320", "url": "https://ubuntu.com/security/CVE-2023-53320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info() The function mpi3mr_get_all_tgt_info() has four issues: 1) It calculates valid entry length in alltgt_info assuming the header part of the struct mpi3mr_device_map_info would equal to sizeof(u32). The correct size is sizeof(u64). 2) When it calculates the valid entry length kern_entrylen, it excludes one entry by subtracting 1 from num_devices. 3) It copies num_device by calling memcpy(). Substitution is enough. 4) It does not specify the calculated length to sg_copy_from_buffer(). Instead, it specifies the payload length which is larger than the alltgt_info size. It causes \"BUG: KASAN: slab-out-of-bounds\". Fix the issues by using the correct header size, removing the subtraction from num_devices, replacing the memcpy() with substitution and specifying the correct length to sg_copy_from_buffer().", "cve_priority": "low", "cve_public_date": "2025-09-16 17:15:00 UTC" }, { "cve": "CVE-2025-39726", "url": "https://ubuntu.com/security/CVE-2025-39726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ism: fix concurrency management in ism_cmd() The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that. This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well. A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it. On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.", "cve_priority": "high", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39779", "url": "https://ubuntu.com/security/CVE-2025-39779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: subpage: keep TOWRITE tag until folio is cleaned btrfs_subpage_set_writeback() calls folio_start_writeback() the first time a folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tag even if there are still dirty blocks in the folio. This can break ordering guarantees, such as those required by btrfs_wait_ordered_extents(). That ordering breakage leads to a real failure. For example, running generic/464 on a zoned setup will hit the following ASSERT. This happens because the broken ordering fails to flush existing dirty pages before the file size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode or for compressed writes, it locks several folios for delalloc and starts writing them out. Let's call the last locked folio folio X. Suppose the write range only partially covers folio X, leaving some pages dirty. Process A calls btrfs_subpage_set_writeback() when building a bio. This function call clears the TOWRITE tag of folio X, whose size = 8K and the block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range. Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. It calls tag_pages_for_writeback() to tag dirty folios with PAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then, B collects tagged folios using filemap_get_folios_tag() and must wait for folio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE) However, between tagging and collecting, process A may call btrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY) As a result, process B won't see folio X in its batch, and returns without waiting for it. This breaks the WB_SYNC_ALL ordering requirement. Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retains the TOWRITE tag. We now manually clear the tag only after the folio becomes clean, via the xas operation.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39810", "url": "https://ubuntu.com/security/CVE-2025-39810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix memory corruption when FW resources change during ifdown bnxt_set_dflt_rings() assumes that it is always called before any TC has been created. So it doesn't take bp->num_tc into account and assumes that it is always 0 or 1. In the FW resource or capability change scenario, the FW will return flags in bnxt_hwrm_if_change() that will cause the driver to reinitialize and call bnxt_cancel_reservations(). This will lead to bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc may be greater than 1. This will cause bp->tx_ring[] to be sized too small and cause memory corruption in bnxt_alloc_cp_rings(). Fix it by properly scaling the TX rings by bp->num_tc in the code paths mentioned above. Add 2 helper functions to determine bp->tx_nr_rings and bp->tx_nr_rings_per_tc.", "cve_priority": "low", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-37861", "url": "https://ubuntu.com/security/CVE-2025-37861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.", "cve_priority": "low", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-38643", "url": "https://ubuntu.com/security/CVE-2025-38643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() Callers of wdev_chandef() must hold the wiphy mutex. But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes: WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985", "cve_priority": "low", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38615", "url": "https://ubuntu.com/security/CVE-2025-38615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: cancle set bad inode after removing name fails The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted. The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's \"icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier\". In some it's outright \"we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles\".", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38361", "url": "https://ubuntu.com/security/CVE-2025-38361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check dce_hwseq before dereferencing it [WHAT] hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used. (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)", "cve_priority": "low", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38259", "url": "https://ubuntu.com/security/CVE-2025-38259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd9335: Fix missing free of regulator supplies Driver gets and enables all regulator supplies in probe path (wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup in final error paths and in unbind (missing remove() callback). This leads to leaked memory and unbalanced regulator enable count during probe errors or unbind. Fix this by converting entire code into devm_regulator_bulk_get_enable() which also greatly simplifies the code.", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38239", "url": "https://ubuntu.com/security/CVE-2025-38239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix invalid node index On a system with DRAM interleave enabled, out-of-bound access is detected: megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it accordingly.", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2022-50071", "url": "https://ubuntu.com/security/CVE-2022-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: move subflow cleanup in mptcp_destroy_common() If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE eBPF program, the MPTCP protocol ends-up leaking all the subflows: the related cleanup happens in __mptcp_destroy_sock() that is not invoked in such code path. Address the issue moving the subflow sockets cleanup in the mptcp_destroy_common() helper, which is invoked in every msk cleanup path. Additionally get rid of the intermediate list_splice_init step, which is an unneeded relic from the past. The issue is present since before the reported root cause commit, but any attempt to backport the fix before that hash will require a complete rewrite.", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2025-37920", "url": "https://ubuntu.com/security/CVE-2025-37920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: Fix race condition in AF_XDP generic RX path Move rx_lock from xsk_socket to xsk_buff_pool. Fix synchronization for shared umem mode in generic RX path where multiple sockets share single xsk_buff_pool. RX queue is exclusive to xsk_socket, while FILL queue can be shared between multiple sockets. This could result in race condition where two CPU cores access RX path of two different sockets sharing the same umem. Protect both queues by acquiring spinlock in shared xsk_buff_pool. Lock contention may be minimized in the future by some per-thread FQ buffering. It's safe and necessary to move spin_lock_bh(rx_lock) after xsk_rcv_check(): * xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers. * xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-43456", "url": "https://ubuntu.com/security/CVE-2026-43456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix type confusion in bond_setup_by_slave() kernel BUG at net/core/skbuff.c:2306! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306 RSP: 0018:ffffc90004aff760 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900 RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780 R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0 Call Trace: ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900 dev_hard_header include/linux/netdevice.h:3439 [inline] packet_snd net/packet/af_packet.c:3028 [inline] packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592 ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646 __sys_sendmsg+0x170/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe1a0e6c1a9 When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond, bond_setup_by_slave() directly copies the slave's header_ops to the bond device: bond_dev->header_ops = slave_dev->header_ops; This causes a type confusion when dev_hard_header() is later called on the bond device. Functions like ipgre_header(), ip6gre_header(),all use netdev_priv(dev) to access their device-specific private data. When called with the bond device, netdev_priv() returns the bond's private data (struct bonding) instead of the expected type (e.g. struct ip_tunnel), leading to garbage values being read and kernel crashes. Fix this by introducing bond_header_ops with wrapper functions that delegate to the active slave's header_ops using the slave's own device. This ensures netdev_priv() in the slave's header functions always receives the correct device. The fix is placed in the bonding driver rather than individual device drivers, as the root cause is bond blindly inheriting header_ops from the slave without considering that these callbacks expect a specific netdev_priv() layout. The type confusion can be observed by adding a printk in ipgre_header() and running the following commands: ip link add dummy0 type dummy ip addr add 10.0.0.1/24 dev dummy0 ip link set dummy0 up ip link add gre1 type gre local 10.0.0.1 ip link add bond1 type bond mode active-backup ip link set gre1 master bond1 ip link set gre1 up ip link set bond1 up ip addr add fe80::1/64 dev bond1", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2022-49858", "url": "https://ubuntu.com/security/CVE-2022-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix SQE threshold checking Current way of checking available SQE count which is based on HW updated SQB count could result in driver submitting an SQE even before CQE for the previously transmitted SQE at the same index is processed in NAPI resulting losing SKB pointers, hence a leak. Fix this by checking a consumer index which is updated once CQE is processed.", "cve_priority": "medium", "cve_public_date": "2025-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-22057", "url": "https://ubuntu.com/security/CVE-2025-22057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: decrease cached dst counters in dst_release Upstream fix ac888d58869b (\"net: do not delay dst_entries_add() in dst_release()\") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30 Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-22083", "url": "https://ubuntu.com/security/CVE-2025-22083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang: 1. Use-after-free when no tpgs are found: This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If a scsi request is then sent we do: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend which sees the vs_tpg we just did a kfree on. 2. Tpg dir removal hang: This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1. The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg. Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir. 3. Tpg leak: This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names. The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs. Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2024-58096", "url": "https://ubuntu.com/security/CVE-2024-58096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode ath11k_hal_srng_* should be used with srng->lock to protect srng data. For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock. So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319 So add srng->lock for them to avoid such warnings. Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct hal_srng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_process_rx(). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-21947", "url": "https://ubuntu.com/security/CVE-2025-21947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix type confusion via race condition when using ipc_msg_send_request req->handle is allocated using ksmbd_acquire_id(&ipc_ida), based on ida_alloc. req->handle from ksmbd_ipc_login_request and FSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion between messages, resulting in access to unexpected parts of memory after an incorrect delivery. ksmbd check type of ipc response but missing add continue to check next ipc reponse.", "cve_priority": "high", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2022-49562", "url": "https://ubuntu.com/security/CVE-2022-49562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing \"random\" pfns for pretty much any other VM_PFNMAP case.", "cve_priority": "low", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2025-21812", "url": "https://ubuntu.com/security/CVE-2025-21812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: rcu protect dev->ax25_ptr syzbot found a lockdep issue [1]. We should remove ax25 RTNL dependency in ax25_setsockopt() This should also fix a variety of possible UAF in ax25. [1] WARNING: possible circular locking dependency detected 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted ------------------------------------------------------ syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated---", "cve_priority": "high", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21801", "url": "https://ubuntu.com/security/CVE-2025-21801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ravb: Fix missing rtnl lock in suspend/resume path Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations. Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down", "cve_priority": "low", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-54683", "url": "https://ubuntu.com/security/CVE-2024-54683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: IDLETIMER: Fix for possible ABBA deadlock Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs: | ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20 | | but task is already holding lock: | ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v] | | which lock already depends on the new lock. A simple reproducer is: | #!/bin/bash | | while true; do | iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\" | iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\" | done & | while true; do | cat /sys/class/xt_idletimer/timers/testme >/dev/null | done Avoid this by freeing list_mutex right after deleting the element from the list, then continuing with the teardown.", "cve_priority": "medium", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2024-53220", "url": "https://ubuntu.com/security/CVE-2024-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to account dirty data in __get_secs_required() It will trigger system panic w/ testcase in [1]: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2752! RIP: 0010:new_curseg+0xc81/0x2110 Call Trace: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is if checkpoint_disabling and lfs_mode are both on, it will trigger OPU for all overwritten data, it may cost more free segment than expected, so f2fs must account those data correctly to calculate cosumed free segments later, and return ENOSPC earlier to avoid run out of free segment during block allocation. [1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2025-21759", "url": "https://ubuntu.com/security/CVE-2025-21759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: extend RCU protection in igmp6_send() igmp6_send() can be called without RTNL or RCU being held. Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection.", "cve_priority": "high", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57999", "url": "https://ubuntu.com/security/CVE-2024-57999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing. These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range. The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries Workqueue: events work_for_cpu_fn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100 LR [c00000000005e830] iommu_init_table+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620 [c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 There are 2 issues in the code 1. The index is \"int\" while the address is \"unsigned long\". This results in negative value when setting the bitmap. 2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well.", "cve_priority": "low", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57982", "url": "https://ubuntu.com/security/CVE-2024-57982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: state: fix out-of-bounds read during lookup lookup and resize can run in parallel. The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array. rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask; While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) { This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again). Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent. The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side. xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2022-49651", "url": "https://ubuntu.com/security/CVE-2022-49651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: srcu: Tighten cleanup_srcu_struct() GP checks Currently, cleanup_srcu_struct() checks for a grace period in progress, but it does not check for a grace period that has not yet started but which might start at any time. Such a situation could result in a use-after-free bug, so this commit adds a check for a grace period that is needed but not yet started to cleanup_srcu_struct().", "cve_priority": "low", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2022-49359", "url": "https://ubuntu.com/security/CVE-2022-49359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Job should reference MMU not file_priv For a while now it's been allowed for a MMU context to outlive it's corresponding panfrost_priv, however the job structure still references panfrost_priv to get hold of the MMU context. If panfrost_priv has been freed this is a use-after-free which I've been able to trigger resulting in a splat. To fix this, drop the reference to panfrost_priv in the job structure and add a direct reference to the MMU structure which is what's actually needed.", "cve_priority": "high", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2022-49234", "url": "https://ubuntu.com/security/CVE-2022-49234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: Avoid cross-chip syncing of VLAN filtering Changes to VLAN filtering are not applicable to cross-chip notifications. On a system like this: .-----. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-' '-1-2-' '-1-2-' Before this change, upon sw1p1 leaving a bridge, a call to dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1. In this scenario: .---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-' When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be called for sw2 and sw3 with a non-existing port - leading to array out-of-bounds accesses and crashes on mv88e6xxx.", "cve_priority": "medium", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2024-57945", "url": "https://ubuntu.com/security/CVE-2024-57945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Fix the out of bound issue of vmemmap address In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)). However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page. For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END. This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base.", "cve_priority": "low", "cve_public_date": "2025-01-21 13:15:00 UTC" }, { "cve": "CVE-2024-53210", "url": "https://ubuntu.com/security/CVE-2024-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct() Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skb_queue_purge() and WARN_ON in iucv_sock_destruct() during socket close. To fix this decrease skb refcount by one if MSG_PEEK is set in order to prevent memory leak and WARN_ON. WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53187", "url": "https://ubuntu.com/security/CVE-2024-53187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check for overflows in io_pin_pages WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1110.115 -proposed tracker (LP: #2168199)", "", " [ Ubuntu: 5.15.0-199.209 ]", "", " * jammy/linux: 5.15.0-199.209 -proposed tracker (LP: #2168214)", " * [SRU] selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value", " (LP: #2107442)", " - selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value", " * CVE-2022-1205", " - ax25: Fix ax25 session cleanup problems", " * CVE-2022-50303", " - drm/amdkfd: Fix double release compute pasid", " * CVE-2023-53320", " - scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info()", " * CVE-2025-39726", " - s390/ism: fix concurrency management in ism_cmd()", " * CVE-2025-39779", " - btrfs: subpage: keep TOWRITE tag until folio is cleaned", " * CVE-2025-39810", " - bnxt_en: Fix memory corruption when FW resources change during ifdown", " * udpgro.sh from ubuntu_kselftests_net failed with J-5.15 (udpgso_bench_rx:", " recv: bad packet len) (LP: #2129861)", " - selftests: udpgro: no need to load xdp for gro", " * CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", " * CVE-2025-37861", " - scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue", " * CVE-2025-38643", " - wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()", " * CVE-2025-38615", " - fs/ntfs3: cancle set bad inode after removing name fails", " * CVE-2025-38361", " - drm/amd/display: Check dce_hwseq before dereferencing it", " * CVE-2025-38259", " - ASoC: codecs: wcd9335: Fix missing free of regulator supplies", " * CVE-2025-38239", " - scsi: megaraid_sas: Fix invalid node index", " * CVE-2025-38069", " - PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops", " * CVE-2022-50071", " - mptcp: move subflow cleanup in mptcp_destroy_common()", " * CVE-2025-37920", " - xsk: Fix race condition in AF_XDP generic RX path", " * CVE-2026-43456", " - bonding: fix type confusion in bond_setup_by_slave()", " - bonding: prevent potential infinite loop in bond_header_parse()", " * CVE-2022-49858", " - octeontx2-pf: Fix SQE threshold checking", " * CVE-2025-22057", " - net: decrease cached dst counters in dst_release", " * CVE-2025-22083", " - vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint", " * CVE-2024-58096", " - wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode", " * CVE-2025-21947", " - ksmbd: fix type confusion via race condition when using", " ipc_msg_send_request", " * CVE-2022-49562", " - KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits", " * CVE-2025-21812", " - ax25: rcu protect dev->ax25_ptr", " * CVE-2025-21801", " - net: ravb: Fix missing rtnl lock in suspend/resume path", " * CVE-2024-54683", " - netfilter: IDLETIMER: Fix for possible ABBA deadlock", " * CVE-2024-53220", " - f2fs: fix to account dirty data in __get_secs_required()", " * CVE-2025-21759", " - ipv6: mcast: extend RCU protection in igmp6_send()", " * CVE-2024-57999", " - powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW", " * CVE-2024-57982", " - xfrm: state: fix out-of-bounds read during lookup", " * CVE-2022-49651", " - srcu: Tighten cleanup_srcu_struct() GP checks", " * CVE-2022-49359", " - drm/panfrost: Job should reference MMU not file_priv", " * CVE-2022-49234", " - net: dsa: Avoid cross-chip syncing of VLAN filtering", " * CVE-2024-57945", " - riscv: mm: Fix the out of bound issue of vmemmap address", " * CVE-2024-53210", " - s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()", " * CVE-2024-53187", " - io_uring: check for overflows in io_pin_pages", "" ], "package": "linux-kvm", "version": "5.15.0-1110.115", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2168199, 2168214, 2107442, 2129861 ], "author": "Alessio Faina ", "date": "Mon, 28 Sep 2026 14:57:31 +0200" } ], "notes": "linux-kvm-headers-5.15.0-1111 version '5.15.0-1111.116' (source package linux-kvm version '5.15.0-1111.116') was added. linux-kvm-headers-5.15.0-1111 version '5.15.0-1111.116' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1109-kvm. As such we can use the source package version of the removed package, '5.15.0-1109.114', 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-1111-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1109.114", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1111.116", "version": "5.15.0-1111.116" }, "cves": [ { "cve": "CVE-2025-68190", "url": "https://ubuntu.com/security/CVE-2025-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked() kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-46242", "url": "https://ubuntu.com/security/CVE-2026-46242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s \"*pprev = next\" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays.", "cve_priority": "high", "cve_public_date": "2026-05-30 13:16:00 UTC" }, { "cve": "CVE-2025-38349", "url": "https://ubuntu.com/security/CVE-2025-38349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: don't decrement ep refcount while still holding the ep mutex Jann Horn points out that epoll is decrementing the ep refcount and then doing a mutex_unlock(&ep->mtx); afterwards. That's very wrong, because it can lead to a use-after-free. That pattern is actually fine for the very last reference, because the code in question will delay the actual call to \"ep_free(ep)\" until after it has unlocked the mutex. But it's wrong for the much subtler \"next to last\" case when somebody *else* may also be dropping their reference and free the ep while we're still using the mutex. Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion. A mutex \"unlock\" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up. See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics: \t\"mutex_unlock() may access the mutex structure even after it has \t internally released the lock already - so it's not safe for \t another context to acquire the mutex and assume that the \t mutex_unlock() context is not using the structure anymore\" So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops _their_ reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it. Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole _point_ of refcounts: unlike mutexes, they are inherently about object lifetimes).", "cve_priority": "high", "cve_public_date": "2025-07-18 08:15:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-80726", "url": "https://ubuntu.com/security/CVE-2026-80726", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-46113", "url": "https://ubuntu.com/security/CVE-2026-46113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, \"KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE\", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the \"correct\" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the \"wrong\" shadow page. However, that was only an imprecision until 2032a93d66fa (\"KVM: MMU: Don't allocate gfns page for direct mmu pages\") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-52988", "url": "https://ubuntu.com/security/CVE-2026-52988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase Publish new hooks in the list into the basechain/flowtable using splice_list_rcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on.", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2023-53231", "url": "https://ubuntu.com/security/CVE-2023-53231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: Fix detection of atomic context Current check for atomic context is not sufficient as z_erofs_decompressqueue_endio can be called under rcu lock from blk_mq_flush_plug_list(). See the stacktrace [1] In such case we should hand off the decompression work for async processing rather than trying to do sync decompression in current context. Patch fixes the detection by checking for rcu_read_lock_any_held() and while at it use more appropriate !in_task() check than in_atomic(). Background: Historically erofs would always schedule a kworker for decompression which would incur the scheduling cost regardless of the context. But z_erofs_decompressqueue_endio() may not always be in atomic context and we could actually benefit from doing the decompression in z_erofs_decompressqueue_endio() if we are in thread context, for example when running with dm-verity. This optimization was later added in patch [2] which has shown improvement in performance benchmarks. ============================================== [1] Problem stacktrace [name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291 [name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi [name:core&]preempt_count: 0, expected: 0 [name:core&]RCU nest depth: 1, expected: 0 CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1 Hardware name: MT6897 (DT) Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4 [2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/", "cve_priority": "medium", "cve_public_date": "2025-09-15 15:15:00 UTC" }, { "cve": "CVE-2023-53707", "url": "https://ubuntu.com/security/CVE-2023-53707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1 The type of size is unsigned int, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later.", "cve_priority": "medium", "cve_public_date": "2025-10-22 14:15:00 UTC" }, { "cve": "CVE-2024-49568", "url": "https://ubuntu.com/security/CVE-2024-49568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg When receiving proposal msg in server, the fields v2_ext_offset/ eid_cnt/ism_gid_cnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2_ext_offset, once exceed the max value, there has the chance to access wrong address, and crash may happen. This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt before using them.", "cve_priority": "high", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2026-89560", "url": "https://ubuntu.com/security/CVE-2026-89560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation Whiteout objects are used in the upper layer of an OverlayFS to indicate that the file with this name does not exist in the unified view, even if it is present in one of the lower layer file systems. For the userspace implementations of OverlayFS (fuse-overlayfs), whiteout objects can be created from userspace as well: * mknod(2) with S_IFCHR and makedev(0, 0) * renameat2(2) with RENAME_WHITEOUT, creating the whiteout in the old place of the moved file. This commit guards whiteout creation in both of these cases with LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered character devices and are not bound to a driver. LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a whiteout object: creating one is the only S_IFCHR creation that the VFS exempts from CAP_MKNOD, so it is as unprivileged as creating a regular file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that expose a kernel interface [1]. For the mknod(2) case, introduce a Landlock erratum. The creation of whiteout objects through mknod(2) was previously guarded using LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using LANDLOCK_ACCESS_FS_MAKE_REG. For the renameat2(2) case, fix a bug: Before this commit, renameat2(2) with RENAME_WHITEOUT would create a directory entry even when all LANDLOCK_ACCESS_FS_MAKE_* rights were denied. This does not affect normal renames within layered OverlayFS mounts: When doing a regular rename() on a mounted fuse-overlayfs, it is the fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT, and only the Landlock domain of that daemon is checked there. Depends-on: 49c9e09d9610 (\"landlock: Fix handling of disconnected directories\") Depends-on: fe72ce6710cb (\"landlock: Add errata documentation section\") [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and add link(2) to the user doc]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2024-41062", "url": "https://ubuntu.com/security/CVE-2024-41062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bluetooth/l2cap: sync sock recv cb and release The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work \t l2cap_sock_release hci_acldata_packet \t l2cap_sock_kill l2cap_recv_frame \t sk_free l2cap_conless_channel \t l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.", "cve_priority": "high", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2022-50406", "url": "https://ubuntu.com/security/CVE-2022-50406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: iomap: fix memory corruption when recording errors during writeback Every now and then I see this crash on arm64: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dm_thin_pool dm_persistent_data XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296). dm_bio_prison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0 dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECT potentially unexpected fatal signal 6. nf_reject_ipv6 potentially unexpected fatal signal 6. ipt_REJECT nf_reject_ipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) ip_tables pc : 000003fd6d7df200 x_tables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wb_workfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseq_set+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : __filemap_set_wb_err+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseq_set+0x1c/0x100 __filemap_set_wb_err+0x24/0xe0 iomap_do_writepage+0x5e4/0xd5c write_cache_pages+0x208/0x674 iomap_writepages+0x34/0x60 xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: ---truncated---", "cve_priority": "low", "cve_public_date": "2025-09-18 16:15:00 UTC" }, { "cve": "CVE-2026-97523", "url": "https://ubuntu.com/security/CVE-2026-97523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close race between scheduler and state change The mptcp scheduler may race with subflow sockets state change: data transmission on the selected socket may fail and a later release could try to use mss_now reset to 0 for a divide operation. Address the issue by explicitly checking for the critical scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97524", "url": "https://ubuntu.com/security/CVE-2026-97524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid unneeded actions on subflow reset Once in a blue moon, the mptcp receive path can recursively call mptcp_data_ready() via state change under unlucky error conditions, and then try to hold the data lock again. Break the recursion loop explicitly checking for the exceptional condition. Add a new flag instead of using an existing one like 'closing', to exit early in subflow_state_change(), and explicitly flush the RX queue at reset time. This avoids unneeded processing to check for available data -- calling get_mapping_status() and more on a dying subflow -- but also in error reporting and worker scheduling. Note that we must consume the currently peeked skb before invoking mptcp_dss_corruption to avoid consuming it again after the eventual reset has freed it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-80833", "url": "https://ubuntu.com/security/CVE-2026-80833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ss support which is one of the only remaining ones. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. Also, it had a buffer overread bug in the line 'memcpy(ctx->seed, d + dlen, ctx->slen);'. There's no point in fixing these bugs separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80834", "url": "https://ubuntu.com/security/CVE-2026-80834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ce support which is one of the only remaining ones. Note that the sun8i-ce support for hwrng remains in place. That is the interface that actually matters. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. There's no point in fixing this separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-74496", "url": "https://ubuntu.com/security/CVE-2026-74496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Fix use-after-free in fou_create() fou_create() publishes struct fou through sk_user_data before adding the new FOU port to the per-netns list. If fou_add_to_port_list() fails, the error path frees fou while it is still reachable through sk_user_data. A concurrent receive can then dereference the freed object in fou_from_sock(). This ordering issue was previously noted in the linked discussion. The failure is reachable when local port 0 is requested. Each socket binds to a different ephemeral port, but fou_cfg_cmp() compares the requested port 0 and reports -EALREADY once an entry already exists. Release the tunnel socket before freeing fou so sk_user_data is cleared first, and defer reclamation with kfree_rcu() to protect concurrent RCU readers. This matches the lifetime handling in fou_release().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-93286", "url": "https://ubuntu.com/security/CVE-2026-93286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: appletalk: fix NULL pointer dereference in aarp_send_ddp() aarp_send_ddp() calls atalk_find_dev_addr(dev) in the LocalTalk fast path without checking for NULL. When the device has no AppleTalk interface configured (dev->atalk_ptr == NULL), this leads to a NULL pointer dereference at the at->s_net access. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:aarp_send_ddp (net/appletalk/aarp.c:552 (discriminator 2)) Call Trace: atalk_sendmsg (net/appletalk/ddp.c:1715) __sys_sendto (net/socket.c:2265 (discriminator 1)) __x64_sys_sendto (net/socket.c:2272) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Add a NULL check consistent with the other callers of atalk_find_dev_addr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93287", "url": "https://ubuntu.com/security/CVE-2026-93287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: reject oversized block transfers in the common path The SMBus block transfer length data->block[0] is validated in i2c_smbus_xfer_emulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbus_xfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked. Add an early validation in __i2c_smbus_xfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback runs. data->block[0] is filled in by the device on SMBus block reads, so the check is scoped to operations where the length is actually supplied by the caller. This is consistent with the existing -EINVAL convention in the emulated path and protects all downstream consumers at once: the smbus_write tracepoint, all native smbus_xfer driver implementations, and the emulated path. Two distinct bugs are fixed by this change: Bug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h) trace_smbus_write() fires before any validation and copies data->block[0]+1 bytes into a 34-byte event buffer. With block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221. BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91 Call Trace: __asan_memcpy+0x23/0x80 trace_event_raw_event_smbus_write+0x27c/0x530 __i2c_smbus_xfer+0x43a/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c) stub_xfer() implements .smbus_xfer directly and only clamps block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With block[0]=0xff and command=0 the loop accesses block[1+i] for i up to 254, far past the 34-byte union. UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44 index 34 is out of range for type '__u8 [34]' Call Trace: __ubsan_handle_out_of_bounds+0xd7/0x120 stub_xfer+0x1971/0x198f [i2c_stub] __i2c_smbus_xfer+0x306/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97931", "url": "https://ubuntu.com/security/CVE-2026-97931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: us122l: Prevent write upgrades for read mappings The hwdep mmap callback rejects read-buffer mappings that are initially writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ. A process that can open the hwdep node O_RDWR can later use mprotect() to make the mapping writable. The read allocation begins with struct usb_stream. Its read_size member is used by the fault handler to decide which pages belong to the read buffer. The read VMA intentionally remains expandable because pcm_usb_stream uses mremap() after reading that size. Changing read_size first can therefore map and access pages beyond the allocation. The same member is also consumed by usb_stream_free(), where changing it can make free_pages_exact() release pages outside the allocation. Clear VM_MAYWRITE for read-buffer mappings after rejecting an initially writable VMA. This keeps the separate output-buffer mapping writable while preventing later permission upgrades.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97568", "url": "https://ubuntu.com/security/CVE-2026-97568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: syncookies: remember the request backup flag Instead of using an uninitialised bit when copying the info in subflow_ulp_clone(). To fix this, no need to extend the join_entry structure: backup is coming from struct mptcp_subflow_request_sock, only one bit. Do the same here by using one bit for both.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97572", "url": "https://ubuntu.com/security/CVE-2026-97572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Propagate RX ring init failures in bnxt_init_nic() bnxt_init_rx_rings() returns an error when bnxt_alloc_one_rx_ring() fails, but bnxt_init_nic() discards that return value and calls bnxt_init_chip(), which enables TPA. If an allocation fails, this could leave rxr->rx_tpa[] partially zeroed and TPA would be enabled over an array with zeroed entries. This would lead to a zeroed DMA address being handed out if the agg_idx is translated to a SW index at a zeroed entry. Fix this by propagating the error out of bnxt_init_nic(). Both callers already check its return value and unwind with bnxt_free_skbs() and bnxt_free_mem(), which tolerate a partially initialized RX ring.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97573", "url": "https://ubuntu.com/security/CVE-2026-97573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset() bnxt_rx_ring_reset() frees the ring buffers and then reallocates them, ignoring the result. bnxt_alloc_one_rx_ring() can fail in bnxt_alloc_one_tpa_info_data(), which returns -ENOMEM on the first failed allocation and leaves the remaining rxr->rx_tpa[] entries zeroed. The error isn't propagated up, so the loop in bnxt_rx_ring_reset continues and at the end the code re-enables TPA with partially unallocated rx_tpa array. This means that when the agg_id from hardware is mapped to a SW index in rxr->rx_tpa[], an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by falling back to a global reset, which is what the existing code already does when other functions fail, but unlike the other failure cases this particular failure has to return because TPA can't be re-enabled since the allocation failed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97576", "url": "https://ubuntu.com/security/CVE-2026-97576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC tile counts The stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from column_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[] and use them as tile-loop bounds, but std_validate_compound() does not bound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling enabled whose tile counts exceed the uAPI array capacity, mirroring the existing compound-control range checks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97582", "url": "https://ubuntu.com/security/CVE-2026-97582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gpio-fan) Fix use-after-free in alarm work fan_alarm_irq_handler() queues fan_data->alarm_work, but nothing cancels it. fan_alarm_notify() dereferences fan_data and its hwmon device. On unbind, devres frees the interrupt, which only waits for the handler itself, and then releases the hwmon device and fan_data, so a pending fan_alarm_notify() can run after those frees. Replace INIT_WORK() with devm_work_autocancel(), registered before devm_request_irq(). The devres cleanup then frees the interrupt first, so no new work can be queued, and cancels the work while fan_data and the hwmon device are still alive. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97592", "url": "https://ubuntu.com/security/CVE-2026-97592", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done. Similar with the buffers which are part of the gcm_sg_walk structs from the variables gw_in and gw_out.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97596", "url": "https://ubuntu.com/security/CVE-2026-97596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reject invalid states in connection template sync records IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6 records.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97598", "url": "https://ubuntu.com/security/CVE-2026-97598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: bound automatic table ID allocation fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment (\"ip rule ... table 0\") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TABLE_MAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable. The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97601", "url": "https://ubuntu.com/security/CVE-2026-97601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97604", "url": "https://ubuntu.com/security/CVE-2026-97604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vfb: defer cleanup until the last reference FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114) Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489) unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97608", "url": "https://ubuntu.com/security/CVE-2026-97608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: unregister loggers before per-net teardown nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL lock nf_log_mutex find logger in loggers[][] net->nf.nf_loggers[pf] = logger unlock nf_log_mutex nf_log_unregister(logger) lock nf_log_mutex loggers[pf][type] = NULL unlock nf_log_mutex synchronize_rcu() module exit returns module core frees backend memory Later, a sysctl read or packet logging operation can dereference the stale per-net logger pointer. Fix this by unregistering the global logger backends before tearing down per-net state. Once the global registrations are gone, later writers can no longer rebind the logger. unregister_pernet_subsys() already waits for an RCU grace period after the pre-exit callback clears the per-net selection, while nf_log_unregister() continues to cover readers of the global logger table. Apply this ordering fix to both nf_log backends that combine per-net teardown with global logger registration.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97611", "url": "https://ubuntu.com/security/CVE-2026-97611", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix use-after-free of the flow table mask array tbl_mask_array_realloc() retires the old mask_array before it stops being reachable: \told = ovsl_dereference(tbl->mask_array); \tif (old) { \t\t... \t\tcall_rcu(&old->rcu, mask_array_rcu_cb); \t} \trcu_assign_pointer(tbl->mask_array, new); call_rcu() only waits for read-side critical sections already in flight. tbl->mask_array still points at old between the call_rcu() and the rcu_assign_pointer(), so a reader entering ovs_flow_tbl_lookup_stats() in that window picks up old in a fresh critical section that the pending grace period does not cover. tbl_mask_array_realloc() runs in process context under ovs_mutex, so the window is preemptible and can outlast the grace period. Then mask_array_rcu_cb() frees old before the swap runs: BUG: KASAN: slab-use-after-free in flow_lookup.constprop.0+0x2bf/0x2f0 Read of size 8 at addr ffff888020b3e018 by task poc/741 flow_lookup.constprop.0+0x2bf/0x2f0 ovs_flow_tbl_lookup_stats+0x4a3/0x5c0 ovs_dp_process_packet+0x19c/0x710 ovs_vport_receive+0x243/0x390 internal_dev_xmit+0x81/0x170 Freed by task 728: kfree+0x16a/0x4e0 rcu_core+0x853/0x1030 Publish the new array before retiring the old one. The kfree_rcu() that call_rcu() replaced ran after the swap.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97612", "url": "https://ubuntu.com/security/CVE-2026-97612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: clear inner_protocol when the last label is popped skb_mpls_push() records the pre-encapsulation network header once, gated on !skb->inner_protocol. skb_mpls_pop() never clears that record, so it outlives the encapsulation it describes. Open vSwitch can then re-push MPLS onto a packet whose inner_network_header still points at the older, deeper offset: push a label, pop every label, recirculate (ovs_flow_key_update() re-derives key->eth.type and resets network_header, but leaves inner_*), then push again. ovs_fragment() trusts the record: \tskb->network_header = skb->inner_network_header; so skb_network_offset() goes negative. The bound check is signed: \tif (skb_network_offset(skb) > MAX_L2_LEN) a negative offset passes it, and prepare_frag() widens the value: \tunsigned int hlen = skb_network_offset(skb); \tmemcpy(&data->l2_data, skb->data, hlen); which is a ~4GiB memcpy out of a 30-byte per-CPU buffer. Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8): BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 prepare_frag+0x3df/0x4e0 ovs_fragment+0x589/0x7e0 do_output+0x4ce/0x5e0 do_execute_actions+0x55d2/0x7b30 ovs_execute_actions+0xea/0x450 Same root-cause shape as commit 975b5b067f52 (\"ipv6: sr: restore network header before routing and forwarding\"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path. Clear inner_protocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/act_mpls.c is the only other skb_mpls_pop() caller and gets the same fix; sch_frag.c saves and restores inner_protocol around fragmentation in the same way OVS does.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97899", "url": "https://ubuntu.com/security/CVE-2026-97899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix memory leak in query_perf_config_list() When krealloc() fails, free the original oa_config_ids before returning to avoid a memory leak. (cherry picked from commit 9977e9d84f46d4f12ad35fbbc0ec4638554bce87)", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97904", "url": "https://ubuntu.com/security/CVE-2026-97904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: initialize policy rwsem before sysfs publication cpufreq_policy_alloc() initializes policy->rwsem after kobject_init_and_add() has created the policy sysfs directory and its default attributes. A sysfs access can therefore reach a policy callback before the semaphore has been initialized. Initialize policy->rwsem before publishing the policy kobject so sysfs callbacks always see an initialized semaphore.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97905", "url": "https://ubuntu.com/security/CVE-2026-97905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: zero-initialize policy cpumask before sysfs publication cpufreq_policy_alloc() allocates policy->cpus with alloc_cpumask_var(), i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate kmalloc_node() allocation, so its bitmap holds whatever the slab allocator left behind: cpufreq_online() cpufreq_policy_alloc() alloc_cpumask_var(&policy->cpus) /* bitmap is uninitialized */ kobject_init_and_add() /* policy%u/ appears in sysfs */ cpufreq_policy_online() cpumask_copy(policy->cpus, cpumask_of(cpu)) /* first valid value */ This leaves a window in which the sysfs attributes are already reachable while policy->cpus is still garbage. show()/store() gate on policy_is_inactive(), i.e. cpumask_empty(policy->cpus), so a non-zero bitmap makes them run the attribute callbacks on a policy that is not initialized yet. Fix this by using zalloc_cpumask_var() for policy->cpus.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97909", "url": "https://ubuntu.com/security/CVE-2026-97909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: initialize IRQ lock before requesting IRQ uni_reader_init() registers the shared IRQ before initializing reader->irq_lock. A pending interrupt can invoke the handler while the lock is still uninitialized. Initialize the lock before registering the IRQ so the interrupt path always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97910", "url": "https://ubuntu.com/security/CVE-2026-97910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sprd: validate compress buffer sizes against fixed allocations sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the fixed allocations. A fragment_size larger than the 32K IRAM data area makes the stage 0 copy_from_user() overflow past the IRAM allocation, and a buffer_size larger than the 2M DDR buffer makes the wrapping copy at the end of sprd_platform_compr_copy() write fully user controlled data past the buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP state reaches the copy callback directly. Reject parameters that do not fit into the fixed buffers in set_params(), and fix the advertised max fragment size: 128K never fitted into the 32K IRAM buffer. The caps values may have been carried over from the qdsp6 driver, which allocates its buffers according to the advertised maxima, unlike this driver. With 32K as max fragment size the advertised limits are self-consistent: 32K * 64 = 2M equals the DDR buffer size. Discovered by Atuin - Automated Vulnerability Discovery Engine.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97923", "url": "https://ubuntu.com/security/CVE-2026-97923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the var ref when its initialization fails create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 (\"tracing: Use hist trigger's var_ref array to destroy var_refs\") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it. The call was correct when it was written, before var refs were taken out of destroy_hist_field(). init_var_ref() cannot free it either. The caller owns the field, so init_var_ref() undoes only its own string allocations and leaves the field alone. Freeing it there would leave create_var_ref() passing freed memory to destroy_hist_field(), which reads its flags. Call __destroy_hist_field(), which frees the field without consulting the flag.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97926", "url": "https://ubuntu.com/security/CVE-2026-97926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: validate cylinder group metadata before caching it ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: \tucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); \tucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); \tucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); \tucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: - c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32 bit count outside the s_csp allocation. - c_frotor becomes a bitmap scan start, start = c_frotor >> 3, and then length = ((s_fpg + 7) >> 3) - start. A start beyond the block bitmap wraps the unsigned length to a huge value, so ubh_scanc() walks far past the cylinder group buffers. c_irotor drives the inode bitmap the same way. A crafted image can set any of these freely, turning an ordinary allocation into an out of bounds access. Reject a cylinder group whose recorded index does not match the group being read, or whose rotors fall outside the group, before the metadata is cached. Valid filesystems keep cg_cgx equal to the group number and the rotors within the group, so only malformed images are rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97927", "url": "https://ubuntu.com/security/CVE-2026-97927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: create the root dentry after loading cylinder metadata ufs_fill_super() installed sb->s_root before it loaded the cylinder group structures for a writable mount: \tsb->s_root = d_make_root(inode); \t... \tif (!sb_rdonly(sb)) \t\tif (!ufs_read_cylinder_structures(sb)) \t\t\tgoto failed; When ufs_read_cylinder_structures() failed, the error path freed the in-core superblock information and set sb->s_fs_info to NULL while sb->s_root stayed installed. get_tree_bdev() then reached deactivate_locked_super(), and because s_root was present, generic_shutdown_super() called sync_filesystem() and the put_super operation. Both dereference UFS_SB(sb), which is now NULL, so a mount that fails only while reading the cylinder groups oopses during teardown. A crafted image whose first cylinder group cannot be read reaches this path. Load the cylinder group metadata first and create the root dentry last, so the superblock is published to the VFS only once it is fully set up. ufs_setup_cstotal() and ufs_read_cylinder_structures() take only the super_block and do not use the root inode, so the reordering is safe.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97930", "url": "https://ubuntu.com/security/CVE-2026-97930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf The in04_last array in struct usx2ydev is declared as char[24], but in04_buf is allocated as sizeof(struct us428_ctls) which is 21 bytes. In i_usx2y_in04_int(), when ctl_snapshot_last == -2 (initialization path): memcpy(usx2y->in04_last, usx2y->in04_buf, sizeof(usx2y->in04_last)); This copies 24 bytes from a 21-byte slab allocation, reading 3 bytes past the end of the source object. Introduce a USX2Y_IN04_SIZE constant defined as sizeof(struct us428_ctls) and use it consistently for the in04_last array, the in04_buf allocation, the URB transfer length, and the comparison loop, replacing the bare 24 and 21 literals throughout.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97940", "url": "https://ubuntu.com/security/CVE-2026-97940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix fib6 walker UAF on seq stop ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a never-started iterator with a zeroed private object is not treated as linked. The same stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only widens the race.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97948", "url": "https://ubuntu.com/security/CVE-2026-97948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver The commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") refactored the EEH code such that the pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken. [<0>] 0xc00000011c78f870 [<0>] __switch_to+0xfc/0x1a0 [<0>] pci_lock_rescan_remove+0x30/0x44 [<0>] eeh_rmv_device+0x290/0x2e0 [<0>] eeh_pe_dev_traverse+0x80/0x130 [<0>] eeh_reset_device+0xcc/0x23c [<0>] eeh_handle_normal_event+0x830/0xa80 [<0>] eeh_event_handler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] start_kernel_thread+0x14/0x18 The issue is seen for cases where the errors are detected on the PHB directly AND|OR for devices where the driver error_detected() returns PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no error handlers like slot_reset(), resume() etc defined).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-74743", "url": "https://ubuntu.com/security/CVE-2026-74743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: inherit needed_headroom and needed_tailroom from lowerdev macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-89792", "url": "https://ubuntu.com/security/CVE-2026-89792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds reads in share config responses Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-97951", "url": "https://ubuntu.com/security/CVE-2026-97951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands When a LUN_RESET aborts a WRITE command that is in the TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and waits for the frontend to finish processing. If the initiator subsequently sends the remaining dataout PDUs, __iscsit_check_dataout_hdr() catches the payload, stops the dataout timer if the sequence is final and finally dumps the data. However, the iSCSI target doesn't trigger the completion process for these aborted commands. Because of this, the abort path hangs indefinitely in target_put_cmd_and_wait(), leading to a deadlocked target worker thread. Fix this by explicitly calling target_complete_cmd() when the final dataout PDU is received for an aborted WRITE command. target_complete_cmd() detects the CMD_T_ABORTED flag and cleanly routes the command into target_abort_work, allowing the abort completion to successfully unblock.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-97952", "url": "https://ubuntu.com/security/CVE-2026-97952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunvdc: unmap LDC cookies when the descriptor send fails __send_request() maps the request's pages into the LDC channel's map table (ldc_map_sg()), fills in the descriptor and marks it VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger(). When the trigger fails, the error path only prints a message: the descriptor stays READY and the cookies are never unmapped. The mapping is normally released in vdc_end_one() when the peer completes the descriptor - but a descriptor whose doorbell was never sent will never complete, and since dr->prod is not advanced on failure, the reset path (vdc_requeue_inflight(), which walks [cons, prod)) never visits it either. The map table entries are leaked permanently. Since commit a11f6ca9aef9 (\"sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN\") trigger failures occur in practice under load, so every resulting I/O error also leaks one request's worth of entries from the fixed-size (8192 entries per channel) map table. Because the allocator hands out contiguous ranges, fragmentation makes large multi-segment requests fail first as the table drains, until ldc_map_sg() fails permanently and the disk is dead until reboot. It also makes any retry-based recovery unusable: requeuing the request on -EAGAIN remaps the pages on every attempt, overwriting desc->cookies and orphaning the previous mapping, so the table drains at the retry rate. This is the memory exhaustion observed when the requeue approach was first tested in October 2025. Roll back on failure: unmap the cookies, mark the descriptor FREE again and clear the request entry. If the trigger failed with -ENOTCONN, __vdc_tx_trigger() has already reset the port, which tears down and reallocates both the dring and the LDC channel including its map table - nothing to roll back, and the stale descriptor must not be touched.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97954", "url": "https://ubuntu.com/security/CVE-2026-97954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix tcp stream corruption with large pages rds_message_map_pages() assigns PAGE_SIZE bytes to every scatterlist entry, even when total_len ends in a partial page. The RDS congestion map is defined as 8192 bytes, so on systems with PAGE_SIZE greater than 8192 the scatterlist maps bytes beyond the end of the congestion map. RDS-TCP transmits the SG contents according to those lengths, so the extra bytes become part of the TCP RDS stream and are interpreted as subsequent RDS message headers, corrupting the stream. Limit the final scatterlist mapping to the number of bytes remaining. This has no effect on systems with a 4K page size and allows RDS-TCP to be used on systems with 16K and larger page sizes. The RDS selftest, which previously hung on 16K pages, now passes.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97957", "url": "https://ubuntu.com/security/CVE-2026-97957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix mailbox segment buffer overflow check_mbox_seq_id_and_seg_len() validates that seq_id does not exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed MBOX_SEG_LEN (48). However, this allows the last segment (seq_id=42) to carry a full 48-byte payload, writing to offset 42*48=2016 for 48 bytes (ending at byte 2064). The receive buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a 16-byte heap buffer overflow. The hinic3 driver already handles this correctly by defining MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it exceeds the remaining buffer space. Apply the same fix to the hinic driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97958", "url": "https://ubuntu.com/security/CVE-2026-97958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain(). If a netlink socket sends RTM_GETCHAIN requests repeatedly without recv()ing the responses, tc_ctl_chain() hogs CPU and triggers Hung Task splat. [0] As caught in the stack trace, netlink_attachskb() could confuse tc_ctl_chain() by returning -EAGAIN when the userspace netlink socket's receive buffer is full. The replay: label exists since commit 32a4f5ecd738 (\"net: sched: introduce chain object to uapi\") but was not used initially. Since commit 9f407f1768d3 (\"net: sched: introduce chain templates\"), the label is needed for RTM_NEWCHAIN because tcf_proto_lookup_ops() may release RTNL to call request_module(). However, the replay logic is unnecessary for RTM_GETCHAIN. Let's apply the replay logic only for RTM_NEWCHAIN. [0]: INFO: task repro:1018 is blocked on a mutex likely owned by task repro:1022. task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 task_flags:0x400040 flags:0x00080000 Call Trace: ? clockevents_program_event (kernel/time/clockevents.c:372) ? pskb_expand_head (net/core/skbuff.c:615) ? skb_release_data (net/core/skbuff.c:1122) ? netlink_attachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/af_netlink.c:1232) ? __netlink_lookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/af_netlink.c:499) ? tc_chain_notify (net/sched/cls_api.c:3045) ? tc_chain_notify (./include/linux/skbuff.h:1384 net/sched/cls_api.c:3041) ? netlink_unicast (net/netlink/af_netlink.c:1335) ? rtnl_unicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985) ? tc_ctl_chain (net/sched/cls_api.c:3242) ? rtnetlink_rcv_msg (net/core/rtnetlink.c:7146) ? netlink_unicast (net/netlink/af_netlink.c:1354) ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:7177) ? netlink_rcv_skb (net/netlink/af_netlink.c:2556) ? netlink_unicast (net/netlink/af_netlink.c:1319) ? netlink_sendmsg (net/netlink/af_netlink.c:1900) ? __sock_sendmsg (net/socket.c:800) ? __sys_sendto (net/socket.c:2281) ? __x64_sys_sendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284) ? do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97959", "url": "https://ubuntu.com/security/CVE-2026-97959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_route: free emptied bucket on filter move route4_change can move an existing filter to a different top-level bucket: route4_set_parms recomputes the handle from TCA_ROUTE4_TO/ FROM/IIF, and the handle-mismatch check is gated on the 'new' flag, so for an existing filter the new handle may differ from the old one and land in a different bucket. When this happens, the filter is unlinked from the old bucket, but the bucket itself is never freed once it goes empty. The stale empty bucket remains in head->table[], causing route4_delete to report *last=false even after the last live filter is gone. That pins the empty tcf_proto and causes a leak. Fix this by refcounting the filters linked to a bucket and freeing the bucket when the count drops to zero. The existing scan in route4_delete goes away with it. The count is updated at all sites that link or unlink a filter during add, change and delete, and the bucket is dropped from head->table[] as soon as it reaches zero. Conditions to recreate the bug: CONFIG_NET_CLS_ROUTE4=y, CONFIG_NET_SCH_INGRESS=y, CONFIG_NET_CLS_ACT=y. tc qdisc replace dev lo clsact tc filter add dev lo ingress protocol ip pref 100 route from 1 to 1 tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \\ route from 1 to 2 tc filter del dev lo ingress protocol ip pref 100 handle 0x10002 \\ route from 1 to 2 tc filter show dev lo ingress | grep -c 'pref 100 route chain 0 '", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97963", "url": "https://ubuntu.com/security/CVE-2026-97963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: initialize ptp_lock at probe time priv->ptp_lock is only initialized in stmmac_ptp_register(), which runs during __stmmac_open(). However, the lock is also used while the interface is down and has never been opened: tc_taprio_configure() invokes the PTP gettime64() callback to compute the EST base time when offloading a TAPRIO schedule, and stmmac_get_time() takes priv->ptp_lock. Using an uninitialized rwlock is undefined behaviour. Move the rwlock_init() to __stmmac_dvr_probe(), together with the other private locks, so that ptp_lock is always valid regardless of the interface state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97964", "url": "https://ubuntu.com/security/CVE-2026-97964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_synctty: ensure a writeable skb header ppp_sync_txmunge() checks headroom before prepending the address and control bytes, but does not ensure that the skb header is writable. A received skb can reach this function through PPP channel bridging without passing through ppp_start_xmit(), which calls skb_cow_head(). For example, a PPPoE frame may share its buffer with a clone queued to an AF_PACKET socket. If it is bridged to a synchronous tty channel, the address/control bytes can overwrite data still visible to that socket. Use skb_cow_head() to ensure both sufficient headroom and a writable header.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97969", "url": "https://ubuntu.com/security/CVE-2026-97969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix clock leak and spurious timer in settimeout() msc313e_wdt_settimeout() unconditionally calls msc313e_wdt_start() which introduces two severe bugs: 1. If the watchdog is already active, calling start() again will increase the reference count of the clock again. However stop() is only called once, the reference count is unbalance. 2. If the watchdog is stopped, calling settimeout() will start the hardware timer accidentally. Factor out the register-writing logic into a helper function. Only call it in settimeout() if the watchdog is running. Otherwise, simply update `wdev->timeout`.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97970", "url": "https://ubuntu.com/security/CVE-2026-97970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Avoid division by zero clk_get_rate() could return 0. Avoid a division by zero panic.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97981", "url": "https://ubuntu.com/security/CVE-2026-97981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Count dropped frames as NAPI work The RX loop only consumes budget when it successfully delivers a frame. Error paths keep consuming descriptors without reducing the budget, so a stream of bad frames can process the entire receive ring in one poll. Move the budget accounting to a common end-of-frame path. This counts each completed frame as NAPI work whether it was delivered or dropped, matching the behavior of the vendor driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97982", "url": "https://ubuntu.com/security/CVE-2026-97982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Fix budget accounting The gmac_rx() function returns the remaining NAPI budget, but its caller treats the return value as the number of packets received. An idle poll therefore reports a full budget and remains scheduled. Return the number of received packets instead. Preserve the existing free queue refill accounting by adding that count directly; continuing to subtract it from the budget would invert the refill behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97991", "url": "https://ubuntu.com/security/CVE-2026-97991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim_blk: reject out-of-range sector starts vdpasim_blk_check_range() logs an invalid start sector but continues validating the request. The subsequent unsigned capacity subtraction can underflow and let an out-of-range buffer offset reach the data path. The invalid offset is used by three request paths. VIRTIO_BLK_T_OUT copies guest data to blk->buffer + offset through vringh_iov_pull_iotlb(), causing an out-of-bounds write in _copy_from_iter() or memcpy(). VIRTIO_BLK_T_IN copies from blk->buffer + offset to the guest through vringh_iov_push_iotlb(), causing an out-of-bounds read in _copy_to_iter(). VIRTIO_BLK_T_WRITE_ZEROES passes blk->buffer + offset to memset(), causing an out-of-bounds write. Reject starts at or beyond the capacity before the subtraction. Treat the capacity boundary as invalid because the IN and OUT paths round byte counts down to sectors for validation but later copy the original byte counts. A sub-sector request at the capacity boundary would otherwise still access past the end of the buffer. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97993", "url": "https://ubuntu.com/security/CVE-2026-97993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx vhost_vdpa_set_config_call() swaps the eventfd_ctx_fdget() return value into v->config_ctx before checking it, so on failure the field briefly holds an ERR_PTR: \tctx = fd == VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd); \tswap(ctx, v->config_ctx); \tif (!IS_ERR_OR_NULL(ctx)) \t\teventfd_ctx_put(ctx); \tif (IS_ERR(v->config_ctx)) { \t\tlong ret = PTR_ERR(v->config_ctx); \t\tv->config_ctx = NULL; \t\treturn ret; \t} Commit 0bde59c1723a (\"vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails\") added that clearing, and spelled out the invariant the rest of the file relies on: \"we consider 'v->config_ctx' valid if it is not NULL\". The window between the swap and the clearing still breaks it. vhost_vdpa_config_cb() only tests for NULL, so a config interrupt delivered inside the window hands the ERR_PTR to eventfd_signal(). Check the fd before installing it instead. That closes the window and matches how vhost_vring_ioctl() handles the same failure for the vq call fd. It also stops a rejected fd from tearing down a config interrupt that was working: until now the swap replaced the live context and put it, so after an EBADF the device silently stopped delivering config interrupts until userspace installed a new fd.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97995", "url": "https://ubuntu.com/security/CVE-2026-97995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_console: do not free control-out buffers on remove __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): \tfree_buf \tremove_vqs \tvirtcons_remove \tunbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97998", "url": "https://ubuntu.com/security/CVE-2026-97998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: cope with concurrent instance destruction Instances are refcounted. However, only memory release happens on the 1 -> 0 transition; the unlink from hashes can occur with any refcount. Uncooperative userspace can force a situation where a queue is pending for destruction from netlink event while a different socket with same portid processes an UNBIND request. With right timing, this will unhash the instance again: Oops: general protection fault, [..] Call Trace: nfulnl_recv_config+0x31a/0xd50 nfnetlink_rcv_msg+0x7c2/0xeb0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98006", "url": "https://ubuntu.com/security/CVE-2026-98006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev The epq_in_urb object belonging to the caiaq device is coupled within the struct snd_usb_caiaqdev. After usb_submit_urb(epq_in_urb, GFP_KERNEL) executes successfully, epq_in_urb is successfully added to the urbp_list queue of the dummy HCD driver (userspace specifies dummy_hcd as the HCD layer driver for the caiaq USB device). When init_card() calls snd_usb_caiaq_send_command() which subsequently fails due to a timeout, and proceeds to call snd_card_free() to release the card, the embedded ep1_in_urb object is also freed. When the dummy HCD driver detects that the URB has been unlinked, it returns the URB (by usb_hcd_giveback_urb()), which triggers [1]. Decouple the ep1_in_urb object from the struct snd_usb_caiaqdev and switch to using a pointer instead. Separately allocate and manage the memory for ep1_in_urb to prevent the release of the snd_card memory object from interfering with it. midi_out_urb has the same issue as ep1_in_urb and is handled in the same way. [1] BUG: KASAN: slab-use-after-free in usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 Write of size 4 at addr ffff88803cee1050 by task ktimers/1/29 Call Trace: usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 dummy_timer+0xaac/0x4d50 drivers/usb/gadget/udc/dummy_hcd.c:2019 __run_hrtimer kernel/time/hrtimer.c:2067 [inline] __hrtimer_run_queues+0x3eb/0xaf0 kernel/time/hrtimer.c:2124 hrtimer_run_softirq+0x1e1/0x2e0 kernel/time/hrtimer.c:2141 Allocated by task 36: snd_card_new+0x7b/0x110 sound/core/init.c:184 create_card sound/usb/caiaq/device.c:429 [inline] snd_probe+0x236/0x1af0 sound/usb/caiaq/device.c:544 Freed by task 36: snd_card_free_when_closed sound/core/init.c:630 [inline] snd_card_free+0x138/0x1d0 sound/core/init.c:662 snd_probe+0x162b/0x1af0 sound/usb/caiaq/device.c:553", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98009", "url": "https://ubuntu.com/security/CVE-2026-98009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: clamp quantum in parse and fallback paths ets_qdisc_change() falls back to psched_mtu() with no floor for bands without an explicit quantum. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so a zero psched_mtu on a headerless device makes the deficit-refill loop spin under the qdisc lock. Move the floor into ets_quantum_parse() so explicitly configured quanta are also clamped to [256, 1<<20], not just the fallback path. Conditions to recreate the bug: CONFIG_NET_SCH_ETS=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root ets bands 3 strict 2 quanta 1 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98010", "url": "https://ubuntu.com/security/CVE-2026-98010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: drr: clamp quantum in change class drr_change_class() rejects explicit quantum==0 but falls back to psched_mtu() with no floor. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 (or a zero psched_mtu on a headerless device) makes the deficit-refill loop spin under the qdisc lock. Add clamp_t(u32, quantum, 256, 1<<20) after the zero reject and on the fallback path. The explicit-zero reject is preserved. Conditions to recreate the bug: CONFIG_NET_SCH_DRR=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root drr tc class add dev dummy0 parent 1: classid 1:1 drr quantum 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98011", "url": "https://ubuntu.com/security/CVE-2026-98011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum in change and init paths hhf_change() accepts any quantum from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) in hhf_change() matching fq_codel_change(). Clamp hhf_init() to [256, 1<<20] matching the siblings, and remove the old fallback that only set quantum=256 on overflow. Conditions to recreate the bug: CONFIG_NET_SCH_HHF=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root hhf tc qdisc change dev dummy0 root hhf quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98012", "url": "https://ubuntu.com/security/CVE-2026-98012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum in change path sfq_change() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and the init clamp. Conditions to recreate the bug: CONFIG_NET_SCH_SFQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root sfq tc qdisc change dev dummy0 root sfq quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98013", "url": "https://ubuntu.com/security/CVE-2026-98013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp quantum in change path fq_pie_change() accepts any quantum value from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Conditions to recreate the bug: CONFIG_NET_SCH_FQ_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq_pie tc qdisc change dev dummy0 root fq_pie quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98014", "url": "https://ubuntu.com/security/CVE-2026-98014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch, prevent mc_list repopulation during vport disable In mlx5_esw_vport_disable(), move esw_apply_vport_rx_mode() ahead of esw_vport_change_handle_locked() so vport->allmulti_rule is NULL before the change handler observes it. During FW-fatal recovery the disable runs while dev->state == INTERNAL_ERROR. The promisc query inside esw_update_vport_rx_mode() fails and returns early, leaving vport->allmulti_rule intact, so esw_update_vport_mc_promisc() runs and adds MLX5_ACTION_ADD entries to vport->mc_list whose flow rules are then installed in the FDB by esw_add_mc_addr(). esw_destroy_legacy_table() tears down the FDB with those refs still held, corrupting the sub-tree and leaving dangling flow_rule pointers in vport->mc_list. Two-stage failure on `echo 1 > /sys/bus/pci/devices//reset`: refcount_t: underflow; use-after-free. tree_put_node+0xef/0x110 [mlx5_core] clean_tree+0x44/0xd0 [mlx5_core] (x5) mlx5_fs_core_cleanup+0x57/0x1c0 [mlx5_core] mlx5_unload+0x65/0xd0 [mlx5_core] ... mlx5_health_try_recover BUG: unable to handle page fault for address: 0000000003000055 down_write+0x1c/0x60 mlx5_del_flow_rules+0x33/0x1f0 [mlx5_core] esw_del_mc_addr+0x7b/0x170 [mlx5_core] esw_apply_vport_addr_list+0x56/0xf0 [mlx5_core] esw_vport_change_handle_locked+0x28b/0x310 [mlx5_core] mlx5_esw_vport_enable+0x270/0x4a0 [mlx5_core] ... mlx5_load ... mlx5_health_try_recover esw_apply_vport_rx_mode(false, false) clears vport->allmulti_rule via its local state machine even when the FW del fails. With the rule NULL the !IS_ERR_OR_NULL(allmulti_rule) gate in the change handler closes, no rules are installed during disable, and the reload starts with a clean mc_list.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98015", "url": "https://ubuntu.com/security/CVE-2026-98015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put In mlx5_eswitch_termtbl_put(), the zero-ref cleanup check reads tt->ref_count after termtbl_mutex has been released. Two concurrent callers on the same mlx5_termtbl_handle race: one decrements ref_count to zero, removes the hash entry, and calls kfree(tt) while the other has already dropped the mutex and is about to evaluate if (!tt->ref_count), producing a use-after-free. Fix this by capturing the result of the decrement into a stack-local last variable before dropping the mutex. The cleanup decision is now made entirely under termtbl_mutex, and tt is not touched after kfree.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98016", "url": "https://ubuntu.com/security/CVE-2026-98016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free race in sample_restore_put() Concurrent teardown of TC sample rules sharing the same restore context may re-read restore->count after dropping restore_lock. At that point another thread may already have completed cleanup and freed the restore object. Use the result of the refcount decrement while holding restore_lock to determine whether cleanup is needed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98022", "url": "https://ubuntu.com/security/CVE-2026-98022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations Several subsystems allocate ring buffers sized by dev->tx_queue_len with no upper bound. An unprivileged user (via unshare -Urn) can set a huge tx_queue_len and exhaust global memory with ring allocations: - pfifo_fast: pfifo_fast_init() and pfifo_fast_change_tx_queue_len() allocate 3 skb_array rings of tx_queue_len entries each. - tun: tun_queue_resize() and the queue-attach path resize ptr_rings to tx_queue_len on the NETDEV_CHANGE_TX_QUEUE_LEN notifier. - tap (macvtap/ipvtap): tap_queue_resize() and tap_init() resize/init ptr_rings to tx_queue_len on the same notifier. netif_change_tx_queue_len() is the single entry point for IFLA_TXQLEN, sysfs, and the SIOCSIFTXQLEN ioctl. Cap new_len at S16_MAX (32767) there so the oversized value is rejected at set time. This takes effect whether the device is up or down, before dev->tx_queue_len is written, before any notifier fires, and before any ring is allocated. The \"> S16_MAX\" check also subsumes the previous unsigned-long truncation test, and a negative ifr_qlen from the ioctl lands far above the cap after conversion, so both old failure modes are covered by the one comparison. tx_queue_len is ambigious: both a per-ring sizing multiplier and a default queue-length/limit knob for consumers that allocate nothing at set time (pfifo/bfifo/gred/plug/sfb limits, htb direct_qlen, qfq max_classes, teql). 32767 is chosen as the largest value NLA_POLICY_FULL_RANGE can express for the u32 IFLA_TXQLEN policy in patch 2/3 while staying a legitimate queue length on high-BDP paths; the ring-memory trade-off of a shared knob is disclosed below. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn). - pfifo_fast: create veth pairs, set tx_queue_len to 500000, attach mq+pfifo_fast. ~28 iterations OOMs a 2GB guest. - tun: create 50 tun devices with IFF_MULTI_QUEUE, set tx_queue_len to 500000, open 8 queues each. ~1.6GB of ptr_ring allocations OOMs a 512MB guest. - tap: same as tun with IFF_TAP. ~960MB OOMs a 512MB guest. - On the fixed kernel the oversized tx_queue_len is rejected with -ERANGE at set time (all four paths: RTM_SETLINK, RTM_NEWLINK create, sysfs, ioctl - the latter two via this check, the former two via this check and the 2/3 parse policy respectively).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98023", "url": "https://ubuntu.com/security/CVE-2026-98023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: reject dynamic fdb entries that reference a nexthop id The commit cited in the Fixes tag allowed VXLAN FDB entries to point to FDB nexthops so that overlay traffic could be load balanced across multiple VTEPs. Such entries can only be configured from user space, cannot be learned and cannot roam. They only make sense with a user space control plane such as E-VPN where data plane learning is disabled. Despite that, the VXLAN driver does not currently prevent such entries from being configured with the \"dynamic\" flag. The per-nexthop FDB list is only protected by the per-device hash lock, which is not sufficient when two VXLAN devices point to the same FDB nexthop and therefore share the list. Aging runs in softirq context without RTNL, so an entry deleted by one device can race with an addition or deletion from the other, leading to list corruption: list_del corruption. next->prev should be ffff8881069d9548, but was dead000000000122. (next=ffff8881069d9448) WARNING: CPU: 0 PID: 90 at lib/list_debug.c:65 __list_del_entry_valid_or_report+0x1aa/0x210 ... vxlan_fdb_destroy+0x5b8/0xad0 vxlan_cleanup+0x328/0x450 call_timer_fn+0x2a/0x1c0 run_timer_softirq+0x18c/0x210 BUG: KASAN: slab-use-after-free in vxlan_fdb_destroy Fix this by rejecting the bogus configuration of dynamic FDB entries that point to FDB nexthops, both when created and when an existing entry is updated. As such, the per-nexthop FDB list is only ever mutated under the RTNL lock. Add test cases to make sure that this does not regress in the future.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98025", "url": "https://ubuntu.com/security/CVE-2026-98025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is \t} else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB \"frame\" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98027", "url": "https://ubuntu.com/security/CVE-2026-98027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer size mv88e6xxx_get_rxnfc() uses rxnfc->rule_cnt as the write index while dumping the policy IDR, clobbering the input value before it has been looked at. That input is the number of entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed policy rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Count into a local so the caller's limit survives the walk, and stop with -EMSGSIZE once it is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98030", "url": "https://ubuntu.com/security/CVE-2026-98030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size bcm_sf2_cfp_rule_get_all() walks the whole cfp.unique bitmap into rule_locs[] without consulting nfc->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed CFP rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98031", "url": "https://ubuntu.com/security/CVE-2026-98031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: Initialize extack in remove_nh_grp_entry() remove_nh_grp_entry() prints the extack message when a listener fails to replace the reduced nexthop group. However, extack is not initialized and listeners are not required to set a message when returning an error. Neither netdevsim nor mlxsw do so when an allocation fails, resulting in the dereference of an uninitialized stack pointer. Fix by zero-initializing extack, as was done in commit 6347c5314cee (\"nexthop: initialize extack in nh_res_bucket_migrate()\").", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98063", "url": "https://ubuntu.com/security/CVE-2026-98063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref in btf_var_show() btf_var_show() calls btf_type_id_resolve() unconditionally, which dereferences btf->resolved_ids. That is NULL for a base BTF - e.g. the vmlinux BTF that bpf_snprintf_btf() renders against - since base BTF is not resolved during parsing. btf_modifier_show() guards this with 'if (btf->resolved_ids)', but btf_var_show() does not. A BPF program that passes the type_id of a BTF_KIND_VAR from the vmlinux BTF to bpf_snprintf_btf() thus NULL-derefs: KASAN: probably user-memory-access in range [0x46638-0x4663f] RIP: 0010:btf_var_show (kernel/bpf/btf.c:2929) Call Trace: btf_type_show (kernel/bpf/btf.c:8259) btf_type_snprintf_show (kernel/bpf/btf.c:8329) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Resolve the var's type directly with btf_type_skip_modifiers() when resolved_ids is NULL, mirroring btf_modifier_show().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98064", "url": "https://ubuntu.com/security/CVE-2026-98064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref when showing a void BTF type btf_modifier_show() resolves the modifier and then calls btf_type_ops(t)->show() unconditionally. For the void type (type_id 0, BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL. A \"const void\" (a modifier resolving to void) cannot be a map key or value - map_check_btf() rejects it because void has no size - so the map dump path does not reach it. But bpf_snprintf_btf() takes a type_id straight from the BPF program, and passing such a \"const void\" from the vmlinux BTF NULL-derefs: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:btf_modifier_show (kernel/bpf/btf.c:2914) Call Trace: btf_type_show (kernel/bpf/btf.c:8251) btf_type_snprintf_show (kernel/bpf/btf.c:8321) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fall back to btf_df_show() when the resolved type has no show op; it emits the \"\" placeholder already used for kinds like FWD and FUNC. bpf_snprintf_btf() then returns the length as usual.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98066", "url": "https://ubuntu.com/security/CVE-2026-98066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Fix potential double-free at error path The fix for caiaq driver's resource management to handle the errors tries to release the resources in a common destructor call, but as a sashiko review for another patch suggested, some of the audio resources such as URBs have been already freed, and this may lead to a double-free. For addressing the double-free, call the common destructor function from each place, and assure that the resource pointers get cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98068", "url": "https://ubuntu.com/security/CVE-2026-98068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: don't let rds_conn_shutdown() consume a concurrent drop rds_conn_shutdown() finishes by moving the path from RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts RDS_CONN_ERROR as the starting state of that final transition, so that a FIN processed in softirq context during the teardown does not derail the shutdown into a noisy error path. But consuming that RDS_CONN_ERROR also consumes the shutdown pass that came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN is a no-op. For the FIN case that is harmless - the socket the FIN arrived on is the very socket the teardown just released. It is not harmless for a dropper that attached something to the path first. rds_tcp_accept_one() is such a dropper. Its path claim in rds_tcp_accept_one_path() transitions RDS_CONN_DOWN -> RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous socket in softirq context, an administrative reset - can put the path into RDS_CONN_ERROR between that claim and the state check that follows, which accepts RDS_CONN_ERROR. The accept then installs the freshly accepted socket with rds_tcp_set_callbacks() while the queued teardown - which sampled tc->t_sock before this socket existed - is still running. rds_connect_path_complete() fails its transition to RDS_CONN_UP and drops the path again, queueing the pass that should reap the socket it just installed. If the in-flight shutdown's final transition consumes that drop's RDS_CONN_ERROR, the queued pass finds the path in RDS_CONN_DOWN and does nothing. The installed socket is never torn down: it sits established with its callbacks armed and its rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some later event drops it again. Reproduced with widened race windows as an ever-growing receive queue on a socket owned by a path stuck in RDS_CONN_DOWN, with the peer's send path wedged behind it. Make the final transition only DISCONNECTING -> DOWN. If it fails because the path is in RDS_CONN_ERROR, a drop raced the teardown: cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one piece of the skipped tail that must not be left behind - and return, letting the pass the drop queued finish the job: it tears down whatever attached to the path in the meantime, completes the transition to RDS_CONN_DOWN, and re-arms the reconnect from its own tail. The timer quiesce in that branch matters because the racing drop does not always queue that pass: rds_conn_path_drop() returns without queueing when a destroy is pending - exactly the situation during a netns teardown or module unload, when a FIN on the dying socket is processed while rds_conn_path_destroy() flushes cp_down_w. If the flushed pass is the one that takes this return, no later pass exists, and rds_conn_path_destroy() would find cp_conn_w still armed (WARN_ON) and then free a path whose reconnect timer can still fire. With the cancel in the branch, every exit of a shutdown pass leaves the timer quiesced no matter which pass completes the transition. The FIN case keeps making progress, one pass later and still without noisy logging. Any other state keeps today's rds_conn_path_error() handling; no current cp_state writer can leave a DISCONNECTING path in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from a non-DISCONNECTING state), so that branch is defensive. On kernels without the preceding patches the same hazard exists with the sample-based quiesce; the fix applies there equally.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98069", "url": "https://ubuntu.com/security/CVE-2026-98069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire the fastpath locks in rds_conn_shutdown() rds_conn_shutdown() quiesces the transmit and receive-refill paths by waiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and then runs the transport shutdown and rds_conn_path_reset(). Sampling the bits clear is not the same as owning them: the moment after the wait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or rds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run concurrently with the teardown. The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the transmit state under it. Oracle UEK fixed the same class of crashes - a 14-year tail of BUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL dereferences in rds_ib_send_cqe_handler() during failover testing - by making the teardown path *acquire* the fastpath bit locks instead of testing them (\"rds: Make sure transmit path and connection tear-down does not run concurrently\"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed. Do the same here: take both locks before calling the transport shutdown, hold them across rds_conn_path_reset(), and release them explicitly with a wake-up afterwards. Both are released with clear_bit_unlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rds_send_path_reset() are ordered before either bit is seen clear by the next acquire_in_xmit() or acquire_refill(). The fastpath users of these bits - rds_send_xmit() and rds_ib_recv_refill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rds_tcp_reset_callbacks() is different: since the previous patch it acquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rds_tcp_accept_one() on the single-threaded krdsd workqueue and holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown(). An IB path's drain in rds_ib_conn_path_shutdown() has no round cap, but no blocking waiter either: rds_tcp_reset_callbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDS_CONN_DISCONNECTING. Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on the path's ordered cp_wq, whose only execution slot is occupied by the blocked cp_down_w itself, so they are pending at most and cancel without flushing - a reliance on cp_wq being ordered that is now noted next to those cancels (on ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98070", "url": "https://ubuntu.com/security/CVE-2026-98070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks() rds_tcp_reset_callbacks() quiesces the transmit path by setting the path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to be sampled clear before swapping the underlying socket and calling rds_send_path_reset(). Sampling the bit clear is not the same as owning it: rds_send_xmit() can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its state recheck after taking the lock is a store-buffering pattern (the resetter writes the state and reads the bit, the sender writes the bit and reads the state) and acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write and the transmit path then runs concurrently with rds_send_path_reset() rewriting cp_xmit_* state - which is exactly what the comment above rds_send_path_reset() tells its callers to prevent. Take the lock instead, hold it across the socket swap and rds_send_path_reset(), and release it with a wake-up at the end. The lock-ordering constraint documented above the wait still holds: the lock is acquired before lock_sock(), so a sender inside tcp_sendmsg() can never be waited on while we hold the socket lock. Two details of the old code go away with the same change: - t_sock is now read only after the lock is acquired. The old code cached it before waiting; the teardown in rds_conn_shutdown() releases that socket and clears t_sock, so a pointer cached before the wait can be stale by the time the accept path resumes. Reading it under RDS_IN_XMIT is what makes the exclusion complete once the teardown owns the same lock, which the next patch arranges; until then the teardown still only samples the bit, and the two paths remain as exposed to each other as they are today. - The old !osock early path called rds_send_path_reset() with no serialization at all. It now runs under the lock like the normal path. The conditional RDS_CONN_RESETTING transition of the previous patch happens before the socket check either way: a path found without a socket is either still connecting (its reconnect worker blocked on t_conn_path_lock) and legitimately goes RESETTING -> UP on the new socket, or it has been torn down meanwhile and is dropped. The in-function comment describing the old wait-based quiesce is rewritten to describe the lock-based one, and the stale block comment above the function (which still described a return value and an incomplete list of t_sock writers) is refreshed to name all four writers - the connect, accept, teardown and swap paths - and what serializes each of them.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98071", "url": "https://ubuntu.com/security/CVE-2026-98071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: clear cp_flags bits individually in rds_conn_path_reset() rds_conn_path_reset() wipes the whole flag word with a plain cp->cp_flags = 0 store. Every other accessor of that word uses atomic bitops, and some of them can run concurrently with the reset: RDS_LL_SEND_FULL is set from rds_send_xmit() and cleared from the transport completion paths, neither of which holds anything that excludes the shutdown worker. A plain store racing an atomic read-modify-write on the same word is a data race, and whichever side loses has its update silently discarded. Clear the two bits the reset is actually responsible for instead. RDS_IN_XMIT and RDS_RECV_REFILL need no store at all here: they belong to the caller, rds_conn_shutdown(), which waits for both to be clear before calling the transport shutdown and this reset. This also gives every bit in cp_flags a single well-defined writer discipline, which the following patches rely on when they turn RDS_IN_XMIT and RDS_RECV_REFILL into bit locks held across the teardown: a blanket store mid-teardown would destroy lock ownership that an atomic clear preserves. Oracle UEK carries the same conversion (\"net/rds: Preserve essential connection state flags\"), motivated by its asynchronous shutdown state machine, whose progress and destroy flags must survive the reset. UEK's variant also clears RDS_IN_XMIT and RDS_RECV_REFILL because there the reset runs as the final step of a teardown that owns both bits, making those clears its unlock. Upstream that release belongs in rds_conn_shutdown(): once a later patch in this series turns the two bits into locks held across the teardown, ending ownership needs release semantics and a wake-up that a plain clear inside the reset would not provide. Based on Oracle UEK commit \"net/rds: Preserve essential connection state flags\" by Gerd Rausch.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98072", "url": "https://ubuntu.com/security/CVE-2026-98072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in release_in_xmit() release_in_xmit() clears RDS_IN_XMIT with clear_bit_unlock() and then checks waitqueue_active() to decide whether anyone needs waking. clear_bit_unlock() is only a release operation: it orders the critical section before the bit clear, but does not order the subsequent plain load of the wait queue head after it. The waiter side does the mirror image - it adds itself to the wait queue and then tests the bit. That is the classic store-buffering pattern: the releasing CPU can read the wait queue as empty while the waiting CPU still reads the bit as set, so the sleeper is never woken. The waiters are rds_conn_shutdown() and rds_tcp_reset_callbacks(), both in uninterruptible wait_event() with no timeout. A lost wake-up strands the shutdown worker on its single-threaded workqueue until some other sender releases the bit again - and on a connection that is being torn down precisely because it failed, there may never be another sender. The barrier used to be there: release_in_xmit() did clear_bit() followed by smp_mb__after_atomic() until commit 1422f28826d2 (\"rds: introduce acquire/release ordering in acquire/release_in_xmit()\") folded both into clear_bit_unlock(), which strengthened the lock hand-off but silently dropped the full barrier the wake-up check depends on. The refill counterpart, release_refill() in net/rds/ib_recv.c, still carries its smp_mb__after_atomic() for exactly this reason. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98074", "url": "https://ubuntu.com/security/CVE-2026-98074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: do not clear curr_active_slave prematurely when releasing all slaves When releasing all slaves during bond destruction (all == true), __bond_release_one() unconditionally clears bond->curr_active_slave to NULL in every iteration. If a backup slave is released before the active slave, bond_alb_deinit_slave() triggers rlb_teach_disabled_mac_on_primary(), which increments the active slave dev promiscuity counter and sets bond_info->primary_is_promisc = 1. Because bond->curr_active_slave was prematurely cleared to NULL when releasing the backup slave, the subsequent iteration releasing the active slave evaluates oldcurrent as NULL, so bond_change_active_slave(bond, NULL) is skipped. Consequently, bond_alb_handle_active_change() is never called to decrement the promiscuity counter, permanently leaking promiscuous mode on the physical device after bond teardown. When oldcurrent == slave, bond_change_active_slave(bond, NULL) already sets bond->curr_active_slave to NULL. We only need to avoid selecting a new active slave when all == true. Replace the if (all) branch with if (!all && oldcurrent == slave).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98075", "url": "https://ubuntu.com/security/CVE-2026-98075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject BPF_PSEUDO_FUNC reference to the main program fixups.c:jit_subprogs() rewrites BPF_PSEUDO_FUNC loads to contain real function addresses. This function is invoked from bpf_jit_subprogs() only when env->subprog_cnt > 1. Meaning that for any program like below: int main(void *ctx) { void *ptr = main; ... bpf_timer_set_callback(..., ptr); ... } The 'ptr' won't be ever converted to contain an address. In combination with e.g. bpf_timer_set_callback() this would lead to a function call at a bogus address. Instead of complicating the implementation, just assume that no useful program needs main to be a sync or async callback and reject BPF_PSEUDO_FUNC loads for the main subprogram.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98076", "url": "https://ubuntu.com/security/CVE-2026-98076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/probes: Fix use-after-free on field name/type of events with multiple probes The fields of a probe-based dynamic event (kprobe, uprobe, eprobe and fprobe events) are created in traceprobe_define_arg_fields() by handing the probe_arg name/type strings to trace_define_field(), which only stores the pointers without copying. Those strings are owned by the trace_probe and are freed when that probe is removed. An event can have several probes attached. The field list is defined only once, by the first probe that registers the event, but it is kept alive by any surviving sibling probe. Deleting just that first probe by symbol - # primary A: fields are defined from A's args echo 'p:kprobes/ev vfs_read a1=$arg1' > kprobe_events # append B: shares A's event call echo 'p:kprobes/ev vfs_write a1=$arg1' >> kprobe_events # delete only A (matched by symbol), B survives echo '-:kprobes/ev vfs_read' >> kprobe_events frees A's args (trace_probe_cleanup() -> traceprobe_free_probe_arg()), but trace_probe_unlink() keeps the trace_probe_event because the probe list is not empty. The event call stays registered via B while its fields now reference freed memory. Any field lookup then reads it, e.g. echo 'a1 == 1' > events/kprobes/ev/filter BUG: KASAN: slab-use-after-free in strcmp+0xa7/0xb0 Call Trace: strcmp trace_find_event_field parse_pred process_preds create_filter apply_event_filter event_filter_write field->name references parg->name (kstrdup'd, freed with the probe) and, for array arguments, field->type references parg->fmt (kmalloc'd, freed with the probe) - the scalar type otherwise points at the static fmttype rodata, which is safe. Have traceprobe_define_arg_fields() duplicate the name and type strings and anchor the copies on the trace_probe_event, which embeds the event call and outlives every individual probe; trace_probe_event_free() releases them. The reproducer above triggers reliably; the field lookup and the delete both run under event_mutex, so this is a dangling reference after removal rather than a race. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98077", "url": "https://ubuntu.com/security/CVE-2026-98077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace() sip_skip_whitespace() returns dptr unchanged when its own loop exhausts the buffer (dptr == limit), instead of NULL like its sibling sip_follow_continuation() returns on its own \"no more data\" path. ct_sip_get_header() only checks for NULL after calling it: dptr = sip_skip_whitespace(dptr, limit); if (dptr == NULL) break; if (*dptr != ':' || ++dptr >= limit) break; so a recognized header name followed only by spaces/tabs running to the exact end of the SIP payload, with no colon, makes the very next statement read one byte past the buffer. Make both \"no more data\" outcomes return NULL, matching the convention sip_follow_continuation() already uses and that both existing callers already check for.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98078", "url": "https://ubuntu.com/security/CVE-2026-98078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix reversed sequence option serialization hton_seq() expects the host-order source first and the unaligned network-order destination second. The version 1 sync sender passes these arguments in reverse for both sequence blocks. This leaves 24 bytes of the kmalloc-backed message unwritten. It may disclose stale heap data and replace the live connection sequence state with values read from the buffer. Pass the connection sequence state as the source and the message payload as the destination for both blocks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98080", "url": "https://ubuntu.com/security/CVE-2026-98080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not force reloc root creation during qgroup_account_snapshot() [BUG] When running btrfs/252 with quota enabled through MKFS_OPTIONS=\"-O quota\", it has a high chance to trigger the following kernel warning and flips the fs RO: BTRFS info (device dm-2): relocating block group 30408704 flags metadata|dup ------------[ cut here ]------------ WARNING: fs/btrfs/extent-tree.c:879 at lookup_inline_extent_backref+0x74b/0x960 [btrfs], CPU#4: btrfs/2173 CPU: 4 UID: 0 PID: 2173 Comm: btrfs Not tainted 7.2.0-rc6-custom+ #457 PREEMPT(full) 3adc6528fb66f7a55fe1095385818e742f200aab Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:lookup_inline_extent_backref+0x74b/0x960 [btrfs] Call Trace: insert_inline_extent_backref+0x7c/0x160 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_inc_extent_ref+0xa9/0x270 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_run_delayed_refs+0x4af/0x11c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_run_delayed_refs+0x9d/0xf0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshot+0x39d/0xf00 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshots+0x9b/0xc0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_commit_transaction+0x280/0xeb0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] prepare_to_relocate+0x147/0x200 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] relocate_block_group+0x6b/0x5e0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_block_group+0x92c/0x2380 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_balance+0xa2c/0x19c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_ioctl+0x2839/0x2d30 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS info (device dm-2): leaf 4593991680 gen 233 total ptrs 175 free space 5953 owner 2 BTRFS info (device dm-2): refs 3 lock_owner 2173 current 2173 \titem 0 key (166772736 METADATA_ITEM 1) itemoff 16250 itemsize 33 \t\textent refs 1 gen 222 flags 2 \t\tref#0: tree block backref root 266 [ Skip the tree dump ] \titem 174 key (263225344 METADATA_ITEM 0) itemoff 10328 itemsize 33 \t\textent refs 1 gen 162 flags 258 \t\tref#0: tree block backref root 267 BTRFS error (device dm-2): extent item not found for insert, bytenr 179847168 num_bytes 16384 parent 4594335744 root_objectid 273 owner 0 offset 0 BTRFS error (device dm-2): failed to run delayed ref for logical 179847168 num_bytes 16384 type 182 action 1 ref_mod 1: -117 [CAUSE] The above error is showing that there is a tree reference to a metadata extent that is no longer there. With \"ref_verify\" mount option (requires CONFIG_BTRFS_DEBUG), there is some extra debug output: BTRFS error (device dm-2): dumping block entry [180961280 16384], num_refs 0, metadata 1, from disk 0 BTRFS error (device dm-2): root entry 256, num_refs 18446744073709551615 BTRFS error (device dm-2): root entry 273, num_refs 18446744073709551615 BTRFS error (device dm-2): Ref action 3, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 1 btrfs_force_cow_block+0x129/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_insert_empty_items+0x3a/0x70 [btrfs] insert_with_overflow+0x53/0x130 [btrfs] btrfs_insert_dir_item+0x125/0x290 [btrfs] btrfs_add_link+0xaa/0x410 [btrfs] btrfs_rename+0x5ea/0xcd0 [btrfs] btrfs_rename2+0x28/0x60 [btrfs] vfs_rename+0x5b2/0xe10 filename_renameat2+0x244/0x430 __x64_sys_rename+0x48/0x70 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98088", "url": "https://ubuntu.com/security/CVE-2026-98088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() dev_to_node() can return NUMA_NO_NODE (-1) on systems without NUMA topology information for the PCI device, such as single-socket boards that don't expose device-to-node affinity. Passing -1 directly into cpumask_of_node() indexes node_to_cpumask_map[-1], an out-of-bounds array read caught by UBSAN: UBSAN: array-index-out-of-bounds in arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' Fall back to cpu_online_mask when no NUMA node is available, rather than assuming dev_to_node() always returns a valid node index.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98090", "url": "https://ubuntu.com/security/CVE-2026-98090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: restore active device pointers after failed sprout btrfs_init_new_device() switches latest_dev and possibly s_bdev from the seed device to the new sprout device before creating the first writable chunks. If chunk creation or the subsequent sprout setup fails, the error path releases the new device without switching those pointers back. btrfs_show_devname() can then dereference the freed latest_dev and crash. Restore the active device pointers to the latest seed device before removing and releasing the failed sprout device.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98091", "url": "https://ubuntu.com/security/CVE-2026-98091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: detach failed sprout device from transaction update list When creating the first metadata chunk for a sprout filesystem, create_chunk() adds the new device to the transaction dev_update_list through device->post_commit_list. If the subsequent system chunk creation fails, btrfs_init_new_device() aborts the transaction and releases the device while post_commit_list is still linked. This triggers a warning in btrfs_free_device() and leaves the transaction list referencing freed memory. Detach the device while holding chunk_mutex before releasing it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98094", "url": "https://ubuntu.com/security/CVE-2026-98094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: fbtft: make dirty_lock IRQ-safe fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled. Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again. The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled: WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2} CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); lock(console_owner); *** DEADLOCK *** Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98095", "url": "https://ubuntu.com/security/CVE-2026-98095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_packet: Don't cast tpacket_hdr.tp_len to int in tpacket_parse_header(). syzbot reported BUG() in sock_sendmsg_nosec(). [0] The problem is that tpacket_parse_header() casts user-provided tpacket_hdr.tp_len, which is u32, to int. If the length is larger than INT_MAX, the following condition in tpacket_parse_header() passes, if (unlikely(tp_len > size_max)) and any negative value can be returned to the caller, up to sock_sendmsg_nosec(). The repro set tpacket_hdr.tp_len to 0xfffffdef, which is cast to -EIOCBQUEUED (-529), triggering BUG() in sock_sendmsg_nosec(). *(uint64_t*)0x200000000008 = 0xfffffdef; ... syscall(__NR_write, /*fd=*/r[0], /*buf=*/0x200000000000ul, /*count=*/1ul); Let's define the local tp_len as u32 in tpacket_parse_header(). [0]: kernel BUG at net/socket.c:803! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 5628 Comm: syz-executor176 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 RIP: 0010:sock_sendmsg_nosec+0x145/0x180 net/socket.c:803 Code: 06 67 48 0f b9 3a eb 95 e8 e8 3a 22 f8 48 89 df 4c 89 f6 4c 89 e2 4d 89 fb 2e e8 32 a5 5c 16 e9 51 ff ff ff e8 cc 3a 22 f8 90 <0f> 0b e8 c4 3a 22 f8 48 83 c3 18 48 89 d8 48 c1 e8 03 42 80 3c 28 RSP: 0018:ffffc90003aefb48 EFLAGS: 00010293 RAX: ffffffff89a578d4 RBX: ffff8880764c67c0 RCX: ffff88807fb23e80 RDX: 0000000000000000 RSI: 00000000fffffdef RDI: 00000000fffffdef RBP: 00000000fffffdef R08: ffffc90003aef747 R09: 1ffff9200075dee8 R10: dffffc0000000000 R11: fffff5200075dee9 R12: 0000000000000001 R13: dffffc0000000000 R14: ffffc90003aefbc0 R15: ffffffff8aac4310 FS: 000055559101b400(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000210 CR3: 0000000073dca000 CR4: 00000000003526f0 Call Trace: __sock_sendmsg net/socket.c:815 [inline] sock_write_iter+0x2de/0x3e0 net/socket.c:1266 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x612/0xba0 fs/read_write.c:687 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f173130ecb9 Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 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 d8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd67e44248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f173130ecb9 RDX: 0000000000000001 RSI: 0000200000000000 RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd67e44388 R13: 0000000000000002 R14: 00002000000000c0 R15: 0000000000000002 ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98096", "url": "https://ubuntu.com/security/CVE-2026-98096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: restore network header before routing and forwarding ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative. This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows. Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98098", "url": "https://ubuntu.com/security/CVE-2026-98098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL deref in tipc_named_node_up() on empty publication list User-space applications can bind a large number of service addresses to one or more sockets. Each binding of a local-scope service address inserts one entry (publication) into the TIPC name table. If the number of these publications exceeds TIPC_MAX_PUBL (65535), protocol service types (such as node state and link state) are no longer inserted into the name table. This causes two issues: 1. User-space applications subscribing to node or link up/down events stop receiving notifications. 2. A NULL pointer dereference can occur: BUG: kernel NULL pointer dereference, address: 00000000000000d0 ... CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full) ... RIP: 0010:tipc_named_node_up (./include/linux/skbuff.h:2251 net/tipc/name_distr.c:195 net/tipc/name_distr.c:221) ... Call Trace: tipc_node_write_unlock (net/tipc/node.c:428) tipc_rcv (net/tipc/node.c:934 net/tipc/node.c:2189) tipc_udp_recv (net/tipc/udp_media.c:389) Thread 1 (tipc_net_finalize) | Thread 2 (named_distribute) -----------------------------|----------------------------- | ... | list_for_each_entry(publ, pls, binding_node) { | ... | __skb_queue_tail(list, skb); | ... | } | ... | hdr = buf_msg(skb_peek_tail(list)); ... | tipc_nametbl_publish(); | If 'tipc_nametbl_publish()' (Thread 1) fails because the number of local publications reaches TIPC_MAX_PUBL, list (Thread 2) will be empty. As a result, NULL is passed to 'buf_msg()', leading to a NULL pointer dereference. Fix these issues by allowing protocol service types (node state, link state, and topology server) to be inserted into the name table unconditionally. This ensures that users subscribing to these types always receive notifications. In addition, the maximum number of local user publications is reduced to (TIPC_MAX_PUBL - 1). This ensures that the maximum bulk size calculated in tipc_link_set_queue_limits() remains valid.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98108", "url": "https://ubuntu.com/security/CVE-2026-98108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan l2cap_new_connection() sets default value of channel mode to match the parent channel. l2cap_le_connect_req() left this at the default, and created L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that mode. This causes FLAG_DEFER_SETUP channels to reply to L2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect. It can also result to stack OOB write (of l2cap_alloc_cid determined values) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not limit maximum number of deferred channels or check for duplicate ident. Fix by setting chan->mode correctly in l2cap_le_connect_req(). Also check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE instead of OOB write to make it less brittle.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98113", "url": "https://ubuntu.com/security/CVE-2026-98113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: rate limit unmapped SID errors A client can include many structurally valid but unmapped SIDs in a DACL. Logging every mapping failure lets one request generate hundreds of kernel error messages. Rate limit the message to prevent an authenticated client from flooding the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98116", "url": "https://ubuntu.com/security/CVE-2026-98116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation with an mmap_count check performed under the PCM stream lock, but the lock is released long before the buffer is actually freed: snd_pcm_sync_stop(), constraint refinement and do_free_pages() all happen in between. snd_pcm_mmap_data(), on the other hand, takes no lock at all: it validates against the old buffer's state and dma_bytes, remaps its pages into the VMA, and only then increments mmap_count. A concurrent mmap() can therefore slip in between the check and the free. remap_pfn_range() installs writable PTEs for the old buffer's pages without taking page references, and the subsequent do_free_pages() returns those pages to the page allocator while the VMA still maps them. This leaves a stale, writable mapping of freed pages: a page-level use-after-free that can be leveraged for local privilege escalation. Make snd_pcm_mmap_data() participate in the buffer-access scheme introduced for hw_params/hw_free: acquire runtime->buffer_accessing before validating and remapping, and release it afterwards. Buffer reallocation already fails with -EBUSY while accessors are active, and the mmap side now fails with -EBUSY while a reallocation is in progress, so the validate/remap sequence and the check/free sequence can no longer interleave. A reproducer that turns this race into a stale writable mapping of the freed DMA buffer pages is available on request.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98121", "url": "https://ubuntu.com/security/CVE-2026-98121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix NULL pointer dereference in PM callbacks msc313e_wdt_probe() doesn't set the driver data for the platform device. As a result, dev_get_drvdata() in msc313e_wdt_suspend() and msc313e_wdt_resume() will return NULL, leading to a NULL pointer dereference afterward. Set the platform device driver data in msc313e_wdt_probe().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98123", "url": "https://ubuntu.com/security/CVE-2026-98123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration sctp_verify_asconf() walks ASCONF-ACK parameters with sctp_walk_params(), which advances by SCTP_PAD4(length), while the consumer sctp_get_asconf_response() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset. When those bytes yield a length of zero, the while loop over asconf_ack_len makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help). The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read. Reject SCTP_PARAM_ERR_CAUSE parameters shorter than sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERR_CAUSE parameter the consumer can see, so the consumer's asconf_ack_len check is dropped and it returns err_param->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTP_PARAM_ERR_CAUSE per RFC 5061. The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98130", "url": "https://ubuntu.com/security/CVE-2026-98130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START The SCTP_CMD_TIMER_START handler checks timer_pending() before calling timer_reduce(). The timer can expire and detach between these operations, causing timer_reduce() to rearm the timer without taking the association reference required for the newly armed timer. The timer callback later unconditionally drops its association reference, which can leave the association reference count unbalanced and result in use-after-free during association teardown. Use the return value of timer_reduce() to determine whether the timer was actually armed. Take the association reference only when timer_reduce() successfully starts a new timer, closing the race between checking the timer state and rearming it. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98154", "url": "https://ubuntu.com/security/CVE-2026-98154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix -EIO cleanup order in queue_rq On -EIO, the RDMA queue_rq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete. Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98157", "url": "https://ubuntu.com/security/CVE-2026-98157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation The poll_msec sysfs store file uses simple_strtoul() which accepts an unsigned long, but the target field (poll_msec) is unsigned int. On 64-bit systems, a value > UINT_MAX is silently truncated when stored. Fix the mismatch by using kstrtouint() instead. This rejects values larger than UINT_MAX at parse time, making truncation impossible. Also add a check for value < 1 to reject the 0-delay case, which would cause the poll work to spin without delay and consume 100% CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89796", "url": "https://ubuntu.com/security/CVE-2026-89796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid infinite kdamond_merge_regions() internal loop Patch series \"mm/damon: unurgent fixes for infinite loop, NULL de-ref and races\", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-98158", "url": "https://ubuntu.com/security/CVE-2026-98158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_async: drop the errored frame instead of resetting its headroom ppp_receive_nonmp_frame() prepends a two-byte direction tag before running the pass/active BPF filters: \t*(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG); Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in ppp_async's process_input_packet() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD: \terr: \t\tif (skb) { \t\t\t/* make skb appear as freshly allocated */ \t\t\tskb_trim(skb, 0); \t\t\tskb_reserve(skb, - skb_headroom(skb)); \t\t} ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head: skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev: kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled ppp_decompress_frame() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason. Rather than restore the headroom, drop the errored frame - as ppp_synctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read. The original V1 of this patch made room in ppp_receive_nonmp_frame() with skb_cow_head(); Eric pointed out that fixing the root cause in the transport is the right approach. Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-93288", "url": "https://ubuntu.com/security/CVE-2026-93288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state sashiko reports: \"nfnl_log_net_exit() calls nf_log_unset(), which clears the logger pointer without an RCU grace period. Immediately after, ops_free_list() frees the per-net state while concurrent packets might still be executing nf_log_packet() under rcu_read_lock().\" Clear the pointer via .pre_exit to make sure rcu readers have completed before pernet storage is free'd. The change in nf_log_syslog.c is only done for consistency: it doesn't use pernet data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93782", "url": "https://ubuntu.com/security/CVE-2026-93782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: flush backend after device ioctls vhost-scsi translates guest response descriptors into userspace iovecs when commands are submitted. Target-core completes those commands asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while an in-flight command still retains response iovecs translated through the old table. If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command completion can write the response to an unrelated userspace object. Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device ioctl. This waits for in-flight commands that can still use the old response iovecs before the ioctl returns.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93783", "url": "https://ubuntu.com/security/CVE-2026-93783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr and dereferences hdr->addr and hdr->ctrl without validating skb->len first. A truncated frame with skb->len less than the minimum header size causes an out-of-bounds read of uninitialized memory. Additionally, a zero-length frame causes skb->len-- to underflow to UINT_MAX, making skb_tail_pointer() read far past the buffer. Commit 23882b828c3c (\"Bluetooth: RFCOMM: validate skb length in MCC handlers\") fixed the same class of missing-length-check bugs in the MCC sub-handlers, but the top-level rfcomm_recv_frame() was left unfixed. KMSAN reports: BUG: KMSAN: uninit-value in rfcomm_run ... Uninit was created at: __alloc_skb+0x474/0xb60 vhci_write+0xe9/0x870 Fix this by rejecting frames smaller than sizeof(struct rfcomm_hdr) + 1 (the minimum frame must have a 3-byte header and a 1-byte FCS).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93784", "url": "https://ubuntu.com/security/CVE-2026-93784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie() The KASAN allocation trace shows that a malformed IE buffer is stored via SIOCSIWGENIE (cfg80211_wext_siwgenie()) without any validation. The crash trace shows that a subsequent SIOCSIWESSID triggers a connection attempt which calls cfg80211_sme_get_conn_ies() to process the stored IE buffer, causing: - An out-of-bounds read in skip_ie() which reads ies[pos+1] (the length byte) past the end of the 1-byte buffer. - An integer underflow in the memcpy size argument when offs returned by ieee80211_ie_split() exceeds ies_len, causing unsigned subtraction to wrap to SIZE_MAX and triggering a fortify panic. Fix this by validating the IE buffer in cfg80211_wext_siwgenie() before storing it. [drop unnecessary ie_len check, update commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93785", "url": "https://ubuntu.com/security/CVE-2026-93785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate idmap key payload length The cifs.idmap key type stores its payload length in key->datalen, which is limited to U16_MAX. Accepting a larger key payload truncates the recorded length and can make later users interpret the payload using inconsistent bounds. Reject oversized preparsed payloads before allocating or copying them. This keeps key->datalen consistent with the stored data for both inline and separately allocated idmap payloads.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93789", "url": "https://ubuntu.com/security/CVE-2026-93789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: bound aligned TLV advance in FW parser Validate ALIGN(tlv_len, 4) against remaining parser length before consuming bytes from the firmware image. This avoids length underflow on malformed TLVs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93795", "url": "https://ubuntu.com/security/CVE-2026-93795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix leaks and online flag on radix_tree_insert failure When radix_tree_insert() fails in blkg_create(), the error path has two issues: 1. blkg->online is set to true unconditionally, even when the blkg was never fully inserted. Move the assignment inside the success block. 2. The error path calls blkg_put() without first calling percpu_ref_kill(). Because the refcount is still in percpu mode, percpu_ref_put() only does this_cpu_sub() without checking for zero, so blkg_release() is never triggered. This permanently leaks the blkg memory, its percpu iostat, policy data, the parent blkg reference, and the cgroup css reference — the latter preventing the cgroup from ever being destroyed. Fix by replacing blkg_put() with percpu_ref_kill(), matching the pattern used in blkg_destroy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93797", "url": "https://ubuntu.com/security/CVE-2026-93797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix an off-by-1 boundary check Before looking at the 11th byte, check the length is big enough.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93798", "url": "https://ubuntu.com/security/CVE-2026-93798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix reloc root cleanup in merge_reloc_roots() If the root we got has zero root refs in its root item, we are resetting the root's ->reloc_root without using barriers like we do everywhere else. Sashiko complained about this while reviewing another patch, and it's correct (see the Link tag below). Also, we should not clear BTRFS_ROOT_DEAD_RELOC_TREE from the root unless the root points to the reloc root we have. Fix this by using clear_reloc_root(), which issues the memory barrier after setting the root's ->reloc_root to NULL and before clearing the bit BTRFS_ROOT_DEAD_RELOC_TREE from the root.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93800", "url": "https://ubuntu.com/security/CVE-2026-93800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol() If during relocation we fail in insert_dirty_subvol() because btrfs_update_reloc_root() returned an error, we will leave a root's reloc_root field pointing to a reloc root that was freed instead of NULL, resulting later in a use-after-free, or double free attempt during unmount. The sequence of steps is this: 1) During relocation the call to btrfs_update_reloc_root() in insert_dirty_subvol() fails, so insert_dirty_subvol() returns the error to merge_reloc_root() without adding the root to the list rc->dirty_subvol_roots; 2) Then merge_reloc_root() aborts the current transaction because insert_dirty_subvol() returned an error; 3) Up the call chain, merge_reloc_roots() gets the error, adds the reloc root for root X to the local reloc_roots list and jumps to the 'out' label, where it calls free_reloc_roots() to free all the reloc roots in the local reloc_roots list. This frees the reloc root for root X; 4) We go up the call chain to relocate_block_group() which calls clean_dirty_subvols() to go over dirty roots and set their ->reloc_root field to NULL, but root X is not in the dirty_subvol_roots list, so its ->reloc_root still points to a reloc root; 5) Relocation finishes, with an error and a transaction abort, but the ->reloc_root field for root X still points to the reloc root that was freed in step 3; 6) When unmounting the fs we end up calling: btrfs_free_fs_roots() btrfs_drop_and_free_fs_root() --> calls btrfs_put_root() against root X's ->reloc_root which is not NULL and points to the already freed reloc root in step 4 above Resulting in a use-after-free to a double free attempt. Syzbot reported this with the following dmesg/syslog: [ 106.004389][ T5339] BTRFS error (device loop0 state A): Transaction aborted (error -5) [ 106.014266][ T5339] BTRFS: error (device loop0 state A) in merge_reloc_root:1655: errno=-5 IO failure [ 106.021891][ T1061] BTRFS error (device loop0 state A): error while writing out transaction: -5 [ 106.026964][ T1061] BTRFS warning (device loop0 state A): Skipping commit of aborted transaction. [ 106.033807][ T5340] BTRFS error (device loop0 state A): bdev /dev/loop0 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 [ 106.039265][ T1061] BTRFS: error (device loop0 state A) in cleanup_transaction:2067: errno=-5 IO failure [ 106.044382][ T5339] BTRFS info (device loop0 state EA): forced readonly [ 106.074329][ T5339] BTRFS: error (device loop0 state EA) in merge_reloc_roots:1887: errno=-5 IO failure [ 106.081004][ T5356] BTRFS info (device loop0 state EA): scrub: started on devid 1 [ 106.085611][ T5339] BTRFS info (device loop0 state EA): balance: ended with status: -30 [ 106.089517][ T5356] BTRFS info (device loop0 state EA): scrub: not finished on devid 1 with status: -30 [ 106.662365][ T5338] BTRFS info (device loop0 state EA): last unmount of filesystem 3a375e4e-b156-4d76-a2ad-16e198ce1409 [ 106.682946][ T5338] ================================================================== [ 106.686574][ T5338] BUG: KASAN: slab-use-after-free in btrfs_put_root+0x2f/0x250 [ 106.690090][ T5338] Write of size 4 at addr ffff88803f978630 by task syz.0.0/5338 [ 106.693173][ T5338] [ 106.694279][ T5338] CPU: 0 UID: 0 PID: 5338 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) [ 106.694293][ T5338] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 106.694300][ T5338] Call Trace: [ 106.694308][ T5338] [ 106.694314][ T5338] dump_stack_lvl+0xe8/0x150 [ 106.694331][ T5338] print_address_description+0x55/0x1e0 [ 106.694343][ T5338] ? btrfs_put_root+0x2f/0x250 [ 106.694358][ T5338] print_report+0x58/0x70 [ 106. ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93802", "url": "https://ubuntu.com/security/CVE-2026-93802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: validate beacon length before fixed buffer copy rsi_prepare_beacon() copies the mac80211 beacon frame after FRAME_DESC_SZ into a management skb whose usable tailroom may be smaller than MAX_MGMT_PKT_SIZE after alignment. Validate the beacon length against the actual tailroom before the copy and skb_put(). Leave ownership of the management skb with the caller on error, matching the existing rsi_send_beacon() cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93803", "url": "https://ubuntu.com/security/CVE-2026-93803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libipw: fix key index receive bound checks libipw_rx() reads skb->data[hdrlen + 3] to extract the WEP key index in both the software-decrypt key selection path and the hardware-decrypted IV/ICV strip path. In both places the existing guard only checks skb->len >= hdrlen + 3, which proves bytes up to hdrlen + 2 but not the byte at hdrlen + 3. Require hdrlen + 4 bytes before reading that item in both paths. This is a local source-boundary check only; it does not change the key index semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93805", "url": "https://ubuntu.com/security/CVE-2026-93805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate rx/tx MLME callback frame lengths before access cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints before rejecting frames shorter than the frame-control field. After that, they only require len >= 2 before dispatching into subtype handlers that assume their fixed fields are present. The frames that trip this are not shorter than 2 bytes; they are short relative to their subtype. mwifiex is a concrete in-tree example on the length side: mwifiex_process_mgmt_packet() only requires a 4-address ieee80211_hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and removing addr4, pkt_len can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARN_ON(len < 2) does not fire on such a frame, and cfg80211_process_deauth() then reads u.deauth.reason_code as a two-byte access starting at offset 24, immediately past the 24-byte buffer. Add a frame-control length gate, then validate each subtype's minimum frame size in an if/else-if chain that mirrors the dispatch logic. Trace only after the frame is known to be well-formed. Side effects of this change: - The WARN_ON(len < 2) is dropped. It only guarded the frame_control read, never the subtype fixed fields, and it does not fire on the frames that actually trigger the out-of-bounds read (which are >= 2). The len >= 2 check is kept as the guard before dereferencing frame_control, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93807", "url": "https://ubuntu.com/security/CVE-2026-93807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers rsi_hal_load_key() copies tx_mic_key and rx_mic_key from data[16] and data[24] whenever key data is present. Those offsets are only part of the 32-byte TKIP key layout. Shorter keys used by other ciphers, such as CCMP, do not provide those bytes, so the unconditional copies can read past the supplied key buffer. Only copy the MIC keys for TKIP, and reject malformed TKIP keys that are shorter than the expected 32-byte layout. [drop useless length check]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93808", "url": "https://ubuntu.com/security/CVE-2026-93808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: caiaq: validate EP1 reply lengths usb_ep1_command_reply_dispatch() uses buf[0] as a command byte and then reads command-specific fixed items from the same URB buffer. Several paths use buf + 1, buf[1], buf[2], or buf + 3 without first proving that urb->actual_length contains those bytes. Add per-command length checks, use a payload length derived from the bytes after the command byte for the control-state copy, and reject short analog input payloads before the input helper reads fixed offsets from the EP1 reply.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93811", "url": "https://ubuntu.com/security/CVE-2026-93811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling 1. When ndr_decode_v4_ntacl() fails, the code jumped to free_n_data which only freed n.data, skipping kfree(acl.sd_buf) and leaking the buffer. Zero-initialize struct xattr_ntacl acl, reorder error labels to out_free to release acl.sd_buf on all error paths. 2. if (acl.sd_size < sizeof(struct smb_ntsd)) is true, original code returned success without freeing sd_buf and left stale *pntsd. Set rc = -EINVAL before jumping to out_free to return error code and free buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93812", "url": "https://ubuntu.com/security/CVE-2026-93812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr ndr_encode_v4_ntacl() allocates sd_ndr.data via kzalloc() at entry. If any subsequent ndr_write_*() call returns error during encoding, the allocated sd_ndr.data won't be freed and causes memory leak. Move kfree(sd_ndr.data) into out label to ensure the buffer gets released on all success and error return paths.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93813", "url": "https://ubuntu.com/security/CVE-2026-93813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tree-checker: validate INODE_REF's namelen [BUG] A crafted btrfs image can trigger the following crash: BUG: unable to handle page fault for address: ffffd1dc42884000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page CPU: 9 UID: 0 PID: 1034 Comm: poc Not tainted 7.1.0-rc4-custom+ #383 PREEMPT(full) 46af0a92938a63be7132e0dfd71e62327c51d5c2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:memcpy+0xc/0x10 Call Trace: read_extent_buffer+0xe4/0x100 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] btrfs_get_name+0x15e/0x1e0 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] reconnect_path+0x165/0x390 exportfs_decode_fh_raw+0x337/0x400 ? drop_caches_sysctl_handler+0xb0/0xb0 ---[ end trace 0000000000000000 ]--- RIP: 0010:memcpy+0xc/0x10 Kernel panic - not syncing: Fatal exception [CAUSE] TThe crafted image has the following corrupted INODE_REF item: item 9 key (258 INODE_REF 257) itemoff 11544 itemsize 4106 \tindex 2 namelen 4096 name: d\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000 The itemsize matches the namelen, but the namelen is 4096, way larger than normal name length limit (BTRFS_NAME_LEN, 255). Meanwhile the memory of the @name is only 255 byte sized, this will cause out-of-boundary access, and cause the above crash. [FIX] Add extra namelen verification for INODE_REF, just like what we have done in ROOT_REF checks. Now the crafted image can be rejected gracefully: BTRFS critical (device dm-2): corrupt leaf: root=5 block=30572544 slot=14 ino=259, invalid inode ref name length, has 4096 expect [1, 255] BTRFS error (device dm-2): read time tree block corruption detected on logical 30572544 mirror 2 [ Rebase, add a Link: tag, add an simple cause analyze ]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93815", "url": "https://ubuntu.com/security/CVE-2026-93815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: au1000: move free_irq out of the close-time spinlocked section au1000_close() calls free_irq() while aup->lock is still held with spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ descriptor request mutex, so it does not belong inside the close-time spinlocked section. This was found by our static analysis tool and then confirmed by manual review of the in-tree au1000_close() .ndo_stop path. The reviewed path keeps aup->lock held across the MAC reset, queue stop and free_irq(dev->irq, dev). A directed runtime validation kept that ndo_stop carrier and the same free_irq(dev->irq, dev) operation under the driver lock. Lockdep reported \"BUG: sleeping function called from invalid context\" and \"Invalid wait context\" while free_irq() was taking desc->request_mutex, with au1000_close() and free_irq() on the stack. Drop aup->lock before freeing the IRQ. The protected close-time work still stops the device and queue before IRQ teardown, but the sleepable IRQ core path now runs outside the spinlocked section.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93816", "url": "https://ubuntu.com/security/CVE-2026-93816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate inline dentry name lengths before conversion Inline dentry conversion copies names out of the inline dentry area before checking that each recorded name length fits in the available filename slots. A corrupted image can therefore make the conversion path read past the inline filename storage while building the regular dentry block. Validate each inline dentry name length against the inline filename area before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93819", "url": "https://ubuntu.com/security/CVE-2026-93819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93820", "url": "https://ubuntu.com/security/CVE-2026-93820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rockchip: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93821", "url": "https://ubuntu.com/security/CVE-2026-93821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93822", "url": "https://ubuntu.com/security/CVE-2026-93822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: iproc: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93825", "url": "https://ubuntu.com/security/CVE-2026-93825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: Add NULL check for spi_get_device_id() in spi_get_device_match_data() Prevent NULL pointer dereference when spi_get_device_id() returns NULL, which can happen when using driver_override without matching SPI ID entry.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93830", "url": "https://ubuntu.com/security/CVE-2026-93830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac2: disable RBUE in default RX interrupt mask Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97407", "url": "https://ubuntu.com/security/CVE-2026-97407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in set_fmt rockchip_pdm_set_fmt() calls pm_runtime_get_sync() before accessing hardware registers, but ignores its return value. If the runtime resume fails, the function continues to perform register accesses while the device state is undefined. Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() and return early on failure to avoid unpowered register accesses.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97408", "url": "https://ubuntu.com/security/CVE-2026-97408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate connectionless PSM length Connectionless L2CAP frames carry a two-byte PSM at the start of the payload. l2cap_recv_frame() currently reads that PSM unconditionally after validating only the outer L2CAP length. A malformed connectionless frame with a zero- or one-byte payload can therefore make the parser read beyond the advertised skb payload and use tailroom bytes as part of the PSM. A VHCI-backed QEMU reproducer injected a one-byte connectionless payload and reached the unchecked read. Reject connectionless frames that cannot contain the PSM before reading or pulling it. This preserves all valid connectionless frames while dropping only structurally incomplete packets.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97411", "url": "https://ubuntu.com/security/CVE-2026-97411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ibm: emac: mal: fix potential system hang in mal_remove() napi_disable() is not idempotent and calling it on an already-disabled or unenabled NAPI context will cause the kernel to spin indefinitely waiting for the NAPI_STATE_SCHED bit to clear. In mal_remove(), napi_disable() is called unconditionally. If no MACs were registered, NAPI was never enabled. Also, if they were registered but subsequently unregistered, NAPI was already disabled in mal_unregister_commac(). In either case, calling napi_disable() causes the kernel to hang upon module removal. Fix this by only calling napi_disable() in mal_remove() if the commac list is not empty (which implies NAPI is enabled).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97413", "url": "https://ubuntu.com/security/CVE-2026-97413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Fix integer underflow in process_read and process_write usr_len is read from a network-supplied message field (le16_to_cpu) and used to compute data_len = off - usr_len without validating that usr_len <= off. A malicious RDMA client can send usr_len > off causing an integer underflow, resulting in data_len wrapping to a huge size_t value which is then passed to the rdma_ev callback as a memory length, leading to out-of-bounds memory access. Fix by reading and validating usr_len <= off before rtrs_srv_get_ops_ids() in both process_read() and process_write(), ensuring the early return path acquires no reference and has no resource leak.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97416", "url": "https://ubuntu.com/security/CVE-2026-97416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: balance: fix potential bg lookup failure in btrfs_may_alloc_data_chunk() [BUG] Running btrfs balance can trigger a null-ptr-deref before relocating a data chunk when metadata corruption leaves a chunk in the chunk tree without a corresponding block group in the in-memory cache: KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] RIP: 0010:btrfs_may_alloc_data_chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601 Call Trace: __btrfs_balance fs/btrfs/volumes.c:4217 [inline] btrfs_balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604 btrfs_ioctl_balance fs/btrfs/ioctl.c:3577 [inline] btrfs_ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313 ... [CAUSE] __btrfs_balance() iterates the on-disk chunk tree and passes the chunk logical bytenr to btrfs_may_alloc_data_chunk() before relocating a data chunk. That helper then queries the in-memory block group cache: cache = btrfs_lookup_block_group(fs_info, chunk_offset); chunk_type = cache->flags; /* cache may be NULL */ A corrupt image can contain a chunk item whose matching block group item is missing, so no block group is ever inserted into the cache. In that case btrfs_lookup_block_group() returns NULL. The code only guards this with ASSERT(cache), which becomes a no-op when CONFIG_BTRFS_ASSERT is disabled. The subsequent dereference of cache->flags therefore crashes the kernel. [FIX] Add a NULL check after btrfs_lookup_block_group() in btrfs_may_alloc_data_chunk() and print and error message for clarity.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97417", "url": "https://ubuntu.com/security/CVE-2026-97417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack() The timestamp-only fast path dereferences the option stream as *(__be32 *)ptr, which assumes 4-byte alignment that the TCP option stream does not guarantee. Use get_unaligned_be32() instead, which reads the value safely and already returns host byte order, so the htonl() on the comparison constant can be dropped. This matches the existing get_unaligned_be32() use later in the same function.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97418", "url": "https://ubuntu.com/security/CVE-2026-97418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es18xx: check control allocation before private data setup snd_es18xx_mixer() creates controls with snd_ctl_new1() and then stores bookkeeping pointers or sets private_free before calling snd_ctl_add(). snd_ctl_new1() can return NULL on allocation failure, so those writes can dereference a NULL control pointer. Check the returned control pointers before using them and return -ENOMEM on allocation failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97419", "url": "https://ubuntu.com/security/CVE-2026-97419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: broadcast netlink notifications in the device's net namespace The HSR generic netlink family sets .netnsok = true. HSR devices can live in network namespaces other than init_net. Two async notifiers broadcast events with genlmsg_multicast(). They are hsr_nl_ringerror() and hsr_nl_nodedown(). That helper delivers only on the default genl socket in init_net. So the events always land in init_net. The network namespace of the device does not matter. This has two effects. A listener in the device's own namespace never sees its own ring error and node down events. A privileged listener in init_net receives events from HSR devices in other namespaces. The payload carries the peer node MAC (HSR_A_NODE_ADDR) and the slave port ifindex (HSR_A_IFINDEX). Switch both callers to genlmsg_multicast_netns(). Other families with .netnsok = true already do this. Examples are gtp, ovpn, team, batman-adv, netdev-genl, ethtool and handshake. hsr_nl_ringerror() already has the slave port. It uses dev_net(port->dev). hsr_nl_nodedown() takes the namespace from the master port via hsr_port_get_hsr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97420", "url": "https://ubuntu.com/security/CVE-2026-97420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: NUL-terminate replaced sysctl value When writing to sysctls, proc_sys_call_handler() guarantees that the buffer passed to proc handlers is NUL-terminated. If bpf_sysctl_set_new_value() replaces the pending sysctl value, it can hand a replacement buffer directly to proc handlers. However, the helper currently copies only buf_len bytes into that buffer without appending a NUL terminator, leaving downstream parsers vulnerable to out-of-bounds access. Fix this by appending a '\\0' after the replaced value to restore the expected sysctl semantics. Since the helper already rejects buf_len greater than PAGE_SIZE - 1, there is always room for the extra byte. Reproduced in a QEMU x86_64 guest booted with KASAN while exercising the sysctl replacement path with a cgroup/sysctl BPF program. The reproducer targets `/proc/sys/net/core/flow_limit_cpu_bitmap`, fills the original user write buffer with non-zero bytes, and overrides the sysctl value so the replacement buffer lacks a terminating NUL. Under that setup, the pre-fix kernel reported: BUG: KASAN: slab-out-of-bounds in strnchrnul+0x72/0x90 Read of size 1 at addr ffff88800de57000 by task repro_patch3/66 CPU: 0 UID: 0 PID: 66 Comm: repro_patch3 Not tainted 7.1.0-rc3-00269-g8370ca1f87cc #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? strnchrnul+0x72/0x90 ? strnchrnul+0x72/0x90 kasan_report+0xca/0x100 ? strnchrnul+0x72/0x90 strnchrnul+0x72/0x90 bitmap_parse+0x37/0x2e0 flow_limit_cpu_sysctl+0xc6/0x840 ? __pfx_flow_limit_cpu_sysctl+0x10/0x10 ? __kvmalloc_node_noprof+0x5ba/0x870 proc_sys_call_handler+0x31d/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? selinux_file_permission+0x39f/0x500 ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... The buggy address is located 0 bytes to the right of allocated 4096-byte region [ffff88800de56000, ffff88800de57000) With this fix applied, rerunning the same sysctl-targeted path yields no corresponding KASAN reports.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97421", "url": "https://ubuntu.com/security/CVE-2026-97421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz() Several corner cases, especially important on 32 bits: - umem->iova is u64, the function argument should pass in u64 or iova will be truncated - Check that the length is not too large for the iova - Check that lengths > 4G don't overflow the GENMASK", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97430", "url": "https://ubuntu.com/security/CVE-2026-97430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: Prevent queuing new commands if xhci is inaccessible Refuse to queue a new command on the command ring if xHC is marked inaccessible with the HCD_FLAG_HW_ACCESSIBLE. HCD_FLAG_HW_ACCESSIBLE is set and cleared in suspend and resume. Also print a warning if xhci is being suspended with commands still pending on the command ring.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97434", "url": "https://ubuntu.com/security/CVE-2026-97434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: fix handling of NAPI on the remove path All the NAPI instances for a DPSW device are attached to the first switch port's net_device but shared by all ports. The NAPI instances get disabled only once the last port goes down. This causes an issue on the .remove() path where each port is unregistered and freed one at a time, causing the NAPI instances to be deleted even though they are not disabled. In order to avoid this, split up the unregister_netdev() calls from the free_netdev() so that we make sure all ports go down before we attempt a deletion of NAPI instances. Also, make the netif_napi_del() explicit as it is on the .probe() path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97435", "url": "https://ubuntu.com/security/CVE-2026-97435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: flower: reject cross-chip redirect dsa_port_from_netdev() may return a valid port from a different switch chip. Programming another chip's port index into the local hardware causes redirection to the wrong port, or an out-of-bounds access if the index exceeds the local chip's port count. Apply a minimal fix that adds a check to catch this case and adjusts the extack message. When cls->common.skip_sw is not set, the operation could instead redirect to the upstream port and let the software or upstream switch(es) handle the forward, but that is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97436", "url": "https://ubuntu.com/security/CVE-2026-97436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: rework FDB management on the bridge leave path On bridge leave, the dpaa2_switch_port_set_fdb() function always allocates a new FDB for the port which is becoming standalone. In case no FDB is found, then the port leaving a bridge will continue to use the current one. The above logic does not cover the case in which there are multiple bridges which have ports from the same DPSW instance. In this case, when the last port leaves bridge #1, it finds an unused FDB to switch to, but the old FDB is not marked as unused. Since the number of FDBs is equal to the number of DPSW interfaces, this will eventually lead to multiple ports sharing the same FDB. Fix this by changing how we are managing the FDBs on the leave path. Instead of directly allocating a new FDB, first verify if the current port is the last one to leave a bridge. If this is the case, then continue to use the current FDB and only allocate another FDB if there are other ports remaining in the bridge.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97437", "url": "https://ubuntu.com/security/CVE-2026-97437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e() The bounds check in ntfs_dir_emit() compares fname->name_len (a character count) against e->size (a byte count) without accounting for the 2-byte-per-character UTF-16LE encoding or the ATTR_FILE_NAME header size: if (fname->name_len + sizeof(struct NTFS_DE) > le16_to_cpu(e->size)) This computes: name_len + 16 > e_size The correct check must account for the ATTR_FILE_NAME header (66 bytes before the name) and the UTF-16LE character size (2 bytes each): sizeof(NTFS_DE) + offsetof(ATTR_FILE_NAME, name) + name_len * sizeof(short) > e_size Which computes: 16 + 66 + name_len * 2 > e_size The correct calculation already exists as fname_full_size() in ntfs.h and is used in cmp_fnames(), namei.c, and fslog.c, but was not used in the readdir path. A crafted NTFS image with an index entry containing a small e->size but large fname->name_len bypasses the current check, causing ntfs_utf16_to_nls() to read past the entry boundary. Additionally, add a key_size validation in hdr_find_e() to ensure the declared key_size does not exceed the available entry data, preventing comparison functions from reading past entry boundaries on the lookup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97438", "url": "https://ubuntu.com/security/CVE-2026-97438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate index entry key bounds [BUG] A malformed NTFS directory index entry can advertise a key_size larger than the bytes actually present in its NTFS_DE payload. Directory lookup then passes that malformed key to cmp_fnames(), which can read past the end of the kmalloc'ed index buffer. BUG: KASAN: slab-out-of-bounds in fname_full_size fs/ntfs3/ntfs.h:590 [inline] BUG: KASAN: slab-out-of-bounds in cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 Read of size 1 at addr ffff88801c313018 by task syz.6.3365/9279 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 __asan_report_load1_noabort+0x14/0x30 mm/kasan/report_generic.c:378 fname_full_size fs/ntfs3/ntfs.h:590 [inline] cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 hdr_find_e.isra.0+0x3ed/0x670 fs/ntfs3/index.c:762 indx_find+0x4b5/0x900 fs/ntfs3/index.c:1186 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... Allocated by task 9279: kasan_save_stack+0x39/0x70 mm/kasan/common.c:56 kasan_save_track+0x14/0x40 mm/kasan/common.c:77 kasan_save_alloc_info+0x37/0x60 mm/kasan/generic.c:573 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0xc3/0xd0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __do_kmalloc_node mm/slub.c:5650 [inline] __kmalloc_noprof+0x2bd/0x900 mm/slub.c:5662 kmalloc_noprof include/linux/slab.h:961 [inline] indx_read+0x41d/0xad0 fs/ntfs3/index.c:1059 indx_find+0x447/0x900 fs/ntfs3/index.c:1179 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... [CAUSE] The index-header validators only validated INDEX_HDR-level geometry. They did not walk each NTFS_DE to verify entry alignment, subnode layout, or that key_size fit inside the entry payload. They also allowed a last sentinel entry to carry a non-zero key_size. [FIX] Walk every NTFS_DE in ntfs3's index-header validators and reject entries with invalid layout, mismatched subnode state, oversized key_size, or non-zero sentinel keys before lookup or log replay can consume them.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97439", "url": "https://ubuntu.com/security/CVE-2026-97439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib [BUG] A corrupted ntfs3 image can hit a NULL function pointer call in generic_perform_write() after toggling system.ntfs_attrib and then overwriting system.dos_attrib on the same file. BUG: kernel NULL pointer dereference, address: 0000000000000000 \\#PF: supervisor instruction fetch in kernel mode \\#PF: error_code(0x0010) - not-present page PGD bed5067 P4D bed5067 PUD 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffff88801025f988 EFLAGS: 00010246 Call Trace: generic_perform_write+0x409/0x8c0 mm/filemap.c:4255 __generic_file_write_iter+0x1bb/0x200 mm/filemap.c:4372 ntfs_file_write_iter+0xcd9/0x1c20 fs/ntfs3/file.c:1253 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x63b/0xf70 fs/read_write.c:686 ksys_write+0x133/0x250 fs/read_write.c:738 __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x77/0xc0 fs/read_write.c:746 ... [CAUSE] system.ntfs_attrib updates ATTR_DATA flags via ni_new_attr_flags() and switches i_mapping->a_ops to ntfs_aops_cmpr when FILE_ATTRIBUTE_COMPRESSED is set. system.dos_attrib then overwrites ni->std_fa from a one-byte DOS attribute value, clearing the compression bit without updating ATTR_DATA or the mapping operations. Old buffered writes use is_compressed(ni) to choose __generic_file_write_iter(). That leaves generic_perform_write() calling a NULL write_begin callback from ntfs_aops_cmpr. [FIX] Treat system.dos_attrib as a low-byte DOS attribute update and preserve the existing non-DOS attribute bits in ni->std_fa. This keeps compressed and sparse state consistent with ATTR_DATA and the mapping operations while keeping the existing DOS attribute semantics intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97440", "url": "https://ubuntu.com/security/CVE-2026-97440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix node refcount leak on ctrl packet alloc failure qrtr_send_resume_tx() calls qrtr_node_lookup() which takes a reference on the returned node. If the subsequent call to qrtr_alloc_ctrl_packet() fails due to memory allocation failure, the function returns -ENOMEM without calling qrtr_node_release() to release the node reference. Add qrtr_node_release(node) before returning on the allocation failure path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97441", "url": "https://ubuntu.com/security/CVE-2026-97441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: ahci: fail probe if BAR too small for claimed ports When an AHCI controller is disabled in BIOS, its HOST_CAP register may contain a bogus value, e.g. 0xFFFFFFFF. Since CAP.NP (Number of Ports) is a zeroes based 5-bit register field, a value of 0x1f means 32 ports. If CAP.NP claims more ports than can physically fit within the mapped BAR region, accessing port registers beyond the BAR boundary causes a kernel panic. Add validation in ahci_init_one() to check that the BAR size is sufficient for the number of ports claimed in CAP.NP. The check calculates the required MMIO size as: required_size = 0x100 (global registers) + max_ports * 0x80 If required_size exceeds the actual BAR size, the probe fails with -ENODEV, preventing the panic and providing a clear error message. [cassel: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97443", "url": "https://ubuntu.com/security/CVE-2026-97443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/ftrace: Fix WARNING in __unregister_ftrace_function perf_ftrace_function_unregister() unconditionally calls unregister_ftrace_function() without checking whether the ftrace_ops was ever successfully registered. This triggers a WARN_ON in __unregister_ftrace_function() when the ops doesn't have FTRACE_OPS_FL_ENABLED set. This can happen during perf_event_alloc() error cleanup when perf_trace_destroy() is called via __free_event() on an event whose ftrace_ops registration failed or was already torn down by perf_try_init_event()'s err_destroy path. The call path is: perf_event_alloc() error cleanup -> __free_event() -> event->destroy() [tp_perf_event_destroy] -> perf_trace_destroy() -> perf_trace_event_close() -> TRACE_REG_PERF_CLOSE -> perf_ftrace_function_unregister() -> unregister_ftrace_function() -> __unregister_ftrace_function() -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to unregister. If the ops is not enabled, just free the filter and return success.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97444", "url": "https://ubuntu.com/security/CVE-2026-97444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in two places Add boundary checks in acpi_ps_get_next_namestring() and acpi_ps_peek_opcode() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97445", "url": "https://ubuntu.com/security/CVE-2026-97445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources() Enhance buffer validation in acpi_ut_walk_aml_resources() to prevent buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97446", "url": "https://ubuntu.com/security/CVE-2026-97446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package() acpi_ns_custom_package() unconditionally dereferences the first element of the package to read the _BIX version number, without checking for NULL: if ((*Elements)->Common.Type != ACPI_TYPE_INTEGER) When firmware returns a _BIX package whose first element is an unresolvable reference, ACPICA evaluates that entry to NULL. acpi_ns_remove_null_elements() does not strip NULL entries for ACPI_PTYPE_CUSTOM packages (fixed-position format would break if elements were shifted), so acpi_ns_custom_package() sees the NULL and causes a crash. Add a NULL check for the first element (version field) before dereferencing it. The caller then receives AE_AML_OPERAND_TYPE instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97448", "url": "https://ubuntu.com/security/CVE-2026-97448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add validation for node in acpi_ns_build_normalized_path() Add validation for node in acpi_ns_build_normalized_path() to prevent use-after-free vulnerabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97449", "url": "https://ubuntu.com/security/CVE-2026-97449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add package limit checks in parser functions Add package limit checks in parser functions to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97450", "url": "https://ubuntu.com/security/CVE-2026-97450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate handler object type in two places ACPICA: validate handler object type in acpi_ev_has_default_handler() and acpi_ev_find_region_handler().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97451", "url": "https://ubuntu.com/security/CVE-2026-97451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op) Add overflow check for Index + Length to prevent integer overflow when calculating the truncation length. This prevents negative size parameter being passed to memcpy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97452", "url": "https://ubuntu.com/security/CVE-2026-97452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Prevent adding invalid references Prevent adding references for local, argument, and debug objects in acpi_ut_copy_simple_object().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97453", "url": "https://ubuntu.com/security/CVE-2026-97453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate byte_count in acpi_ps_get_next_package_length() Validate package length reading in acpi_ps_get_next_package_length().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97454", "url": "https://ubuntu.com/security/CVE-2026-97454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in acpi_ps_get_next_field() Add boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97455", "url": "https://ubuntu.com/security/CVE-2026-97455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix use-after-free in acpi_ds_terminate_control_method() Fix use-after-free issue in acpi_ds_terminate_control_method() by clearing references to method locals and arguments.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97456", "url": "https://ubuntu.com/security/CVE-2026-97456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix condition check in acpi_ps_parse_loop() Fix condition check for AML_ELSE_OP in acpi_ps_parse_loop() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97472", "url": "https://ubuntu.com/security/CVE-2026-97472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: fix temp address generation after prefix deprecation When a router temporarily deprecates an IPv6 prefix (either by sending a Router Advertisement with Preferred Lifetime = 0 or by letting the lifetime expire) and later restores it, the kernel permanently loses its ability to generate temporary privacy addresses (RFC 8981) for that prefix. This happens because the address worker attempts to generate a replacement temporary address when the current one nears expiration. As the base prefix is deprecated already, the generation fails after marking the temporary address as already having spawned a replacement (ifp->regen_count++). When the router eventually restores the prefix, the temporary address becomes active again. However, once it naturally expires, the address worker sees this temporary address already tried to generate one and skips the regeneration. Fix the issue by resetting the regen_count check of the latest temp address generated for the prefix updated by the incoming RA.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97475", "url": "https://ubuntu.com/security/CVE-2026-97475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tegra/soctherma: Switch to devm cooling device registration Use devm_thermal_of_cooling_device_register() to simplify resource management and avoid manual cleanup in error paths. As a side effect this change has the benefit of solving an existing issue. Before, the function tegra_soctherm_remove() only called debugfs_remove_recursive() and never called thermal_cooling_device_unregister() for any of the cooling devices registered here. After the driver removal, the thermal framework's cdev list would still hold references to thermal_cooling_device objects whose devdata pointer (ts) pointed to memory already freed by the platform device's devm cleanup. With this change, the cooling device is unregistered when the driver is removed, thus fixing the issue above.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97476", "url": "https://ubuntu.com/security/CVE-2026-97476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: filter RDS_INFO_* getsockopt by caller's netns The RDS_INFO_* family of getsockopt(2) options reads several file-scope global lists that are not per-netns: rds_sock_info / rds6_sock_info, rds_sock_inc_info / rds6_sock_inc_info -> rds_sock_list rds_tcp_tc_info / rds6_tcp_tc_info -> rds_tcp_tc_list rds_conn_info / rds6_conn_info, rds_conn_message_info_cmn (for the *_SEND_MESSAGES and *_RETRANS_MESSAGES variants), rds_for_each_conn_info (for RDS_INFO_IB_CONNECTIONS) -> rds_conn_hash[] The handlers do not filter by the caller's network namespace. rds_info_getsockopt() has no netns or capable() check, and rds_create() has no capable() check, so AF_RDS is reachable from an unprivileged user namespace. As a result, an unprivileged caller in a fresh user_ns plus netns can read the bound address and sock inode of every RDS socket on the host, the peer address of incoming messages on every RDS socket on the host, the peer address and TCP sequence numbers of every rds-tcp connection on the host, and the peer address and RDS sequence numbers of every RDS connection on the host. The rds-tcp transport is reachable from a non-initial netns (see rds_set_transport()), so a one-shot init_net gate at rds_info_getsockopt() would deny legitimate per-netns visibility to rds-tcp callers. Instead, filter at each handler by comparing the netns of the caller's socket to the netns of the list entry, or to rds_conn_net(conn) for connection paths. Only copy entries whose netns matches the caller. Counters (RDS_INFO_COUNTERS) are aggregate statistics and remain global. Reproducer (KASAN VM, rds and rds_tcp loaded): an AF_RDS socket binds 127.0.0.1:4242 in init_net as root. A child process enters a fresh user_ns plus netns and opens AF_RDS there, then calls getsockopt(SOL_RDS, RDS_INFO_SOCKETS). Before this change, the child sees the init_net socket. After this change, the child sees zero entries. Drop the rds_sock_count, rds_tcp_tc_count, and rds6_tcp_tc_count globals. v2 used them for the size precheck and lens->nr; v3 replaced the precheck with a per-ns count from a first pass over the list, so the globals have no remaining readers. The matching increments and decrements in rds_create()/rds_destroy_sock() and rds_tcp_set_callbacks()/rds_tcp_restore_callbacks() go away with them. Reported by the kernel test robot under clang W=1.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97481", "url": "https://ubuntu.com/security/CVE-2026-97481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix possible ISR soft lockup There are rare cases in which the host gets stuck in the ISR because it is flooded with messages during the startup phase. The reason for the soft lockup in the ISR is the missing FIFO error IRQ (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers the IRQ immediately again. Fix this by adding a check for the FIFOE status and clearing the FIFO if no data is ready (DR). This behavior was observed on an AM62L device which uses the OMAP 8250 driver. Fix it for all 8250 drivers, since the OMAP driver's special IRQ setup handling may trigger this behavior more frequently, but it is not ensured that other 8250 drivers aren't affected.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97482", "url": "https://ubuntu.com/security/CVE-2026-97482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET log goku_irq() handles a number of bus events under a single ep0 path. It already guards the gadget driver suspend/resume callbacks against a NULL ->driver: \tif (dev->gadget.speed != USB_SPEED_UNKNOWN \t\t\t&& dev->driver \t\t\t&& dev->driver->resume) { \t\tspin_unlock(&dev->lock); \t\tdev->driver->resume(&dev->gadget); \t\t... \t} but the very next branch unconditionally dereferences dev->driver when an INT_USBRESET arrives: \tif (stat & INT_USBRESET) { \t\tACK(INT_USBRESET); \t\tINFO(dev, \"USB reset done, gadget %s\\n\", \t\t\tdev->driver->driver.name); \t} If the controller raises INT_USBRESET before any gadget driver has been bound (or after one has been unbound), dev->driver is NULL and the printk dereferences NULL. smatch flags the inconsistency: drivers/usb/gadget/udc/goku_udc.c:1618 goku_irq() error: we previously assumed 'dev->driver' could be null (see line 1607) Fall back to a placeholder when the gadget driver is not bound. No functional change while a gadget driver is bound.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97483", "url": "https://ubuntu.com/security/CVE-2026-97483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: hcd: fix possible deadlock in rh control transfers >From within the SCSI error handler memory allocations must not trigger IO. Handling errors in UAS and the storage driver may involve resetting a device. The thread doing the reset itself relies on VM magic. However, that is insufficient, as resetting a device involves resuming it. Resumption as well as resetting involves conrol transfers to the parent of the device to be reset. That may be a root hub. Hence usbcore must heed the flags passed to usb_submit_urb() processing control transfers to root hubs. The problem exist since the storage driver has been merged.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97484", "url": "https://ubuntu.com/security/CVE-2026-97484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vhci_hcd: fix NULL deref in status_show_vhci platform_get_drvdata() can return NULL if a VHCI host controller's probe failed (e.g. due to USB bus number exhaustion). status_show_vhci() checked for a NULL pdev but not for a NULL hcd returned by platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not return NULL - it returns a pointer offset of 0x260, causing a NULL pointer dereference when that value is subsequently dereferenced. Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move status_show_not_ready() above status_show_vhci() to make it callable from the new error path without a forward declaration.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97485", "url": "https://ubuntu.com/security/CVE-2026-97485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: omfs: handle set_blocksize failures omfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97486", "url": "https://ubuntu.com/security/CVE-2026-97486", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hpfs: handle set_blocksize failures hpfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97487", "url": "https://ubuntu.com/security/CVE-2026-97487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: handle set_blocksize failures jfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97488", "url": "https://ubuntu.com/security/CVE-2026-97488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qnx4: handle set_blocksize failures qnx4 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97489", "url": "https://ubuntu.com/security/CVE-2026-97489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bfs: handle set_blocksize failures bfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the \tBUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97490", "url": "https://ubuntu.com/security/CVE-2026-97490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: affs: handle set_blocksize failures affs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97491", "url": "https://ubuntu.com/security/CVE-2026-97491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Don't sleep inside rds_ib_conn_path_shutdown New rds rdma self tests exposed a hang when tearing down the ib network configs. This is caused by the shutdown worker thread sleeping on the wait_event call, which blocks other work items in the queue. Fix this by changing wait_event to wait_event timeout, and looping until the wait check succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97492", "url": "https://ubuntu.com/security/CVE-2026-97492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed In case reconfiguration of NAN fails, we call ieee80211_handle_reconfig_failure, that marks all interfaces as not in the driver. Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces is called to destroy all the interfaces. If we have any other interface but the NAN one, for example a BSS station, then when its state (links, stations) will be removed, we won't tell the driver about this, because we will think that the interfaces are not in the driver, and then drivers might remain with dangling pointers to objects like stations and links (at least for iwlwifi this is the case). ieee80211_handle_reconfig_failure is meant to be called after we cleaned up the state in the driver, there is no reason to call it for NAN reconfiguration failure. Fix the code to just warn in such a case, as we do in other error paths in reconfig where it is too complicated to rewind.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97502", "url": "https://ubuntu.com/security/CVE-2026-97502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: avoid NULL deref of host->data in IRQ handler mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL: if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; } So we may legitimately reach the rest of the handler with host->data == NULL (and therefore data == NULL). The DATDNE branch already guards against this with an explicit \"if (data != NULL)\" check, but the subsequent TOUTRD (\"read data timeout\") and CRCWR/CRCRD (\"data CRC error\") branches dereference data unconditionally: if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); } if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... } If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this: drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914) Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch. No functional change for callers where data is non-NULL, which is the only case in which these branches did meaningful work before this change.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97506", "url": "https://ubuntu.com/security/CVE-2026-97506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ixp4xx - fix buffer chain unwind on allocation failure chainup_buffers() builds a linked list of buffer descriptors for a scatterlist. If dma_pool_alloc() fails while constructing the list, the current code sets buf to NULL and later dereferences it unconditionally at the end of the function: buf->next = NULL; buf->phys_next = 0; This can lead to a null-pointer dereference on allocation failure. If the failure happens after part of the descriptor chain has already been allocated and DMA-mapped, the partially constructed chain also needs to be released. Fix this by terminating the partially constructed chain on allocation failure and letting the callers unwind it via their existing cleanup paths. Also fix ablk_perform() to preserve the hook pointers before checking for failure, so partially built chains can be freed correctly.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97507", "url": "https://ubuntu.com/security/CVE-2026-97507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dm1105: fix missing error check for dma_alloc_coherent The return value of dm1105_dma_map(), which handles DMA memory allocation, is ignored in dm1105_hw_init(). If dma_alloc_coherent() fails, the driver will proceed using a NULL pointer for DMA transfers, leading to a kernel oops or invalid hardware access. Fix this by checking the return value and propagating -ENOMEM on failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97508", "url": "https://ubuntu.com/security/CVE-2026-97508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Set tb->root_switch to NULL when domain is stopped Similarly what we do with the firmware connection manager. This makes tb_xdp_handle_request() return error to the remote host. However, we need to make sure we keep the uuid alive so that we can reply until the whole domain is released.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97510", "url": "https://ubuntu.com/security/CVE-2026-97510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Release request if tb_cfg_request() fails in __tb_xdomain_response() If tb_cfg_request() fails setting up the request (for example the control channel is shut down already) it returns an error without calling the callback. To avoid leaking that memory, call tb_cfg_request_put() if tb_cfg_request() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-90053", "url": "https://ubuntu.com/security/CVE-2026-90053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_htb: limit htb_classify inner-class filter hops htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent. The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification. htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90054", "url": "https://ubuntu.com/security/CVE-2026-90054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix corruption of urgent data on multi-segment retransmit On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: \t/* tcp_write_xmit() */ \tlimit = mss_now; \tif (tso_segs > 1 && !tcp_urg_mode(tp)) \t\tlimit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: \t/* __tcp_retransmit_skb() */ \tlen = cur_mss * segs;\t\t/* segs > 1, no urg_mode check */ \t... \t/* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: \tseg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) \tseg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) \tseg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90055", "url": "https://ubuntu.com/security/CVE-2026-90055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90056", "url": "https://ubuntu.com/security/CVE-2026-90056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: only stop PTP if it was initialized fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90058", "url": "https://ubuntu.com/security/CVE-2026-90058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai. Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted. Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90062", "url": "https://ubuntu.com/security/CVE-2026-90062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: move hardware offload step after building the chain blob Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90063", "url": "https://ubuntu.com/security/CVE-2026-90063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90067", "url": "https://ubuntu.com/security/CVE-2026-90067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: validate banner payload length When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (`server_feat` and `server_req_feat`). Therefore, `payload_len` must be at least 16 bytes. Fix this by adding a check in `process_banner_prefix()` to reject a `payload_len` smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90068", "url": "https://ubuntu.com/security/CVE-2026-90068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix off-by-one check on the second enum channel The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80x_mux_values. The core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which defaults off.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-93245", "url": "https://ubuntu.com/security/CVE-2026-93245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: policy_int make sure list heads are initialized before fail path If profile create fails before policy_init is complete the list heads are not properly initialized causing profile_free() sanity checks to trigger the following splat. AppArmor WARN aa_policy_destroy: (((!list_empty(&policy->profiles) && (&policy->profiles)->prev != ((void *) 0x122 + (0xdead000000000000UL))))): WARNING: security/apparmor/lib.c:509 at aa_policy_destroy+0x164/0x1b0 security/apparmor/lib.c:509, CPU#0: syz.0.17/5541 Modules linked in: CPU: 0 UID: 0 PID: 5541 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:aa_policy_destroy+0x16b/0x1b0 security/apparmor/lib.c:509 Code: 85 ed 7e 4d e8 96 bc 37 fd 5b 41 5c 41 5e 41 5f 5d e9 19 27 4e 07 cc e8 83 bc 37 fd 48 8d 3d 0c f0 d3 0b 48 c7 c6 a4 eb 38 8e <67> 48 0f b9 3a e9 04 ff ff ff e8 66 bc 37 fd 48 8d 3d ff ef d3 0b RSP: 0018:ffffc9000345eaa0 EFLAGS: 00010293 RAX: ffffffff848f530d RBX: ffff88803f734800 RCX: ffff88801af2a580 RDX: 0000000000000000 RSI: ffffffff8e38eba4 RDI: ffffffff90634320 RBP: 0000000000000000 R08: 0000000000000cc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d95913 R12: dead000000000122 R13: ffff88803f734800 R14: ffff88803f734828 R15: dffffc0000000000 FS: 00007f5f6a1836c0(0000) GS:ffff88808c519000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d02407b048 CR3: 0000000012aa9000 CR4: 0000000000352ef0 Call Trace: aa_free_profile+0x9d/0x9f0 security/apparmor/policy.c:334 aa_alloc_profile+0x1e4/0x3e0 security/apparmor/policy.c:416 unpack_profile security/apparmor/policy_unpack.c:1153 [inline] aa_unpack+0x17db/0x7430 security/apparmor/policy_unpack.c:1748 aa_replace_profiles+0x226/0x2a20 security/apparmor/policy.c:1183 policy_update+0x234/0x4a0 security/apparmor/apparmorfs.c:505 profile_load+0x1cb/0x320 security/apparmor/apparmorfs.c:522 vfs_write+0x296/0xba0 fs/read_write.c:685 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f6939e0d9 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:00007f5f6a183028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f5f69625fa0 RCX: 00007f5f6939e0d9 RDX: 0000000000000041 RSI: 0000200000000400 RDI: 0000000000000003 RBP: 00007f5f6a183090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f5f69626038 R14: 00007f5f69625fa0 R15: 00007ffe23725c18", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90070", "url": "https://ubuntu.com/security/CVE-2026-90070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Return zero on status read failure st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or error path instead of acting on an invalid status value. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90071", "url": "https://ubuntu.com/security/CVE-2026-90071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: restore skb->dev on the slave failure path teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90072", "url": "https://ubuntu.com/security/CVE-2026-90072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90073", "url": "https://ubuntu.com/security/CVE-2026-90073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare \"tc qdisc add ... hhf\" succeeds with a clamped quantum but \"tc qdisc add ... hhf limit 1000\" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90074", "url": "https://ubuntu.com/security/CVE-2026-90074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp default quantum to avoid signed overflow fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90075", "url": "https://ubuntu.com/security/CVE-2026-90075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_codel: clamp default quantum and mtu fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests \"*backlog <= params->mtu\"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memory_limit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double psched_mtu() call. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90078", "url": "https://ubuntu.com/security/CVE-2026-90078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: fix length calculations and avoid invalid header warnings syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act(): !skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55 There are a few issues in tcf_skbmod_act(): 1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets). Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90081", "url": "https://ubuntu.com/security/CVE-2026-90081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in rds_cong_map_updated() rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-89780", "url": "https://ubuntu.com/security/CVE-2026-89780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: restore skb->dev on deaggregated frames rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89789", "url": "https://ubuntu.com/security/CVE-2026-89789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets().", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90088", "url": "https://ubuntu.com/security/CVE-2026-90088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90102", "url": "https://ubuntu.com/security/CVE-2026-90102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: key the data server cache on the NFS version nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4. Two deviceids on one address with different ds_versions[0].version therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL. Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90103", "url": "https://ubuntu.com/security/CVE-2026-90103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix LAYOUTSTATS send buffer exhaustion encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that. ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for. The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held. Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90107", "url": "https://ubuntu.com/security/CVE-2026-90107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free pending qentry in smc_llc_flow_stop() before memset smc_llc_flow_stop() resets a flow struct with a blind memset: \tspin_lock_bh(&lgr->llc_flow_lock); \tmemset(flow, 0, sizeof(*flow)); \tflow->type = SMC_LLC_FLOW_NONE; \tspin_unlock_bh(&lgr->llc_flow_lock); If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object. A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct. Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90114", "url": "https://ubuntu.com/security/CVE-2026-90114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: Reject descending VLAN tunnel ranges A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90126", "url": "https://ubuntu.com/security/CVE-2026-90126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf8563: fix clock provider leak on unbind pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference. The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90128", "url": "https://ubuntu.com/security/CVE-2026-90128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: fix wrong list iterated in add_direct_chain error path In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89779", "url": "https://ubuntu.com/security/CVE-2026-89779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate ef->size covers the record's name and value When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to cover it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89781", "url": "https://ubuntu.com/security/CVE-2026-89781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read in read_log_rec_buf() read_log_rec_buf() copies a log record into a caller buffer starting at \tu32 off = lsn_to_page_off(log, lsn) + log->record_header_len; log->record_header_len (and log->data_off, used for the following pages) comes verbatim from the on-disk restart area and is only checked for 8-byte alignment in is_rst_area_valid(), so off can exceed log->page_size. \"tail = log->page_size - off\" then underflows and memcpy() reads past the page_size-sized buffer returned by read_log_page(), spilling adjacent slab memory into the replay buffer. This is reachable by mounting a crafted NTFS image: BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580 Read of size 64 at addr ffff88800a877ff8 by task exploit/127 read_log_rec_buf fs/ntfs3/fslog.c:2299 log_replay fs/ntfs3/fslog.c:4216 ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324 ntfs_fill_super fs/ntfs3/super.c:1392 get_tree_bdev_flags fs/super.c:1694 __x64_sys_mount fs/namespace.c:4360 The buggy address is located 4088 bytes to the right of the 4096-byte region [ffff88800a876000, ffff88800a877000) Reject an in-page offset outside the current page before the copy. [almaz.alexandrovich@paragon-software.com: replaced the >= sign with >]", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90140", "url": "https://ubuntu.com/security/CVE-2026-90140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cuse: wait for pending RCU callbacks on module exit Since commit 053fc4f755ad (\"fuse: fix UAF in rcu pathwalks\"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory: userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text! The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour). Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90141", "url": "https://ubuntu.com/security/CVE-2026-90141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix integer overflow in ftp helper port/address parsing ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16 (hport) and into unsigned char (p[]) without checking for overflow. A crafted FTP PASV/EPSV response with an over-long port or address octet wraps the value, so the helper configures the data connection with a truncated port/address. The netfilter conntrack FTP helper had the same defect, fixed in commit 2b413fc689ba (\"netfilter: nf_conntrack_ftp: avoid u16 overflows\"). Apply the equivalent fix here: widen the port accumulator to u32 and reject values above 65535, and reject address octets above 255.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90143", "url": "https://ubuntu.com/security/CVE-2026-90143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: kcm: Hold RCU read lock while running BPF parser kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser program. Hold the RCU read lock while running the program.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90151", "url": "https://ubuntu.com/security/CVE-2026-90151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: remove callback IDR entry on client allocation failure nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown. A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it. Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client. This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90157", "url": "https://ubuntu.com/security/CVE-2026-90157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative optlen in cgroup getsockopt hook A cgroup getsockopt BPF program can shrink ctx->optlen after the kernel getsockopt handler has run. The kernel-buffer variant, used by TCP_ZEROCOPY_RECEIVE, only rejects values larger than the original length. If BPF writes a negative optlen, that value is accepted and propagated back to the TCP getsockopt code. It can then be passed to copy_to_sockptr() as a size_t and trigger the hardened usercopy bytes > INT_MAX warning. Reject negative ctx.optlen in __cgroup_bpf_run_filter_getsockopt_kern(), matching the lower-bound validation already present in the sockptr-based getsockopt hook.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90160", "url": "https://ubuntu.com/security/CVE-2026-90160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lwt_bpf: Restore reserved headroom after xmit program ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output. That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise. On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb. Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90198", "url": "https://ubuntu.com/security/CVE-2026-90198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix use-after-free in snd_card_do_free() A use-after-free was detected in snd_card_do_free() when a sound card managed by devres is unbound while a user-space application still holds an open file descriptor. For managed cards, the memory is allocated using devres_alloc(), and its release function is set to __snd_card_release(), which calls snd_card_free(). When the device is unbound, the unbind thread calls snd_card_free(), which drops a reference to the card's device. If the user thread still has an open file descriptor, the reference count does not reach zero, and the unbind thread blocks on wait_for_completion(&released). When the user thread closes the file descriptor, it drops the final reference, invoking the device release callback release_card_device(), which calls snd_card_do_free(). snd_card_do_free() performs cleanup and calls complete(card->release_completion). This wakes up the unbind thread, which returns from snd_card_free() and __snd_card_release(). The devres core then immediately frees the memory block containing the snd_card structure. Meanwhile, the user thread continues execution in snd_card_do_free() and evaluates `if (!card->managed)`. It reads the `managed` boolean from the snd_card structure that was just freed by the unbind thread, triggering a KASAN use-after-free. Fix this by caching the value of card->managed in a local variable before calling complete(). This ensures that the card pointer is not dereferenced after the unbind thread has been woken up and potentially freed the card. BUG: KASAN: use-after-free in snd_card_do_free sound/core/init.c:604 [inline] BUG: KASAN: use-after-free in release_card_device+0x1ab/0x1b0 sound/core/init.c:153 Read of size 1 at addr ffff8881912ec909 by task syz-executor130/5857 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description+0x55/0x1e0 mm/kasan/report.c:378 print_report+0x58/0x70 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 snd_card_do_free sound/core/init.c:604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c:153 device_release+0xc4/0x1f0 drivers/base/core.c:-1 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x222/0x550 lib/kobject.c:737 snd_card_file_remove+0x331/0x390 sound/core/init.c:1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c:2986 __fput+0x418/0xa50 fs/file_table.c:512 fput_close_sync+0x11f/0x240 fs/file_table.c:617 __do_sys_close fs/open.c:1511 [inline] __se_sys_close fs/open.c:1496 [inline] __x64_sys_close+0x7e/0x110 fs/open.c:1496 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90202", "url": "https://ubuntu.com/security/CVE-2026-90202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers _base_release_memory_pools() unconditionally frees every ioc->pcie_sg_lookup[] entry, including ones the setup loop never allocated after a partial failure, causing a \"bad dma\" warning on debug kernels or a NULL pointer dereference otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90203", "url": "https://ubuntu.com/security/CVE-2026-90203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check block offset is not negative If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93252", "url": "https://ubuntu.com/security/CVE-2026-93252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix circular locking dependency in ocfs2_init_acl() A lockdep warning indicates a circular locking dependency between `&oi->ip_xattr_sem` and `&journal->j_trans_barrier`: WARNING: possible circular locking dependency detected is trying to acquire lock: (&oi->ip_xattr_sem){++++}-{4:4}, at: ocfs2_init_acl+0x2fd/0x7e0 fs/ocfs2/acl.c:367 but task is already holding lock: (&journal->j_trans_barrier){.+.+}-{4:4}, at: ocfs2_start_trans+0x3ab/0x700 fs/ocfs2/journal.c:369 The deadlock involves two code paths: Path 1 (setxattr) where `ocfs2_xattr_set()` acquires `ip_xattr_sem` (write) and then starts a transaction, which acquires `j_trans_barrier` (read); and Path 2 (mkdir/mknod) where `ocfs2_mknod()` starts a transaction (`j_trans_barrier` read) and then calls `ocfs2_init_acl()`, which attempts to acquire `ip_xattr_sem` (read) on the parent directory to retrieve the default ACL. Because rw_semaphores are subject to writer priority, a pending writer on `j_trans_barrier` (e.g., the journal commit thread) can cause Path 1 to block, while Path 2 is blocked waiting for Path 1 to release `ip_xattr_sem`. The patch fixes the lock ordering by precomputing the ACL state before starting the OCFS2 transaction, while preserving POSIX ACL storage semantics and the existing inode/security initialization order. By reading the parent directory's default ACL and preparing the new inode's ACLs outside the transaction, `ip_xattr_sem` is always acquired before `j_trans_barrier`. `struct ocfs2_acl_state` encapsulates the prepared ACL state, while `ocfs2_acl_init_prepare()` and `ocfs2_acl_init_release()` avoid code duplication between `ocfs2_mknod()` and `ocfs2_init_security_and_acl()`. `ocfs2_calc_xattr_init()` and `ocfs2_init_acl()` use this precomputed state, removing internal `ip_xattr_sem` acquisition and redundant disk reads. Additionally, remove the `ip_xattr_sem` acquisition from `ocfs2_xattr_set_handle()`. This function is only used while initializing a new inode that has not yet been inserted into the inode hash or attached to a dentry, meaning there is no risk of concurrent access and the lock is unnecessary.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90209", "url": "https://ubuntu.com/security/CVE-2026-90209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/debug: Fix deadlock during unregister Unregistering an s390dbf debug area while one of the associated debugfs files is being written to can cause a deadlock: $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs write debugfs_file_get() debug_unregister() mutex_lock(debug_mutex) debugfs_remove() wait for debugfs_file_put() debug_file_ops.write() debug_input() mutex_lock(debug_mutex) ==> DEADLOCK Fix this by splitting debug_unregister() into an s390dbf and debugfs part, and running only the s390dbf part with debug_mutex locked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90214", "url": "https://ubuntu.com/security/CVE-2026-90214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: fix stream_data leak on open error In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream. Free stream_data and clear the stream pointer on the error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90216", "url": "https://ubuntu.com/security/CVE-2026-90216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubi: Fix rollback for explicit UBI device numbers ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90218", "url": "https://ubuntu.com/security/CVE-2026-90218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix WARNING in res_to_rt syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via addr_handler() during asynchronous address resolution: \" WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ib_addr process_one_req RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c:624 process_one_work kernel/workqueue.c:3375 [inline] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c:3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 \" In addr_handler(), cma_acquire_dev_by_src_ip() is called to populate id_priv->cma_dev and bind the associated ib_device to id_priv->id.device. If cma_acquire_dev_by_src_ip() returns an error (non-zero status), the ID remains unassociated with any RDMA device. Previously, rdma_restrack_add(&id_priv->res) was invoked unconditionally even when cma_acquire_dev_by_src_ip() failed, passing a resource with a NULL dev pointer and triggering the WARN_ON assertion in res_to_rt(). Fix this by only adding the resource to restrack when acquiring the device succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90219", "url": "https://ubuntu.com/security/CVE-2026-90219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Free debugfs on registration failure c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev. Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90221", "url": "https://ubuntu.com/security/CVE-2026-90221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing nci_core_init_rsp_packet_v1() and nci_core_init_rsp_packet_v2() parse the CORE_INIT_RSP packet without validating that the skb contains enough data. A malformed response (e.g. injected via virtual_ncidev) can declare a large num_supported_rf_interfaces while providing insufficient data, causing reads of uninitialized slab memory. This is later used in nci_init_complete_req(), triggering a KMSAN uninit-value warning. Add skb length checks before accessing packet fields: - Validate the skb has at least 1 byte for the status field. - Validate the skb can hold the fixed-size header before parsing. - In v2, bounds-check each variable-length rf_interface entry and its extension parameters within the parsing loop. - In v1, verify the skb is large enough for both the variable-length rf_interfaces array and the trailing rsp_2 structure.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90222", "url": "https://ubuntu.com/security/CVE-2026-90222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: hold a reference to the request skb during send_frame __pn533_send_async() publishes the command and then calls dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame can be matched to this command: the I2C threaded IRQ runs pn533_recv_frame(), which queues cmd_complete_work, and pn533_send_async_complete() frees cmd->req with consume_skb(). On the I2C transport, pn533_i2c_send_frame() still dereferences the same skb after i2c_master_send() returns, so a completion that races the send can free the skb while the transport is still using it. The request skb is owned by the command object and may be freed by command completion at any time after dev->cmd is published, so the transport send path must not assume it stays alive. Hold a temporary reference to the request skb across the send_frame() call so the transport always sees a live skb even if completion races the send. Add a pn533_send_cmd_frame() helper and use it from all three send paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90223", "url": "https://ubuntu.com/security/CVE-2026-90223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound SNL TLV parsing to the skb and add length checks nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed: - For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made \"service_name_len = length - 1\" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90224", "url": "https://ubuntu.com/security/CVE-2026-90224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix double completion race in nci_data_exchange_complete nci_close_device() and nci_rx_work can both call nci_data_exchange_complete() concurrently. After commit 4527025d440ce8 (\"nfc: nci: fix circular locking dependency in nci_close_device\") moved flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock), rx_work is no longer serialized with the explicit completion call in the close path. Both callers read the non-NULL callback pointer and invoke rawsock_data_exchange_complete(), which calls sock_put() -- but only one sock_hold() was taken, so the second sock_put() underflows the refcount and frees the socket while it is still in use. Replace the bare clear_bit(NCI_DATA_EXCHANGE) with test_and_clear_bit() so that only the first caller proceeds to invoke the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90225", "url": "https://ubuntu.com/security/CVE-2026-90225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: read llcp_sock->local under the socket lock in getsockopt nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and then dereferenced the cached pointer inside the locked region. llcp_sock_bind() assigns and clears llcp_sock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on lock_sock(), and then dereference a freed nfc_llcp_local once bind() has unwound. Move the llcp_sock->local read and the NULL check inside the lock_sock(sk) region so bind() cannot mutate or free the pointer between the load and the use.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90226", "url": "https://ubuntu.com/security/CVE-2026-90226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: avoid userspace overflow on invalid optlen nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90228", "url": "https://ubuntu.com/security/CVE-2026-90228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() When a host issues an Identify command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89784", "url": "https://ubuntu.com/security/CVE-2026-89784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6 rpcb_register_inet4() and rpcb_register_inet6() store the result of rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL. rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROC_SET encode path: rpcb_register_call() -> rpc_call_sync() -> rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel. The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890) rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910) rpcauth_wrap_req_encode (net/sunrpc/auth.c:745) call_encode (net/sunrpc/clnt.c:1966) __rpc_execute (net/sunrpc/sched.c:952) rpc_run_task (net/sunrpc/clnt.c:1243) rpc_call_sync (net/sunrpc/clnt.c:1272) rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500) svc_generic_rpcbind_set nfsd_rpcbind_set svc_register svc_setup_socket svc_addsock write_ports nfsctl_transaction_write vfs_write The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFP_KERNEL kstrdup() in rpc_sockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check. Mirror that handling: bail out with -ENOMEM when rpc_sockaddr2uaddr() returns NULL, before the address is fed into the encoder.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90245", "url": "https://ubuntu.com/security/CVE-2026-90245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: kyro: Validate overlay viewport coordinates The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90248", "url": "https://ubuntu.com/security/CVE-2026-90248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: fix teardown of an adopted proto on insert-race loss In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90249", "url": "https://ubuntu.com/security/CVE-2026-90249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes The IIO core does not filter duplicate writes to the event enable attribute, so writing the same value twice invokes write_event_config() twice. Enabling twice leaks a runtime PM reference, preventing the device from ever suspending again; disabling twice underflows the usage count and triggers a \"Runtime PM usage count underflow\" warning. Bail out early when the requested state matches the current state. While at it, switch to pm_runtime_resume_and_get() so a failed resume is propagated to userspace instead of silently marking the event enabled.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90251", "url": "https://ubuntu.com/security/CVE-2026-90251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: \tif (skb->len < sizeof(*rp)) { \t\tbt_dev_err(hdev, \"MSFT supported features length mismatch\"); \t\tgoto failed; \t} evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so \tmsft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, \t\t\t\t GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes (\"skb->len=11 evt_prefix_len=255\", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with \"MSFT event prefix length mismatch\" and msft->evt_prefix is left unset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90257", "url": "https://ubuntu.com/security/CVE-2026-90257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: avoid OOB read of build info string The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read Build Information) and hands the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length. A backend that answers with status only leaves that pointer past the end of the received data, so the walk reads adjacent slab memory until it meets a NUL. Those bytes reach the kernel log and the firmware-info debugfs file. To fix this, print the string with a bounded \"%.*s\" limited to skb->len - 1. A short or unterminated response then prints as much as arrived instead of failing setup. This mirrors commit dd068ef04412 (\"Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()\"), which fixed the identical pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90274", "url": "https://ubuntu.com/security/CVE-2026-90274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: etm4x: fix underflow for usage of (nrseqstate - 1) According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR is implemented only when TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000. IOW, the number of usage in the initialisation or setting TRCSEQEVR with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000. Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR relevant fields setup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90281", "url": "https://ubuntu.com/security/CVE-2026-90281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend Runtime PM must be enabled before creating the PHY, since phy_create() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference. Take a runtime PM usage reference with pm_runtime_get_noresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90283", "url": "https://ubuntu.com/security/CVE-2026-90283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: release subpool on fill_super failure hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size mount options are specified. hugepage_new_subpool() may also reserve huge pages for min_size. If root dentry creation fails after the subpool is created, the failure path frees the subpool with kfree(). This bypasses hugepage_put_subpool() and can leave min_size reservations charged. Use hugepage_put_subpool() on the failure path, matching the normal put_super path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90284", "url": "https://ubuntu.com/security/CVE-2026-90284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: do not queue completed sysfs fallback requests fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to pending_fw_head. device_add() publishes the fallback loading interface, so a userspace helper which discovers the device by scanning sysfs can write 0 to the loading attribute and complete the request before it is queued as pending. In that interleaving firmware_loading_store() calls fw_state_done() while pending_list still points to itself, so it cannot remove an entry from pending_fw_head. The subsequent unconditional list_add() then queues an already-completed fw_priv. Once the request is released, pending_fw_head can retain a pointer to freed memory and the next fallback request can fault while validating the list. Only in-flight fallback requests need suspend or reboot abort handling. If the request is already DONE after device_add(), return success from the fallback path without sending another uevent, waiting again, or queueing it as pending. This preserves the invariant that pending_fw_head contains only active fallback requests.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90285", "url": "https://ubuntu.com/security/CVE-2026-90285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path qla2x00_sysfs_read_vpd() called ha->isp_ops->read_optrom() a second time after releasing optrom_mutex. The repeated read is redundant and, unlike the first, runs without optrom_mutex held, exposing flash access to concurrent optrom operations. Drop the duplicate call.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90286", "url": "https://ubuntu.com/security/CVE-2026-90286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx6: Use PFP on the compute queues too On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90290", "url": "https://ubuntu.com/security/CVE-2026-90290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Restore DAIF state on error Sashiko AI has reported that if swsusp_mte_save_tags() for some reason fails we return from swsusp_arch_suspend() with DAIF being masked - that is not what we'd expect. Restore the saved DAIF state before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93256", "url": "https://ubuntu.com/security/CVE-2026-93256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: mask DAIF before restoring hibernated kernel The arm64 hibernate code manages the exception masking in an unsound way, leading to potential crashes and/or warnings during resume. When a hibernation image is saved in `swsusp_arch_suspend()`, all DAIF exceptions are masked (by virtue of `local_daif_save()`), and the suspended image is saved assuming that all DAIF exceptions will remain masked when the image is restored. When a hibernation image is resumed by `swsusp_arch_resume()`, only interrupts are masked (by virtue of `local_irq_disable()` in `resume_target_kernel()`). When pseudo-NMI is enabled the DAIF.IF bits will be clear, and regardless of pseudo-NMI the DAIF.DA bits will be clear. This means that there are two problems: (1) It is possible to take Debug, SError, or pseudo-NMI exceptions during the resume process. This is unsafe, as during the resume process both the old ane new kernels will tranisently be in an inconsistent state, and swsusp_arch_suspend_exit() won't retain an executable mapping of any exception vectors. Any exception taken here will be fatal and silent. (2) When re-entering the resumed kernel, some DAIF bits will be clear unexpectedly. This permits Debug, SError, or pseudo-NMI exceptions to be taken for a short period while the resumed kernel is not yet in a consistent state. This is detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING. Avoid these issues by masking all DAIF exceptions during resume.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90292", "url": "https://ubuntu.com/security/CVE-2026-90292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix use-after-free in siw_accept() siw_accept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it. The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association. Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90293", "url": "https://ubuntu.com/security/CVE-2026-90293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: post the full-feature receive buffers after session registration isert_put_login_tx() posts the full-feature receive buffers before __transport_register_session() runs, so an initiator that does not wait for the final Login Response can still have a SCSI command executed against an se_session whose se_tpg is NULL - the same oops as the previous patch, at target_submit+0xbe. Post them from isert_get_rx_pdu(), which the previous patch already uses to send that response, and post them before that send: the receive queue is filled at the moment the initiator is told it may use it. Allocating there keeps the existing property that a memory allocation failure cannot happen once the final Login Response is on the wire. The receive queue is already empty between the final Login Request and isert_post_recvm(); this moves the second point later, from a median of 92 us to 172 us over 1200 logins. Only an initiator that sends before it has been told to can reach that window, and on IB and RoCE its send is retried there until the buffers appear - isert_rdma_accept() asks for rnr_retry_count = 7. iWARP has no RNR flow control, so there the same send terminates the connection instead. Measured over rxe, 400 login cycles per run, with an initiator that does not wait: an instrumented build counted no entries to isert_recv_done() before the buffers are posted in 10 runs, where that initiator oopsed 8 of 10 unpatched runs and 5 of 10 with only the previous patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90294", "url": "https://ubuntu.com/security/CVE-2026-90294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: delay the final Login Response until the session is registered isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90295", "url": "https://ubuntu.com/security/CVE-2026-90295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: \timx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), \t\t\t\t GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90296", "url": "https://ubuntu.com/security/CVE-2026-90296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix devres accumulation across driver rebind imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system. Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver(). That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release. Tested by rebinding the driver on qemu's mcimx6ul-evk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90297", "url": "https://ubuntu.com/security/CVE-2026-90297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: crtc: Propagate layer initialization error sun4i_crtc_init() returns plain NULL when layer initialization fails, while all its other error paths return an error pointer. The only caller, sun4i_tcon_bind(), checks the result with IS_ERR() and happily continues with tcon->crtc set to NULL. sun4i_rgb_init() and sun4i_lvds_init() then dereference it in drm_crtc_mask(), which oopses. Return the error pointer instead.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90298", "url": "https://ubuntu.com/security/CVE-2026-90298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: tcon: Drop TCON TOP device reference of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90302", "url": "https://ubuntu.com/security/CVE-2026-90302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: synchronize heartbeat callbacks with o2net teardown Patch series \"ocfs2: harden heartbeat teardown races\". This series fixes two OCFS2 heartbeat/o2net teardown races found by KASAN. This patch (of 2): Heartbeat callbacks stay registered while configfs local-node teardown enters o2net_stop_listening(). A node-down event can still run through o2net_disconnect_node() and o2net_set_nn_state() while teardown is destroying o2net_wq, so the later queue/flush operations can hit a dead workqueue. KASAN has caught this as a slab-use-after-free in __queue_work() with the call chain: KASAN slab-use-after-free in __queue_work+0x56/0xa90 Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __queue_work+0x56/0xa90 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __queue_delayed_work+0x58/0x1e0 queue_delayed_work_on+0xb4/0xc0 o2net_set_nn_state+0x467/0x840 o2net_disconnect_node+0x7b/0xe0 o2net_hb_node_down_cb+0x54/0x60 o2hb_run_event_list+0x236/0x2d0 o2hb_check_slot+0xad4/0xbc0 lock_release+0xc8/0x290 o2hb_check_slot+0x9ea/0xbc0 trace_hardirqs_on+0x18/0x130 o2hb_do_disk_heartbeat+0x646/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) __lock_acquire+0x466/0x2260 lockdep_hardirqs_on_prepare+0xea/0x1a0 ktime_get_with_offset+0xe9/0x230 o2hb_thread+0x14e/0x770 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 __switch_to+0x2e9/0x730 ret_from_fork_asm+0x1a/0x30 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x292/0x760 __alloc_workqueue+0x736/0xc60 alloc_workqueue_noprof+0xb1/0x110 o2net_start_listening+0xe5/0x430 o2nm_node_local_store+0x184/0x310 configfs_write_iter+0x18a/0x210 vfs_write+0x469/0x810 ksys_write+0xd2/0x170 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 rcu_core+0x4f4/0x1320 handle_softirqs+0x156/0x660 queue_delayed_work_on o2net_set_nn_state o2net_disconnect_node o2net_hb_node_down_cb o2hb_run_event_list Keep heartbeat callbacks registered so quorum state still tracks node state, but stop them from driving o2net reconnect/disconnect work once local teardown starts. Mark the transport offline before destroying o2net_wq, wait for any in-flight heartbeat callback to finish, and delay bring-up replay until the new local node is published through o2nm_this_node(). The replay also has to stay serialized with heartbeat callback delivery. Otherwise a live-node snapshot can be copied, a real hb_down callback can install -ENOTCONN for a peer, and the stale replay can call o2net_hb_node_up() for that same peer and queue reconnect work even though heartbeat is already down. The buggy scenario involves two paths, with each column showing the order within that path: local-node teardown: heartbeat node-down callback: 1. configfs local-off enters 1. o2hb_run_event_list() invokes o2net_stop_listening(). o2net_hb_node_down_cb(). 2. teardown heads for 2. the callback reaches destroy_workqueue(o2net_wq). o2net_disconnect_node() and o2net_set_nn_state(). 3. teardown destroys and NULLs 3. the callback flushes or queues o2net_wq. work through o2net_wq.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90303", "url": "https://ubuntu.com/security/CVE-2026-90303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults When CONFIG_DEBUG_USER=y, and cmdline \"user_debug=31\" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the \"oops\" state, acquiring a lock may risk a deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90307", "url": "https://ubuntu.com/security/CVE-2026-90307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it: BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8) Without KASAN the returned bytes are whatever is next in the slab. One run returned \".strtab\". rsp->data[3] in srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90314", "url": "https://ubuntu.com/security/CVE-2026-90314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression \"table_sz - offset - sizeof(*hdr)\", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90316", "url": "https://ubuntu.com/security/CVE-2026-90316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/omap: dsi: Do not copy isr table To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90318", "url": "https://ubuntu.com/security/CVE-2026-90318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: release buffer head after rebuilding parent fat_scan_logstart() leaves the matching directory entry's buffer head in sinfo.bh for the caller to release, just like fat_scan(). fat_rebuild_parent() uses the directory entry to rebuild the parent inode for the nostale_ro NFS export path, but does not release sinfo.bh after a successful scan. Release it once fat_build_inode() has consumed the directory entry data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90319", "url": "https://ubuntu.com/security/CVE-2026-90319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: clear mport->net when rio_add_net() fails rio_alloc_net() stores the newly allocated rio_net in mport->net before rio_scan_alloc_net() registers the device. If rio_add_net() fails, rio_scan_alloc_net() drops the device reference with put_device(), which releases the rio_net through the device release callback. However, mport->net is left pointing at the freed object. A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rio_net again. Clear mport->net in the rio_add_net() failure path, matching the cleanup done for the destID table allocation failure path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90327", "url": "https://ubuntu.com/security/CVE-2026-90327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: do not write beyond optlen in getsockopt pep_getsockopt() clamps the reported length to the caller's buffer with min_t(), but then stores the value with put_user(val, (int __user *) optval), which always writes sizeof(int) bytes. A getsockopt() call with an optlen smaller than sizeof(int) thus reports the clamped length yet writes a full int, one to three bytes past the user buffer. Write the value with copy_to_user() bounded by len, so at most optlen bytes are copied, matching the length reported back to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90329", "url": "https://ubuntu.com/security/CVE-2026-90329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: synchronize input before cleaning up a failed probe hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90334", "url": "https://ubuntu.com/security/CVE-2026-90334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: clear cdev pointer after cdev_add() failure tty_cdev_add() drops the cdev reference when cdev_add() fails, but leaves driver->cdevs[index] pointing to freed memory. tty_unregister_device() later passes that stale pointer to cdev_del(), causing a use-after-free. Clear the slot after dropping the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90341", "url": "https://ubuntu.com/security/CVE-2026-90341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: coreboot: Validate table bounds The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90348", "url": "https://ubuntu.com/security/CVE-2026-90348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90360", "url": "https://ubuntu.com/security/CVE-2026-90360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: use system_freezable_wq for init complete work schedule_delayed_work() uses system_wq, which is non-freezable, allowing regulator_init_complete_work to run concurrently with system suspend. This work fires ~30s after boot to disable unused regulators via I2C. When it races with PM suspend, the I2C adapter may already be suspended, triggering a -ESHUTDOWN warning in __i2c_transfer(): WARNING: ... at __i2c_transfer+0x36c/0x3c8 Call trace: __i2c_transfer i2c_transfer regmap_i2c_write _regmap_update_bits regulator_disable_regmap _regulator_do_disable regulator_late_cleanup regulator_init_complete_work_function process_one_work Switch to system_freezable_wq so the work is frozen before any device is suspended, eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90361", "url": "https://ubuntu.com/security/CVE-2026-90361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix leak in ath11k_service_ready_ext_event() Currently, during ath11k_service_ready_ext_event() processing, svc_rdy_ext.mac_phy_caps can be allocated during TLV parsing. This is a temporary allocation that is freed on the success path, but not on the error path. If parsing succeeds far enough to allocate mac_phy_caps and then fails on a later TLV, the allocation leaks. So free the allocation on the error path. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90362", "url": "https://ubuntu.com/security/CVE-2026-90362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Drop dev_pm_opp_set_rate(0) dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Drop the explicit call to it. Every call site of ops->link_clk_disable() is followed by pm_runtime_put(), so the power vote will be rescinded if deemed safe. Patchwork: https://patchwork.freedesktop.org/patch/742783/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90372", "url": "https://ubuntu.com/security/CVE-2026-90372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss If a peer's VHT/HE MCS map has no supported spatial stream (all fields 0x3), the loop exits with nss == 0 and the function returned (u8)-1 (255), which was then written into the firmware sta_rec_bf beamforming fields. Clamp the result to 0.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90378", "url": "https://ubuntu.com/security/CVE-2026-90378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt792x: Fix memory leak in SDIO TX path When tx_prepare_skb() returns an error in the SDIO TX path, the skb is not freed, leading to a memory leak. This can occur when zero-length frames (such as WNM NULL frames) are dropped to prevent potential hardware TX hangs. Fix this by properly releasing the skb with ieee80211_tx_status_ext() when tx_prepare_skb() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90382", "url": "https://ubuntu.com/security/CVE-2026-90382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set. Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf (\"mt76x2: remove some harmless WARN_ONs in tx status and rx path\") did for the neighboring rx and tx status paths. Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93261", "url": "https://ubuntu.com/security/CVE-2026-93261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/lockdep: Fix NULL pointer dereference in __lock_set_class() register_lock_class() can return NULL when the lock class pool is exhausted, graph_lock() fails, or key validation fails. However, __lock_set_class() uses the return value directly in pointer arithmetic without a NULL check: class = register_lock_class(lock, subclass, 0); hlock->class_idx = class - lock_classes; If class is NULL, this computes a wild offset that corrupts hlock->class_idx. The subsequent reacquire_held_locks() call will invoke hlock_class() with this corrupted index, leading to a NULL or out-of-bounds pointer dereference. Add the missing NULL check, consistent with how __lock_acquire() already handles this case at the same call site.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93283", "url": "https://ubuntu.com/security/CVE-2026-93283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix device_register() error path When device_register() fails in i3c_master_register_new_i3c_devs(), put_device() is called to drop the reference taken by device_register(). That drops the last reference, so the device's release callback i3c_device_release() runs and frees the i3c_device. Two problems follow from that: i3c_device_release() does WARN_ON(i3cdev->desc), so it warns because desc->dev->desc still points back at the descriptor. Clear it before calling put_device(). After put_device() frees the i3c_device, desc->dev is left pointing at freed memory, so clear desc->dev as well. That prevents, for example, i3c_master_unregister_i3c_devs() seeing desc->dev as non-NULL and dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90386", "url": "https://ubuntu.com/security/CVE-2026-90386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90388", "url": "https://ubuntu.com/security/CVE-2026-90388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Check atomic pool allocation result directly The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90391", "url": "https://ubuntu.com/security/CVE-2026-90391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone dmirror_fault() is called from the dmirror_read() and dmirror_write() retry loops after dmirror_do_read() or dmirror_do_write() finds a missing device page table entry. If the mirrored mm has already exited, mmget_not_zero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress. Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90393", "url": "https://ubuntu.com/security/CVE-2026-90393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF in bpf_netns_link_update_prog In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90394", "url": "https://ubuntu.com/security/CVE-2026-90394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sc2731_charger: cancel work on remove The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released. Set the platform drvdata used by remove, then cancel the work after unregistering the notifier. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90395", "url": "https://ubuntu.com/security/CVE-2026-90395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: isp1704_charger: cancel work on remove The USB notifier and initial VBUS detection can schedule isp->work. The remove path unregisters the notifier and power supply, but does not wait for queued or running work before tearing down the power supply state. Cancel the work after unregistering the notifier. Do this before unregistering the power supply. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93262", "url": "https://ubuntu.com/security/CVE-2026-93262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5-ppl: fix use-after-free in ppl_do_flush() The loop in ppl_do_flush() continues iterating after calling ppl_io_unit_finished(), touching io->pending_flushes and leading to a use-after-free. Add a break statement to stop the loop once io is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90403", "url": "https://ubuntu.com/security/CVE-2026-90403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix error path in rtl_pci_probe() In the last error path in rtl_pci_probe(), the cleanup functions are skipped due to a wrong goto label. Moreover, the successful call to rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to be reverted. Fix this issue by updating the labels and adding the relevant cleanup functions to the last error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90411", "url": "https://ubuntu.com/security/CVE-2026-90411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request __nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the rsp_iu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmd_iu unmapped and still marked the op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call .exit_request() when .init_request() fails, the cmd_iu mapping is leaked for every op whose rsp_iu mapping fails. Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and returns the error without marking the op idle, so it stays in the FCPOP_STATE_UNINIT state set by the initial memset().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90413", "url": "https://ubuntu.com/security/CVE-2026-90413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject login PDUs declaring more data than was received isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), \tpayload_length = ntoh24(login_req->dlength); \ttmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90414", "url": "https://ubuntu.com/security/CVE-2026-90414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject PDUs declaring more data than was received isert_recv_done() hands each received PDU to the opcode handlers without ever looking at wc->byte_len, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) - out of the fixed-size descriptor: isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len); Because the declared length is never checked against wc->byte_len, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer. Nothing upstream of isert closes this door: - __iscsit_check_dataout_hdr() bounds the inbound payload against conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check. - iscsi_set_connection_parameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsi_check_acceptor_state(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling. - isert never clamps the negotiated value to its own fixed receive descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated. The imm_data_len == data_len path is more than an over-read: it aliases the receive descriptor via sg_set_buf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated. Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN: BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 isert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout() (ib_isert.c:1160), inlined through isert_rx_opcode(). Validate wc->byte_len against the framing in isert_recv_done() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISER_HEADERS_LEN (commit 29e7b925ae6d (\"IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN\")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all. isert reads the data segment from a fixed offset: isert_get_data() returns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum against wc->byte_len bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything furth ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90415", "url": "https://ubuntu.com/security/CVE-2026-90415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: free STAG index when TPT entry write fails write_tpt_entry() allocates a new STAG index with c4iw_get_resource() and bumps stats.stag.cur before programming the entry. When write_adapter_mem() fails, it returns the error without releasing the index or reversing the statistic. No MR is inserted into rhp->mrs, so deregistration never reclaims it, leaking the index until device teardown. Record whether this call allocated the index and, on a failed write, return it to tpt_table and decrement stats.stag.cur. Key the rollback on both the write error and that flag, not the error alone: a non-reset update carries a caller-owned STAG that this call did not allocate and must not free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90416", "url": "https://ubuntu.com/security/CVE-2026-90416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed \"%d\" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as \"-2147483648\\n\" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with \"%u\" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90419", "url": "https://ubuntu.com/security/CVE-2026-90419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent out-of-bounds read in super root block parsing super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90420", "url": "https://ubuntu.com/security/CVE-2026-90420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix infinite loop in nilfs_clean_segments() syzbot reported a hung task in nilfs_transaction_begin(). This occurs because the cleaner ioctl falls into an infinite loop if nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device is remounted as read-only after an I/O error). Currently in nilfs_clean_segments(), if err is non-zero, it logs the error and sleeps but doesn't abort when it encounters a terminal error like -EROFS. This causes the thread to loop forever. Fix this by breaking out of the loop if nilfs_segctor_construct() returns -EROFS. This matches the behaviour in nilfs_segctor_write_out(), which also handles -EROFS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93264", "url": "https://ubuntu.com/security/CVE-2026-93264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Fix PBL chunk length computation On register MR, when creating the PBL, if it's an indirect PBL we create a chunk list to hold the PBL pages pointers. Each chunk is 4KB in size and can hold 510 addresses (EFA_PTRS_PER_CHUNK) and has a 12-byte control buffer at the end of it holding the next chunk's pointer and its length. If the PBL number of pages is a multiple of EFA_PTRS_PER_CHUNK, the calculated last chunk length is wrongly computed as 0, even though that chunk is fully populated with 510 real page pointers. This wrong length is used both to DMA map the chunk and is propagated to the device, causing the device to see the chunk as empty and reject the memory registration. Fix the calculation so it will be performed only if the number of pages isn't a multiple of EFA_PTRS_PER_CHUNK, if it is, its already handled in the above loop correctly. Also prevent out-of-bounds reach in the chunks array in such scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89782", "url": "https://ubuntu.com/security/CVE-2026-89782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject restart table growth beyond U16_MAX entries During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): \trt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90431", "url": "https://ubuntu.com/security/CVE-2026-90431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: Prevent crash handling to race with rproc_del() There's no synchronization between rproc_crash_handler_work() and rproc_del(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues. To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds. In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a \"deleting\" flag is introduced. This is similar to the RPROC_DELETE state that was introduced to ensure that \"start\" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the \"state\" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90434", "url": "https://ubuntu.com/security/CVE-2026-90434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: release zisofs block pointer buffer head zisofs_fill_pages() reads the compressed block pointer table. The error paths release the current buffer_head, the loop also releases the old buffer_head when it advances. However, the success path leaves the last buffer_head referenced. Release it before returning success.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90435", "url": "https://ubuntu.com/security/CVE-2026-90435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix integer overflow of user QP buffer size set_user_buf_size() computes the QP buffer size by left-shifting the user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers. A sufficiently large rq.wqe_cnt causes signed integer overflow, which is undefined behavior, and yields a small or negative buf_size, causing ib_umem_get() to map a buffer smaller than the hardware will actually write into. Replace the shifts and addition with check_shl_overflow() and check_add_overflow(), rejecting invalid user inputs. Moreover, guard the identical shift computing qp->sq.offset in _create_user_qp() before set_user_buf_size() is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92476", "url": "https://ubuntu.com/security/CVE-2026-92476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Initialize completion before requesting IRQ kmb_ocs_aes_probe() requests the device IRQ before initializing irq_completion. Once the handler is registered it can run immediately, and ocs_aes_irq_handler() unconditionally calls complete(). An interrupt in this window would therefore use an uninitialized completion. Initialize the completion before requesting the IRQ, as the sibling OCS HCU and ECC drivers already do.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89785", "url": "https://ubuntu.com/security/CVE-2026-89785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89787", "url": "https://ubuntu.com/security/CVE-2026-89787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check dir entry fits before reading the hash trailer in ext4_search_dir() For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4_DIRENT_HASHES()), at an offset derived from de->name_len. On the sb_no_casefold_compat_fallback() path ext4_match() reads that trailer, but ext4_search_dir()'s by-hand pre-check only tests de->name + de->name_len <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4_DIRENT_HASHES(de) lands past the block end, so ext4_match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object: BUG: KASAN: use-after-free in ext4_match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4_match (fs/ext4/namei.c:1435) ext4_search_dir (fs/ext4/namei.c:1470) __ext4_find_entry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4_lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filename_lookup (fs/namei.c:2842) vfs_statx (fs/stat.c:353) __do_sys_newfstatat (fs/stat.c:538) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4_match(). This is the same bound ext4_check_dir_entry() already enforces via ext4_dir_rec_len(), so no well-formed entry is rejected. The other caller, ext4_find_dest_de(), runs ext4_check_dir_entry() first and is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92494", "url": "https://ubuntu.com/security/CVE-2026-92494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix buffer_head leak in ext4_init_orphan_info ext4_init_orphan_info() reads orphan file blocks with ext4_bread() and stores the returned buffer_head in oi->of_binfo[i].ob_bh. If ext4_bread() succeeds but the orphan block magic or checksum validation fails, the function jumps to out_free. However, the old out_free loop starts releasing buffers from i - 1, so the current buffer_head at index i is skipped. This leaks the buffer_head reference obtained by ext4_bread() on the bad magic and bad checksum error paths. Fix this by tracking the number of successfully read buffer_heads and releasing exactly those buffer_heads on the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92496", "url": "https://ubuntu.com/security/CVE-2026-92496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx() Currently, in ath11k_wmi_tlv_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Add an upfront length check before dereferencing skb->data as a wmi_cmd_hdr. The check is placed before the trace_ath11k_wmi_event() call to preserve the existing trace semantics (tracing the full raw WMI event including the header), unlike the analogous ath12k fix which could use skb_pull_data() directly. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92498", "url": "https://ubuntu.com/security/CVE-2026-92498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: avoid buffer overreads in WMI event handlers The following WMI event handlers currently read from the event buffer without first verifying that the message was large enough to hold the expected event: ath6kl_wmi_scan_complete_rx() ath6kl_wmi_addba_req_event_rx() ath6kl_wmi_delba_req_event_rx() Add length checks to prevent overread.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92501", "url": "https://ubuntu.com/security/CVE-2026-92501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drain in-flight DIO before buffered write fallback generic/746 started failing intermittently on ext3 (no-extent inodes). The test triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO. Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied, post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback) ----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared() iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async) dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0, 8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range() iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages() invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO) This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92504", "url": "https://ubuntu.com/security/CVE-2026-92504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int3400: clean up ODVP on probe failures evaluate_odvp() creates per-ODVP sysfs files before the thermal zone and later probe resources are registered. The current unwind path only calls cleanup_odvp() from the late sysfs failure path, so failures after evaluate_odvp() but before that label, including thermal_tripless_zone_device_register() failures, leave the ODVP files and storage behind. Move the ODVP cleanup to the common ART/TRT unwind path so every failure after evaluate_odvp() releases the ODVP state. Also clear the cached ODVP pointers in cleanup_odvp(), because evaluate_odvp() can already call it for partial setup failures while probe continues.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92508", "url": "https://ubuntu.com/security/CVE-2026-92508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_free_cq() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93268", "url": "https://ubuntu.com/security/CVE-2026-93268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: skip extra isize expansion during mount to prevent deadlock ext4_try_to_expand_extra_isize() is called from __ext4_mark_inode_dirty() while holding an active jbd2 handle. During mount (!SB_ACTIVE), the expand path may move xattrs to external blocks and release ea_inodes via iput(). When !SB_ACTIVE, iput() calls write_inode_now() which acquires s_writepages_rwsem, creating a circular lock dependency: s_writepages_rwsem --> jbd2_handle --> xattr_sem --> s_writepages_rwsem This can be triggered via: ext4_process_orphan() -> ext4_truncate() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() or: ext4_evict_inode() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() Skip expansion when !SB_ACTIVE. This is a minor loss of functionality (extra isize won't grow for these inodes during mount), which e2fsck can resolve later if needed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89786", "url": "https://ubuntu.com/security/CVE-2026-89786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bounds read in ext4_read_inline_dir() ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: \tdir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic \".\" and \"..\" land at their block-dir offsets. A dirent is formed at \"dir_buf + pos - extra_offset\", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92521", "url": "https://ubuntu.com/security/CVE-2026-92521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92522", "url": "https://ubuntu.com/security/CVE-2026-92522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: validate MADT IOAPIC entry bounds The IOAPIC hotplug lookup parses both MADT and _MAT records directly. The MADT walk previously used a subtable's declared length to advance the cursor after only locating a generic header. The _MAT path likewise passed a generic header to the IOAPIC helper. Validate that a current record has a complete generic header, that its declared length is contained in the available record range, and that a typed IOAPIC record contains the full fixed IOAPIC body before reading its fields. Use the same relation for both MADT and _MAT provider paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92524", "url": "https://ubuntu.com/security/CVE-2026-92524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc() When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93037", "url": "https://ubuntu.com/security/CVE-2026-93037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Propagate sdma_txinit_ahg() errors set_txreq_header_ahg() ignores the return value of sdma_txinit_ahg(). If sdma_txinit_ahg() fails, it returns before initializing tx->txreq. However, set_txreq_header_ahg() ignores the error and returns the AHG change count, causing the caller to continue processing the request as though initialization had succeeded. Propagate sdma_txinit_ahg() failures to the caller and abort request processing when initialization fails. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93039", "url": "https://ubuntu.com/security/CVE-2026-93039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: Keep link pointers valid on realloc failure meson_card_reallocate_links() grows the DAI link and private data arrays with two consecutive krealloc() calls and updates the owner pointers only after both calls have succeeded. A successful krealloc() may move the data: it frees the old block and returns a new one. When that happens for the link array and the second krealloc() then fails, card->dai_link still points to the block that krealloc() already freed, and the error path frees the new block too. The probe error path then calls meson_card_clean_references(), which dereferences card->dai_link and kfree()s it again, resulting in a use-after-free and a double free. Commit card->dai_link and card->num_links right after the first krealloc() succeeds, so the pointer always refers to a valid allocation that meson_card_clean_references() can walk and free. krealloc() with __GFP_ZERO zero-initializes the added entries, so walking them on the error path is safe. With both failure paths reduced to a plain return, drop the goto labels and the error message.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93040", "url": "https://ubuntu.com/security/CVE-2026-93040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize channel state checks pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent. For example, pause() can observe EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93041", "url": "https://ubuntu.com/security/CVE-2026-93041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize abort state updates dw_edma_abort_interrupt() drops vc.lock before changing request and status. issue_pending() can acquire the lock in that small window, observe the old busy state, and skip starting queued descriptors. Then the abort handler overwrites the channel status as idle, leaving the new descriptors stranded for good. Keep descriptor completion and the state transition in the same critical section.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93046", "url": "https://ubuntu.com/security/CVE-2026-93046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: software node: Fix software_node_get_reference_args() with index -1 The bounds check for the index passed to software_node_get_reference_args() was failing when passed UINT_MAX, this in turn would lead to an out of bound access in the property array. Fix the bound check to also cover the UINT_MAX case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93048", "url": "https://ubuntu.com/security/CVE-2026-93048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior. Commit 5daa7b21496a (\"mtd: prepare partition add and del functions for ioctl requests\") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e (\"mtd: add a flags for partitions which should just leave smth. after them\") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value. With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers: WARN_ON((!mtd->erasesize || !master->_erase) && \t\t!(mtd->flags & MTD_NO_ERASE)) in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the \"out of reach\" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error. Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93049", "url": "https://ubuntu.com/security/CVE-2026-93049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdswap: Avoid freeing registered blktrans device twice In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice. add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev. The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89777", "url": "https://ubuntu.com/security/CVE-2026-89777", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio_msi_cap_len() lazily allocates the per-device MSI permission table: \tvdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); \tif (!vdev->msi_perm) \t\treturn -ENOMEM; \tret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); \tif (ret) { \t\tkfree(vdev->msi_perm); \t\treturn ret;\t\t/* vdev->msi_perm left dangling */ \t} When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at \"if (vdev->msi_perm) return len;\" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93051", "url": "https://ubuntu.com/security/CVE-2026-93051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ad525x_dpot: use driver core groups for sysfs files ad_dpot_probe() creates per-RDAC sysfs files manually and then optionally creates the command sysfs group. This leaves probe responsible for rolling back partial sysfs state and makes remove responsible for matching every file that probe created. Move the device attributes into driver core dev_groups for the I2C and SPI drivers and use an is_visible() callback to expose only the attributes supported by the probed device. With this shape, the driver core creates the sysfs files only after probe succeeds and removes them before the remove callback frees the driver data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93052", "url": "https://ubuntu.com/security/CVE-2026-93052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: bcm-vk: Use acquire/release for msgq_inited bcm_vk_sync_msgq() fills the message queue information and then sets msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the message queues and their cached queue information. atomic_set()/atomic_read() do not order those accesses. A reader can see msgq_inited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate. Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the gate and does not publish queue state to readers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93053", "url": "https://ubuntu.com/security/CVE-2026-93053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: speakup: keyhelp: guard letter_offsets possible out-of-range indexing help_init() builds letter_offsets[] by using the first byte of each function name as an index via `(start & 31) - 1`. If function_names are overridden from sysfs (root) with a name starting outside [a–z], the index underflows or exceeds the array, leading to OOB write. Function names can be overridden with the following commands as root: modprobe speakup_soft echo \"0 _bad\" > /sys/accessibility/speakup/i18n/function_names # then press Insert+2 on /dev/tty This fix checks the first letter in help_init(), and if it is not in the [a–z] range the function returns an error to the caller. Eventually this error is propagated to drivers/accessibility/speakup/main.c:2217, which causes a bleep sound.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93054", "url": "https://ubuntu.com/security/CVE-2026-93054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same \"device gone\" state as normal uio_unregister_device().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93055", "url": "https://ubuntu.com/security/CVE-2026-93055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: UDF symlink pathComponent header OOB read udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93056", "url": "https://ubuntu.com/security/CVE-2026-93056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: remove broken string configfs attributes The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for the fn_play, fn_cap, and fn_cntl string options. The store function contains an inverted null check on the kstrndup() return value. This means every write attempt returns -ENOMEM on success and dereferences a NULL pointer on allocation failure. The attributes have been broken and unused for many years. Remove the UAC1_STR_ATTRIBUTE macro and the three attributes it generated. The internal defaults (FILE_PCM_PLAYBACK, FILE_PCM_CAPTURE, FILE_CONTROL) set in f_audio_alloc_inst() are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93061", "url": "https://ubuntu.com/security/CVE-2026-93061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Avoid stack over-read in debug output helpers host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93067", "url": "https://ubuntu.com/security/CVE-2026-93067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clamps an AUX read to the payload limit: \tsize_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: \tif (size) \t\tsize = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 (\"drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer\").", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93271", "url": "https://ubuntu.com/security/CVE-2026-93271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate ath11k can receive HT/VHT/HE frames whose reported MCS is above the maximum that can be expressed in the corresponding mac80211 rate space (e.g. an HE frame reported with MCS 12, while HE tops out at MCS 11). The frame itself is valid and decodes correctly, but for such a frame ath11k_dp_rx_h_rate() leaves rx_status->rate_idx set to the out-of-range value and never assigns rx_status->encoding, so it stays RX_ENC_LEGACY from the ath11k_dp_rx_h_ppdu() initialization. Once that frame reaches mac80211 it trips the rate sanity check and the frame is dropped with a splat: ath11k_pci 0000:03:00.0: Received with invalid mcs in HE mode 12 WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:5433 ieee80211_rx_list+0xb0a/0xe90 [mac80211] Dropping the frame would discard otherwise valid data, so instead cap the reported MCS to the maximum the rate space can express and deliver the frame. Set rx_status->encoding before the range check and assign rate_idx from the capped value, so a frame with an out-of-range MCS no longer leaves partial or bogus rate metadata behind. Also downgrade the logging level since they are not treated as invalid frames now. The only loss is that such a frame is reported as the capped MCS in the rx rate statistics. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93095", "url": "https://ubuntu.com/security/CVE-2026-93095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: validate thread record before delete key rebuild hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93098", "url": "https://ubuntu.com/security/CVE-2026-93098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: glink: fix deadlock in endpoint destroy during driver detach During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89778", "url": "https://ubuntu.com/security/CVE-2026-89778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: fix out-of-bounds page array access on empty zisofs block zisofs_uncompress_block()'s empty-block fast path returns pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the decompression path which returns bytes produced relative to poffset. zisofs_fill_pages() uses that return to advance its page cursor, so when the zisofs block size is below PAGE_SIZE and a sub-page block leaves poffset partway into a page, a following empty block over-counts and advances pages[] one element past its end, after which \"if (poffset && *pages)\" reads pages[1] out of bounds. rock.c only rejects a block-size shift > 17, so a crafted \"ZF\" Rock Ridge record can set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a compressed file on such a mounted ISO9660 image. Return the byte count relative to poffset and zero only [poffset, PAGE_SIZE) of the first page, matching the decompression path. The page-aligned case (poffset == 0) is unaffected. BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290) Read of size 8 at addr ffff88800f5eac48 by task exploit/142 zisofs_read_folio (fs/isofs/compress.c:290) read_pages (mm/readahead.c:184) ... filemap_read (mm/filemap.c:2814) vfs_read (fs/read_write.c:574) __x64_sys_pread64 (fs/read_write.c:769) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address is located 0 bytes to the right of the allocated 8-byte region in the kmalloc-8 cache", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93102", "url": "https://ubuntu.com/security/CVE-2026-93102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Free RX data on late probe failure hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning. If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears down the device data without calling hfi1_free_rx(). This leaks netdev_rx and its dummy netdev. Free the RX support after IB unregistration and before postinit_cleanup(), as done on normal device removal.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93103", "url": "https://ubuntu.com/security/CVE-2026-93103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89783", "url": "https://ubuntu.com/security/CVE-2026-89783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use \"sp->len >= XFRM_MAX_DEPTH\", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]'", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93108", "url": "https://ubuntu.com/security/CVE-2026-93108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ipoib: Drain RCU callbacks during module teardown IPoIB reclamation completions can be signaled from inside an RCU callback. Teardown can wake before the callback returns and unload ib_ipoib while its code is still executing. Client registration failure can also remove already-added devices and queue callbacks. Wait after client and workqueue teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93109", "url": "https://ubuntu.com/security/CVE-2026-93109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Drain RCU callbacks during module teardown devx_free_subscription() can remain queued after the last DevX event file drops its module reference or an auxiliary driver detaches its devices. mlx5_ib can then unload before the callback runs. Registration error unwind has the same risk because driver registration can attach existing devices before failing. Wait after all drivers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93110", "url": "https://ubuntu.com/security/CVE-2026-93110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Wait for RCU callbacks before unloading ib_core put_gid_ndev() is queued with call_rcu() and implemented in ib_core. Stopping the workqueues does not drain callbacks already queued, so RCU could invoke it after the module code has been unloaded. synchronize_rcu() does not wait for callbacks. Wait for them after all producers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93114", "url": "https://ubuntu.com/security/CVE-2026-93114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/surface: acpi-notify: Check ACPI companion before use Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 (\"ACPI: driver: Check ACPI_COMPANION() against NULL during probe\") does for the core ACPI platform drivers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93115", "url": "https://ubuntu.com/security/CVE-2026-93115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93120", "url": "https://ubuntu.com/security/CVE-2026-93120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93130", "url": "https://ubuntu.com/security/CVE-2026-93130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix resource leak on module load failure We need to properly clean up the SMBIOS request and the privacy driver when the module load fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93131", "url": "https://ubuntu.com/security/CVE-2026-93131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-privacy: Fix race condition Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93138", "url": "https://ubuntu.com/security/CVE-2026-93138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire(). Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93140", "url": "https://ubuntu.com/security/CVE-2026-93140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 (\"udf: Mark LVID buffer as uptodate before marking it dirty\"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline] vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline] __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93141", "url": "https://ubuntu.com/security/CVE-2026-93141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: r8a66597: avoid double free of ep0_req in probe error path If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL. Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once. Issue found using a prototype static analysis tool and confirmed by code review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93145", "url": "https://ubuntu.com/security/CVE-2026-93145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister() gdsc_unregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pm_genpd_remove() on the individual generic_pm_domain structures registered by gdsc_init(): \tvoid gdsc_unregister(struct gdsc_desc *desc) \t{ \t\tstruct device *dev = desc->dev; \t\tsize_t num = desc->num; \t\tgdsc_pm_subdomain_remove(desc, num); \t\tof_genpd_del_provider(dev->of_node); \t} That leaves dangling entries on the global gpd_list. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdsc_init() will end up trying to re-register a name that is still in the list and pm_genpd_init() returns -EEXIST. While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh of_genpd_get_from_provider() call racing with the teardown could attach to a domain that is mid-removal. Iterate the scs[] array and pm_genpd_remove() each registered domain after the subdomain links are torn down. The regulators stay devm- managed (devm_regulator_get_optional() in gdsc_register()), so the release happens automatically when the underlying device is unbound; just the genpd accounting needs to be undone explicitly.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93278", "url": "https://ubuntu.com/security/CVE-2026-93278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown cvm_oct_rx_shutdown calls free_irq and netif_napi_del without disabling the napi instance first. As the free_irq only waits for completion of hard interrupt handlers, the napi poll function could still be active. If cvm_oct_remove proceeds to free the plat structure (which holds the NAPI instances), the active poll function will access freed memory, resulting in a use-after-free crash.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93279", "url": "https://ubuntu.com/security/CVE-2026-93279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown The TX cleanup tasklet can be scheduled by the watchdog IRQ handler to execute cvm_oct_tx_do_cleanup. There can be a pending tasklet in the queue which might run after the cvm_oct_remove() frees net_device structures, causing a use-after-free in cvm_oct_tx_do_cleanup() as it iterates cvm_oct_device[] which is an array of netdevice pointers. Add tasklet_kill() after free_irq() to ensure the tasklet is no longer scheduled or running before teardown proceeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93280", "url": "https://ubuntu.com/security/CVE-2026-93280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: greybus: audio: bound the topology section sizes against the fetched size gb_audio_gb_get_topology() fetches a topology blob of a module-supplied size, and gbaudio_tplg_parse_data() then walks it by adding the module-supplied size_dais, size_controls and size_widgets fields to form the control, widget and route section offsets. Those le32 sizes are never checked against the fetched blob, so a module reporting a small topology size but large section sizes makes the offsets point past the allocation, and parsing reads out of bounds. Reject a topology whose section sizes do not fit within the fetched size before it is parsed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93151", "url": "https://ubuntu.com/security/CVE-2026-93151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: fix response resource leak on queue teardown When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm \"kworker/2:1H\", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 unreferenced object 0xffff88814bd05e80 (size 64): comm \"kworker/3:1H\", pid 148, jiffies 4295195428 backtrace (crc e35510cb): __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources() that frees up the RDMA read/write context and the request SGLs of such responses.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93158", "url": "https://ubuntu.com/security/CVE-2026-93158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul - stop probe if context pool creation fails sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool. Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93159", "url": "https://ubuntu.com/security/CVE-2026-93159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes. If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated work_data is not usable for producing RNG output and must not remain associated with the hwrng state. Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data. Fix this by freeing the pending work_data. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93160", "url": "https://ubuntu.com/security/CVE-2026-93160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-ecc - reject hardware ECDH without a public key The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm. atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93161", "url": "https://ubuntu.com/security/CVE-2026-93161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - clear AES key schedule from stack qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame. Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93165", "url": "https://ubuntu.com/security/CVE-2026-93165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Fix memory overread in ring handler `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93167", "url": "https://ubuntu.com/security/CVE-2026-93167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: csky: Fix a4/a5 restoration in syscall trace path The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93170", "url": "https://ubuntu.com/security/CVE-2026-93170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93177", "url": "https://ubuntu.com/security/CVE-2026-93177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup vddInd, vddciInd and mvddInd from VBIOS-parsed tables index into vddc, vddci and vddmem lookup tables without bounds checks across nine sites. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93178", "url": "https://ubuntu.com/security/CVE-2026-93178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93274", "url": "https://ubuntu.com/security/CVE-2026-93274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: bcm2835: Don't remove an unregistered GPIO chip If the devm_pinctrl_register() function fails, bcm2835_pinctrl_probe() calls gpiochip_remove() before gpiochip_add_data() has registered the GPIO chip. This means that upon failure the gpio_chip.gpiodev is NULL resulting in a null pointer dereference inside the gpiochip_remove() function. Remove the unnecessary function call to gpiochip_remove(). No GPIO cleanup is required because the GPIO chip has not yet been registered. Without this change there is potential for a kernel panic upon registration failure", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93183", "url": "https://ubuntu.com/security/CVE-2026-93183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/lima: call drm_mm_init() with a valid allocation range lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2: [ 1.736297] ------------[ cut here ]------------ [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931! [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.750697] Modules linked in: [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree) [ 1.769446] Workqueue: events_unbound deferred_probe_work_func [ 1.775261] PC is at drm_mm_init+0x9c/0xa4 [ 1.779339] LR is at lima_vm_create+0x144/0x17c [ ... ] Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93185", "url": "https://ubuntu.com/security/CVE-2026-93185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rt700-sdw: always drain jack work on remove rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93188", "url": "https://ubuntu.com/security/CVE-2026-93188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: bound device-supplied profile index kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93189", "url": "https://ubuntu.com/security/CVE-2026-93189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path (\"hwmon: prevent packets from going to driver for probe\", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93191", "url": "https://ubuntu.com/security/CVE-2026-93191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix incorrect task context in smack_msg_queue_msgrcv The smack_msg_queue_msgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task. In the msgsnd() syscall path, if a receiver is already waiting, the pipelined_send() optimization is used to push the message directly to the receiver task: ipc/msg.c`pipelined_send(): ` smp_store_release(&msr->r_msg, msg) In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->r_tsk, passed as the 'target' parameter): ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, target := msr->r_tsk,,) However, smack_msg_queue_msgrcv() ignores the 'target' and checks 'current': smack_msg_queue_msgrcv(…) ` smk_curacc_msq(isp, MAY_READWRITE); // current task 'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy. Test: 1) create a sysv message queue with label “foo” 2) echo \"bar foo r\" >/smack/load2 3) msgrcv(,,,0,MSG_NOERROR) in \"bar\"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a \"foo\"-labeled task: \"bar\"-labeled task gets the message. This patch fixes the issue by checking permission on the 'target' task instead of 'current'. (2008-02-04, Casey Schaufler)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2025-40123", "url": "https://ubuntu.com/security/CVE-2025-40123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce expected_attach_type for tailcall compatibility Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-89947", "url": "https://ubuntu.com/security/CVE-2026-89947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: meson: align gxbb_32k_clk_sel number of parents with actual count The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c (\"clk: amlogic: gxbb: drop non existing 32k clock parent\") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80671", "url": "https://ubuntu.com/security/CVE-2026-80671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf sched: Fix register_pid() overflow, strcpy, and BUG_ON register_pid() has several issues when processing untrusted perf.data: 1. Integer overflow: (pid + 1) * sizeof(struct task_desc *) can wrap to a small value on 32-bit systems when pid is large (e.g. 0x40000000), causing realloc to return a tiny buffer followed by out-of-bounds writes in the initialization loop. 2. Heap buffer overflow: strcpy(task->comm, comm) copies the untrusted comm string into a fixed 20-byte COMM_LEN buffer with no length check. 3. BUG_ON on allocation failure: perf.data is untrusted input, so allocation failures should be handled gracefully rather than killing the process. 4. Realloc of sched->tasks assigned directly back, leaking the old pointer on failure; nr_tasks incremented before the realloc, leaving corrupted state on failure. Cap pid at PID_MAX_LIMIT (4194304, matching the kernel's maximum on 64-bit), replace strcpy with strlcpy, guard against NULL comm, replace BUG_ON with NULL returns using safe realloc patterns, and add NULL checks in callers that dereference the result.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-93203", "url": "https://ubuntu.com/security/CVE-2026-93203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: avoid CRC corruption due to parallel claim add batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either * add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone But when the \"new\" claim code was running in parallel to the \"change backbone\" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the \"new\" claim code path: * CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point. * CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc. * CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc The CRC is then wrong for both: * claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs. To avoid this, split the functionality in clear separate parts: * new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back) * update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93204", "url": "https://ubuntu.com/security/CVE-2026-93204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: atomically update mac addresses When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2025-22039", "url": "https://ubuntu.com/security/CVE-2025-22039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix overflow in dacloffset bounds check The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl(). This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer. This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.", "cve_priority": "high", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-21651", "url": "https://ubuntu.com/security/CVE-2025-21651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: don't auto enable misc vector Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below: [ 16.324639] Call trace: [ 16.324641] __queue_delayed_work+0xb8/0xe0 [ 16.324643] mod_delayed_work_on+0x78/0xd0 [ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge] [ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge] [ 16.324666] __handle_irq_event_percpu+0x64/0x1e0 [ 16.324667] handle_irq_event+0x80/0x170 [ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc [ 16.324671] __handle_domain_irq+0x84/0xfc [ 16.324673] gic_handle_irq+0x88/0x2c0 [ 16.324674] el1_irq+0xb8/0x140 [ 16.324677] arch_cpu_idle+0x18/0x40 [ 16.324679] default_idle_call+0x5c/0x1bc [ 16.324682] cpuidle_idle_call+0x18c/0x1c4 [ 16.324684] do_idle+0x174/0x17c [ 16.324685] cpu_startup_entry+0x30/0x6c [ 16.324687] secondary_start_kernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]--- So don't auto enable misc vector when request irq..", "cve_priority": "low", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43088", "url": "https://ubuntu.com/security/CVE-2026-43088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: zero aligned sockaddr tail in PF_KEY exports PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE` Fix those paths by clearing only the aligned sockaddr tail after `pfkey_sockaddr_fill()`.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31420", "url": "https://ubuntu.com/security/CVE-2026-31420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: mrp: reject zero test interval to avoid OOM panic br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock. The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames. Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2025-22103", "url": "https://ubuntu.com/security/CVE-2025-22103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix NULL pointer dereference in l3mdev_l3_rcv When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-21649", "url": "https://ubuntu.com/security/CVE-2025-21649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is sent on HIP08 devices Currently, HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL. But the tx process would still try to set hardware time stamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash. [ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge] [ 128.292938] sp : ffff800059b93140 [ 128.297200] x29: ffff800059b93140 x28: 0000000000003280 [ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080 [ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001 [ 128.315969] x23: 0000000000000000 x22: 0000000000000194 [ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000 [ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000 [ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24 [ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000 [ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368 [ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02 [ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0 [ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000 [ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff [ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294 [ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080 [ 128.390626] Call trace: [ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3] [ 128.405468] xmit_one.constprop.0+0xc4/0x200 [ 128.410600] dev_hard_start_xmit+0x54/0xf0 [ 128.415556] sch_direct_xmit+0xe8/0x634 [ 128.420246] __dev_queue_xmit+0x224/0xc70 [ 128.425101] dev_queue_xmit+0x1c/0x40 [ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch] [ 128.435409] do_output+0x60/0x17c [openvswitch] [ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch] [ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch] [ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch] [ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch] [ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch] [ 128.471460] xmit_one.constprop.0+0xc4/0x200 [ 128.476561] dev_hard_start_xmit+0x54/0xf0 [ 128.481489] __dev_queue_xmit+0x968/0xc70 [ 128.486330] dev_queue_xmit+0x1c/0x40 [ 128.490856] ip_finish_output2+0x250/0x570 [ 128.495810] __ip_finish_output+0x170/0x1e0 [ 128.500832] ip_finish_output+0x3c/0xf0 [ 128.505504] ip_output+0xbc/0x160 [ 128.509654] ip_send_skb+0x58/0xd4 [ 128.513892] udp_send_skb+0x12c/0x354 [ 128.518387] udp_sendmsg+0x7a8/0x9c0 [ 128.522793] inet_sendmsg+0x4c/0x8c [ 128.527116] __sock_sendmsg+0x48/0x80 [ 128.531609] __sys_sendto+0x124/0x164 [ 128.536099] __arm64_sys_sendto+0x30/0x5c [ 128.540935] invoke_syscall+0x50/0x130 [ 128.545508] el0_svc_common.constprop.0+0x10c/0x124 [ 128.551205] do_el0_svc+0x34/0xdc [ 128.555347] el0_svc+0x20/0x30 [ 128.559227] el0_sync_handler+0xb8/0xc0 [ 128.563883] el0_sync+0x160/0x180", "cve_priority": "medium", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2023-52676", "url": "https://ubuntu.com/security/CVE-2023-52676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Guard stack limits against 32bit overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904", "cve_priority": "high", "cve_public_date": "2024-05-17 15:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "low", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-90015", "url": "https://ubuntu.com/security/CVE-2026-90015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89816", "url": "https://ubuntu.com/security/CVE-2026-89816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used Commit 1c6ceeee6ebb (\"drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits\") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93234", "url": "https://ubuntu.com/security/CVE-2026-93234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: validate TV mode names before creating enum property The GUD protocol returns TV mode names as fixed-size GUD_CONNECTOR_TV_MODE_NAME_LEN entries and requires each name to be NUL-terminated. gud_connector_add_tv_mode() currently passes each fixed-size entry directly to drm_mode_create_tv_properties_legacy(), which eventually reaches drm_property_add_enum() and strlen(). If a device returns an entry without a terminating NUL byte, strlen() reads past the end of the slot and can run beyond the allocated buffer, triggering an out-of-bounds read. Validate that each returned TV mode name contains a NUL terminator within its fixed-size slot before passing it to the DRM property code. If a malformed entry is found, reject the device response with -EIO. This fixes the out-of-bounds read without changing the handling of valid devices, and avoids silently truncating malformed protocol data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89817", "url": "https://ubuntu.com/security/CVE-2026-89817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: NUL-terminate TV mode names read from the device gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89821", "url": "https://ubuntu.com/security/CVE-2026-89821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid divide-by-zero in __is_lut_linear() __is_lut_linear() computes the expected value of each entry with \texpected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89823", "url": "https://ubuntu.com/security/CVE-2026-89823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: fix race between partial drm_dev_register() failure and ioctl If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89843", "url": "https://ubuntu.com/security/CVE-2026-89843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89845", "url": "https://ubuntu.com/security/CVE-2026-89845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89846", "url": "https://ubuntu.com/security/CVE-2026-89846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: \tif (IS_FWI2_CAPABLE(ha)) { \t\tsense_data += rsp_info_len; \t\tpar_sense_len -= rsp_info_len; \t} rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): \tif (sense_len > par_sense_len) \t\tsense_len = par_sense_len; \tmemcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89847", "url": "https://ubuntu.com/security/CVE-2026-89847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid double completion in async IOCB timeout qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates \"if (sp->comp) complete(sp->comp)\"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93242", "url": "https://ubuntu.com/security/CVE-2026-93242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb() qla24xx_process_response_queue() advances ring_ptr past the head IOCB before dispatching, so by the time __qla_consume_iocb() runs, ring_ptr already points at the first continuation IOCB. The function however looped purex->entry_count times starting at ring_ptr. As entry_count includes the head, this consumed one entry too many: it stamped RESPONSE_PROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked. Mark the head processed and account for it, then consume only the entry_count - 1 continuation IOCBs, matching __qla_copy_purex_to_buffer().", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89849", "url": "https://ubuntu.com/security/CVE-2026-89849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path qla2x00_status_entry() filters out non-TYPE_SRB entries and the SRB_NVME_CMD, SRB_BIDI_CMD and SRB_TM_CMD types, then falls through to a SCSI fast path that assumes the command is an SRB_SCSI_CMD. The first thing on that path, qla_chk_edif_rx_sa_delete_pending(), and the subsequent handling both evaluate GET_CMD_SP(sp), i.e. sp->u.scmd.cmd. The srb u union overlays the SCSI command pointer with other command layouts (bsg_job, iocb_cmd). If firmware delivers an unexpected STATUS_TYPE IOCB for a non-SCSI handle, sp->u.scmd.cmd can read as a non-NULL garbage pointer, bypassing the NULL checks in qla_chk_edif_rx_sa_delete_pending() and at the cp == NULL test, and leading to a wild pointer dereference. Reject any SRB whose type is not SRB_SCSI_CMD before entering the fast path. The outstanding_cmds slot is left untouched so a genuinely non-SCSI command still completes through its proper handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89850", "url": "https://ubuntu.com/security/CVE-2026-89850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Don't query firmware state while chip is down qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89851", "url": "https://ubuntu.com/security/CVE-2026-89851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace enable parsing in debugfs qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as \"disable\" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89852", "url": "https://ubuntu.com/security/CVE-2026-89852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89853", "url": "https://ubuntu.com/security/CVE-2026-89853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89854", "url": "https://ubuntu.com/security/CVE-2026-89854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix cs84xx use-after-free on host teardown qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89855", "url": "https://ubuntu.com/security/CVE-2026-89855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize flash version read in reset handler The \"update cache versions without reset\" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89856", "url": "https://ubuntu.com/security/CVE-2026-89856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as \"ha->max_req_queues = ha->msix_count - 1\" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent \"ha->max_req_queues--\" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following \"ha->req_q_map[0] = req\" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89858", "url": "https://ubuntu.com/security/CVE-2026-89858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89861", "url": "https://ubuntu.com/security/CVE-2026-89861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89863", "url": "https://ubuntu.com/security/CVE-2026-89863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check qla_chk_edif_rx_sa_delete_pending() obtains the SCSI command via GET_CMD_SP(sp) and immediately dereferences cmd->sc_data_direction. That command pointer can be NULL: the firmware may post a status completion for a command that has already been returned or aborted. The caller qla2x00_status_entry() acknowledges this on the very same status path, re-fetching GET_CMD_SP(sp) and bailing out with the \"Command already returned\" message when it is NULL -- but that check runs only after qla_chk_edif_rx_sa_delete_pending() has already dereferenced the pointer, so a NULL cmd crashes the kernel in interrupt context. Return early when cmd is NULL, before touching cmd->sc_data_direction.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89864", "url": "https://ubuntu.com/security/CVE-2026-89864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: \tstruct qla_i2c_access { \t\tuint16_t device, offset, option, length; \t\tuint8_t buffer[0x40]; \t} __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89865", "url": "https://ubuntu.com/security/CVE-2026-89865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: \tif (len == 1) \t\topt |= BIT_0; \tif (opt & BIT_0) \t\tlen = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89871", "url": "https://ubuntu.com/security/CVE-2026-89871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89872", "url": "https://ubuntu.com/security/CVE-2026-89872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. [Sakari Ailus: Fix subject prefix and coding style a little.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89876", "url": "https://ubuntu.com/security/CVE-2026-89876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tda18250: fix possible integer overflow Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89878", "url": "https://ubuntu.com/security/CVE-2026-89878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: check firmware size before reading trailing marker s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89879", "url": "https://ubuntu.com/security/CVE-2026-89879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: bound JPEG frame size before copying into the buffer s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: \tpayload = le32_to_cpu(pdword[3]); \tif (payload > vc->req_image_size)\t/* payload is checked ... */ \t\treturn -EINVAL; \tvc->pkt_size = payload; \tvc->jpg_size = le32_to_cpu(pdword[4]);\t/* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89880", "url": "https://ubuntu.com/security/CVE-2026-89880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89881", "url": "https://ubuntu.com/security/CVE-2026-89881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89883", "url": "https://ubuntu.com/security/CVE-2026-89883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: sunxi-cir: Unregister rc device on probe failure After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93236", "url": "https://ubuntu.com/security/CVE-2026-93236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common When VIDIOC_TRY_FMT is called with an unsupported pixel format on the OUTPUT queue, vdec_try_fmt_common() falls back to V4L2_PIX_FMT_MPEG2. However, if a distro has locally patched MPEG2 support out (as it has been broken for some time) the platform format table does not contain MPEG2 so find_format() returns NULL and the subsequent dereference of fmt_out->max_width triggers a NULL pointer dereference. Fix this by falling back to the first format in the platform's format array instead of hardcoding V4L2_PIX_FMT_MPEG2. This is always valid since every platform defines at least one format.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89887", "url": "https://ubuntu.com/security/CVE-2026-89887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov7740: fix use-after-destroy in remove The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89888", "url": "https://ubuntu.com/security/CVE-2026-89888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov02a10: fix endpoint parsing use-after-free The ov02a10_check_hwcfg() function calls fwnode_handle_put(ep) immediately after allocating and parsing the endpoint. However, it subsequently calls fwnode_property_read_u32() using the same 'ep' handle, leading to a potential use-after-free. Additionally, reading the optional 'ovti,mipi-clock-voltage' property used to overwrite the 'ret' variable. If the property was missing, 'ret' would become negative, and this failure code would be incorrectly returned at the end of the function, causing probe to fail entirely. Fix the use-after-free by moving fwnode_property_read_u32() before the endpoint is parsed and freed. Avoid the error leak by not assigning the result of fwnode_property_read_u32() to 'ret'.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89890", "url": "https://ubuntu.com/security/CVE-2026-89890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: go7007: defer the ALSA v4l2 put until card release go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89891", "url": "https://ubuntu.com/security/CVE-2026-89891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free of dev_next->devlist on disconnect When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 (\"USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89892", "url": "https://ubuntu.com/security/CVE-2026-89892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: defer audio-only extension registration The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89893", "url": "https://ubuntu.com/security/CVE-2026-89893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: cancel NetUP CI work before teardown netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89894", "url": "https://ubuntu.com/security/CVE-2026-89894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: reject geometry changes while the VBI queue is busy vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: \toffset = lines_completed * (dev->width << 1) + ...; \tif (dma_q->current_field == 2) \t\toffset += dev->width * 2 * dma_q->lines_per_field; \tmemcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89895", "url": "https://ubuntu.com/security/CVE-2026-89895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cobalt: Avoid freeing ALSA private data twice snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89896", "url": "https://ubuntu.com/security/CVE-2026-89896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: fix memory leak in cedrus_init_ctrls() In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89897", "url": "https://ubuntu.com/security/CVE-2026-89897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: Serialize exclusive follower delivery cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89901", "url": "https://ubuntu.com/security/CVE-2026-89901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89923", "url": "https://ubuntu.com/security/CVE-2026-89923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Free guest debug data on vcpu destroy kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89924", "url": "https://ubuntu.com/security/CVE-2026-89924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix old_data leak in guest debug error path __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89925", "url": "https://ubuntu.com/security/CVE-2026-89925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory leak in guest debug handling bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89926", "url": "https://ubuntu.com/security/CVE-2026-89926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix length check __import_wp_info() struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: \twp_info->len = bp_data->len; \t[...] \tif (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) \t\treturn -EINVAL; \twp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89927", "url": "https://ubuntu.com/security/CVE-2026-89927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89930", "url": "https://ubuntu.com/security/CVE-2026-89930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter KVM services local TLB flushes on \"full\" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89932", "url": "https://ubuntu.com/security/CVE-2026-89932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always flush vpid02 on first use Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89936", "url": "https://ubuntu.com/security/CVE-2026-89936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: dac: m62332: Fix regulator reference count imbalance m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89937", "url": "https://ubuntu.com/security/CVE-2026-89937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sgp30: Handle IAQ thread creation failure kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89939", "url": "https://ubuntu.com/security/CVE-2026-89939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89945", "url": "https://ubuntu.com/security/CVE-2026-89945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l34: drain threaded IRQ before runtime suspend cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89946", "url": "https://ubuntu.com/security/CVE-2026-89946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89948", "url": "https://ubuntu.com/security/CVE-2026-89948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89949", "url": "https://ubuntu.com/security/CVE-2026-89949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89951", "url": "https://ubuntu.com/security/CVE-2026-89951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix stale receive device on merged fragments Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89952", "url": "https://ubuntu.com/security/CVE-2026-89952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89953", "url": "https://ubuntu.com/security/CVE-2026-89953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89954", "url": "https://ubuntu.com/security/CVE-2026-89954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: afs: validate v2 image info bounds The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89964", "url": "https://ubuntu.com/security/CVE-2026-89964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: eisa: Fix infinite loop when parsing invalid IRQ value When an invalid value is passed via the \"eisa_irq_edge=\" kernel command line parameter (e.g. \"eisa_irq_edge=16,5\"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89965", "url": "https://ubuntu.com/security/CVE-2026-89965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: reject an arena whose nfree is below the lane count The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89968", "url": "https://ubuntu.com/security/CVE-2026-89968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: reject unsolicited H2CData PDUs nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the \"list_add double add\" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89969", "url": "https://ubuntu.com/security/CVE-2026-89969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as \tqueue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89973", "url": "https://ubuntu.com/security/CVE-2026-89973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: check the data direction of a C2HData PDU nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89979", "url": "https://ubuntu.com/security/CVE-2026-89979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race between non-atomic ops and trigger-start We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89980", "url": "https://ubuntu.com/security/CVE-2026-89980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: harmony: initialize locks before requesting IRQ snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89982", "url": "https://ubuntu.com/security/CVE-2026-89982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89983", "url": "https://ubuntu.com/security/CVE-2026-89983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89984", "url": "https://ubuntu.com/security/CVE-2026-89984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \\ \t./perf bench syscall basic --loop 1000 | \\ \t./perf script -i - --fields brstack|tr ' ' '\\n'| \\ \tgrep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89989", "url": "https://ubuntu.com/security/CVE-2026-89989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89993", "url": "https://ubuntu.com/security/CVE-2026-89993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Initialize IRQ data before requesting IRQs dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89997", "url": "https://ubuntu.com/security/CVE-2026-89997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix resume-vs-remove race If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89999", "url": "https://ubuntu.com/security/CVE-2026-89999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: validate report length in wacom_intuos_pro2_bt_irq wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: \twacom_intuos_pro2_bt_pen(wacom); \tif (type == INTUOSP2_BT || type == INTUOSP2S_BT) { \t\twacom_intuos_pro2_bt_touch(wacom); \t\twacom_intuos_pro2_bt_pad(wacom); \t\twacom_intuos_pro2_bt_battery(wacom); \t} else { \t\twacom_intuos_gen3_bt_pad(wacom); \t\twacom_intuos_gen3_bt_battery(wacom); \t} Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] \t(the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT (\"gen3\"): wacom_intuos_gen3_bt_battery() reads data[45], \tso the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 (\"HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq\") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90000", "url": "https://ubuntu.com/security/CVE-2026-90000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: rmi: fix OOB access with undersized RMI reports The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: \tdata->input_report_size = hid_report_len(input_report); \tdata->output_report_size = hid_report_len(output_report); \talloc_size = data->output_report_size + data->input_report_size; \tdata->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); \tdata->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly \"this probe validated the reports\"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90007", "url": "https://ubuntu.com/security/CVE-2026-90007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Use rollback index when freeing MSI-X vectors pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90011", "url": "https://ubuntu.com/security/CVE-2026-90011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where \tpadding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90017", "url": "https://ubuntu.com/security/CVE-2026-90017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: \tconst u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); \t... \tc = frame_body[0]; \t... \ta = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90018", "url": "https://ubuntu.com/security/CVE-2026-90018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: \tif (attr_ptr + 4 > wps_ie + wps_ielen) \t\tbreak; \tu16 attr_id = get_unaligned_be16(attr_ptr); \tu16 attr_data_len = get_unaligned_be16(attr_ptr + 2); \tu16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: \tmemcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack \"u8 sr\"/\"u8 selected_registrar\" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The \"attr_ptr + 4 > wps_ie + wps_ielen\" header check above was added by commit 1463ca3ec6601 (\"staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()\"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90019", "url": "https://ubuntu.com/security/CVE-2026-90019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: fix null pointer dereference in usb_put_function_instance() usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90020", "url": "https://ubuntu.com/security/CVE-2026-90020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90025", "url": "https://ubuntu.com/security/CVE-2026-90025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix OOB altmode array index The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90031", "url": "https://ubuntu.com/security/CVE-2026-90031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90032", "url": "https://ubuntu.com/security/CVE-2026-90032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: usbtv: keep device alive while ALSA card exists The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90033", "url": "https://ubuntu.com/security/CVE-2026-90033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90034", "url": "https://ubuntu.com/security/CVE-2026-90034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2025-38097", "url": "https://ubuntu.com/security/CVE-2025-38097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: remove encap socket caching to avoid reference leak The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used \"recently\", but it's a lot more complex than just not caching the socket.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2026-89515", "url": "https://ubuntu.com/security/CVE-2026-89515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables() During fuzz testing, the following issue was discovered: BUG: KMSAN: uninit-value in __dma_map_sg_attrs+0x217/0x310 __dma_map_sg_attrs+0x217/0x310 dma_map_sg_attrs+0x4a/0x70 ata_qc_issue+0x9f8/0x1420 __ata_scsi_queuecmd+0x1657/0x1740 ata_scsi_queuecmd+0x79a/0x920 scsi_queue_rq+0x4472/0x4f40 blk_mq_dispatch_rq_list+0x1cca/0x3ee0 __blk_mq_sched_dispatch_requests+0x458/0x630 blk_mq_sched_dispatch_requests+0x15b/0x340 __blk_mq_run_hw_queue+0xe5/0x250 __blk_mq_delay_run_hw_queue+0x138/0x780 blk_mq_run_hw_queue+0x4bb/0x7e0 blk_mq_sched_insert_request+0x2a7/0x4c0 blk_execute_rq+0x497/0x8a0 sg_io+0xbe0/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Uninit was created at: __alloc_pages+0x5c0/0xc80 alloc_pages+0xe0e/0x1050 blk_rq_map_user_iov+0x2b77/0x6100 blk_rq_map_user_io+0x2fa/0x4d0 sg_io+0xad6/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Bytes 14-15 of 16 are uninitialized Memory access of size 16 starts at ffff88800cbdb000 When processing the last unaligned element of the scatterlist, it is supplemented with missing bytes in the amount of pad_len. These bytes remain uninitialized, which leads to a problem. Extend last_sg->length by pad_len first, then use sg_zero_buffer() to zero those pad_len bytes. sg_zero_buffer() uses sg_miter internally, which correctly handles sg entries spanning multiple pages and padding that crosses a page boundary. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80689", "url": "https://ubuntu.com/security/CVE-2026-80689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions mmio_trace_rw() and mmio_trace_mapping() retrieve mmio_trace_array into tr and pass it to __trace_mmiotrace_rw() and __trace_mmiotrace_map(). If these functions are invoked while mmio_trace_array is NULL (e.g. before initialization or after disabled), accessing tr->array_buffer.buffer will result in a NULL pointer dereference crash. Fix this by adding an explicit NULL check for tr at the beginning of __trace_mmiotrace_rw() and __trace_mmiotrace_map().", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80888", "url": "https://ubuntu.com/security/CVE-2026-80888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: drop dma_buf reference on foreign-fd prime import ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-80912", "url": "https://ubuntu.com/security/CVE-2026-80912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: reject an unclaimed class value in security_get_classes() security_get_classes() sizes an array by p_classes.nprim and fills it at value - 1, so a class value the policy never defines leaves a NULL. sel_make_classes() passes every entry to sel_make_dir(), reaching the same d_alloc_name() dereference as the permission array. The class symbol table is allowed to be sparse (policydb_class_isvalid() exists to absorb that), but this getter builds its own array straight from the hash table and has no such predicate. Fail the lookup when a value went unclaimed instead of handing out the NULL. Conforming policies define every class they declare and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-89595", "url": "https://ubuntu.com/security/CVE-2026-89595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix stale object mask after concurrent mark updates When a mark gets a new event bit, fanotify and inotify may avoid recalculating the object mask if the cached aggregate already contains that bit. This is racy with a recalculation triggered by a concurrent update to another mark on the same connector. The concurrent scan can read the mark before the new bit is added, while the updater reads the old aggregate before that scan publishes its result. The updater then skips recalculation and the scan publishes a mask without the bit, leaving the object mask stale after both updates complete. This can be reproduced with two fanotify groups watching the same inode: one thread removes FAN_MODIFY from one existing mark while another thread adds FAN_MODIFY to the other mark. After both fanotify_mark() calls return, writes can fail to produce FAN_MODIFY for the group whose mark now contains the bit. This was reproduced on an unmodified v6.12.95 kernel. The equivalent inotify interleaving loses IN_MODIFY events. For normal fanotify additions, recalculate whenever the raw mark mask changes. The normal mask is not cleared asynchronously, so an unchanged addition cannot introduce missing interest. Always recalculate ignore-mask updates because FS_MODIFY handling may clear the ignore mask without taking mark->lock, making snapshot comparisons unreliable. Always recalculate after updating an existing inotify watch. Its replace path temporarily sets mark->mask to zero, so a concurrent scan can observe zero even when the old and final masks are equal. Assigning the replacement mask directly would avoid the transient zero, but existing-watch updates are infrequent, so unconditional recalculation is simpler.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89603", "url": "https://ubuntu.com/security/CVE-2026-89603", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-74378", "url": "https://ubuntu.com/security/CVE-2026-74378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe get_srq_wqe() reads wqe->dma.num_sge from the shared receive queue buffer, which is mapped into userspace. It validates num_sge against max_sge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify num_sge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe. Read num_sge into a local variable and use it for both the bounds check and the size calculation.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-89488", "url": "https://ubuntu.com/security/CVE-2026-89488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix CT limit teardown use-after-free Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state. An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down. Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists. Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization. The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90049", "url": "https://ubuntu.com/security/CVE-2026-90049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80977", "url": "https://ubuntu.com/security/CVE-2026-80977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't touch shared zerocopy state in skb_tx_error() skb_tx_error() completes the zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone shares, while the caller only owns the reference it is about to drop. Through a clone it tells the producer its pages are free and drops SKBFL_SHARED_FRAG for an skb that is still in flight. Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC: clone_execute() sends a skb_clone() into ovs_dp_process_packet() while do_execute_actions() keeps forwarding the original, and skb_clone() does not privatise the frags here -- skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN. A flow miss on the clone then strips the marker from the packet still being forwarded, and a later local ESP delivery decrypts in place over frags it does not own privately. Skip it for a cloned skb. Nothing is lost: skb_release_data() clears the zerocopy state once the last reference to the shared data goes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80928", "url": "https://ubuntu.com/security/CVE-2026-80928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix cred UAF in smack_file_send_sigiotask() When inspecting the credentials of another task, objective credentials (->real_cred, accessed with __task_cred()) must always be used. Accessing ->cred on a non-current task is forbidden unless that task is being created or destroyed; a task is allowed to change its own ->cred pointer with no synchronization, and changing ->cred should only affect the current syscall. smack_file_send_sigiotask() was accessing both sets of credentials: First tsk->cred, then __task_cred(tsk). Fix it, always access the objective credentials here. I have tested that this bug can lead to a KASAN-reported UAF of struct cred in smack_file_send_sigiotask(), and that this fix prevents the race.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-93222", "url": "https://ubuntu.com/security/CVE-2026-93222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: avoid shared siginfo namespace rewrites send_signal_locked() rewrites sender ids for the target namespace. Group sends reuse the same siginfo, so one recipient can affect the next. Copy the siginfo before changing it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-80930", "url": "https://ubuntu.com/security/CVE-2026-80930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80931", "url": "https://ubuntu.com/security/CVE-2026-80931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: ds28e17: reject an oversize length on an I2C block read w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the device. The downstream slave puts a length byte in buf[0]. The driver then reads that many bytes into buf[1] with w1_f19_i2c_read(). buf[0] is controlled by the device and can be 0 to 255. w1_f19_i2c_read() only rejects a zero count. The caller buffer is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read run past it, up to about 222 bytes out of bounds. The SMBus core does check buf[0] against I2C_SMBUS_BLOCK_MAX. That check runs after master_xfer returns. By then the write is already done. i2c-algo-bit rejects an oversize length before it copies, and returns -EPROTO. Reject a length above I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites, the same way i2c-algo-bit does.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80932", "url": "https://ubuntu.com/security/CVE-2026-80932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: flush works in dependency order virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work. In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it. KASAN reported: BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80938", "url": "https://ubuntu.com/security/CVE-2026-80938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex mt7615_suspend() acquired the mt76 mutex and then called cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the same mutex via mt7615_mutex_acquire() at the top of the worker, so if mac_work is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against. Flush scan_work and mac_work before taking the mutex, matching the suspend paths in mt7921 and mt7925. scan_work only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps mac_work from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80941", "url": "https://ubuntu.com/security/CVE-2026-80941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb() The skb passed to the rtw_hci_tx_write() is expected to be freed when the function fails, but the error path in rtw_txq_push_skb() does not free the skb before returning. This can lead to a memory leak in rtw_txq_push() where a dequeued skb is passed to rtw_txq_push_skb().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80944", "url": "https://ubuntu.com/security/CVE-2026-80944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Detach sync cmd buffer on interrupted wait mwifiex synchronous commands keep the caller-provided data buffer in cmd_node->data_buf. Several callers pass stack-allocated objects there. If wait_event_interruptible_timeout() is interrupted, the caller can return and release that stack object while the firmware command is still the current command. A late firmware response then reaches the normal response handler, which can copy data through cmd_node->data_buf into the stale stack address. This fixes a stack corruption observed during repeated association and disassociation cycles. The panic trace showed the command wait being interrupted immediately before a bad pointer dereference: cmd_wait_q terminated: -512 Unable to handle kernel paging request at virtual address 002c583837384662 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted ... Tainted: [M]=MACHINE_CHECK The fault address decodes as little-endian ASCII: 0x002c583837384662 -> \"bF878X,\\0\" which is a fragment of the VERSION_EXT firmware string exposed as debugfs \"verext\": w8997o-V4, RF878X, FP92, 16.92.21.p153.7 The same runs also showed corrupted control data containing: 0x2400372e333531 -> \"153.7\\0$\" which is the tail of the same VERSION_EXT string. This points at a late VERSION_EXT response writing through a stale stack-backed data_buf after the interrupted wait returned. After cancelling pending commands on an interrupted or timed-out wait, detach the caller-owned data buffer from the still-current command. This preserves the existing command cancellation behaviour while preventing a late response from writing through a pointer whose lifetime ended with the waiting caller. Tested on an i.MX8MP board using an 88W8997.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80949", "url": "https://ubuntu.com/security/CVE-2026-80949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() The memory allocated for buf is not freed in some of the error paths in brcmf_sdio_read_control(). Fix that by adding vfree() calls. [arend: rework as suggested by Johannes]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80951", "url": "https://ubuntu.com/security/CVE-2026-80951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: bound IBI payload to the requested max_payload_len svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into the IBI slot. The loop is bounded by the hardware FIFO size (SVC_I3C_FIFO_SIZE), not by the slot size. slot->data points into the IBI pool, which i3c_generic_ibi_alloc_pool() sizes at max_payload_len per slot. svc_i3c_master_request_ibi() only rejects a max_payload_len larger than SVC_I3C_FIFO_SIZE, so a driver can request a smaller one. mctp-i3c requests 1. Each readsb() then copies the controller RXCOUNT bytes (up to 31) with no check against the slot size. A device that sends more bytes than the slot holds writes past slot->data, an out-of-bounds write into the IBI pool. Bound the loop by dev->ibi->max_payload_len and clamp each read to the space left in the slot, the same way dw-i3c does. A device can still send more than the requested payload. Flush the leftover bytes from the RX FIFO so they do not leak into the next transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80952", "url": "https://ubuntu.com/security/CVE-2026-80952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix info leak and UAF in device unregister path i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During device_unregister(), device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct i3c_device_info, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind. Keep desc valid until device_unregister() has completed. Since device_unregister() drops the device reference and may free the device, take an extra reference with get_device() before unregistering. Clear desc afterwards and release the extra reference with put_device(). This preserves the release-time invariant that desc must be NULL while avoiding both the information leak and a potential use-after-free from writing desc after the device has been released.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80963", "url": "https://ubuntu.com/security/CVE-2026-80963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-stats: fix a crash if allocation of per-cpu data fails If \"dm_kvzalloc(percpu_alloc_size, cpu_to_node(cpu))\" fails, the code jumps to the \"out\" label and calls dm_stat_free. dm_stat_free does \"for_each_possible_cpu(cpu) { dm_kvfree(s->stat_percpu[cpu][0].histogram, s->histogram_alloc_size);\", which crashes with NULL pointer dereference if s->stat_percpu[cpu] is NULL. This commit fixes the bug by testing s->stat_percpu[cpu] for NULL before using it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80964", "url": "https://ubuntu.com/security/CVE-2026-80964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: virmidi: Check card index validity at probe virmidi driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80965", "url": "https://ubuntu.com/security/CVE-2026-80965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: serial-u16550: Check card index validity at probe serial-u16550 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80966", "url": "https://ubuntu.com/security/CVE-2026-80966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: portman2x4: Check card index validity at probe Although portman2x4 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80967", "url": "https://ubuntu.com/security/CVE-2026-80967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcxhr: initialize mutexes before requesting threaded IRQ pcxhr_probe() requests pcxhr_threaded_irq() before initializing mgr->lock, even though the threaded handler takes that mutex. Initialize the manager locks before request_threaded_irq() so an early interrupt cannot run against uninitialized mutex state during probe.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80968", "url": "https://ubuntu.com/security/CVE-2026-80968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mts64: Check card index validity at probe Although mts64 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80969", "url": "https://ubuntu.com/security/CVE-2026-80969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mpu401: Check card index validity at probe mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80971", "url": "https://ubuntu.com/security/CVE-2026-80971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: clear the URB pointers on disconnect bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind: \tusb_kill_urb(bcd2k->midi_out_urb); \tusb_kill_urb(bcd2k->midi_in_urb); \tusb_free_urb(bcd2k->midi_out_urb); \tusb_free_urb(bcd2k->midi_in_urb); The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core: \tbcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE; \t... \tret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC); usb_kill_urb() does not stop a later submission either, so a submit that races the disconnect can requeue the URB after it has been reaped. midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits it from the completion handler. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000] Write of size 4 at addr ffff00001827d388 by task bpoc/168 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 Freed by task 168: usb_free_urb bcd2000_disconnect [snd_bcd2000] BUG: KASAN: slab-use-after-free in usb_submit_urb Read of size 8 at addr ffff00001827d3b8 by task bpoc/168 Clear both pointers after freeing and test them on the paths that can still run. Poison the URBs before freeing them: usb_poison_urb() waits for a running completion handler and rejects any later submission, so after it returns the input path is quiesced and only the rawmidi trigger path can still reach bcd2000_midi_send(). No unpoison is needed; the URBs are freed on the next line. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80972", "url": "https://ubuntu.com/security/CVE-2026-80972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Check card index validity at probe aloop driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80973", "url": "https://ubuntu.com/security/CVE-2026-80973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: bound the MIDI event length from the device usb6fire_comm_receiver_handler() forwards a MIDI event using a length byte the device supplies, with no bound and no check that the transfer delivered that many bytes: \tif (!urb->status) { \t\tif (rt->receiver_buffer[0] == 0x10) /* midi in event */ \t\t\tif (midi_rt) \t\t\t\tmidi_rt->in_received(midi_rt, \t\t\t\t\t\trt->receiver_buffer + 2, \t\t\t\t\t\trt->receiver_buffer[1]); \t} receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the device chooses, so a device that answers with 0x10 and a length of 0xFF makes snd_rawmidi_receive() read 255 bytes starting two bytes into a 64-byte object. The bytes past the buffer are handed to userspace through the rawmidi read path. urb->actual_length is not consulted either, so a short transfer leaves both the type byte and the length byte at their previous values and the handler acts on stale data. The receiver URB is submitted from usb6fire_comm_init() at probe, so the read happens on plug with no user action; forwarding to userspace also needs a MIDI input substream open, since usb6fire_midi_in_received() only calls snd_rawmidi_receive() when rt->in is set. KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device: BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive Read of size 255 at addr ffff000009f64682 by task bash/183 __asan_memcpy snd_rawmidi_receive usb6fire_midi_in_received [snd_usb_6fire] usb6fire_comm_receiver_handler [snd_usb_6fire] Allocated by task 11: usb6fire_comm_init [snd_usb_6fire] usb6fire_chip_probe [snd_usb_6fire] The buggy address is located 2 bytes inside of allocated 64-byte region [ffff000009f64680, ffff000009f646c0) Reject the event when the length exceeds the bytes that follow the header, and require the transfer to have delivered the header plus that many bytes. The receiver URB is submitted with a 64-byte transfer_buffer_length, so a genuine device cannot deliver an event longer than those 62 bytes and nothing valid is dropped. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80976", "url": "https://ubuntu.com/security/CVE-2026-80976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: reset IP6CB after IPv6 decapsulation decap_and_validate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags. End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet. The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports: BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu ip6_protocol_deliver_rcu+0x1118/0x1450 ip6_input_finish+0x11b/0x240 seg6_local_input_core+0xed/0x2e0 lwtunnel_input+0x1e9/0x4e0 ipv6_rthdr_rcv+0x525f/0x6c50 ip6_protocol_deliver_rcu+0xcb7/0x1450 Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field. Use IP6CB(skb)->iif rather than skb->skb_iif because VRF processing can replace skb_iif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKB_L3SLAVE for the same reason.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80978", "url": "https://ubuntu.com/security/CVE-2026-80978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap advertised IP tunnel headroom IP tunnel devices derive their advertised needed_headroom from lower output devices. A stack of user-created devices can make the derived value larger than the 16-bit skb header offsets can represent. Once IP output reserves it, skb head expansion can wrap those offsets. The runtime transmit path already caps a growing needed_headroom at 512. Apply the same cap when tunnel configuration publishes needed_headroom derived from a lower output device. Capping the advertised value is safe: IP tunnel transmit still expands the skb when a packet needs more headroom. A nonsensical stacked configuration can therefore incur an extra reallocation, but it cannot publish an unbounded reservation to upper layers.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80983", "url": "https://ubuntu.com/security/CVE-2026-80983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket refcount leak in smc_switch_conns() smc_switch_conns() takes a reference on the SMC socket before dropping lgr->conns_lock, so the connection stays alive while the CDC slot is fetched: sock_hold(&smc->sk); read_unlock_bh(&lgr->conns_lock); /* pre-fetch buffer outside of send_lock, might sleep */ rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend); if (rc) goto err_out; The err_out label only drops the wr_tx link reference, so this early exit returns without the matching sock_put(). The second error exit is not affected, because sock_put() has already run by then. A leaked sk_refcnt means the smc_sock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down. smc_cdc_get_free_slot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smc_switch_conns() run in the first place. Restructure so there is a single sock_put() covering both outcomes, instead of adding a second one to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80987", "url": "https://ubuntu.com/security/CVE-2026-80987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Reject oversized TX buffers ntb_process_tx() handles an oversized buffer by calling tx_handler() with a NULL data pointer and returning success. ntb_netdev therefore neither frees the skb in its completion callback nor takes its enqueue error path, leaking it. Reject oversized buffers in ntb_transport_tx_enqueue() before acquiring a queue entry and return -EMSGSIZE. The caller retains ownership of the buffer, and the preceding netdev patch frees the skb when enqueue returns this permanent error.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80988", "url": "https://ubuntu.com/security/CVE-2026-80988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Fail TX enqueue when the QP link is down Commit f195a1a6fe41 (\"ntb: Drop packets when qp link is down\") meant to make ntb_transport_tx_enqueue() drop packets submitted while the QP link is down, but it only returns 0 without consuming the packet. Zero means success by this function's contract, so ntb_netdev reports NETDEV_TX_OK and forgets the skb: nothing queued it, nothing frees it, and it leaks, one skb for every transmit racing a link-down. Return -ENOLINK instead, restoring the contract that a non-zero return leaves the buffer owned by the caller. With the preceding patch, ntb_netdev frees the skb on non-retryable enqueue failures and returns NETDEV_TX_OK, so a packet racing with link-down is dropped without leaking or entering a busy retry loop.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80994", "url": "https://ubuntu.com/security/CVE-2026-80994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix flow mask use-after-free on flow deletion The commit in the Fixes tag below made so flow->mask free is scheduled via RCU right after it is removed from the flow table. The pointer stays in the flow structure and it can be accessible while in the same RCU critical section. This is done to avoid requiring ovs_mutex for the ovs_flow_free(). However, while removing the flow during processing of CMD_DEL, we do not take RCU read lock before the removal, and ovs_flow_cmd_fill_info() uses the flow->mask pointer afterwards. The RCU read lock is taken, but it's already late at that point. The comment on that line acknowledges that the lock is cosmetic and doesn't serve a real purpose. This leads to use-after-free if the RCU grace period passes between removal and the filling. It is a short race window, but it is there and can lead to a real crash in case memory allocation for the info takes a bit longer: BUG: KASAN: slab-use-after-free in __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 BUG: KASAN: slab-use-after-free in ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 Read of size 4 at addr ffff88801ee89970 by task ovs_flow_del_ec/9487 Call Trace: __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c:930 ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c:1467 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Allocated by task 9487: mask_alloc net/openvswitch/flow_table.c:967 flow_mask_insert net/openvswitch/flow_table.c:1012 ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c:1084 ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c:1086 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Freed by task 9485: rcu_free_sheaf+0x1e/0x100 mm/slub.c:5978 rcu_do_batch kernel/rcu/tree.c:2645 rcu_core+0x59c/0x10c0 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9a0 kernel/softirq.c:622 ... instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 ovs_flow_tbl_remove() must be called after the ovs_flow_cmd_fill_info() to avoid this race. This also helps with cleaning up the forced cast and the cosmetic RCU read lock. Before the commit in the Fixes tag the order did not matter as long as the flow object itself was not freed. A wider RCU critical section could be another option, but we have a GFP_KERNEL allocation in the way. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-32042.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81000", "url": "https://ubuntu.com/security/CVE-2026-81000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tun: bound receive headroom tun_get_user() uses tun->align both as skb headroom and when choosing how much packet data to keep linear. OVS can propagate an oversized headroom request from another port to TUN or TAP. When align is larger than the usable space in a one-page skb head, SKB_MAX_HEAD(align) underflows and the result becomes negative when stored in good_linear. That value later wraps when assigned to the size_t linear variable, and tun_alloc_skb() can place skb->data outside the allocated head. Bound the headroom stored by TUN to the one-page skb-head budget and the largest non-sentinel 16-bit skb header offset. Leave one linear byte for raw TUN and a complete Ethernet header for TAP, including NET_IP_ALIGN. Also pull the raw-TUN protocol byte and the TAP Ethernet header before accessing them, so these checks remain safe for nonlinear skbs supplied by other allocation paths.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81001", "url": "https://ubuntu.com/security/CVE-2026-81001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: fix use-after-free in sl_sync() slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor. priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop: \t/* Snapshot list, allow later requests */ \tlist_replace_init(&net_todo_list, &list); \t__rtnl_unlock(); \t... \t\tif (dev->priv_destructor) \t\t\tdev->priv_destructor(dev);\t/* slip_devs[i] = NULL */ \t\tif (dev->needs_free_netdev) \t\t\tfree_netdev(dev); \t\t... \t\t/* Free network device */ \t\tkobject_put(&dev->dev.kobj); So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed */ sl = netdev_priv(dev) if (sl->tty || sl->leased) /* use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860 Commit e58c19124189 (\"slip: Fix use-after-free Read in slip_open\") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it. Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: the ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81002", "url": "https://ubuntu.com/security/CVE-2026-81002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xdp: fix zero-copy frame layout xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page and advertises PAGE_SIZE as its frame size. It allows the copied frame to occupy the page tail needed by skb_shared_info and records zero headroom even when metadata separates the frame header from packet data. An AF_XDP zero-copy packet redirected through cpumap can therefore make the skb overlap skb_shared_info or place it beyond the allocated page. Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result. BUG: KASAN: slab-out-of-bounds in skb_gro_receive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skb_gro_receive (net/core/gro.c:174) udp_gro_receive (net/ipv4/udp_offload.c:812) inet_gro_receive (net/ipv4/af_inet.c:1539) dev_gro_receive (net/core/gro.c:515) gro_receive_skb (net/core/gro.c:633) cpu_map_kthread_run (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Kernel panic - not syncing: KASAN: panic_on_warn set ...", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81003", "url": "https://ubuntu.com/security/CVE-2026-81003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: filter frames in afiucv_hs_rcv() by ingress device afiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-byte name fields in the transport header alone. No check is made against the net_device the frame arrived on. This can cause a frame arriving on any netdev to be delivered to an AF_IUCV socket. Three problems follow. First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL. iucv_sock_bind() takes the classic path whenever the requested userid matches iucv_userid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucv_hs_callback_syn() for such a match inherits hs_dev = NULL and transport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable. Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections Third, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() calls sk_alloc(&init_net, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAP_NET_RAW capability valid within that namespace can send a raw ETH_P_AF_IUCV frame on its own lo device and have it matched against init_net sockets. Fix all three by skipping any socket whose hs_dev does not match the ingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hs_dev is always a device in init_net (iucv_sock_bind() scans for_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket. Note that AF_IUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81005", "url": "https://ubuntu.com/security/CVE-2026-81005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: si: Fix NULL pointer dereference after failed registration try_smi_init() allocates new_smi->si_sm and later calls ipmi_register_smi_mod(), which maps to ipmi_add_smi(). During ipmi_add_smi(), the upper IPMI message handler obtains the initial BMC device information through __bmc_get_device_id(). This can fail if the BMC does not return a successful response to the Get Device ID command. When the BMC returns a nonzero completion code, the device-id helper retries the command and eventually returns -EIO if the device ID still cannot be fetched. On this failure path, ipmi_add_smi() logs \"Unable to get the device id\" and goes to out_err_started, where it invokes the lower driver's shutdown callback. try_smi_init() then logs the returned registration failure: ipmi_si IPI0001:00: IPMI message handler: Unable to get the device id: -5 ipmi_si IPI0001:00: Unable to register device: error -5 For ipmi_si, the shutdown callback is shutdown_smi(), which cleans up the SI state machine data, frees smi_info->si_sm, and sets smi_info->si_sm and smi_info->intf to NULL. However, intf->in_shutdown is not set on this failed-registration rollback path. Therefore, the asynchronous redo_bmc_reg work item can still retry BMC device-id probing after the lower driver has already cleared its SI state machine data. In the observed case, that retry path reached start_next_msg(), which passed the NULL smi_info->si_sm pointer to the selected KCS state machine handler: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Workqueue: events redo_bmc_reg [ipmi_msghandler] RIP: start_kcs_transaction+0x2c/0x190 [ipmi_si] Call Trace: start_next_msg+0x50/0x80 [ipmi_si] check_start_timer_thread.part.9+0x3b/0x50 [ipmi_si] sender+0x69/0x80 [ipmi_si] i_ipmi_request+0x2ac/0x9d0 [ipmi_msghandler] __get_device_id.isra.29+0xaa/0x180 [ipmi_msghandler] __bmc_get_device_id+0xef/0x950 [ipmi_msghandler] redo_bmc_reg+0x52/0x60 [ipmi_msghandler] process_one_work+0x1a7/0x360 Set intf->in_shutdown on the out_err_started path before invoking the lower driver's shutdown callback. This prevents later redo_bmc_reg retries from using an interface whose lower driver state has been cleaned up, and applies the same shutdown state to other IPMI interfaces as well.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81007", "url": "https://ubuntu.com/security/CVE-2026-81007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: validate write message length ipmb_write() read message fields before validating the length byte. A zero or short write can read uninitialized stack bytes. A length smaller than the SMBus header underflows the block write length. Require a non-empty buffer and the minimum IPMB request length. Also require the length byte plus payload before parsing the message.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81008", "url": "https://ubuntu.com/security/CVE-2026-81008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: interconnect: Fix use after free in icc_get() and of_icc_get_by_index() In of_icc_get_by_index() and icc_get(), if the dynamic allocation for path->name fails via kasprintf(), the error handling path directly calls kfree(path) to free the path object and returns an error. However, prior to this point, path_find() calls path_init(), which already links the path's requests into the req_list of the respective interconnect nodes via hlist_add_head(). Directly invoking kfree(path) leaves dangling pointers in the hlist. A subsequent call to icc_get() or icc_set_bw() will traverse or modify these corrupted lists, triggering a slab use afterfree. KASAN report showing the vulnerability when reproducing via debugfs: BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0 Fix this by replacing kfree(path) with the proper teardown function, icc_put(path), which safely removes the requests from the req_list using hlist_del() and drops the provider usage references before freeing the memory. Additionally, in icc_get(), ensure that the icc_lock mutex is released prior to calling icc_put(path) to avoid a deadlock, as icc_put() internally acquires the same lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81017", "url": "https://ubuntu.com/security/CVE-2026-81017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Bound the EC-reported sensor number Each EC FIFO event carries an 8-bit sensor number (in->sensor_num). cros_ec_sensorhub_ring_handler() validates the FIFO event count, the per-read count and the ring bound, but not the sensor number, which cros_ec_sensor_ring_process_event() then uses unchecked to index sensorhub->batch_state[] - allocated with only sensorhub->sensor_num entries. A sensor number of sensor_num or larger is an out-of-bounds read and write of batch_state[]. Validate the sensor number in the ring handler, where each event is read from the EC, and drop a malformed event before it is used.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89440", "url": "https://ubuntu.com/security/CVE-2026-89440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: via-sdmmc: stop card-detect handling on probe failure request_irq() registers the SD card-detect interrupt and the probe enables it before mmc_add_host() runs. If mmc_add_host() fails, the error path only unmaps the registers and returns: the interrupt stays registered, so the handler keeps running against the host once it is freed. via_sdc_isr() dereferences sdhost and its MMIO base and schedules carddet_work, which via_sdc_card_detect() also runs against freed memory through its container_of() dereference. Add a probe-error path that disables and frees the interrupt and cancels carddet_work before unmapping. carddet_work can re-enable the device interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it again after cancelling the work. This issue was found by an in-house static analysis tool and confirmed by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89444", "url": "https://ubuntu.com/security/CVE-2026-89444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer set_attribute() populates the security area of the BIOS attribute request buffer with the current admin password via populate_security_buffer(), then dumps the whole request buffer with print_hex_dump_bytes(). This can expose the plaintext admin password in the kernel log. The same issue was fixed for the password attribute path by commit d1a196e0a6dc (\"platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data\"). Remove the remaining dump from the BIOS attribute path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93206", "url": "https://ubuntu.com/security/CVE-2026-93206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/proc: Use file_ns_capable() when checking config space read access proc_bus_pci_read() decides how much of the config space is readable based on capable(CAP_SYS_ADMIN), which checks the credentials of the task calling read(), not the credentials of the process that opened the file. The sysfs equivalent, pci_read_config(), has checked the credentials of the opening process since commit de139a339395 (\"pci: check caps from sysfs file open to read device dependent config space\"), so a privileged process can open the config space file and pass the file descriptor to an unprivileged process (for example, a process running a KVM guest with an assigned device), which can then read the entire config space. The check was subsequently routed through the LSM framework in commit 47970b1b2aa6 (\"pci: use security_capable() when checking capablities during config space read\") and converted to the dedicated helper in commit ab0fa82b2df9 (\"pci-sysfs: use proper file capability helper function\"). Thus, the two interfaces check the same capability against different credentials. Checking the credentials of the task calling read() makes the outcome depend on who reads rather than who opened, so the restriction is bypassed whenever a more privileged process reads through the descriptor. Checking the credentials recorded in file->f_cred settles the decision at open() time and ties it to the file, where it cannot change with the caller. Use file_ns_capable() to check CAP_SYS_ADMIN against the credentials in effect when the file was opened, bringing the procfs interface in line with the sysfs behaviour. As a result, a file descriptor opened by a privileged process and passed to an unprivileged one now allows the entire config space to be read through procfs, matching sysfs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89456", "url": "https://ubuntu.com/security/CVE-2026-89456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Propagate partial completion length across ERP recovery dasd_default_erp_postaction() copies the timing and device state from the finished ERP request back to the original request but drops proc_bytes. A request that was partially completed, an ESE read of a not-yet-allocated track returns fewer bytes than requested, and then recovered through the ERP chain loses its partial-completion length. __dasd_cleanup_cqr() then sees proc_bytes == 0 and completes the whole request instead of requeueing the remainder, silently returning zeroed data for the part that was never read. Carry proc_bytes over to the original request like the other per-request state.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89457", "url": "https://ubuntu.com/security/CVE-2026-89457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Guard sysfs discipline callbacks against unallocated private data Several sysfs show/store handlers call a discipline callback that dereferences device->private, either directly or through the DASD_DEFINE_ATTR() macro. During dasd_generic_set_online() the discipline is assigned before check_device() allocates device->private, so an unprivileged read of one of these world-readable attributes in that window dereferences a NULL pointer and panics. Guard the dereference inside each callback that actually touches device->private.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89458", "url": "https://ubuntu.com/security/CVE-2026-89458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Do not complete a failed ESE read as successful dasd_int_handler() completes an NRF read of an unallocated ESE track by calling ese_read() and unconditionally marking the request DASD_CQR_SUCCESS. dasd_eckd_ese_read() can return an error before it has zeroed the destination buffer: a failed sense-data parse or a current track outside the requested range both return early, leaving the destination pages untouched. The request is still completed successfully, so the block layer is handed stale / uninitialized memory instead of zeros. Check the ese_read() return value and fail the request through the normal error path instead of forcing DASD_CQR_SUCCESS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89461", "url": "https://ubuntu.com/security/CVE-2026-89461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: synchronize work cancellation on suspend max17040_work() requeues itself after every poll. cancel_delayed_work() only cancels a pending instance and does not wait for a callback that is already running. If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns. Use cancel_delayed_work_sync() to ensure polling is quiesced before suspend completes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89463", "url": "https://ubuntu.com/security/CVE-2026-89463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ucs1002: fix use-after-free on remove ucs1002 has no remove callback, so unbind runs entirely through devm. The alert IRQ handler queues the health_poll delayed work, and the work reschedules itself while the chip reports a bad-health condition. devm frees the alert IRQ, which only synchronizes the handler; it does not cancel the delayed work, which can then run after devm frees the driver data and dereference it. Register health_poll with devm_delayed_work_autocancel() before the alert IRQ is requested. devm then frees the IRQ before cancelling the work, so the handler can no longer queue it and the work is cancelled before the driver data is freed. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89464", "url": "https://ubuntu.com/security/CVE-2026-89464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: twl4030_charger: cancel workers via devm bci is devm-allocated. Two workers (bci->work and bci->current_worker) dereference it. twl4030_bci_remove() disables charging and masks interrupts. It cancels neither worker. A worker pending at remove() can run after devm frees bci. The USB transceiver comes from devm_usb_get_phy_by_node(). devm unregisters its notifier only after remove() returns. A cancel_work_sync() in remove() can then race a notifier reschedule. devm_work_autocancel() and devm_delayed_work_autocancel() avoid that. They cancel the workers during devm release, before bci is freed. The current_worker is registered first, since devm will cancel in reverse order and bci->work can reschedule current_worker. [Move comment about order into the commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89469", "url": "https://ubuntu.com/security/CVE-2026-89469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: lp8727: fix use-after-free in lp8727_release_irq() lp8727_isr_func(), the threaded IRQ handler, is the only caller that arms pchg->work via schedule_delayed_work(). lp8727_release_irq() currently cancels the work before freeing the IRQ, so an IRQ delivered in between can re-arm the work through the threaded handler. After .remove returns the devm layer frees pchg while lp8727_delayed_func() may still run and dereference it. Free the IRQ first so the threaded handler is quiesced and can no longer queue work, then cancel the delayed work to drain the final generation. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89470", "url": "https://ubuntu.com/security/CVE-2026-89470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS Currently the cros_usbpd-charger driver probe iterates based on raw charger port count returned by the embedded controller. The only check is against the number of USB PD ports which the embedded controller also defines. A malicious embedded controller could return an inaccurate port count (up to 255) resulting in an out of bounds write and subsequent memory corruption. Update helper functions in cros_usbpd-charger to limit port counts to EC_USB_PD_MAX_PORTS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89471", "url": "https://ubuntu.com/security/CVE-2026-89471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd-charger: bound the EC-reported port count cros_usbpd_charger_probe() reads two port counts from the EC and uses one of them, num_charger_ports, as the loop bound when populating a fixed-size array: \tstruct port_data *ports[EC_USB_PD_MAX_PORTS];\t/* 8 entries */ \t... \tfor (i = 0; i < charger->num_charger_ports; i++) \t\tcharger->ports[charger->num_registered_psy++] = port; Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports (from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The only validation is a sanity check that compares the two EC-reported values against each other: \tif (num_charger_ports < num_usbpd_ports || \t num_charger_ports > num_usbpd_ports + 1) \t\treturn -EPROTO; It never checks either count against EC_USB_PD_MAX_PORTS, the size of the ports[] array. A malfunctioning, malicious or compromised EC that reports num_usbpd_ports == num_charger_ports == N for any N > 8 (for example both 255) passes this check, and the loop then writes N pointers into the 8-entry ports[] array embedded in the devm_kzalloc()'d charger_data, overflowing it by up to 255 - 8 = 247 entries (~1976 bytes): a slab out-of-bounds write. Reject a port count larger than the ports[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89474", "url": "https://ubuntu.com/security/CVE-2026-89474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: drain usb_work before freeing the charger The USB-PHY notifier queues usb_work, whose handler calls power_supply_changed(bq->charger). The reset devm action only unregisters the notifier and was registered before the power supplies, so devm frees bq->charger on unwind before the action runs; a usb_work still queued can then dereference it. Register the reset action after the power supplies, so it unregisters the notifiers and drains usb_work before the supplies are released. Initialize usb_work and obtain the PHY references before registering the notifiers, so the worker cannot run before the supplies exist. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89475", "url": "https://ubuntu.com/security/CVE-2026-89475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq24257: fix use-after-free on remove The STAT-pin interrupt is devm-managed, so it stays armed until the devm cleanup that runs after remove() returns. remove() cancels bq->iilimit_setup_work while the threaded handler can still fire; that handler reschedules the work and dereferences bq, so the work runs against freed memory once devm frees bq. Make the delayed work device-managed with devm_delayed_work_autocancel(), registered before the interrupt request. The devm cleanup then releases the interrupt first, so the handler can no longer reschedule the work, and cancels the work before bq is freed. The explicit cancel_delayed_work_sync() in remove() is no longer needed and is dropped. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89476", "url": "https://ubuntu.com/security/CVE-2026-89476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix stream->outcnt underflow on duplicate RECONF responses A cached RECONF chunk may contain more than one request parameter. A duplicate response can therefore find and process the same ADD_OUT request again while another parameter is still outstanding, rolling back outcnt twice and possibly underflowing it. Track outstanding request types as bits and clear each bit after its first response. Later responses for the same request are then ignored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89477", "url": "https://ubuntu.com/security/CVE-2026-89477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix NULL deref on untransmitted RECONF completion sctp_process_strreset_outreq(), sctp_process_strreset_addstrm_out() and sctp_process_strreset_resp() complete a pending stream reconfiguration request by stopping the reconf timer on the transport it was sent on: \tt = asoc->strreset_chunk->transport; \tif (timer_delete(&t->reconf_timer)) \t\tsctp_transport_put(t); chunk->transport is assigned by __sctp_packet_append_chunk() when the chunk is appended to an outbound packet, and sctp_outq_flush_ctrl() arms the reconf timer at that same point. A request already published in asoc->strreset_chunk but not yet transmitted has neither, so completing it dereferences NULL. Two ways to get there. sctp_send_asconf_del_ip() sets asoc->src_out_of_asoc_ok without sending anything when the address being removed is the association's last one, and sctp_outq_flush_ctrl() then leaves every non-ASCONF control chunk queued; as only sctp_process_asconf_ack() clears that flag, it persists. An unprivileged process that removes such an address and then asks for a stream reset panics the kernel from softirq. A peer needs neither ASCONF nor local help: sctp_cmd_interpreter() uncorks the outqueue only once the whole packet has been processed, so a reply built while walking a RECONF chunk stays untransmitted for the rest of that walk, and one RECONF chunk carrying [Incoming SSN Reset Request, Outgoing SSN Reset Request, Response] -- or two RECONF chunks in one packet -- reaches the same dereference. KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef] RIP: 0010:timer_delete+0x67/0x110 Call Trace: sctp_process_strreset_addstrm_out (net/sctp/stream.c:832) sctp_sf_do_reconf (net/sctp/sm_statefuns.c:4212) sctp_do_sm (net/sctp/sm_sideeffect.c:1172) sctp_assoc_bh_rcv (net/sctp/associola.c:1044) sctp_rcv (net/sctp/input.c:243) ip_local_deliver (net/ipv4/ip_input.c:262) process_backlog (net/core/dev.c:6680) A response can only acknowledge a request that was actually sent, so do not match asoc->strreset_chunk while chunk->transport is NULL. Guarding the lookup covers all three completion sites.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89478", "url": "https://ubuntu.com/security/CVE-2026-89478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: drop a chunk if its transport was removed sctp_rcv() resolves the transport once per packet and leaves it in chunk->transport. The lookup reference, or the one sctp_add_backlog() takes if the socket is owned by userspace, keeps it around until the chunk has been processed. An authenticated ASCONF DEL-IP can remove it in the meantime. sctp_assoc_rm_peer() takes the transport out of the association and calls sctp_transport_free(), which tags it dead and drops the reference the association held. There is a window on both paths: the packet can sit on the socket backlog, and on the direct path the lookup completes before bh_lock_sock(). The DATA chunk in that packet puts the removed transport back into asoc->peer.last_data_from. Once the packet is done that reference goes away and the transport is freed by RCU, so the next delayed SACK carries the pointer into the SACK chunk and sctp_outq_select_transport() reads the freed transport's state. Drop the chunk in sctp_inq_push(), next to the existing rcvr->dead check. Both paths reach it with the association's socket lock held. The peer retransmits it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89479", "url": "https://ubuntu.com/security/CVE-2026-89479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stop processing a packet once its association is deleted sctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference. A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(), so the association and its transports are freed. The endpoint loop has no counterpart to the asoc->base.dead check in sctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed transport and is then passed to sctp_do_sm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context. The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctp_inq_free() releases the chunk on the association receive path. sctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89480", "url": "https://ubuntu.com/security/CVE-2026-89480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: reject a read that transferred too few bytes nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above. A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target. Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89482", "url": "https://ubuntu.com/security/CVE-2026-89482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone Commit 25e5cb780e62 (\"nvme-tcp: fix possible crash in write_zeroes processing\") established that blk_rq_payload_bytes() must not be read without first checking blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight, because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now tests the same two.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89483", "url": "https://ubuntu.com/security/CVE-2026-89483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: zero the discard fallback page nvme_setup_discard() always maps sizeof(struct nvme_dsm_range) * NVME_DSM_MAX_RANGES = 4096 bytes as the DSM payload however many ranges the command declares, because some devices ignore the 'Number of Ranges' field - the Fixes: commit records two that read past the declared ranges. A single-range discard fills only the first 16 bytes. Normally the buffer comes from kzalloc() and the other 4080 bytes are zero. When that allocation fails the code falls back to the per-controller ctrl->discard_page, which nvme_init_ctrl() obtains with alloc_page(GFP_KERNEL) and nothing ever zeroes, so those 4080 bytes are whatever the page last held and are handed to the controller. Reaching it requires the kzalloc(GFP_ATOMIC | __GFP_NOWARN) to fail, that is memory pressure; it is not remotely triggerable. Failing the allocation under KMSAN reproduces it, with the leaked tail full of vmemmap struct page pointers. The extent in the report is a partial transfer of the payload, not the whole 4096 bytes; the 16-byte boundary in it is the one declared range: [ 11.991601] BUG: KMSAN: uninit-value in dma_map_phys+0x14c8/0x1900 [ 11.991969] dma_map_phys+0x14c8/0x1900 [ 11.992220] dma_map_page_attrs+0xcf/0x130 [ 11.992485] e1000_xmit_frame+0x4099/0x6d10 [ 11.992768] dev_hard_start_xmit+0x22f/0xa80 [ 11.993068] sch_direct_xmit+0x35c/0xcb0 [ 11.993315] __dev_queue_xmit+0x1ee5/0x5eb0 [ 11.993608] ip_finish_output2+0x1903/0x1c30 [ 11.993881] ip_finish_output+0x288/0x870 [ 11.994125] ip_output+0x15e/0x400 [ 11.994365] __ip_queue_xmit+0x1e85/0x1fb0 [ 11.994639] ip_queue_xmit+0x60/0x80 [ 11.994899] __tcp_transmit_skb+0x4e71/0x5fa0 [ 11.995210] tcp_write_xmit+0x3a36/0x9160 [ 11.995533] __tcp_push_pending_frames+0xc5/0x3c0 [ 11.995854] tcp_push+0x7dc/0x840 [ 11.996076] tcp_sendmsg_locked+0x766c/0x8400 [ 11.996371] tcp_sendmsg+0x4b/0x90 [ 11.996572] inet_sendmsg+0x134/0x2a0 [ 11.996823] __sock_sendmsg+0x265/0x360 [ 11.997076] sock_sendmsg+0x100/0x1e0 [ 11.997293] nvme_tcp_try_send+0x196f/0x6370 [ 11.997605] nvme_tcp_queue_rq+0x1d54/0x20b0 [ 11.997882] blk_mq_dispatch_rq_list+0x5ee/0x2e50 [ 11.998175] __blk_mq_sched_dispatch_requests+0x16dc/0x24a0 [ 11.998539] blk_mq_sched_dispatch_requests+0x11b/0x2c0 [ 11.998865] blk_mq_run_work_fn+0x13b/0x280 [ 11.999146] process_scheduled_works+0x966/0x1ad0 [ 11.999465] worker_thread+0xe44/0x1480 [ 11.999709] kthread+0x53b/0x600 [ 11.999927] ret_from_fork+0x29f/0x7c0 [ 12.000191] ret_from_fork_asm+0x1a/0x30 [ 12.000460] [ 12.000558] Uninit was created at: [ 12.000788] __alloc_frozen_pages_noprof+0x8bf/0xd30 [ 12.001096] alloc_pages_mpol+0x1d0/0x5f0 [ 12.001326] alloc_pages_noprof+0x102/0x290 [ 12.001627] nvme_init_ctrl+0x5a3/0x9f0 [ 12.001891] nvme_tcp_create_ctrl+0xd75/0x19b0 [ 12.002170] nvmf_dev_write+0x4c68/0x4fd0 [ 12.002426] vfs_write+0x587/0x1a10 [ 12.002636] __x64_sys_write+0x207/0x4f0 [ 12.002874] x64_sys_call+0x2ff0/0x3ea0 [ 12.003123] do_syscall_64+0x147/0x3b0 [ 12.003400] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 12.003680] [ 12.003777] Bytes 16-2843 of 2844 are uninitialized [ 12.004068] Memory access of size 2844 starts at ffff888109f82000 [ 12.004412] [ 12.004530] CPU: 0 UID: 0 PID: 101 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMECTL-gf5098b6bae76 #1 PREEMPT(lazy) [ 12.005127] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 12.005762] Workqueue: kblockd blk_mq_run_work_fn [ 12.006073] ===================================================== Allocate the page with __GFP_ZERO. The single allocation site covers every use of it: bytes no discard has written stay zero, and bytes one did write hold that controller's own range list, which it has already been sent.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89485", "url": "https://ubuntu.com/security/CVE-2026-89485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: pin next file across nlm_inspect_file lock-drop nlm_traverse_files() pins the current file with f_count++ across a mutex_unlock for nlm_inspect_file(), but nothing pins the saved next pointer. A concurrent nlm_release_file() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step. Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock. Always call nlm_file_release() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlm_file_inuse(), which does a live walk of the inode lock list, rather than the cached f_locks field, so skipped files that never ran nlm_inspect_file() are evaluated correctly. Because every file in a hash bucket is now pinned and released, files skipped by the is_failover_file predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89487", "url": "https://ubuntu.com/security/CVE-2026-89487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: only skb_tx_error() a packet we are about to drop queue_userspace_packet() borrows the packet skb -- it only copies it into a private netlink message (user_skb) and does not own it; on return do_execute_actions() keeps forwarding it through the flow's remaining actions. Its error path nevertheless calls skb_tx_error(skb), which via skb_zcopy_clear() does skb_shinfo(skb)->flags &= ~SKBFL_ALL_ZEROCOPY, stripping SKBFL_SHARED_FRAG from that live skb (skb_tx_error()'s kerneldoc says \"skb must be freed afterwards\"). For a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG is what makes esp_input() skb_cow_data() before in-place AEAD; once it is stripped a later local ESP-in-UDP delivery decrypts in place over pages the sender does not own -- an unprivileged page-cache write (the \"Fragnesia\" primitive). do_execute_actions() ignores output_userspace()'s return value, so any action after a failed USERSPACE upcall inherits the stripped skb. Move the skb_tx_error() to the flow-miss drop path - the \"default\" branch of ovs_dp_process_packet()'s switch(error), before kfree_skb(). The call has been here since commit 36d5fe6a0007 (\"core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors\") but was harmless until esp_input() began relying on SKBFL_SHARED_FRAG to gate in-place decrypt; only then did stripping it on a still-forwarded skb become a page-cache write primitive.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89489", "url": "https://ubuntu.com/security/CVE-2026-89489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openrisc: fix arbitrary kernel memory access via or1k_atomic syscall sys_or1k_atomic() (syscall 244 in the \"or1k\" ABI) takes two user pointers, v1 and v2, and swaps the words they point to in hand-written assembly. l.lwz r29,0(r4) l.lwz r27,0(r5) l.sw 0(r4),r27 l.sw 0(r5),r29 The pointers are not checked with access_ok(). The four memory accesses also have no exception table entries. A caller passes a kernel address as either pointer, and the syscall reads from and writes to it directly. This gives an unprivileged process a kernel read/write primitive. It overwrites kernel data such as the sys_call_table, gaining code execution in kernel context. Check both pointers before entering the critical section. Add fixups for the four memory accesses so faults on valid but unmapped user addresses return -EFAULT. [shorne@gmail.com: fix comment style]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89490", "url": "https://ubuntu.com/security/CVE-2026-89490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix readdir position truncation on 32-bit kernels In ocfs2_dir_foreach_blk_el(), the directory cookie position is rebuilt with \tctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset; `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask \t~(sb->s_blocksize - 1) is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB block size). In the AND expression with the 64-bit `ctx->pos`, that unsigned operand is zero-extended to 64 bits per the usual arithmetic conversions, yielding 0x00000000fffff000. The high 32 bits of `ctx->pos` are silently cleared, even though directory size is allowed to exceed 4 GiB. When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position is reset back into the first 4 GiB block, making the re-validation path re-enumerate already-returned dirents indefinitely. This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken for all non-inline directories, so a directory large enough to cross 4 GiB reaches it. This is the same class of bug that commit 3dce5bb82c97 (\"exfat: Fix bitwise operation having different size\") fixed in exfat, and the fix mirrors the equivalent ext4 fix in this series. Cast the operand to loff_t so the mask is 64-bit before the AND: \tctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89491", "url": "https://ubuntu.com/security/CVE-2026-89491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cluster: don't sleep while holding o2hb_live_lock in o2hb_region_pin() Patch series \"ocfs2: cluster: o2hb_region_pin() fixes\", v2. This series fixes three related issues in o2hb_region_pin(), all are from the original implementation in commit: 58a3158a5d17 (\"ocfs2/cluster: Pin/unpin o2hb regions\"): 1) It is called with o2hb_live_lock (a spinlock) held, but the underlying configfs_depend_item() sleeps (takes inode rwsem and pins the filesystem). This triggers BUG under CONFIG_DEBUG_ATOMIC_SLEEP. 2) When called from the configfs drop_item callback, it creates a lock order inversion: parent inode_lock -> configfs root inode_lock, which can deadlock against subsystem unregistration paths taking root -> parent. 3) If pinning fails partway through o2hb_region_inc_user(), the o2hb_dependent_users counter is leaked and partially-pinned regions are never released, leaving heartbeat regions unprotected on subsequent mounts. Patch 1 reworks o2hb_region_pin() to drop o2hb_live_lock across each sleeping configfs_depend_item() call, using a config_item reference to keep the region alive while unlocked. Patch 2 adds a from_callback parameter to select configfs_depend_item_unlocked() when called from configfs context, avoiding the inode_lock nesting. Patch 3 fixes the error path in o2hb_region_inc_user() to unpin and decrement the counter on failure. This patch (of 3): o2hb_region_pin() is always called with the o2hb_live_lock spinlock held (from o2hb_region_inc_user() and o2hb_heartbeat_group_drop_item()), but it calls o2nm_depend_item() -> configfs_depend_item(), which sleeps: it pins the configfs filesystem and takes the configfs root inode rwsem. Under CONFIG_DEBUG_ATOMIC_SLEEP this triggers: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c in_atomic(): 1, ... name: mount.ocfs2 down_write configfs_depend_item o2hb_region_pin o2hb_region_inc_user o2hb_register_callback dlm_register_domain_handlers ... ocfs2_dlm_init ocfs2_mount_volume ocfs2_fill_super Rework o2hb_region_pin() to pin one region at a time with the lock dropped across the sleeping call: under o2hb_live_lock find the next eligible region and take a config_item reference to keep it alive, drop the lock, call o2nm_depend_item(), then retake the lock and record the pin. The config_item_put() is done with the lock released as well, since o2hb_region_release() also acquires o2hb_live_lock and can sleep. The region list may change while unlocked, so the scan restarts from the top after each pin. Local heartbeat still pins only the matching region; global heartbeat pins all eligible regions. The unpin path is unaffected: configfs_undepend_item() only takes a spinlock and does not sleep.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89493", "url": "https://ubuntu.com/security/CVE-2026-89493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate rl_used against rl_count in refcount block validator ocfs2_find_refcount_rec_in_rl() walks the on-disk refcount record array with: \tfor (; i < le16_to_cpu(rb->rf_records.rl_used); i++) { \t\trec = &rb->rf_records.rl_recs[i]; \t\t... rl_recs[] lives in a single metadata block (4096 bytes on the common configuration), so its real capacity is fixed by ocfs2_refcount_recs_per_rb(sb) (247 records for a 4K block with the 16-byte ocfs2_refcount_rec). rl_used and rl_count are both read directly off disk by ocfs2_validate_refcount_block() and are never checked against that capacity, nor against each other, before any refcount/reflink/CoW operation walks the array. A crafted (or corrupted) refcount block with rl_used == 0xffff makes the loop above walk far past the end of the block, dereferencing rl_recs[i] for i up to 65534. The resulting index is then handed to the sibling ocfs2_insert_refcount_rec(), whose insert-shift does: \tif (index < le16_to_cpu(rf_list->rl_used)) \t\tmemmove(&rf_list->rl_recs[index + 1], \t\t\t&rf_list->rl_recs[index], \t\t\t(le16_to_cpu(rf_list->rl_used) - index) * \t\t\t sizeof(struct ocfs2_refcount_rec)); i.e. a memmove() of up to (0xffff - index) * 16 bytes (~1 MiB) from an offset already past the block. This is reachable from an ordinary reflink (FICLONE) against a crafted/corrupted ocfs2 image: attaching an extent whose cpos sorts past every real record in the leaf forces the lookup to run off the end instead of returning early on a match. The attacker model is local: CAP_SYS_ADMIN mounting a crafted or corrupted ocfs2 image, or a raw write to the block device backing an already-mounted ocfs2 filesystem. ocfs2_validate_refcount_block() already validates the block's ECC, signature, rf_blkno and rf_fs_generation, but never rl_count/rl_used against the block's actual on-disk capacity. This is the same class of gap that ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) already closes for the sibling extent-list header, which checks both the record capacity and the \"used\" bound before any code walks h_list.l_recs[]: \tif (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) { \t\trc = ocfs2_error(...); \t\tgoto bail; \t} \tif (le16_to_cpu(eb->h_list.l_next_free_rec) > \t le16_to_cpu(eb->h_list.l_count)) { \t\trc = ocfs2_error(...); \t\tgoto bail; \t} Add the equivalent pair of checks to ocfs2_validate_refcount_block(): reject a refcount block whose rl_count does not match the fixed per-block capacity returned by ocfs2_refcount_recs_per_rb(), and reject rl_used > rl_count. Both checks are skipped when OCFS2_REFCOUNT_TREE_FL is set, because in that case the same union bytes hold an ocfs2_extent_list (rf_list), not the refcount record list (rf_records) -- that layout is already validated separately by ocfs2_validate_extent_block() when the referenced extent block is read. This mirrors the existing \"!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)\" guard used elsewhere in this file (e.g. ocfs2_get_refcount_rec()) to decide whether rf_records or rf_list is the live member of the union. With this in place, a forged rl_used/rl_count is caught at block validation time (ocfs2_error()), consistent with every other corruption check in this function, instead of driving an out-of-bounds read in ocfs2_find_refcount_rec_in_rl() and a subsequent out-of-bounds memmove() in ocfs2_insert_refcount_rec(). Verified against a crafted image on a v6.19 KASAN (KASAN_GENERIC) build: replaying the same reflink (FICLONE) reliably hit a KASAN report in __ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() before this patch, and triggers no report once ocfs2_validate_refcount_block() rejects the forged rl_used/rl_count.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89494", "url": "https://ubuntu.com/security/CVE-2026-89494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate lengths in dlm_mig_lockres_handler A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres->ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain. Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres->lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len <= DLM_LOCKID_NAME_MAX, num_locks <= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89495", "url": "https://ubuntu.com/security/CVE-2026-89495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: bound namelen in dlm_migrate_request_handler Patch series \"ocfs2/dlm: bound peer-controlled lengths in the o2dlm\". The o2dlm receive handlers trust u8 length and count fields from the wire without bounding them, so a node in a DLM domain can corrupt or panic any other node with a malformed message. Three defects: - dlm_migrate_request_handler() passes migrate->namelen unchecked to dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an o2dlm_mle slab object: a heap out-of-bounds write of up to ~215 attacker-controlled bytes. - dlm_mig_lockres_handler() passes mres->lockname_len unchecked to dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname slab object: a heap out-of-bounds write of up to ~223 bytes. - the same handler trusts mres->num_locks without checking that the message is large enough to hold that many entries, so dlm_process_recovery_data() walks mres->ml[] past the kmalloc(data_len) copy and trips a BUG_ON (an out-of-bounds read ending in a panic). The other o2dlm receive handlers already reject an oversized name; the migration and recovery handlers have omitted it since the DLM was added (see the Fixes tags). Patch 1 bounds namelen; patch 2 validates lockname_len, num_locks, and the payload size. Conforming recovery and migration traffic is unaffected. o2net authenticates peers only by the DLM domain key, so any node that has joined the domain -- including a compromised or malicious member -- can send these messages. There is no local trigger; the attacker must already be a member of the cluster. Each sink was confirmed under KASAN with an out-of-tree module mirroring it exactly -- a kmem_cache/kmalloc of the real destination size, then the same unclamped memcpy/loop: slab-out-of-bounds Write for the two writes, Read for the recovery walk, and a panic. A userspace AddressSanitizer build faults identically under -m32 and -m64. Scrubbed logs are available on request. I reported this privately to security@kernel.org and the ocfs2 maintainers on 2026-06-20; with no response after the standard embargo period I am posting the fix publicly. I have no embargo requirement. This patch (of 2): A node receiving a DLM_MIGRATE_REQUEST message trusts the peer-supplied name length (migrate->namelen) without bounding it. dlm_init_mle() then copies that many bytes into the fixed DLM_LOCKID_NAME_MAX-byte mname[] array of an o2dlm_mle slab object, so a malformed message from a cluster peer overflows the slab object by up to ~215 bytes: a heap out-of-bounds write of attacker-controlled data, reachable by any node in the domain. Reject an oversized name, the way dlm_master_request_handler() and the other o2dlm receive handlers already do; the migration handler omits the check entirely. Conforming messages are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89496", "url": "https://ubuntu.com/security/CVE-2026-89496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: always run deallocs on copy-on-write completion Local fuzzing of 6.12.94 has found the following memory leak caused by doing 'copy_file_range()' within the same filesystem: unreferenced object 0xffff88812192c980 (size 32): comm \"syz.0.49\", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................ c0 c5 92 21 81 88 ff ff 00 02 00 00 00 06 00 00 ...!............ backtrace (crc 7068d63f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] ocfs2_find_per_slot_free_list fs/ocfs2/alloc.c:6618 [inline] ocfs2_cache_block_dealloc+0x155/0x4b0 fs/ocfs2/alloc.c:6786 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:944 [inline] direct_splice_actor+0x232/0x480 fs/splice.c:1167 splice_direct_to_actor+0x4b4/0xb60 fs/splice.c:1111 do_splice_direct_actor fs/splice.c:1210 [inline] do_splice_direct+0x10f/0x1c0 fs/splice.c:1236 do_sendfile+0x430/0xbf0 fs/read_write.c:1388 unreferenced object 0xffff88812192c5c0 (size 32): comm \"syz.0.49\", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 29 70 00 00 00 00 00 00 19 00 00 00 00 00 00 00 )p.............. backtrace (crc afec850f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ocfs2_cache_block_dealloc+0x25c/0x4b0 fs/ocfs2/alloc.c:6793 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:9 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89497", "url": "https://ubuntu.com/security/CVE-2026-89497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: skip leading spaces before parsing client debug masks orangefs_prepare_cdm_array() sizes each client debug keyword buffer with strcspn(cds_head, \" \"), but then parses the keyword with %s. The %s conversion skips leading whitespace, while strcspn() does not. If a client debug entry starts with a space, the allocation can be sized for an empty keyword while sscanf() copies the following non-empty token. This can write past the end of the allocated keyword buffer. Skip leading spaces before computing the keyword length so the allocation matches the string parsed by sscanf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89498", "url": "https://ubuntu.com/security/CVE-2026-89498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix double-free of trailer_buf on readdir copy failure On a readdir downcall, orangefs_devreq_write_iter() frees op->downcall.trailer_buf with vfree() when copy_from_iter_full() fails, but does not clear the pointer before goto Efault. The waiter in do_readdir() is then woken with a negative status and frees the same pointer again on its r < 0 path, causing a deterministic double-free. A client holding /dev/pvfs2-req triggers it by sending a readdir downcall whose declared trailer_size exceeds the bytes it supplies. Clear the pointer after freeing so the readdir-side vfree() becomes a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89504", "url": "https://ubuntu.com/security/CVE-2026-89504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: as3722_get_regulator_dt_data: fix premature of_node_put leaving dangling of_node pointer In as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a reference on np, which is then assigned to pdev->dev.of_node. The function immediately calls of_node_put(np), releasing the reference and leaving pdev->dev.of_node as a dangling pointer. Remove the of_node_put(np) call to let the device hold the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89508", "url": "https://ubuntu.com/security/CVE-2026-89508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Lock the handler in ucma_set_ib_path() ucma_set_ib_path() calls ucma_event_handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference: \tmutex_lock(&ctx->file->mut);\t\t\t/* file A */ \tlist_add_tail(&uevent->list, &ctx->file->event_list);\t/* file B */ \tmutex_unlock(&ctx->file->mut);\t\t\t/* file B */ \twake_up_interruptible(&ctx->file->poll_wait);\t/* file B */ A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION caller sleeps in mutex_lock(), so the list_add_tail() lands on file B's event_list while only file A's mutex is held, racing every other user of that list: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0 Read of size 8 at addr ffff888153c6a418 by task poc_corr/486 Call Trace: __list_add_valid_or_report+0x1aa/0x1c0 ucma_event_handler+0x1be/0xc00 ucma_set_ib_path+0x45e/0x710 ucma_set_option+0x32e/0x590 ucma_write+0x1f9/0x330 Allocated by task 505: ucma_write_cm_event+0x1a1/0x660 Freed by task 505: kfree+0x1da/0x4c0 ucma_get_event+0x5d5/0x7e0 The freed object is a ucma_event that another thread dequeued from file B's list under file B's mutex. File A's mut is left held on top of that, wedging its next writer in uninterruptible sleep. This path needs a bound and address-resolved cm_id, so it requires an RDMA device to be present. Take the handler lock around the call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89510", "url": "https://ubuntu.com/security/CVE-2026-89510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Cancel reg_work before freeing device on remove c4iw_uld_state_change() queues reg_work to register the RDMA device. c4iw_remove() can free ctx->dev while this work is pending or running, leaving c4iw_register_device() accessing the freed device. Cancel reg_work before removing the device. The registration work can tear down ctx->dev when registration fails, so do not unregister or deallocate it again in that case. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89511", "url": "https://ubuntu.com/security/CVE-2026-89511", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: Fix NULL pointer dereference in TPA fragment processing Under memory pressure, the qede driver encounters NULL pointer dereferences when processing TPA continuation fragments. Commit 8a8633978b84 (\"qede: Add build_skb() support.\") accidentally dropped the assignment of tpa_info->buffer.data in qede_tpa_start(). When memory pressure causes an SKB allocation failure in qede_tpa_start(), the driver sets tpa_start_fail = true and attempts to recycle the physical page later in qede_tpa_end() via qede_reuse_page(). However, because buffer.data was left uninitialized (NULL), qede_reuse_page() pushes a \"ghost\" BD (valid DMA mapping but NULL data pointer) back into the active Rx ring. The next time the hardware uses this ring slot, it passes a NULL page to qede_fill_frag_skb(), causing a kernel panic. Example crash from production system: BUG: unable to handle kernel NULL pointer dereference at 0x8 RIP: qede_fill_frag_skb+0x96/0x430 [qede] Call Trace: qede_rx_int+0xb06/0x1de0 qede_poll+0x2f4/0x6c0 __napi_poll+0x2d/0x130 Fix the root cause by restoring the tpa_info->buffer.data assignment in qede_tpa_start(), ensuring valid pages are correctly tracked and recycled. Additionally, update the stale comment for struct qede_agg_info::buffer to reflect its current usage.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89512", "url": "https://ubuntu.com/security/CVE-2026-89512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: scp: Fix device reference leak on failed lookup Make sure to drop the reference taken to the SCP device when attempting to look up its driver data before the driver has been bound. Note that holding a reference to a device does not prevent its driver data from going away.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89524", "url": "https://ubuntu.com/security/CVE-2026-89524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: clamp assoc request/response lengths before subtracting IE offsets ath6kl_cfg80211_connect_event() subtracts fixed IE offsets from assoc_req_len (-= 4) and assoc_resp_len (-= 6), both u8, with no lower bound. The aggregate check recently added to ath6kl_wmi_connect_event_rx() bounds the declared lengths from above (their sum must fit the received event), but an assoc request/response shorter than its fixed offset still underflows here: the u8 wraps to ~250, and cfg80211_connect_result() / cfg80211_roamed() then treat that wrapped value as the IE length and copy that many bytes out of the small assoc_info buffer to user space via nl80211, disclosing adjacent slab memory. Clamp both lengths to their offsets before subtracting. Found by 0sec (https://0sec.ai) using automated source analysis; the missing lower bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89525", "url": "https://ubuntu.com/security/CVE-2026-89525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: reject VAT indexes equal to the entry count UDF 1.50 virtual partition mapping uses the VAT as an array of physical block mappings. s_num_entries stores the number of entries in that array, not the highest valid index. The valid VAT indexes are therefore below s_num_entries. udf_get_pblock_virt15() currently rejects only indexes greater than s_num_entries. A crafted image can request index s_num_entries, pass the bounds check, and make the kernel read one entry past the allocated VAT table. Change the check to reject block >= s_num_entries, so the count is handled as an exclusive upper bound. A crafted UDF image reproduced this on origin/master commit 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53 with a KASAN slab-out-of-bounds report in udf_get_pblock_virt15(). Trail of Bits has a reproducer that triggers kernel panic demonstrating the bug, and can share it if needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89532", "url": "https://ubuntu.com/security/CVE-2026-89532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix pcl_for_each_segment for empty chunks When a parsed chunk list contains a chunk whose ch_segcount is zero, pcl_for_each_segment computes its inclusive upper bound as &chunk->ch_segments[ch_segcount - 1]. ch_segcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the ch_segments flex array. The loop body then walks unrelated memory at sizeof(struct svc_rdma_segment) stride until it faults. A zero-segcount chunk is reachable from the wire: xdr_check_write_chunk() only rejects segcount values greater than rc_maxpages, and pcl_alloc_write() links a freshly allocated chunk onto rc_write_pcl/rc_reply_pcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves ch_segcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svc_rdma_get_inv_rkey() iterates all four PCLs with pcl_for_each_segment and dereferences segment->rs_handle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault. xdr_check_write_list / xdr_check_reply_chunk pcl_alloc_write() chunk = pcl_alloc_chunk(...) /* ch_segcount = 0 */ list_add_tail(&chunk->ch_list, &pcl->cl_chunks) /* fill loop iterates zero times for wire segcount 0 */ svc_rdma_get_inv_rkey() pcl_for_each_chunk(rc_write_pcl) pcl_for_each_segment(segment, chunk) pos <= &ch_segments[0u - 1u] /* 0xFFFFFFFF */ segment->rs_handle /* OOB read -> GPF */ Fix by switching the macro to a half-open upper bound that uses ch_segcount directly. For ch_segcount == 0 the loop start equals the loop end and the body is skipped; for ch_segcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and net/sunrpc/xprtrdma/svc_rdma_rw.c remain correct under the new bound, so no caller changes are needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89533", "url": "https://ubuntu.com/security/CVE-2026-89533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix offset arithmetic in read_chunk_range svc_rdma_read_chunk_range() walks a Read chunk's segment list to build a sub-range starting at byte offset and spanning length bytes for a Position-Zero or Call chunk. Two arithmetic defects in the per-segment loop produce wrong DMA lengths and a u32 underflow: pcl_for_each_segment(segment, chunk) { if (offset > segment->rs_length) { offset -= segment->rs_length; continue; } dummy.rs_handle = segment->rs_handle; dummy.rs_length = min_t(u32, length, segment->rs_length) - offset; dummy.rs_offset = segment->rs_offset + offset; First, the skip predicate uses '>' instead of '>='. When offset equals the segment's full rs_length, the segment is fully consumed and should be skipped, but the loop falls through into the body. The resulting dummy.rs_length is min_t(u32, length, rs_length) - rs_length, which underflows to a near-UINT_MAX u32 when length is smaller than rs_length, or is zero otherwise. Second, the length formula subtracts offset from the min_t() result rather than from segment->rs_length before the cap. For offset > 0 the segment's residual is rs_length - offset, not rs_length, so the cap must be applied to the residual. With the current bracketing, whenever length is smaller than rs_length - offset the per-segment length becomes length - offset instead of length, silently dropping offset bytes from the rebuilt chunk. Combined with the boundary case above it also enables the u32 underflow path, which propagates a huge nr_bvec into svc_rdma_build_read_segment() and a multi-MiB kmalloc_array_node() in svc_rdma_get_rw_ctxt(). Additionally, svc_rdma_read_call_chunk() can invoke this function with length == 0 when the last Read chunk ends exactly at the end of the Call chunk. With the corrected >= predicate, every segment is skipped and the function returns the initial -EINVAL, rejecting a valid request. Return success immediately when length is zero. Also break out of the loop once length is fully consumed to avoid passing zero-length segments to svc_rdma_build_read_segment(). Fix by using '>=' so a fully-consumed segment is skipped, by moving '- offset' inside min_t() so the cap is applied to the segment's residual length, by returning success for zero-length requests, and by stopping iteration when the requested range has been consumed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89538", "url": "https://ubuntu.com/security/CVE-2026-89538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field gss_krb5_unwrap_v2() sets buf->len to a logical length, which can be much smaller than head[0].iov_len (the allocated receive-page capacity). It then calls xdr_buf_trim() with a trim length derived from the 16-bit \"extra count\" (ec) field in the Kerberos v2 token header. The ec field is authenticated by the post-decrypt memcmp() against the encrypted header copy, so a randomly-mutated value is rejected. However, any peer holding a valid GSS context can legitimately encrypt a token whose ec exceeds the plaintext length. Per RFC 4121, such a token is structurally malformed. Although xdr_buf_trim() now clamps the buf->len subtraction to avoid unsigned underflow, the buffer is still left in a semantically invalid state (zero length, inconsistent iov lengths) when ec is oversized. Reject these tokens before calling xdr_buf_trim(), giving callers a well-defined GSS_S_DEFECTIVE_TOKEN error and keeping the xdr_buf internally consistent. The wrapped blob begins at a nonzero offset -- both callers pass len as offset + opaque_len -- so buf->len still counts the offset bytes that precede the blob. Compare the trim length against the remaining wrapped segment, buf->len - offset, rather than the whole buffer; comparing against buf->len alone leaves an offset-wide window in which an oversized ec passes the test and xdr_buf_trim() cuts into the bytes ahead of the blob.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89540", "url": "https://ubuntu.com/security/CVE-2026-89540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: init gssp_lock before publishing proc entry create_use_gss_proxy_proc_entry() publishes /proc/net/rpc/use-gss-proxy via proc_create_data() before init_gssp_clnt() runs mutex_init() on sn->gssp_lock. Once the dentry is linked under proc_subdir_lock it is immediately reachable from userspace, so a write that lands in the window drives set_gssp_clnt() into mutex_lock() on a zero-initialized struct mutex. create_use_gss_proxy_proc_entry(net) proc_create_data(\"use-gss-proxy\", ...) /* dentry live */ init_gssp_clnt(sn) mutex_init(&sn->gssp_lock) /* too late */ write_gssp() set_gssp_clnt(net) mutex_lock(&sn->gssp_lock) /* uninitialized */ gssp_rpc_create(...) sn->gssp_clnt = clnt mutex_unlock(&sn->gssp_lock) The window spans only the two statements between proc_create_data() returning and init_gssp_clnt(), so a writer reaches it only if the registering thread is preempted there while another task is already opening the freshly published file. register_pernet_subsys() runs in preemptible context under pernet_ops_rwsem, so that preemption is possible, and the window widens on auth_rpcgss module load, when the proc entry is created for every live net namespace whose tasks are already running. A writer that wins the race locks a zero-filled struct mutex. On CONFIG_DEBUG_MUTEXES the missing magic value trips a \"lock used without init\" splat; on a production kernel the fast path acquires the lock via CMPXCHG(owner, 0, current). In the latter case a second writer that arrives before init_gssp_clnt() re-zeroes owner can enter set_gssp_clnt() concurrently, shut down the first writer's clnt while it is still in use, and leak the loser's clnt. Fix by initializing sn->gssp_lock in sunrpc_init_net() so its lifetime matches the sunrpc_net it lives in. sn->gssp_clnt is already NULL from the kzalloc that backs net_generic storage, so the lazy helper is no longer needed; drop init_gssp_clnt(), its prototype, and the call from create_use_gss_proxy_proc_entry(). sunrpc.ko is a build-time dependency of auth_rpcgss.ko, so sunrpc_init_net() has always run on every netns before any auth_gss pernet init can publish the proc entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89541", "url": "https://ubuntu.com/security/CVE-2026-89541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_unwrap_resp_priv length checks gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 (\"SUNRPC: svcauth_gss: enforce krb5 token minimum length\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89542", "url": "https://ubuntu.com/security/CVE-2026-89542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_krb5_unwrap_v2 against short tokens gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and ptr+6 before validating that the token is at least GSS_KRB5_TOK_HDR_LEN (16) bytes long, and its rotate_left() helper passes buf->len - base to xdr_buf_subsegment() without verifying that base <= buf->len. When a caller hands in a sub-16-byte token, or a token whose declared len leaves base past the end of the buffer, three distinct failures follow: gss_krb5_unwrap_v2(offset, len, buf) ptr = buf->head[0].iov_base + offset ec = *(ptr + 4) /* OOB read on short head */ rrc = *(ptr + 6) /* OOB read on short head */ rotate_left(offset + 16, buf, rrc) xdr_buf_subsegment(buf, &subbuf, base, buf->len - base) /* u32 wrap when base > len */ _rotate_left(&subbuf, shift) shift %= buf->len /* divide-by-zero when base == len */ After decryption, the cleanup arithmetic has the same shape: movelen = min_t(unsigned int, buf->head[0].iov_len, len); movelen -= offset + GSS_KRB5_TOK_HDR_LEN + headskip; BUG_ON(offset + GSS_KRB5_TOK_HDR_LEN + headskip + movelen > buf->head[0].iov_len); The BUG_ON re-adds the value just subtracted, so it reduces to min(A, B) > A and is permanently false; it cannot catch the unsigned underflow of movelen, which then drives a ~UINT_MAX-byte memmove(). Add four defense-in-depth guards inside the unwrap core so it is safe regardless of what its callers validate: - reject tokens with len - offset < GSS_KRB5_TOK_HDR_LEN before touching ptr+4/ptr+6; - bail from rotate_left() when buf->len <= base, covering both the underflow and zero-length cases; - return early from _rotate_left() when buf->len is zero, so the shift %= buf->len modulo cannot fault; - replace the dead BUG_ON with a live check that returns GSS_S_DEFECTIVE_TOKEN before the movelen subtraction.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89548", "url": "https://ubuntu.com/security/CVE-2026-89548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: always drain cache_cleaner before destroying a cache_detail sunrpc_destroy_cache_detail() only cancels the global cache_cleaner delayed_work when cache_list is empty. During per-netns teardown cache_list is never empty because init_net's caches remain registered, so the cancel never fires. After unlink, the caller proceeds to cache_destroy_net() which kfrees the cache_detail while cache_clean() may still hold a dangling pointer to it. The result is a use-after-free: cache_dequeue() takes cd->queue_lock on freed memory, and cache_put() dereferences cd->cache_put as a function pointer from freed slab. Drop the list_empty guard so that cancel_delayed_work_sync() always runs, ensuring any in-flight cache_clean() completes before the cache_detail is freed. Re-arm the cleaner afterwards if other caches are still registered.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89549", "url": "https://ubuntu.com/security/CVE-2026-89549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: route to a populated pool in svc_pool_for_cpu() svc_set_num_threads() spreads the requested threads evenly across the service's pools (base = nrservs / sv_nrpools). When a service runs fewer threads than it has pools -- e.g. an nfsd configured with fewer threads than the host has NUMA nodes while running in \"pernode\" or \"percpu\" mode -- the trailing pools are left with no threads at all. svc_xprt_enqueue() selects a pool from the CPU servicing the transport, queues the transport on that pool's sp_xprts, and only wakes a thread from the same pool. Each thread services exclusively its own pool, so a transport that lands on a threadless pool is enqueued on sp_xprts and never picked up: the connection hangs indefinitely. Have svc_pool_for_cpu() skip pools that currently have no threads, falling back to the next populated pool. This trades NUMA locality for a guarantee that the work is actually serviced. sp_nrthreads is only updated under the service mutex; the lockless read here is a best-effort routing hint, so annotate it with data_race().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89551", "url": "https://ubuntu.com/security/CVE-2026-89551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow xdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by walking the tail, pages, and head iovecs. Each per-section step uses min_t() so it never removes more bytes than that section holds, but the final accounting at the fix_len label subtracts the total bytes actually consumed from buf->len without any clamp: fix_len: buf->len -= (len - trim); When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches xdr_buf_trim() in exactly that state: buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip; buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip); xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip); buf->len is a small wire-derived value while the iov_lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder. Fix by clamping the decrement so buf->len bottoms out at zero: buf->len -= min_t(unsigned int, buf->len, len - trim); On the normal path where the iov_lens sum to buf->len, (len - trim) is always <= buf->len and the result is identical to before. No callers change behavior outside the underflow case.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89554", "url": "https://ubuntu.com/security/CVE-2026-89554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection. Restore subflow_req->local_id from the cookie entry, as done for the other fields.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89555", "url": "https://ubuntu.com/security/CVE-2026-89555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: reload header after pskb_may_pull() mpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop when an MPLS route has multiple nexthops. While walking the MPLS label stack, the hash routine caches hdr for the current label. After finding the bottom-of-stack label, it calls pskb_may_pull() before reading the inner IP header. If an skb is constructed with the inner IP header in nonlinear data and insufficient tailroom in the linear head, pskb_may_pull() calls pskb_expand_head() to replace the skb head and free the old one. This leaves hdr pointing to freed memory. The IPv6 path can invalidate hdr again when it performs a second pull for the larger header. The issue was found through static analysis. A reproducer sending a legal Geneve packet through a bareudp/MPLS multipath setup triggered the same KASAN report in 2 of 2 unpatched runs: BUG: KASAN: slab-use-after-free in mpls_select_multipath Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23 Call Trace: mpls_select_multipath mpls_forward __netif_receive_skb_list_core netif_receive_skb_list_internal napi_complete_done gro_cell_poll __napi_poll net_rx_action Freed by task 23: kfree pskb_expand_head __pskb_pull_tail mpls_select_multipath Reload hdr from the current skb head after each successful pull before deriving the inner IPv4 or IPv6 header pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89557", "url": "https://ubuntu.com/security/CVE-2026-89557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: do overflow check for sb->bblog_shift in super_1_load() In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 } bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c. Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller. This may avoid unnecessary check, make the badblocks API code more simple and elegant.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89559", "url": "https://ubuntu.com/security/CVE-2026-89559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Prevent integer overflow in __nd_label_validate() The on-media namespace index field nslot is a u32 read from the DIMM label storage area. __nd_label_validate() bounds it against the config area size, but sizeof_namespace_label() returns unsigned, so the product nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before the comparison. A crafted nslot passes the bound and is then used as the loop trip count in nd_label_data_init(), whose memset() walks off the end of the config_size buffer: an out-of-bounds write. The field is not trusted -- it comes from the medium, or from userspace via ND_CMD_SET_CONFIG_DATA. Evaluate the product in 64-bit so the bound check is exact; conforming labels are unaffected. The check was safe when introduced by commit 4a826c83db4e (\"libnvdimm: namespace indices: read and validate\"): it multiplied by sizeof(struct nd_namespace_label), a size_t, so on a 64-bit build the product did not wrap. Commit 564e871aa66f (\"libnvdimm, label: add v1.2 nvdimm label definitions\") narrowed it to 32 bits when the label size became a runtime value read via sizeof_namespace_label().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93226", "url": "https://ubuntu.com/security/CVE-2026-93226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU iterator to dump route exceptions rt6_nh_dump_exceptions() uses hlist_for_each_entry() to iterate over RCU-protected exception lists. The caller holds rcu_read_lock(), but does not hold rt6_exception_lock, so rt6_insert_exception() can concurrently add an entry with hlist_add_head_rcu(). KCSAN reports this race (irrelevant details omitted): ================================================================== BUG: KCSAN: data-race in rt6_insert_exception / rt6_nh_dump_exceptions write (marked) to 0xffff8a7c44c59620 of 8 bytes by interrupt on cpu 5: rt6_insert_exception+0x3bb/0x760 __ip6_rt_update_pmtu+0x4fe/0x750 ip6_sk_update_pmtu+0x19a/0x3b0 udpv6_err+0x3ff/0x800 icmpv6_notify+0x1e1/0x440 icmpv6_rcv+0x8c0/0xab0 ip6_protocol_deliver_rcu+0x616/0x840 ip6_input_finish+0xb9/0x160 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff8a7c44c59620 of 8 bytes by task 549 on cpu 14: rt6_nh_dump_exceptions+0xb3/0x260 rt6_dump_route+0x53e/0x5f0 fib6_dump_node+0x6d/0xf0 fib6_walk_continue+0x290/0x2d0 fib6_dump_table+0x28d/0x360 inet6_dump_fib+0x37d/0x620 rtnl_dumpit+0x7b/0xd0 netlink_dump+0x3ae/0x7e0 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f 4 locks held by dumper/549: ... #1: (rcu_read_lock){....}-{1:3}, at: inet6_dump_fib+0x88/0x620 #2: (&tb->tb6_lock){+.-.}-{3:3}, at: fib6_dump_table+0x1e9/0x360 #3: (rcu_read_lock){....}-{1:3}, at: rt6_dump_route+0x483/0x5f0 value changed: 0xffff8a7c44e05700 -> 0xffff8a7c45d60100 Reported by Kernel Concurrency Sanitizer on: CPU: 14 UID: 0 PID: 549 Comm: dumper Not tainted 7.2.0-rc7-virtme #38 PREEMPT(lazy) ... Use hlist_for_each_entry_rcu() to safely iterate over the exception list.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89562", "url": "https://ubuntu.com/security/CVE-2026-89562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: fix hardware header length for NBMA tunnels ip6gre_tnl_link_config_route() accumulates the lower device's hardware header length into dev->hard_header_len whenever header_ops is set. This is incorrect for both users of header_ops. ip6gretap and ip6erspan have a fixed Ethernet hardware header length. For an NBMA ip6gre tunnel, ip6gre_header() creates only the GRE header, the optional FOU or GUE header, and the outer IPv6 header. The lower device header is headroom needed later, not part of the tunnel device's hardware header. Keep the lower device header in needed_headroom. Set hard_header_len to the tunnel header length only for ARPHRD_IP6GRE devices with header_ops, and leave the fixed Ethernet header length unchanged for tap and erspan devices.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89563", "url": "https://ubuntu.com/security/CVE-2026-89563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit() ip6_tnl_xmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skb_realloc_headroom(), copies skb->sk ownership, consumes the original skb, and then continues processing with the replacement skb kept only in its local variable. That is safe only if the helper cannot fail afterwards. But this helper still has post-reallocation error exits. collect_md tunnels reject non-NONE encap after the replacement, and ip6_tnl_encap() can also fail later. In those cases the helper returns an error to its callers while the caller still only has the original skb pointer. Both ip6_tnl_start_xmit() and the IPv6 GRE paths free the caller skb on error, so they can end up freeing an skb that ip6_tnl_xmit() already consumed. Use skb_cow_head() instead. It provides the required headroom and writability without privately replacing the caller-owned skb, so later error returns cannot leave callers with a stale pointer. The Ethernet users, ip6gretap and ip6erspan, clear IFF_TX_SKB_SHARING and already call skb_cow_head() before entering ip6_tnl_xmit(). They do not rely on the removed skb_shared() reallocation. This also makes the IPv6 tunnel path consistent with ip_tunnel_xmit().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89569", "url": "https://ubuntu.com/security/CVE-2026-89569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: serialize security confirmation handling rfcomm_security_cfm() looks up a session on session_list and then walks its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown uses rfcomm_mutex, krfcommd can close and free the same session and DLCs concurrently: hci_rx_work krfcommd ----------- --------- rfcomm_session_get() rfcomm_lock() rfcomm_session_close() rfcomm_dlc_unlink() rfcomm_session_del() kfree(s) rfcomm_unlock() walk s->dlcs The callback can then read a freed session list head and touch freed DLCs while updating their flags or timers. Serialize the session lookup and DLC traversal in rfcomm_security_cfm() with rfcomm_mutex. This matches the existing RFCOMM session lifetime rules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink() from tearing the objects down while the callback is using them. KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440 Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89 Workqueue: hci0 hci_rx_work Call Trace: rfcomm_security_cfm+0x41c/0x440 hci_encrypt_cfm+0x139/0x590 hci_encrypt_change_evt+0x37b/0xc40 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 69: rfcomm_session_add+0x9e/0x2f0 rfcomm_run+0x44b/0x41e0 Freed by task 69: kfree+0x131/0x3c0 rfcomm_session_del+0x188/0x220 rfcomm_run+0x1985/0x41e0", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89573", "url": "https://ubuntu.com/security/CVE-2026-89573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm array: reject an array block whose value size is not the caller's array_block_check() can only compare the header against itself, so a block with value_size 4 and max_entries 1018 is internally consistent and passes. dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and the roots for both live in the superblock. Point the mappings root at a hint block and __load_mappings() walks it through an info whose value size is 8, so element_at() strides 8 bytes over 4-byte entries and reaches offset 8160 of a 4096-byte block. get_ablock() and __shadow_ablock() are the two places that hold the block and the caller at once. Reject there when the two value sizes disagree. Arrays only ever read their own blocks, so this fires on crafted metadata only.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89575", "url": "https://ubuntu.com/security/CVE-2026-89575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm raid1: reserve space for NUL-terminator in build_constructor_string() Reserve space for the termination NUL after the maximum 20 decimal digits of a long long value to avoid buffer overflow in sprintf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89576", "url": "https://ubuntu.com/security/CVE-2026-89576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-era: fix shadowed superblock leak on take-snap failure metadata_take_snap() bumps the live superblock refcount and then dm_tm_shadow_block() allocates a new block for the metadata snapshot. If the subsequent dm_sm_inc_block() of writeset_tree_root or era_array_root fails, the function only unlocks the clone and returns. The newly allocated shadow block is never returned to the metadata space map, so each failed take-snap permanently leaks one metadata block. Free the clone with dm_sm_dec_block() on those error paths, matching the final step of metadata_drop_snap().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89582", "url": "https://ubuntu.com/security/CVE-2026-89582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix double free in bnx2x_init_firmware() error path bnx2x_init_firmware() frees bp->init_ops, bp->init_data and bp->init_ops_offsets in its error path without setting them to NULL. The cleanup function bnx2x_release_firmware() frees the same three pointers unconditionally, so if init_firmware fails and release_firmware is later called (e.g. from __bnx2x_remove or through the function state machine), all three are freed a second time. Set each pointer to NULL after kfree() in the error path so that the subsequent kfree(NULL) in bnx2x_release_firmware() is a safe no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89585", "url": "https://ubuntu.com/security/CVE-2026-89585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: auxdisplay: charlcd: cancel backlight work on registration failure With CONFIG_CHARLCD_BL_FLASH, charlcd_init() schedules bl_work before charlcd_register() calls misc_register(). If registration fails, the caller frees the charlcd object while delayed work still contains its address. Add charlcd_deinit() to cancel the delayed work and turn the backlight off. Use it for both registration rollback and normal unregistration.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89586", "url": "https://ubuntu.com/security/CVE-2026-89586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes ata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the UNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command. The TRIM descriptor is built by ata_format_dsm_trim_descr() into the 2048-byte ata_scsi_rbuf staging buffer, and the number of bytes copied is compared against the logical sector size by the caller: \tsize = ata_format_dsm_trim_descr(scmd, trmax, block, n_block); \tif (size != len)\t\t/* len == sdp->sector_size */ \t\tgoto invalid_param_len; ata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE (2048). On a device whose logical sector size exceeds that (e.g. a 4Kn device, where sector_size == 4096) the function can never return more than 2048, while the caller expects it to return sector_size. The comparison therefore always fails, so every TRIM is rejected with \"Parameter list length error\" and WARN_ON() splats on each attempt. TRIM / discard is thus completely broken on such devices. The descriptor was incorrectly sized from the logical sector size. A DSM TRIM payload is a list of 512-byte pages, each holding up to ATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical sector size. The Block Limits VPD page already advertises a single such page as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical blocks), so the block layer never sends a request that needs more than one page. Emit exactly one 512-byte page, independent of the logical sector size, and transfer only that page (COUNT == 1). For a 512-byte-sector device this is unchanged; devices with larger logical sectors now work instead of failing every TRIM.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89594", "url": "https://ubuntu.com/security/CVE-2026-89594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device The OMAP SSI driver uses a synthetic HSI controller device allocated via hsi_alloc_controller(), which does not go through the normal OF/platform device initialization path. As a result, the embedded struct device does not have a DMA mask initialized by default. After recent DMA API hardening changes, dma_map_sg() and related helpers now require a valid dma_mask to be present, otherwise the driver may crash or trigger warnings when attempting DMA mapping operations. Fix this by explicitly initializing the DMA mask for the SSI controller device and setting a 32-bit DMA mask, which matches the hardware capabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89596", "url": "https://ubuntu.com/security/CVE-2026-89596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix off-by-one when saving/restoring non-PCI config space nv_suspend() and nv_resume() walk the non-PCI configuration space with \tfor (i = 0; i <= np->register_size/sizeof(u32); i++) which runs one iteration too many. saved_config_space is declared as \tu32 saved_config_space[NV_PCI_REGSZ_MAX/4]; and NV_PCI_REGSZ_VER3 is equal to NV_PCI_REGSZ_MAX (0x604), so on a VER3 device register_size/sizeof(u32) is exactly the array length and the last iteration addresses one element past the end. The element it lands on is np->name_rx[0..3]: saved_config_space[] is followed immediately by char name_rx[IFNAMSIZ + 3], and char needs no padding. Nothing observable is corrupted by that, because nv_request_irq() rewrites name_rx with sprintf() before it is ever passed to request_irq(). The bug is the out-of-bounds access itself, which UBSAN reports and which CONFIG_UBSAN_TRAP=y turns into a trap that aborts the running kernel code, plus an MMIO read and, on resume, an MMIO writel() to base + 0x604, one dword past the range the driver mapped: \tnp->base = ioremap(addr, np->register_size); VER1 and VER2 devices stay inside the array, but they too get the stray read and the stray write one dword past their own window. Caught by UBSAN on an Apple Macmini3,1 (MCP79) during a deep S3 cycle. The splat below is trimmed: the build path in the file name, the CPU and taint lines, the Workqueue line, the \"?\" hint frames, and the frames below device_suspend are all cut. The kernel was tainted, with an out-of-tree nouveau and CPU_OUT_OF_SPEC; forcedeth itself was the stock module. UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c:6225:25 index 385 is out of range for type 'u32 [385]' Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... Both loops are hit. UBSAN reports each source location only once per module load (__ubsan_handle_out_of_bounds() calls suppress_report(), which does test_and_set_bit(REPORTED_BIT, ...) on the struct source_location), so the two splats land in the first S3 cycle after the module is loaded and later cycles are silent even though the access still runs off the end every time. In that first cycle line 6225 is reported from pci_pm_suspend and line 6240 from pci_pm_resume. The same off-by-one was fixed in nv_get_regs() by commit ba9aa134287f (\"forcedeth: fix buffer overflow\") in 2012; these two loops were missed. The suspend and resume side was reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix, but the patch was attached rather than sent inline and the thread ended there. Use < instead of <=, which saves and restores exactly register_size bytes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89597", "url": "https://ubuntu.com/security/CVE-2026-89597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: unregister connector callback on init failure uvesafb_init() registers the v86d connector callback before registering the platform driver. If platform_driver_register() fails, the function returns the error directly and leaves the connector callback registered. The later platform-device failure path already unregisters the callback. Add the same cleanup before the final return when platform-driver registration fails. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89599", "url": "https://ubuntu.com/security/CVE-2026-89599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: panel-dsi-cm: initialize lock before registering display dsicm_probe() registers the display before initializing ddata->lock. Once omapdss_register_display() publishes the display, another consumer can reach a dsicm callback that takes this mutex while it is still uninitialized. Initialize the mutex before registering the display so the published callbacks always see a valid lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89605", "url": "https://ubuntu.com/security/CVE-2026-89605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: release message context on send failure ecryptfs_send_message_locked() moves a message context from the free list to the allocated list before sending the request to the userspace daemon. If ecryptfs_send_miscdev() fails, the context is left on the allocated list and cannot be reused. Move it back to the free list on failure and clear the caller's pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89606", "url": "https://ubuntu.com/security/CVE-2026-89606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject too-small tag 70 packets ecryptfs_parse_tag_70_packet() subtracts fixed metadata fields from the parsed packet body size to derive the encrypted filename size. A malformed packet with a body smaller than those fixed fields can underflow that size calculation. Reject tag 70 packets before the subtraction unless the body contains the signature, cipher code, and at least one byte of encrypted filename data.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89607", "url": "https://ubuntu.com/security/CVE-2026-89607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key() sets decrypted_key_size = encrypted_key_size and performs two out-of-bounds writes: 1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into decrypted_key[64] via scatterlist, overflowing into the parent ecryptfs_auth_tok struct. 2. memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes into crypt_stat->key[64], corrupting root_iv, keysig_list, and mutexes in ecryptfs_crypt_stat. Only AES-192 (cipher code 0x08) enables this because it sets crypt_stat->key_size = 24 independently of encrypted_key_size, allowing crypto_skcipher_setkey() to succeed while encrypted_key_size exceeds ECRYPTFS_MAX_KEY_BYTES. The PKI decryption path (parse_tag_65_packet) already validates decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path omits this check. Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also protects the 512-byte encrypted_key[] buffer, so the former 512-byte check is removed as redundant. [tyhicks: Adjust the code comment to refer to macros representing the buffer sizes rather than mentioning the buffer size values since they may change in the future]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89608", "url": "https://ubuntu.com/security/CVE-2026-89608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: pass packet set buffer size to parser ecryptfs_parse_packet_set() receives a pointer into the file header, but it calculates the remaining packet buffer size from PAGE_SIZE - 8. For version 1 headers the packet set starts later in the header, so this can overstate the available buffer. Pass the actual packet set buffer length from the caller and calculate per-packet limits from the remaining bytes in that buffer. Recompute the remaining length after consuming a tag 3 packet before parsing the following tag 11 packet.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89609", "url": "https://ubuntu.com/security/CVE-2026-89609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: hold msg ctx list lock when cleaning daemon queue ecryptfs_exorcise_daemon() drops queued messages from a dying daemon without holding ecryptfs_msg_ctx_lists_mux, but ecryptfs_msg_ctx_alloc_to_free() requires that lock. Take the list lock while moving the queued contexts back to the free list to avoid racing with other global msg ctx list users.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89615", "url": "https://ubuntu.com/security/CVE-2026-89615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound page_lcns[] index by the log record The copy_lcns loop and the redo shorten loop index page_lcns[] at j + i, where i runs up to the log record's lcns_follow. That count is checked only against the record's own length, not the target entry, so check_dp_table() (which validates the entry's lcns_follow) does not cover it: the copy_lcns entry may even be freshly allocated after that check, and find_dp() bounds j but not i. A crafted record thus overflows page_lcns[] of an otherwise valid entry. Add dp_range_ok() and reject, before each loop, any record whose run does not fit the entry. These are the only two page_lcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded. [almaz.alexandrovich@paragon-software.com: original patch contained changes to the problem already handled, applied partly]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89616", "url": "https://ubuntu.com/security/CVE-2026-89616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame() ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target pages and then trusts decompress_lznt()'s return value: unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem, frame_size); if ((ssize_t)unc_size < 0) err = unc_size; else if (!unc_size || unc_size > frame_size) err = -EINVAL; decompress_lznt() stops as soon as the compressed stream is exhausted (e.g. a zero chunk header) and returns the number of bytes it actually wrote, which may be far less than frame_size. The bytes between unc_size and frame_size are never written. The only memset() that follows zeroes the region beyond i_valid; when the frame lies entirely within the file's valid size that memset() does not run, so the gap retains whatever was in the just-vmapped pages. All pages are then marked uptodate and returned to userspace, disclosing uninitialized (recently-freed) kernel page memory. A crafted compressed file whose stream decompresses to only a few bytes leaks the remainder of every frame on a plain read(2), which is enough to recover kernel pointers and defeat KASLR. Zero the [unc_size, frame_size) tail immediately after a successful LZNT decompress so the remainder reads back as zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89617", "url": "https://ubuntu.com/security/CVE-2026-89617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate dirty page table on log replay Each DIR_PAGE_ENTRY ends in a page_lcns[] array whose length is the on-disk lcns_follow field. check_rstbl() validates the table bookkeeping but never checks that this array fits in the entry, so a crafted lcns_follow lets the v0->v1 conversion memmove and later replay passes run off the entry. Add check_dp_table() to reject, right after check_rstbl(), any entry larger than its size claims via struct_size() (the same expression used to allocate these entries, so the check is overflow-safe by construction). All consumers can then trust lcns_follow as the real capacity. This covers every page_lcns[] access whose index is bounded by the entry itself (the conversion memmove, the HotFix store via find_dp(), and the self-bounded scan loops). Accesses whose index comes from the log record need a separate bound and are handled in a follow-up patch.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89621", "url": "https://ubuntu.com/security/CVE-2026-89621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: mcp2221: validate report size in mcp2221_raw_event() mcp2221_raw_event() never validates the size of incoming HID reports. In the MCP2221_I2C_GET_DATA path it trusts the device-supplied data[3] as the copy length without checking that 4 + data[3] bytes actually exist in the received report. A malicious or misbehaving USB device can send a short report with a large data[3], causing the memcpy to read past the valid report data in the HID transfer buffer and leak uninitialized kernel memory back to userspace through the I2C/SMBus read path. Add a minimum size check at entry and validate that the source range fits within the received report before the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89626", "url": "https://ubuntu.com/security/CVE-2026-89626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix field sysfs group cleanup on failure hid_sensor_custom_add_attributes() creates one sysfs group for each custom sensor field. If sysfs_create_group() fails after some groups have already been created, the function returns the error without removing the previously created groups. Add a local unwind path to remove the groups that were already created. With enable_sensor exposed only after the field attributes are ready, this path can free sensor_inst->fields without leaving enable_sensor able to access pointers into that array.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89627", "url": "https://ubuntu.com/security/CVE-2026-89627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: free buffered reports when destroying device roccat_report_event() duplicates each report with kmemdup() and stores the allocation in a circular-buffer slot. The allocation is released only when that slot is reused. The device destruction paths free struct roccat_device without releasing reports still stored in cbuf[]. This makes those allocations unreachable and leaks up to ROCCAT_CBUF_SIZE report buffers per device. Add a small destructor that frees every buffered report before freeing the device, and use it in both paths that can destroy a registered device.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89628", "url": "https://ubuntu.com/security/CVE-2026-89628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: picolcd: clamp eeprom debugfs read to bytes actually received picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte supplied by the device in its REPORT_EE_DATA reply -- clamped only to the caller's read() count: \tret = resp->raw_data[2]; \tif (ret > s) \t\tret = s; \tif (copy_to_user(u, resp->raw_data+3, ret)) It never checks resp->raw_size, the number of bytes picolcd_raw_event() actually copied into the 64-byte raw_data[] of the kmalloc'd struct picolcd_pending. A device (or a spoofed picoLCD) returning a length byte of 0xff, read with a count >= 255, makes copy_to_user() read past raw_data[] into adjacent slab memory and return it to userspace through the debugfs \"eeprom\" file: \tBUG: KASAN: slab-out-of-bounds in _copy_to_user \tRead of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd] The debug-dump path in the same file already validates the device length byte against the received size before trusting it; this read does not. The file is created S_IRUSR (root-only) and a crafted device is needed, so it is neither unprivileged- nor remotely-triggerable. Clamp the copy length to resp->raw_size - 3 (the payload actually received, minus the 3-byte header), floored at 0 for short replies.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89643", "url": "https://ubuntu.com/security/CVE-2026-89643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: avoid dropping live tree ref on fsnotify rule autoremove audit_del_rule() is used for both netlink deletion templates and internal fsnotify autoremove. The former passes a parsed template which owns a temporary tree reference; the latter passes the installed entry itself. The unconditional audit_put_tree() at the end of audit_del_rule() assumes the template case. For mixed AUDIT_DIR plus AUDIT_EXE rules, an fsnotify autoremove event therefore drops the installed rule's live tree reference. Repeating this across rules sharing the same tree can free the tree while another rule still references it, and a later autoremove dereferences the freed pathname while comparing rules. Move the temporary-tree put to audit_rule_change(), the caller that owns deletion templates. Keep it in the AUDIT_DEL_RULE cleanup so both successful deletion and -ENOENT still release the parser-owned tree. [PM: dropped unnecessary comment for line length reasons]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89649", "url": "https://ubuntu.com/security/CVE-2026-89649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound xattr value length in __build_xattrs() __build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare \"p += len\" and no ceph_decode_need() check that \"len\" bytes remain in the blob. For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob. The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space. Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89650", "url": "https://ubuntu.com/security/CVE-2026-89650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound num_export_targets array for mds info v2/v3 ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from each per-mds info record and advances the decode cursor by num_export_targets * sizeof(u32) without first checking that many bytes remain. The only upper-bound check that catches a runaway cursor (*p > info_end) is gated on info_v >= 4, because info_end is left NULL for info_v 2 and 3. When the monitor sends an MDS map whose per-mds info version is 2 or 3 with an oversized num_export_targets, the cursor moves past the message front buffer and the later export-targets loop calls the unchecked ceph_decode_32() on out-of-bounds memory. A kernel client processes CEPH_MSG_MDS_MAP from its monitor session (net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an on-path attacker on an unsigned/unencrypted messenger session, can therefore drive an out-of-bounds read in the client kernel; on x86_64 with KASAN it is reported as a slab-out-of-bounds read in ceph_mdsmap_decode(). The decoded values land in the internal info->export_targets[] array, so the consequence is a kernel out-of-bounds read, not an information leak to the attacker. Impact: a malicious or compromised Ceph monitor sending an MDS map with a per-mds info version of 2 or 3 and an oversized num_export_targets field triggers an out-of-bounds read in the CephFS client kernel. Add a ceph_decode_need() for the export-targets array before advancing the cursor, so the bound is enforced for every info_v >= 2, not only info_v >= 4. This mirrors the count-then-need idiom already used for m_data_pg_pools later in the same function. Compute the export-targets byte count with size_mul() and reuse that checked length when advancing the cursor, so the attacker-controlled num_export_targets multiplication fails closed on overflow rather than relying on the later kcalloc() guard.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89653", "url": "https://ubuntu.com/security/CVE-2026-89653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode MDSMap export_targets entries are monitor controlled. check_new_map() uses each entry as a bit number in a fixed stack bitmap, so a rank outside the protocol namespace can make set_bit() write past the end of the array. Reject ranks outside CEPH_MAX_MDS while decoding the map. Do not validate against possible_max_rank here because maps may legitimately reference ranks beyond a temporarily reduced max_mds.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89655", "url": "https://ubuntu.com/security/CVE-2026-89655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock list_for_each_entry() iterates ci->i_cap_flush_list but drops i_ceph_lock to send cap messages. During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid <= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock. When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next on freed memory. The race timeline: __kick_flushing_caps() handle_cap_flush_ack() ----------------------- ----------------------- holds i_ceph_lock <--- iterates to cf (tid=10) prepares FLUSH message drops i_ceph_lock <--- __send_cap() ── FLUSH(tid=10) \t MDS sends FLUSH_ACK(tid=10) ---> acquires i_ceph_lock cf->tid(10) <= flush_tid(10), detaches cf from i_cap_flush_list drops i_ceph_lock ceph_free_cap_flush(cf) <- frees it! acquires i_ceph_lock <--- for-loop advances: cf = list_next_entry(cf, i_list) -- UAF on freed cf->i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS may respond with FLUSH_ACK quickly enough that handle_cap_flush_ack() frees cf before __kick_flushing_caps can finish the iteration. Fix by converting to a manual while loop: save the next pointer under i_ceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89656", "url": "https://ubuntu.com/security/CVE-2026-89656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject buckets with mismatched CRUSH ids crush_decode() stores bucket data by array slot, and the mapper later derives the per-bucket workspace index from the decoded bucket id. A malformed map can therefore make one bucket reuse another bucket's workspace by encoding an id different from -1 - slot. For uniform buckets, the second replica selection expands the source bucket's permutation into that aliased workspace buffer. If the source bucket is larger than the aliased bucket, the write runs past the smaller permutation array and can escape the kvmalloc'd CRUSH workspace. KASAN reports a slab OOB write of 4 bytes in bucket_perm_choose(). Reject buckets whose encoded id does not match their array slot. Valid CRUSH maps already use the canonical negative id corresponding to the bucket slot, so this restores the invariant expected by work->work[-1 - in->id] without changing valid map behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89662", "url": "https://ubuntu.com/security/CVE-2026-89662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent lock owner use-after-free during client teardown __destroy_client() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on cl_ownerstr_hashtbl. client_has_state() does not count a bare owner, so DESTROY_CLIENTID can reach __destroy_client() with such owners present. __destroy_client() then walks the table, calling remove_blocked_locks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flc_owner. The per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently of client state. The two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks(). nfsd4_release_lockowner() holds a reference across the same call; __destroy_client() does not. Hold cl_lock across the walk, taking a reference and unhashing each owner, then drop it before remove_blocked_locks() and nfs4_put_stateowner(), which take blocked_locks_lock and cl_lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89663", "url": "https://ubuntu.com/security/CVE-2026-89663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: revoke copy-notify stateids before dropping their reference Copy-notify stateids live in the s2s_cp_stateids IDR and on their parent stid's sc_cp_list, pinned by a single membership reference. _free_cpntf_state_locked() only unlinks an entry once its refcount reaches zero, so any revoke path that runs while a concurrent find_cpntf_state()/manage_cpntf_state() holder has elevated cs_count drops the reference without unlinking, leaving the entry discoverable with its membership reference already consumed. A second revoke or a laundromat tick then frees it while the reader still holds the pointer -- a KASAN-detectable use-after-free at the reader's nfs4_put_cpntf_state(). This affected all three revoke paths: - The parent-stid drain (nfs4_free_cpntf_statelist()) repeatedly called _free_cpntf_state_locked() on the first list entry; a holder that had bumped cs_count made it return early, so the next iteration re-decremented and burned the holder's reference. - OFFLOAD_CANCEL (manage_cpntf_state()) and laundromat expiry likewise used _free_cpntf_state_locked() and could drop 2->1 without unlinking. Add revoke_cpntf_state_locked(), which unhashes the entry from the IDR and sc_cp_list first (deferring the final free to any holder), and use it from all three revoke paths. The drain now walks with list_for_each_entry_safe() and revokes each entry unconditionally, so it terminates in one pass per entry regardless of cs_count. The unhash is gated on !list_empty(&cps->cp_list); the idr_remove() gate matters because idr_alloc_cyclic() may have recycled the so_id by then. Keep _free_cpntf_state_locked() for the reference-holder put path only, where a concurrent revoke may already have unlinked the entry (its list_del_init() then a no-op).", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89665", "url": "https://ubuntu.com/security/CVE-2026-89665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE The NFSv2 sattr decoder converts the wire useconds to nanoseconds in svcxdr_decode_sattr(): \tiap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC; tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds value such as 4294968 wraps to tv_nsec == 704. The corruption therefore happens during decode, before any proc function can inspect the value, and a later range check on tv_nsec would see an in-range result and accept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply. NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return for a malformed time argument, and the check cannot move to the proc function the way the v3/v4 nsec range checks do. Guard the raw useconds before the multiplication and reject values greater than 1000000. useconds == 1000000 is kept: it is the Sun convention for \"set to the current server time\", and the in-tree Linux NFSv2 client emits it in both the atime and the mtime field for a plain touch / utimes(file, NULL) (see encode_sattr() and xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000 would turn that common operation into a hard decode failure for both SETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap on ILP32, so the Sun convention value passes through safely. Only genuinely out-of-range values (> 1000000) are rejected. The atime and mtime guards are therefore symmetric. The decoder only applied the Sun convention in the mtime block, which clears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a client puts 1000000 in the atime field but not in the mtime field, the atime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET set, so the bogus value reached the filesystem. Apply the convention in the atime block as well, clearing ATTR_ATIME_SET so the server uses its current time and ignores the value. Only ATTR_ATIME_SET is cleared there. The mtime block keeps its existing behavior, where 1000000 means \"set both atime and mtime to now\". [ cel: various tweaks, addenda, and clean-ups ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89669", "url": "https://ubuntu.com/security/CVE-2026-89669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: initialize copy-notify stateid before publishing it nfsd4_copy_notify() finished initializing the cpntf state after nfs4_alloc_init_cpntf_state() had already linked it into the s2s_cp_stateids IDR and the parent's sc_cp_list, with cs_count == 1 (the membership reference) and none held for the caller. A racing OFFLOAD_CANCEL (crafted cl_id == nn->s2s_cp_cl_id plus the guessable so_id) could reach manage_cpntf_state() and free the entry, turning the caller's subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid writes into use-after-free. The owning clientid was also only recorded after publication, so it could not gate an ownership check in that window. Record cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state() before nfs4_init_cp_state() publishes the entry, and return it with an extra reference. The caller reads the stateid under that reference and drops it with nfs4_put_cpntf_state(); on a late error the laundromat reaps the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89673", "url": "https://ubuntu.com/security/CVE-2026-89673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo nfsd4_ff_encode_getdeviceinfo() computes the da_addr_body reservation as 16 + netid_len + addr_len, but the subsequent xdr_encode_opaque() calls emit 8 + round_up(netid_len, 4) + round_up(addr_len, 4) bytes. The mismatch means the declared da_addr_body length exceeds the actual encoded data by 2-8 bytes on every flexfile GETDEVICEINFO reply, leaking stale reply-page content to the client and mis-aligning the subsequent version list decode. Use xdr_align_size() for each string length to match what xdr_encode_opaque() actually writes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89674", "url": "https://ubuntu.com/security/CVE-2026-89674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client: - fh_len doesn't account for XDR padding on the file handle data - uid and gid lengths use \"8 + len\" but xdr_encode_opaque() actually writes \"4 + xdr_align_size(len)\" bytes - ds_len omits the flags and stats_collect_hint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client. Fix this by breaking out every encoded field explicitly in the ds_len calculation, using xdr_align_size() for all variable-length opaque fields, and correcting the header constants.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89684", "url": "https://ubuntu.com/security/CVE-2026-89684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix cpntf publish race in nfs4_init_cp_state nfs4_alloc_init_cpntf_state() published the new cpntf entry into the s2s_cp_stateids IDR (with cs_type set) in one s2s_cp_lock section, then took the lock again to list_add() it onto p_stid->sc_cp_list. In the gap the entry is reachable by so_id but cp_list is still {NULL,NULL} from kzalloc. A racing OFFLOAD_CANCEL (so_id is echoed to the client as cnr_stateid, so any NFSv4.2 client can drive it) reaches manage_cpntf_state() -> _free_cpntf_state_locked() and does list_del() on the zeroed list_head, oopsing the server. Fold the cs_type assignment and the list_add() into the same critical section as idr_alloc_cyclic(), so a concurrent lookup either misses the entry or sees a fully linked cp_list. INIT_LIST_HEAD() the entry after allocation and switch _free_cpntf_state_locked() to list_del_init() so a stale unlink is a no-op. nfs4_init_copy_state() passes NULL p_stid and skips the list_add, preserving NFS4_COPY_STID semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89694", "url": "https://ubuntu.com/security/CVE-2026-89694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: check client ownership when cancelling a copy-notify stateid On the OFFLOAD_CANCEL path (clp != NULL), manage_cpntf_state() freed the target cpntf state without checking ownership. The lookup key st->si_opaque.so_id is allocated cyclically (guessable) and the embedded clientid is the fixed per-net nn->s2s_cp_cl_id, so any authenticated NFSv4.2 client could cancel and free another client's copy-notify stateid. Compare the creating clientid recorded in state->cp_p_clid against the requesting client's cl_clientid and return nfserr_bad_stateid on a mismatch instead of freeing the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89696", "url": "https://ubuntu.com/security/CVE-2026-89696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref When CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return success with fh_dentry and fh_export both NULL if fh_verify() returns nfserr_stale and putfh->no_verify is true. The NFSD4_FH_FOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserr_nofilehandle check -- it does not prevent subsequent ops from running with a NULL fh_dentry. A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes check_if_stalefh_allowed() to set no_verify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fh_want_write() which dereferences fh_export->ex_path.mnt without calling fh_verify() first, causing a NULL pointer dereference in the nfsd kthread. Fix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set and fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow) and ops with ALLOWED_WITHOUT_FH (which don't need a resolved filehandle) may proceed. All other ops receive nfserr_stale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERR_STALE returned at that point.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89697", "url": "https://ubuntu.com/security/CVE-2026-89697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: add fh_want_write() for early-verified SETATTR in nfsd_proc_setattr() The BOTH_TIME_SET branch calls fh_verify() early so setattr_prepare() can inspect the dentry. This causes nfsd_setattr() to skip fh_want_write(), so notify_change() runs without a mount write reference. Add the missing fh_want_write() call after the early fh_verify().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89699", "url": "https://ubuntu.com/security/CVE-2026-89699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: validate symlink target length in NFSv4 CREATE nfsd4_decode_create() accepts an unbounded cr_datalen from the wire for NF4LNK symlink targets, allowing a client to force a kmalloc of up to the maximum RPC payload size (several MiB) per COMPOUND op that persists until compound teardown. The VFS rejects oversized targets with ENAMETOOLONG, but the allocation has already occurred. Reject cr_datalen == 0 early with nfserr_inval and cr_datalen greater than NFS4_MAXPATHLEN (PATH_MAX) with nfserr_nametoolong to bound the allocation.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89704", "url": "https://ubuntu.com/security/CVE-2026-89704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: sample writeback error cursor before async COPY loop _nfsd_copy_file_range() samples dst->f_wb_err into \"since\" after the copy loop, then uses it to detect writeback errors via filemap_check_wb_err() once vfs_fsync_range() returns. Because the nfsd_file cache reuses a single struct file across requests targeting the same inode, a concurrent COMMIT or stable WRITE on dst advances dst->f_wb_err to the current mapping->wb_err via file_check_and_advance_wb_err() during its own vfs_fsync_range(). If that advancement lands between the writeback error appearing in mapping->wb_err and the COPY worker sampling \"since\", the worker captures the already-advanced cursor, errseq_check() sees cur == since and returns zero, and NFSD4_COPY_F_COMMITTED is set even though writeback failed. CB_OFFLOAD then encodes wr_stable_how = FILE_SYNC4, the client treats the copied data as durable, and the failure becomes silent data loss. Sample since once at the start of the function. The cursor then reflects state in effect before this COPY issues any writes, and filemap_check_wb_err() detects any error that occurs during the copy regardless of which thread first observes it. This matches the pattern used by nfsd_vfs_write() and nfsd4_clone_file_range().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89706", "url": "https://ubuntu.com/security/CVE-2026-89706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: Reset write verifier when async COPY writeback fails Async COPY captures nn->writeverf at request time and reports it to the client via CB_OFFLOAD after the worker kthread completes. When the post-copy vfs_fsync_range() or filemap_check_wb_err() in _nfsd_copy_file_range() reports an error, the worker correctly leaves NFSD4_COPY_F_COMMITTED clear so that CB_OFFLOAD encodes wr_stable_how as NFS_UNSTABLE, but the server's write verifier is not rotated. A client that receives NFS_UNSTABLE in CB_OFFLOAD follows up with COMMIT to make the copied data durable. With the verifier unchanged, COMMIT returns the same value the client just received via CB_OFFLOAD, and the client concludes the copy is durable -- silently dropping the data whose writeback in fact failed. This violates the UNSTABLE+COMMIT durability contract (RFC 7862 section 15.1, RFC 8881 section 18.32) and matches the bug just fixed in nfsd_vfs_write() and nfsd_commit(). Rotate nn->writeverf at the writeback-failure site. The async COPY worker has no svc_rqst, so commit_reset_write_verifier() is not available here; calling nfsd_reset_write_verifier() directly mirrors the trace-less reset already used by nfsd_file_check_write_error() for the same purpose. Filter out -EAGAIN and -ESTALE, matching commit_reset_write_verifier(), since neither indicates a durable-storage failure.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89710", "url": "https://ubuntu.com/security/CVE-2026-89710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget path When the server returns a new layout stateid while a valid one is still held, pnfs_layout_process() calls pnfs_mark_matching_lsegs_return() on the on-stack free_me list and jumps to out_forget. Segments whose reference count drops to zero are unlinked from lo->plh_segs and moved to free_me by mark_lseg_invalid(); for an idle cached segment the layout header holds the only reference, so this happens on the first decrement. out_forget never drains free_me -- only the success path calls pnfs_free_lseg_list(). Commit 814b84971388 (\"pNFS/NFSv4: Fix a layout segment leak in pnfs_layout_process()\") added the drain; commit 08bd8dbe8882 (\"pNFS/NFSv4: Try to return invalid layout in pnfs_layout_process()\") removed it while switching the destination to lo->plh_return_segs, which is drained elsewhere. Commit fb700ef02676 (\"NFSv4.1: Simplify layout return in pnfs_layout_process()\") switched the destination back to free_me without restoring the drain. Restore the pnfs_free_lseg_list() call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89711", "url": "https://ubuntu.com/security/CVE-2026-89711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check The header for commit e75b23f9e323 (\"nfsd: check d_can_lookup in fh_verify of directories\") details the assumption that justified adding the WARN_ON_ONCE to nfsd_mode_check(), that assumption is invalid (in the case of NFS reexport). When NFSD exports an NFS filesystem it is very possible for nfsd_mode_check() to encounter a @dentry that doesn't have i_op->lookup (see nfs_fhget()'s NFS_ATTR_FATTR_MOUNTPOINT and NFS_ATTR_FATTR_V4_REFERRAL handling, and d_flags_for_inode()). So remove nfsd_mode_check()'s WARN_ON_ONCE(). The nfserr_notdir return on that branch must stay. It guards the subsequent lookup_one_unlocked() -> __lookup_slow() path, which calls inode->i_op->lookup() with no NULL check, so returning nfserr_notdir is what keeps a client LOOKUP into such a @dentry from dereferencing a NULL method pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89712", "url": "https://ubuntu.com/security/CVE-2026-89712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock nfsd4_ssc_expire_umount() walks nn->nfsd_ssc_mount_list with list_for_each_entry_safe(ni, tmp, ...). For each expired entry it sets nsui_busy = true, drops nfsd_ssc_lock to run mntput() on the source vfsmount, then reacquires the lock to list_del + kfree the entry and continue iterating via the macro's saved tmp pointer. The nsui_busy flag protects the current ni from concurrent nfsd4_ssc_setup_dul() finders during the lock-drop window, but it does not pin tmp. Another nfsd RPC thread that fails its source- server mount and reaches nfsd4_ssc_cancel_dul() will, during that same window, take nfsd_ssc_lock, list_del + kfree its own ssc_umount item, and release the lock. If that item is the saved tmp of the expire walk, the next iteration dereferences a freed nfsd4_ssc_umount_item. Restart the walk from the head after the mntput() unlock window so no saved next pointer survives the lock-drop. The list is bounded by the number of active inter-server source mounts (typically small) and the expire delayed-work runs periodically rather than per-IO, so the restart is cheap.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89720", "url": "https://ubuntu.com/security/CVE-2026-89720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: fix out-of-bounds read in signature length check ubifs_sb_verify_signature() bounds the on-disk ubifs_sig_node->len field before handing the signature payload to verify_pkcs7_signature(), but the check has the wrong sign: \tif (le32_to_cpu(signode->len) > snod->len + sizeof(struct ubifs_sig_node)) The signature bytes start sizeof(struct ubifs_sig_node) (UBIFS_SIG_NODE_SZ, 64 bytes) into the node, so the payload is at most \tsnod->len - sizeof(struct ubifs_sig_node) bytes long. Adding the header size instead of subtracting it accepts a declared length up to 2 * UBIFS_SIG_NODE_SZ larger than the node actually holds -- past the end of c->sbuf, which is vmalloc(c->leb_size). verify_pkcs7_signature() -> pkcs7_parse_message() -> asn1_ber_decoder() is then handed that inflated length and reads beyond the allocation while walking the DER headers. The node length comes straight from the mounted image, so a crafted signed UBIFS image reaches this via ubifs_read_superblock() before the signature is cryptographically checked. snod->len is guaranteed to be >= UBIFS_SIG_NODE_SZ by the node scanner (c->ranges[UBIFS_SIG_NODE].min_len == UBIFS_SIG_NODE_SZ), so the corrected subtraction cannot underflow. Legitimately signed images are unaffected: a correct superblock never declares a signature longer than the node it is embedded in.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93213", "url": "https://ubuntu.com/security/CVE-2026-93213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: of: fix out-of-bounds read in of_alias_scan() stem parser The stem parser tests isdigit(*(end - 1)) before checking end > start and so reads one byte before the property name when the name is empty or all digits. Check the bound first.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89723", "url": "https://ubuntu.com/security/CVE-2026-89723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after truncation Shuangpeng Bai reported that KASAN detected a slab-out-of-bounds error in nilfs_direct_propagate() during testing. Analysis revealed that after truncating a file, a node block immediately below the B-tree root was not deleted. Instead, it remained in the B-tree node cache in a dirty state. The log writer subsequently detected this block and incorrectly invoked nilfs_direct_propagate() on it, which is designed to handle only data blocks in direct mapping. B-tree nodes in the cache are managed by virtual block numbers, and their logical keys typically exceed the range expected by direct mapping. Consequently, processing such a node as a direct mapping entry triggers a slab-out-of-bounds access. The root cause is that when a B-tree mapping collapses into a direct mapping during truncation, an intermediate node block pointed to by the root node is left behind as garbage instead of being explicitly deleted. This resolves the issue by adding a nilfs_btree_discard() operation to delete the remaining intermediate node block during the conversion. A 'deform' flag is added to the bop_delete interface to explicitly signal that the deletion is part of a mapping transformation. This allows the B-tree mapping implementation to perform the necessary cleanup and discarding of the residual node structure that would be otherwise be left orphaned after the transition.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89724", "url": "https://ubuntu.com/security/CVE-2026-89724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vicodec: fix out-of-bounds write in FWHT encoder vidioc_s_fmt_vid_out() sizes the encoder CAPTURE buffer from the compressed descriptor pixfmt_fwht, whose sizeimage_mult is 3: coded_w * coded_h * 3 + sizeof(struct fwht_cframe_hdr). fwht_encode_frame() encodes one plane per component, and an incompressible plane takes the FWHT_FRAME_UNENCODED path in encode_plane(), copying the plane verbatim. For a 4-component pixel format all four planes are full resolution (width_div == height_div == 1), so a frame that forces every plane through the unencoded fallback writes sizeof(struct fwht_cframe_hdr) + 4 * coded_w * coded_h bytes, overrunning the plane by coded_w * coded_h, which can result in corruption of adjacent kernel heap memory. Bump pixfmt_fwht.sizeimage_mult from 3 to 4, matching the largest components_num among the supported raw formats, so the capture buffer is always large enough for the unencoded fallback.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89725", "url": "https://ubuntu.com/security/CVE-2026-89725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: stm32: prevent out-of-bounds write on RX overflow stm32_rx_done() appends each received CEC byte to rx_msg.msg[] using rx_msg.len as the write index, incrementing it on every RXBR (receive-byte-ready) interrupt without checking it against the buffer size: \tcec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF; rx_msg.msg[] is a fixed CEC_MAX_MSG_SIZE (16) byte array in struct cec_msg, and rx_msg.len is only reset on RXACKE/RXOVR or after a completed message (RXEND). The number of bytes received before RXEND is decided by the remote CEC device (it sets EOM), not by the driver. A peer that keeps sending bytes without ending the message drives RXBR repeatedly, pushing rx_msg.len past 16 and writing peer-controlled bytes out of bounds into the surrounding memory. This is reachable in normal operation once the driver has probed and receiving is enabled, from the IRQ thread, without any local privilege. The length check in the CEC core runs on the consumer side, after the byte has been stored, so it does not prevent the overflow. Bound the index in the driver before the store, as the other platform CEC drivers already do (e.g. tegra_cec), dropping the excess bytes of an overlong frame. Found by static analysis tool CodeQL.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89726", "url": "https://ubuntu.com/security/CVE-2026-89726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen() Patch series \"lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()\", v2. This series fixes an off-by-one out-of-bounds read in ucs2_strnlen(). The first patch is the real fix, the second patch comes as a bonus and fixes the code indentation. This patch (of 2): ucs2_strnlen() checks the current character before checking whether the caller-provided maximum length has been reached. If the input is not NUL-terminated within that bound, the loop can read one ucs2_char_t past the limit. Test the length before dereferencing to prevent an off-by-one out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89729", "url": "https://ubuntu.com/security/CVE-2026-89729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature sensor_hub_get_feature() clamps its return value to the caller's buffer size, but the copy loop still copies field->report_size / 8 bytes for each report value. A malicious HID descriptor can advertise a large feature field size while an IIO caller supplies a small stack buffer, such as a single s32, causing an out-of-bounds write. HID core stores parsed report values in __s32 slots and clamps extracted values to 32 bits. Reject feature fields that require more than one slot per value, guard the total byte count calculation, and clamp each per-value copy to the remaining caller buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89730", "url": "https://ubuntu.com/security/CVE-2026-89730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write The trailing byte path in altera_cvp_send_block() dereferences a u32 pointer even when only 1-3 bytes remain in the input buffer. If the buffer ends at a page or scatterlist boundary, this can read past the valid image data and fault. Copy the remaining bytes into a zero-initialized u32 before writing the final word so only valid bytes are read from the input buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89732", "url": "https://ubuntu.com/security/CVE-2026-89732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Prevent deadlock during ep0 read loop Currently, ffs_ep0_read() holds ffs->mutex when it prepares to go to sleep waiting for an event. When no setup events are pending, it calls wait_event_interruptible_exclusive_locked_irq() with the mutex still held. The wait macro deliberately drops the waitqueue spinlock before sleeping but does not drop the mutex. If a userspace daemon is polling ep0 via read() and the gadget is asynchronously torn down via configfs (e.g., echo \"\" > UDC), a deadlock can occur: 1. The configfs teardown calls functionfs_unbind(), which queues a FUNCTIONFS_UNBIND event. 2. The daemon wakes up, consumes the event, and drops the mutex. 3. However, if the daemon loops and immediately issues another read() before exiting, it reacquires ffs->mutex and again goes into an interruptible sleep. 4. Meanwhile, functionfs_unbind() continues execution and attempts to acquire ffs->mutex to tear down ep0req. 5. The kernel deadlocks because the configfs thread is stuck in an uninterruptible sleep waiting for the mutex, while the userspace daemon is in an interruptible sleep holding the mutex forever because no more events will arrive. To fix this, we drop both the waitqueue spinlock and ffs->mutex before going to sleep, and use wait_event_interruptible_exclusive() instead. Upon waking up, we jump back to the `retry` label to safely reacquire the mutex and re-evaluate the state machine. By not sleeping with ffs->mutex held, we natively decouple gadget teardowns (which require the mutex) from userspace polling.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89733", "url": "https://ubuntu.com/security/CVE-2026-89733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and uvc_function_unbind() In uvc_function_bind() error path, we use usb_ep_free_request which uses uvc->control_req but does not set it to NULL afterwards. Thus, uvc->control_req is a dangling pointer causing a UAF. Also we do not set the uvc->control_buf pointer to NULL after freeing it, which is another dangling pointer. Fix it by setting uvc->control_req to NULL after we run usb_ep_free_request() and uvc->control_buf to NULL after kfree. Do the same for uvc_function_unbind().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93214", "url": "https://ubuntu.com/security/CVE-2026-93214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: fix deadlock in usbg_make_tpg() usbg_make_tpg() held dep_lock while calling configfs_depend_item_unlocked(), which acquires the configfs root inode lock when operating across subsystems. This creates a circular lock dependency with configfs_rmdir(): dep_lock -> configfs root inode lock -> su_mutex -> dep_lock In usbg_make_tpg(), dep_lock only serialized the read of opts->ready, which is a monotonic flag that transitions from false to true exactly once (in tcm_set_name()) and never reverts. Remove dep_lock from usbg_make_tpg() entirely and use READ_ONCE/WRITE_ONCE to access opts->ready locklessly instead.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89736", "url": "https://ubuntu.com/security/CVE-2026-89736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: Fix use-after-free on sound card disconnect g_audio_cleanup() invokes snd_card_free_when_closed() to initiate sound card teardown and immediately frees the underlying struct snd_uac_chip context. However, snd_card_free_when_closed() returns asynchronously while ALSA control elements (kctls) remain open in userspace. When userspace control applications access or close these open file descriptors, kctl callbacks attempt to dereference kctl->private_data pointing to &uac->c_prm or &uac->p_prm within the freed uac structure, resulting in a use-after-free (UAF) memory corruption. Fix this issue by deferring the destruction of struct snd_uac_chip until all references to the ALSA sound card are released. Register a custom card->private_free callback (u_audio_card_free) during g_audio_setup() that frees uac and its associated playback/capture request and ring buffers only when the sound card reference count drops to zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89741", "url": "https://ubuntu.com/security/CVE-2026-89741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"media: v4l2-dev: fix error handling in __video_register_device()\" This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a. The intentions of that patch were good, but it doesn't work. The idea is that if device_register fails, you have to do a put_device to let the ref counter release resources. However, the V4L2 API says that if video_register_device() fails, then you have to call video_device_release(), which kfree()s the video_device struct. But the put_device() will already have freed the struct, so you end up in a double-free scenario. There is not really a good way of fixing this without breaking video_register_device() into two parts, one that initializes everything, and one that does the actual device_register, and then converting all V4L2 drivers to this new model. That is a massive job, and it is very unlikely that device_register will fail. So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89742", "url": "https://ubuntu.com/security/CVE-2026-89742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: mport_cdev: fix use-after-free in dma_req_free() dma_req_free() acquires buf_mutex through req->map, drops the mapping reference with kref_put(), and then dereferences req->map again to unlock the mutex. If kref_put() drops the last reference, mport_release_mapping() frees the mapping, and the subsequent mutex_unlock() dereferences a freed object. This is a use-after-free. Fix this by caching map and md before kref_put(), clearing req->map while holding buf_mutex, and using the cached md for mutex unlocking. The bug is reachable from userspace via the RapidIO mport character device interface.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89749", "url": "https://ubuntu.com/security/CVE-2026-89749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix crash passing ERR_PTR to kthread_stop() event_test_stuff() calls kthread_run() and unconditionally passes the returned task_struct pointer to kthread_stop(). kthread_run() returns an error pointer such as ERR_PTR(-ENOMEM) when kthread creation fails, for example under memory pressure during the boot-time event self-test. kthread_stop() then dereferences the invalid pointer, crashing the kernel. Check the result of kthread_run() before passing it to kthread_stop(). Use WARN_ON() so that a failure to create the self-test thread does not go unnoticed, matching the ring-buffer self-test fix in commit 91542863abad (\"ring-buffer: Fix crash passing ERR_PTR to kthread_stop()\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89752", "url": "https://ubuntu.com/security/CVE-2026-89752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: memcg: stop reclaim when a limit update is superseded kernfs serializes file operations only per open file, so separate open files can update the same memory.high or memory.max file concurrently. Both handlers store the new limit before synchronous reclaim, but continue to use the writer's local target in the reclaim loop. If another writer raises or removes the limit, the first writer can continue reclaiming toward a stale target. For memory.max, this can leave the writer looping indefinitely once reclaim retries are exhausted. The OOM path sees sufficient margin under the current limit and returns true without killing, while the writer still compares usage against its stale target and records another OOM event. Check the current limit at the start of each reclaim iteration and stop if it no longer matches the writer's target. Reproducer: Populate a cgroup with anonymous memory and disable swapping. Lower memory.max from one open file, then restore it to \"max\" through another open file after the new limit becomes visible. Without the patch, the first writer remains blocked and repeatedly increments the OOM event counter. With the patch, it returns normally. This was not motivated by a reported production workload. We found it through automated randomized testing for our cgroup observability work and reduced it to the reproducer above.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89753", "url": "https://ubuntu.com/security/CVE-2026-89753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: \t0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 \ttask:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89765", "url": "https://ubuntu.com/security/CVE-2026-89765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers/itimer: Zero-init old itimerval before copy to userspace On native sparc64, struct __kernel_old_timeval contains a four-byte hole after tv_usec because tv_sec is 64-bit while __kernel_suseconds_t is 32-bit. put_itimerval() fills only the named fields in a stack-allocated __kernel_old_itimerval and copies the entire object to userspace, so getitimer() can expose the two padding holes. Zero-initialize the aggregate before assigning the fields so implicit padding is deterministic before it crosses the user/kernel boundary.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93219", "url": "https://ubuntu.com/security/CVE-2026-93219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/timer-sun4i: Advertise a real minimum delta sun4i_clkevt_next_event() compensates for the timer stop/start synchronization delay by programming evt - TIMER_SYNC_TICKS into the hardware interval register. The clockevent device currently advertises TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed to call set_next_event() with evt == TIMER_SYNC_TICKS. That programs a zero-tick interval. With oneshot/highres/nohz timer operation this can leave the next event stuck, which was observed as a boot hang on Allwinner D1 after the clockevents core started reusing forced minimum-delta events. Advertise one extra tick instead, so the smallest event accepted by the core still programs at least one hardware tick after the synchronization compensation.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-23191", "url": "https://ubuntu.com/security/CVE-2026-23191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix racy access at PCM trigger The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers. For addressing the UAF, this patch changes two things: - It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.", "cve_priority": "high", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-80824", "url": "https://ubuntu.com/security/CVE-2026-80824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbfs: fix use-after-free of usb_device in usbdev_release() usbdev_release() drops its reference to the struct usb_device before draining the list of completed async URBs, but that drain path reads back through the same object: free_async() calls dec_usb_memory_use_count() for any URB whose buffer came from the usbfs mmap() region, and its first statement is bus_to_hcd(ps->dev->bus). After a disconnect the usbfs reference can be the last one, in which case usb_put_dev() frees the device and the subsequent loop reads offset 80 of freed memory and uses the result as a struct usb_hcd *, which hcd_buffer_free_pages() then dereferences. This is reachable by an unprivileged process that has read/write access to a /dev/bus/usb node: mmap() the fd, submit one URB with a buffer inside the mapping, wait for the device to be unplugged, then munmap() and close(). It reproduces on every attempt rather than being a race, because a live MAP_SHARED vma holds a reference on the struct file, so usbdev_release() cannot run until the last vma is gone and the freeing branch of dec_usb_memory_use_count() is always taken. BUG: KASAN: slab-use-after-free in dec_usb_memory_use_count+0x3ae/0x410 Read of size 8 at addr ffff8880122ee050 by task poc/769 CPU: 1 UID: 1000 PID: 769 Comm: poc Tainted: G B 6.12.94 #3 Call Trace: dec_usb_memory_use_count+0x3ae/0x410 free_async+0x2aa/0x4f0 usbdev_release+0x375/0x460 __fput+0x3ea/0xb50 __x64_sys_close+0x86/0x100 Allocated by task 11: usb_alloc_dev+0x55/0xd90 hub_event+0x2524/0x43d0 Freed by task 769: kfree+0x121/0x360 device_release+0xd2/0x280 usb_put_dev+0x23/0x30 usbdev_release+0x2d8/0x460 Release the device reference after the drain loop instead. Nothing between the two points requires it to have been dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80826", "url": "https://ubuntu.com/security/CVE-2026-80826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: c67x00: fix use-after-free in c67x00_add_iso_urb() When TD creation fails for the last packet of an isochronous URB, c67x00_add_iso_urb() gives the URB back before updating the endpoint scheduling state. c67x00_giveback_urb() frees the URB private data, and the completion callback may release the final URB reference. The following accesses to urbp->ep_data, urb->interval, and urbp->cnt can therefore use freed memory. Update next_frame and cnt before giving back the failed final packet, making the giveback the last operation that uses the URB and its private data.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80827", "url": "https://ubuntu.com/security/CVE-2026-80827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: option: fix slab OOB read in interrupt URB callback The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. [ johan: use dev_err(); split signals declaration and initialisation ]", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80828", "url": "https://ubuntu.com/security/CVE-2026-80828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Complete cleanup after system-resume errors A failed system resume can leave the card unusable until reboot. usb_audio_resume() jumps to err_out when snd_usb_pcm_resume() or snd_usb_mixer_resume() fails. The error path skips the out: block, which restores D0 and decrements chip->num_suspended_intf. The card stays in SNDRV_CTL_POWER_D3hot, so later control access blocks in snd_power_ref_and_wait(). USB core logs an interface resume callback error. It does not retry that callback, so a later callback cannot complete the skipped cleanup. usb_audio_suspend() increments num_suspended_intf before returning success. A system-resume callback must consume the system-suspend count even if a component resume fails. Otherwise, the stranded count skews later suspend and resume cycles. Do not apply this cleanup to runtime-resume errors. Runtime PM can retry -EAGAIN or -EBUSY without another suspend callback. The count must continue to describe that suspended interface. Other runtime-resume errors latch runtime_error in the PM core and do not cause an immediate callback retry. Both parts of the system-resume error path are longstanding. Commit 88a8516a2128a (\"ALSA: usbaudio: implement USB autosuspend\") introduced err_out past the D0 restore. Commit 862b2509d157c (\"ALSA: usb-audio: Fix inconsistent card PM state after resume\") later moved num_suspended_intf-- into the out: block. The error path now skips both operations. No third-party code is needed to reach the error path. snd_usb_mixer_resume() ends in snd_usb_mixer_activate(), which returns the result of usb_submit_urb() for devices that have a mixer status URB. Its mixer->private_resume hook can also fail through scarlett2_init_notify(). snd_usb_pcm_resume() issues a SET_CUR request to a UAC3 power domain. It can return -EPIPE or -EIO when the device stalls the request. Route a component error through out: only when system_suspend is nonzero. Continue to return runtime-resume errors through err_out. Later component resume stages remain skipped. The original error still reaches USB core. A later transfer can fail if the device did not recover. I reproduced the system-resume failure on an Audient iD14 MkI with an out-of-tree diagnostic mixer resume hook. An injected -EIO on the unpatched core left control readers in uninterruptible sleep in snd_power_ref_and_wait() until a reboot. With this patch, the same failure restored control access. A second system suspend and resume also succeeded after I disabled fault injection.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80829", "url": "https://ubuntu.com/security/CVE-2026-80829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output() snd_usbmidi_novation_output() lays out a two-byte header at transfer_buffer[0..1] and passes &transfer_buffer[2] together with a length of ep->max_transfer - 2 to snd_rawmidi_transmit(): \tcount = snd_rawmidi_transmit(ep->ports[0].substream, \t\t\t\t &transfer_buffer[2], \t\t\t\t ep->max_transfer - 2); ep->max_transfer comes from the output endpoint's wMaxPacketSize via usb_maxpacket(). A malformed or malicious device can advertise a bulk OUT endpoint with a wMaxPacketSize of 1 - the USB core only clamps this value downwards - so ep->max_transfer becomes 1 and the count argument becomes -1. snd_rawmidi_transmit() passes the negative count on to __snd_rawmidi_transmit_peek(), where \"if (count1 > count) count1 = count\" leaves count1 negative; get_aligned_size() keeps it negative for a byte-stream substream, so the following memcpy(buffer, ..., count1) runs with a (size_t)-1 length and writes far past the transfer buffer, which was allocated with usb_alloc_coherent(ep->max_transfer). This is the same class of bug that was fixed for snd_usbmidi_akai_output() in commit 0970274613fb (\"ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()\"); the novation output routine was left unguarded. Bail out when the endpoint cannot hold the two-byte header plus at least one payload byte.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80830", "url": "https://ubuntu.com/security/CVE-2026-80830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: Add lock to usb_wakeup_notification() Add a spin lock to usb_wakeup notification to prevent a race condition with dereferencing freed memory. This could be hit by the xHCI driver as it calls this function from an IRQ and could race with the hub_disconnect() function, which properly grabs this lock to protect the state of the device.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80921", "url": "https://ubuntu.com/security/CVE-2026-80921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: zero stale crypto bits When shadowing crypto access bits from a format0 apcb (crycb 0 or 1), the bits 64..255 are unchanged from whatever is in the vsie page in the crycb and thus in the apcb. This gives a nested guest potential access to a device no longer available. Zero out the remaining bits.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80831", "url": "https://ubuntu.com/security/CVE-2026-80831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: mxs-dcp - fix source scatterlist length access mxs_dcp_aes_block_crypt() uses sg_dma_len() without mapping the source scatterlist with dma_map_sg() first. Therefore, sg_dma_len() is invalid and could return zero or a stale DMA length, causing encryption and decryption to process the wrong number of bytes when CONFIG_NEED_SG_DMA_LENGTH=y. Use the original scatterlist length instead.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80832", "url": "https://ubuntu.com/security/CVE-2026-80832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qce - fix CCM AAD buffer underallocation The AAD buffer allocated in qce_aead_ccm_prepare_buf_assoclen() can be smaller than the length later programmed into the DMA scatterlist. The allocation size is currently calculated as: ALIGN(assoclen, 16) + MAX_CCM_ADATA_HEADER_LEN while the DMA length is set to: ALIGN(assoclen + adata_header_len, 16) Since ALIGN() does not distribute over addition, the allocation can be smaller than the DMA length. For example, when assoclen = 32 and adata_header_len = 2: allocation = ALIGN(32, 16) + 6 = 38 DMA length = ALIGN(32 + 2, 16) = 48 As a result, the QCE hardware can read beyond the allocated buffer while computing the CBC-MAC over the associated data. The extra bytes are folded into the authentication tag, resulting in an incorrect tag and causing CCM self-test failures such as: alg: aead: ccm-aes-qce encryption test failed (wrong result) on test vector 8 Fix the allocation by adding the maximum possible AAD header length before alignment: ALIGN(assoclen + MAX_CCM_ADATA_HEADER_LEN, 16) This guarantees that the allocated buffer is large enough for the fully padded AAD data for all supported header sizes.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80840", "url": "https://ubuntu.com/security/CVE-2026-80840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: seg6: clear IPv4 control block on IPIP decapsulation End.DX4 and End.DT4 decapsulate an IPv4 packet through decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), which normally clears IPCB before IPv4 interprets skb->cb. The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts. The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40. Both tcp_v4_save_options() and __ip_options_echo() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls __ip_options_echo(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte option-data area. Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced: BUG: KASAN: slab-out-of-bounds in __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm. Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80842", "url": "https://ubuntu.com/security/CVE-2026-80842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: fix use-after-free of a master VLAN's multicast context br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so once it is cleared under the lock no reader can arm the context again. For a master VLAN the handshake never runs. __vlan_del() clears BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so br_multicast_toggle_one_vlan(masterv, false) returns early on !br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is never taken. br_vlan_put_master() then drains the context in br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a reader still inside rcu_read_lock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no br_vlan_is_brentry() test and flips the flag under br->multicast_lock, so it is not affected. The reader is the bridge transmit path. For a master VLAN br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after br_multicast_ctx_deinit() has already stopped them. BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 Allocated by task 610: br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 Only test br_vlan_is_brentry() when enabling, like the br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before br_multicast_ctx_deinit() drains the context.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80843", "url": "https://ubuntu.com/security/CVE-2026-80843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix xfrm_state_construct() auth-trunc leak attach_auth_trunc() can allocate x->aalg while leaving x->props.aalgo at zero when the selected auth algorithm has no sadb_alg_id. One real case is cmac(aes). xfrm_state_construct() then treats !x->props.aalgo as \"no auth algorithm attached yet\" and calls attach_auth(). That overwrites x->aalg and loses the first allocation. Any later failure or teardown only frees the replacement pointer. Check whether x->aalg is already attached instead of inferring that state from x->props.aalgo.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80844", "url": "https://ubuntu.com/security/CVE-2026-80844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah6: validate routing header segments_left AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6_rearrange_rthdr() assumes that segments_left is not larger than the number of addresses described by the routing header's hdrlen field. That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segments_left value. With segments_left equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access. Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80846", "url": "https://ubuntu.com/security/CVE-2026-80846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: drop ESP-in-TCP packets with no ingress device ESP-in-TCP receives records through the TCP strparser. handle_esp() restores skb->dev from the saved skb_iif before passing the packet into the XFRM input path. Queued TCP data can be processed after the original ingress device has been removed, for example during veth or net namespace teardown. In that case dev_get_by_index_rcu() returns NULL. The XFRM IPv4 and IPv6 input paths both expect skb->dev to be valid while building the route lookup, so queued ESP-in-TCP data can dereference a NULL device. Drop the packet if the saved ingress device can no longer be resolved. Such a packet can no longer be routed through the normal XFRM receive path, and this preserves the existing behaviour for packets whose ingress device still exists.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80848", "url": "https://ubuntu.com/security/CVE-2026-80848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: fix UAF during close ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80854", "url": "https://ubuntu.com/security/CVE-2026-80854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: keep port count until LUN teardown completes tcm_usbg_drop_nexus() permits session removal once tpg_port_count reaches zero. However, usbg_port_unlink() currently decrements that count from the fabric_pre_unlink() callback, before core_dev_del_lun() waits for active se_lun references to drain. If removal of the last LUN races a nexus removal, the latter can observe a zero port count and call target_remove_session(). This frees sess_cmd_map while an in-flight struct usbg_cmd, including its work item, can still be accessed. Overlapping the last-LUN unlink with nexus removal reproduces this lifetime violation as a DEBUG_OBJECTS \"free active\" warning for usbg_cmd_work, followed by a target-core BUG/Oops. The generic target-core unlink path has no callback after core_dev_del_lun() completes. Add an optional fabric_post_unlink() callback and use it for the f_tcm port count. The count now remains nonzero until core_dev_del_lun() has finished draining active LUN references, preventing nexus removal from freeing the session during command completion.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80855", "url": "https://ubuntu.com/security/CVE-2026-80855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on open O_TRUNC DAX failure fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open(\"file\", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80856", "url": "https://ubuntu.com/security/CVE-2026-80856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on setattr writeback failure fuse_do_setattr() takes filemap_invalidate_lock() for a DAX truncate (fault_blocked = true) and releases it at the out:/error: labels. But when a writeback flush is also needed, a write_inode_now() failure returns directly and leaks the lock, so any later fault or truncate on the file stalls on the stale rwsem. For example, truncate(2) on a setuid file reaches fuse_do_setattr() with both ATTR_SIZE and ATTR_MODE set: truncate(2) └─ do_truncate() ├─ dentry_needs_remove_privs() # S_ISUID └─ notify_change() # KILL_SUID -> ATTR_MODE └─ fuse_setattr() # no killpriv: │ # ia_valid |= ATTR_MODE └─ fuse_do_setattr() ├─ filemap_invalidate_lock() # IS_DAX && is_truncate └─ write_inode_now() # is_wb && ATTR_MODE └─ if (err) # e.g. daemon -> -EIO return err # <- lock leaked Fix this by adding an unlock label that releases the lock before returning the error, and use it for the fuse_dax_break_layouts() failure path as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80923", "url": "https://ubuntu.com/security/CVE-2026-80923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: dbgtty: Fix unregister on tty_register_driver() failure If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80768", "url": "https://ubuntu.com/security/CVE-2026-80768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: ft260: fix stack-use-after-return write in I2C read race ft260_i2c_read() points dev->read_buf at a caller-supplied buffer (often an on-stack variable), arms a completion and waits up to five seconds for the device to return the data. The HID input callback ft260_raw_event() runs in the input/IRQ path, independent of the dev->lock mutex held by the read path, and copies the device-supplied payload into dev->read_buf after a plain NULL check. These two paths share read_buf, read_idx and read_len with no serialization. If the device delays its response until the read times out, ft260_i2c_read() resets the controller, clears read_buf and returns, unwinding the stack frame the buffer lived in. A response that arrives at that moment lets ft260_raw_event() pass the NULL check and then memcpy() the device-controlled payload into the now-freed stack location, a bounded but attacker-influenced stack-use-after-return write triggerable by malicious or malfunctioning hardware. Add a dedicated spinlock that serializes every access to read_buf, read_idx and read_len. ft260_raw_event() now holds it across the NULL check, the memcpy and the index update, while the read path takes it when arming and when clearing the buffer, so the teardown can no longer slip between the check and the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80766", "url": "https://ubuntu.com/security/CVE-2026-80766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: fix use-after-free of inrange_timer on remove uclogic_remove() cancels the pen in-range timer and then stops the device: \ttimer_delete_sync(&drvdata->inrange_timer); \thid_hw_stop(hdev); timer_delete_sync() only guarantees the timer is idle at that instant. uclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop() stops the transport several lines later, and every report with pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer: \tmod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); A report landing between the timer_delete_sync() call and the transport teardown in hid_hw_stop() re-arms inrange_timer after it was cancelled. uclogic_remove() then returns and the devm drvdata is freed, while hid_hw_stop() has already freed the input device drvdata->pen_input points at, so when the timer fires ~100 ms later uclogic_inrange_timeout() dereferences freed memory -- a use-after-free in timer-softirq context. Swapping the two calls is not a fix: stopping the device first frees drvdata->pen_input via hidinput_disconnect() while the timer may still be pending, so a timer already armed before removal fires on the freed input device in the window before timer_delete_sync() runs. Use timer_shutdown_sync() before hid_hw_stop() instead. It cancels the timer, waits for a running callback while pen_input is still valid, and prevents any further re-arming -- a later mod_timer() from an in-flight report is silently ignored -- so the timer is provably dead before hid_hw_stop() frees the inputs. This is the ordering the timer core documents for this \"timer re-armed from another path\" teardown case.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80789", "url": "https://ubuntu.com/security/CVE-2026-80789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: bound SGL data length before allocating command buffers nvmet_tcp_map_data() reads the host-controlled 32-bit sgl->length and, for the in-capsule offset descriptor (type 0x01), checks it against port->inline_data_size before use. Any other SGL descriptor type -- including the non-inline transport SGL data-block descriptor (type (NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, the type a real host uses for out-of-capsule writes) skips that check entirely and falls straight through to: \tcmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt); with len taken directly from the wire, unbounded up to 4 GiB. nvmet_req_init() only parses the command and never inspects sgl->length, and nvmet_check_transfer_len() -- the only other place transfer_len is validated -- runs later, from req->execute(), after the allocation has already happened. For a write command the target responds with an R2T and parks the command waiting for the host to send the data; if the host (or an unauthenticated peer that simply never follows up) never does, the sgl_alloc() buffer stays resident for the life of the command. NVMe/TCP has no mandatory authentication in the default configuration, so any peer able to reach the target portal and complete a Fabrics connect can drive this with a single crafted command, repeatable across queues and connections for amplification. This is unbounded kernel memory allocation triggered by a remote, effectively unauthenticated peer. Validate len against the same NVMET_TCP_MAXH2CDATA ceiling this file already uses to bound per-PDU H2C data, for every SGL descriptor type, before doing any allocation. This closes the gap for the non-inline descriptor while leaving the existing, tighter inline_data_size check in place for the in-capsule case. Runtime-verified on a v6.19 KASAN stand: with this bound in place, a crafted write command carrying an oversized non-inline SGL length is rejected before sgl_alloc() runs, where the same request previously drove an unbounded ~256 MiB kernel allocation (up to 4 GiB) that stayed resident pending an R2T the host never satisfies.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80783", "url": "https://ubuntu.com/security/CVE-2026-80783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event() magicmouse_raw_event() handles DOUBLE_REPORT_ID (0xf7) packets, which pack two touch reports into one, by splitting the packet and calling itself on each half. The only guard against runaway recursion is a \"size < 1\" check, which stops zero-sized calls but does not bound the recursion depth. A malicious HID device that matches this driver can send a report starting with DOUBLE_REPORT_ID and filled with the sequence [0xf7, 0x00]. Each level consumes two bytes and recurses on the remainder, so an incoming report of up to HID_MAX_BUFFER_SIZE (16 KiB) drives roughly 8000 nested calls. That easily exhausts the 16 KiB kernel stack, leading to a stack overflow: a panic with CONFIG_VMAP_STACK, or memory corruption without it. A double report only ever wraps two normal reports; it is never legitimately nested. Refuse to re-enter the DOUBLE_REPORT_ID case from a recursive call so the recursion depth is bounded to two, while all valid packets keep being parsed exactly as before.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80796", "url": "https://ubuntu.com/security/CVE-2026-80796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: add data_len bound checks to activation parameter extractors nci_extract_activation_params_iso_dep() and nci_extract_activation_params_nfc_dep() read an inner length byte from the NCI RF_INTF_ACTIVATED_NTF payload and use it to memcpy() into fixed kernel buffers, but neither function receives the caller-validated activation_params_len. A crafted NCI notification with activation_params_len=1 and an inner length byte of up to 20 (NFC-A) or 50 (NFC-B) causes memcpy() to read that many bytes past the one valid byte in the activation params region -- a slab out-of-bounds read of kernel memory adjacent to the NCI skb. The sibling nci_extract_rf_params_*() family was given equivalent protection by commit 571dcbeb8e63 (\"net: nfc: nci: Fix parameter validation for packet data\"), but the two activation parameter extractors were not updated at that time. Add a data_len parameter to both functions, guard against an empty region before consuming the inner length byte, decrement the remaining count after consuming it, and clamp the copy length to what is actually available. Update both call sites to pass ntf.activation_params_len, which is already validated against the skb at ntf.c:801.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80807", "url": "https://ubuntu.com/security/CVE-2026-80807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid block index in GC ioctl Syzbot reported list corruption caused by a double list_add_tail() call on bh->b_assoc_buffers within nilfs_lookup_dirty_data_buffers(). Analysis revealed that the root cause was the insertion of a page/folio with a page index of ULONG_MAX into the page cache via the GC ioctl. filemap_get_folios_tag(), called by nilfs_lookup_dirty_data_buffers(), repeatedly detects a dirty folio with a page index of ULONG_MAX due to index wrap-around, leading to duplicate processing of dirty buffers. As a preparatory step, the GC ioctl loads the page/folio of the block to be moved during GC and inserts it into the page cache based on information in the nilfs_vdesc structure passed as an argument. Normally, this does not cause issues because the user-space GC library configures the nilfs_vdesc structure properly. However, since there is no range check on the parameters determining the page index, a request with artificially crafted parameters -- such as those generated by Syzbot -- can result in a page/folio being inserted with a page index of ULONG_MAX, triggering the above problem. This resolves the issue by checking the ranges of 'vd_offset' and 'vd_vblocknr' in the nilfs_vdesc structure that determine the page index, thereby preventing the invalid page/folio insertions.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80916", "url": "https://ubuntu.com/security/CVE-2026-80916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcov: fix data corruption and race conditions on PREEMPT_RT syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area. On PREEMPT_RT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state. Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites. Note that while the temporary storage is now on a per-thread basis, the per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that kcov_remote_start() and kcov_remote_stop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state. It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when __init function of built-in module runs. But this patch also fixes crashing the kernel when vmalloc_node() in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in (1) doing vmalloc() in kcov_remote_start() despite !in_task() context (2) out-of-array-bounds access if (1) succeeded but kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE (3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes problems.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-43437", "url": "https://ubuntu.com/security/CVE-2026-43437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain() In the drain loop, the local variable 'runtime' is reassigned to a linked stream's runtime (runtime = s->runtime at line 2157). After releasing the stream lock at line 2169, the code accesses runtime->no_period_wakeup, runtime->rate, and runtime->buffer_size (lines 2170-2178) — all referencing the linked stream's runtime without any lock or refcount protecting its lifetime. A concurrent close() on the linked stream's fd triggers snd_pcm_release_substream() → snd_pcm_drop() → pcm_release_private() → snd_pcm_unlink() → snd_pcm_detach_substream() → kfree(runtime). No synchronization prevents kfree(runtime) from completing while the drain path dereferences the stale pointer. Fix by caching the needed runtime fields (no_period_wakeup, rate, buffer_size) into local variables while still holding the stream lock, and using the cached values after the lock is released.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-53089", "url": "https://ubuntu.com/security/CVE-2026-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in offloaded map/prog info fill When querying info for an offloaded BPF map or program, bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns() obtain the network namespace with get_net(dev_net(offmap->netdev)). However, the associated netdev's netns may be racing with teardown during netns destruction. If the netns refcount has already reached 0, get_net() performs a refcount_t increment on 0, triggering: refcount_t: addition on 0; use-after-free. Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains valid, they cannot prevent the netns refcount from reaching zero. Fix this by using maybe_get_net() instead of get_net(). maybe_get_net() uses refcount_inc_not_zero() and returns NULL if the refcount is already zero, which causes ns_get_path_cb() to fail and the caller to return -ENOENT -- the correct behavior when the netns is being destroyed.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2025-40102", "url": "https://ubuntu.com/security/CVE-2025-40102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000) Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-39925", "url": "https://ubuntu.com/security/CVE-2025-39925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: j1939: implement NETDEV_UNREGISTER notification handler syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 (\"can: j1939: move j1939_priv_put() into sk_destruct callback\") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on \"struct j1939_priv\" held by j1939_sk_bind() call prevents \"struct net_device\" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. [mkl: remove space in front of label]", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2024-58095", "url": "https://ubuntu.com/security/CVE-2024-58095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before txBeginAnon() call Added a read-only check before calling `txBeginAnon` in `extAlloc` and `extRecord`. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes. Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-58094", "url": "https://ubuntu.com/security/CVE-2024-58094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before truncation in jfs_truncate_nolock() Added a check for \"read-only\" mode in the `jfs_truncate_nolock` function to avoid errors related to writing to a read-only filesystem. Call stack: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) If the `isReadOnly(ip)` condition is triggered in `jfs_truncate_nolock`, the function execution will stop, and no further data modification will occur. Instead, the `xtTruncate` function will be called with the \"COMMIT_WMAP\" flag, preventing modifications in \"read-only\" mode.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-46754", "url": "https://ubuntu.com/security/CVE-2024-46754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Remove tst_run from lwt_seg6local_prog_ops. The syzbot reported that the lwt_seg6 related BPF ops can be invoked via bpf_test_run() without without entering input_action_end_bpf() first. Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a (\"ipv6: sr: Add seg6local action End.BPF\"). The reason is that the per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self test case but each BPF function expects it. Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.", "cve_priority": "low", "cve_public_date": "2024-09-18 08:15:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-80806", "url": "https://ubuntu.com/security/CVE-2026-80806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't enable DAX on new encrypted files Currently, when a new encrypted regular file is created, the call to ext4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made before EXT4_INODE_ENCRYPT is set. As a result, it can set S_DAX if the filesystem is mounted with \"-o dax=always\". EXT4_INODE_ENCRYPT then actually gets set a bit later in __ext4_new_inode(), when it calls fscrypt_set_context() which calls ext4_set_context(). ext4_set_context() sets EXT4_INODE_ENCRYPT and calls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too. This was intended to clear S_DAX as well. However, this was broken by commit 043546e46dc7 (\"fs/ext4: Only change S_DAX on inode load\"). This causes data written to the file to bypass encryption, also causing xfstests failures such as generic/548 (when \"-o dax=always\" is used). Fix this by simplifying the flow by making __ext4_new_inode() set EXT4_INODE_ENCRYPT earlier. This makes it take effect in ext4_set_inode_flags(inode, init=true), making S_DAX never be set. Similarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first place on new encrypted inodes. Then it doesn't need to be cleared. As a result of these simplifications, ext4_set_context() no longer needs to change inode flags or state when 'handle != NULL'. Remove that too.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80863", "url": "https://ubuntu.com/security/CVE-2026-80863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix OOB in free_rd_atomic_resources() free_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic. Updating max_dest_rd_atomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] BUG: KASAN: slab-out-of-bounds in rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 Write of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063 CPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xf7/0x600 mm/kasan/report.c:482 kasan_report+0xe4/0x120 mm/kasan/report.c:595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fefc75a70cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fefc8495018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd RDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007 RBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0 Allocated by task 11063: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5296 [inline] __kmalloc_noprof+0x32a/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:155 [inline] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_ma ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80590", "url": "https://ubuntu.com/security/CVE-2026-80590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 (\"net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list\") and by commit 9e4b7a99a03a (\"net: gso: fix panic on frag_list with mixed head alloc types\") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 (\"tun: Allow GSO using virtio_net_hdr\"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80765", "url": "https://ubuntu.com/security/CVE-2026-80765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: validate initial device info bounds The Hyper-V synthetic HID host supplies SYNTH_HID_INITIAL_DEVICE_INFO messages that contain a HID descriptor followed by the report descriptor bytes. mousevsc_on_receive_device_info() trusts bLength and wDescriptorLength without checking that the received packet contains both byte ranges. A malformed host or backend message can therefore make the guest read past the received VMBus packet while copying the report descriptor. Pass the received initial-device-info size into the parser and reject descriptor lengths that exceed the packet. Impact: A malicious Hyper-V host or backend can crash a guest by sending a short initial device-info message with an oversized HID report descriptor length.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80767", "url": "https://ubuntu.com/security/CVE-2026-80767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix use-after-free in enable_sensor enable_sensor_store() can call set_power_report_state(), which dereferences sensor_inst->power_state and sensor_inst->report_state. These pointers refer to entries in sensor_inst->fields. Create the field attributes before exposing the enable_sensor sysfs attribute, so enable_sensor cannot be accessed before the state it depends on has been initialized. On remove, delete enable_sensor before freeing the field attributes, so a concurrent sysfs write cannot dereference freed memory through power_state or report_state.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80918", "url": "https://ubuntu.com/security/CVE-2026-80918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix number/pointer type confusion on long items When fetch_item() is called by hid_scan_report() on an item with HID_ITEM_TAG_LONG, it stores a pointer to the item data in item->data.longdata instead of storing a value directly in item->data.{u8/u16/u32}. When item_udata() or item_sdata() encounters such an item, it incorrectly assumes that the item is in short format, and therefore returns the lower part of a kernel pointer reinterpreted as a number. When a HID device is connected whose descriptor contains a HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this causes the lower half of a kernel pointer to be printed into dmesg as a number, like this: hid (null): invalid report_size 107953555 To fix it, let item_udata() and item_sdata() verify that the item is in short format. Note that this bug only affects hid_scan_report(), while the main parsing pass hid_parse_collections() will always bail out when encountering a long item. Sidenote: There are currently no users of data.longdata; maybe we should just remove any parsing of long-format descriptors as a follow-up.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80889", "url": "https://ubuntu.com/security/CVE-2026-80889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix timer drain order, wakeup handling and tx_gen ordering This patch is a follow-up to commit cf070fe33bfb (\"can: isotp: serialize TX state transitions under so->rx_lock\") which addresses following sashiko-bot findings: - isotp_sendmsg(): drain so->txfrtimer first so a stale callback can't re-arm echotimer after the claim - isotp_release(): wake so->wait after forcing ISOTP_SHUTDOWN so a sleeping sendmsg() claim isn't stranded - isotp_sendmsg(): have both wait_event_interruptible() calls in isotp_sendmsg() also wake on ISOTP_SHUTDOWN and do not return claim to IDLE to avoid corrupting a concurrent isotp_release() process. - isotp_sendmsg(): handle potential claim of a new transfer when the wait_event_interruptible() call returns in CAN_ISOTP_WAIT_TX_DONE mode. Don't touch timers and states of the new transfer if a new thread incremented so->tx_gen before getting the lock at err_event_drop. - isotp_sendmsg(): handle a stuck can_send() and omit timer and state changes if a new transfer was claimed. wait_tx_done() returns the error recorded in so->tx_result[], tagged with the caller's own generation. - isotp_tx_timeout(): on a claimed timeout, record the ECOMM error for the timed-out transfer's own generation in so->tx_result[]; sk->sk_err is raised unconditionally, same as every other error path here. - isotp_tx_gen_done()/isotp_tx_timeout(): always read tx.state (acquire) before tx_gen - the reverse order let a weakly ordered CPU pair a fresh tx.state with a stale tx_gen/tx_result slot. - isotp_sendmsg(): wait_tx_done: drain sk_err via sock_error() once we have read the result from so->tx_result[], so an already-reported error doesn't stay latched for a later poll()/SO_ERROR. Also align the remaining lock-free so->tx.state/rx.state/cfecho accesses and use skb->hash as unique loopback echo frame indicator.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-46170", "url": "https://ubuntu.com/security/CVE-2026-46170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: free sk if last When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on \"itself\".", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46158", "url": "https://ubuntu.com/security/CVE-2026-46158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: always decrease sk refcount When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as \"unlikely\".", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-80555", "url": "https://ubuntu.com/security/CVE-2026-80555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Free all memory if cp_init() fails The routine cp_free() is called to unpin/free any memory once an I/O is completed successfully, or if cp_prefetch() fails. But if cp_init() fails, and cp->initialized is not enabled, the same routine cannot be used to free all the memory. An attempt to address this exists in ccwchain_handle_ccw(), where a single call to ccwchain_free() is made for the currently-processed CCW segment. But this will leak other segments (created as a result of a Transfer in Channel) that had been allocated as part of the same channel program. Address this by performing the cleanup outside of the recursive ccwchain_handle_ccw()/ccwchain_loop_tic() logic.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2025-68794", "url": "https://ubuntu.com/security/CVE-2025-68794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: adjust read range correctly for non-block-aligned positions iomap_adjust_read_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio. Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-80781", "url": "https://ubuntu.com/security/CVE-2026-80781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix OOB read of field->usage in hid_set_field() hid_set_field() hands field->usage + offset to hid_dump_input() before the guard that bounds offset: \thid_dump_input(field->report->device, field->usage + offset, value); \tif (offset >= field->report_count) { \t\thid_err(...); \t\treturn -1; \t} Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is allocated inline with the hid_field in hid_register_field() and holds field->maxusage entries, so an offset past it reads off the end of the kvzalloc()ed allocation and into a neighbouring object. Had the guard run first, offset < report_count <= maxusage would already have confined the pointer to the array. A caller supplies such an offset today. picolcd_fb_send_tile() validates only report->maxfield before issuing hid_set_field(report->field[0], 11 + i, ...) for i = 0..31, so its offsets are fixed at 11..42 and are never checked against the bound field. When the device registers that field with fewer usages, the framebuffer deferred-io work drives the read on every tile. KASAN reports a 4-byte slab-out-of-bounds read in hid_dump_input() below hid_set_field(), and the same boot logs \"offset (1) exceeds report_count (1)\" from the guard that runs only afterwards. Move the hid_dump_input() call below the guard. Because field->maxusage >= field->report_count, the guard then establishes that field->usage + offset lies inside the array before it is dereferenced, for every caller and without changing behaviour on the valid path. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80782", "url": "https://ubuntu.com/security/CVE-2026-80782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: do not keep a stale msc->input if no input is claimed magicmouse_input_mapping() caches the first hid_input's input_dev in msc->input while the report descriptor is parsed, and the rest of the driver treats a non-NULL msc->input as proof that an input device was registered. That does not hold on the hid-input error path. If hidinput_connect() fails -- for instance because input_register_device() returns an error -- it unwinds through hidinput_disconnect(), which frees every input_dev it created, including the one cached in msc->input. The failure does not abort the probe. hid_connect() only skips the claim: \tif ((connect_mask & HID_CONNECT_HIDINPUT) && !hidinput_connect(hdev, \t\t\t\tconnect_mask & HID_CONNECT_HIDINPUT_FORCE)) \t\thdev->claimed |= HID_CLAIMED_INPUT; and the \"device has no listeners\" bailout below it does not fire for this driver, which sets ->raw_event; on the USB Magic Mouse 2 / Magic Trackpad 2 paths hidraw and hiddev are claimed as well. hid_hw_start() therefore returns 0 and magicmouse_probe() continues with msc->input pointing at freed memory. Being non-NULL, it passes the \"input not registered\" check in probe and the NULL checks in ->raw_event and ->event, so the next input report dereferences freed memory. Clear msc->input when the HID core did not claim an input device, so the existing NULL checks cover this case as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-80583", "url": "https://ubuntu.com/security/CVE-2026-80583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses The \"DEC0 MODE\" to \"DEC7 MODE\" controls are enumerated, but tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 (\"ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type\") and commit 0ea5eff7c606 (\"ASoC: codecs: va-macro: fix accessing array out of bounds for enum type\"), but tx-macro was missed. On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value sanity check catches the 4 bytes written past the enumerated item and every read of these controls fails with -EINVAL: snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80587", "url": "https://ubuntu.com/security/CVE-2026-80587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid combining some incoming suboptions Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80547", "url": "https://ubuntu.com/security/CVE-2026-80547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Implement a crw lock Unlike the channel_program struct, which covers synchronous I/O submissions and asynchronous interrupts, the CRW region relies exclusively on asynchronous events coming from hardware. Implement a lock to manage the list of those payloads, to ensure they are read cohesively.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80548", "url": "https://ubuntu.com/security/CVE-2026-80548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Selectively expand io_mutex The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80552", "url": "https://ubuntu.com/security/CVE-2026-80552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure index for read/write regions are within range The introduction of the capability chain rightly clamped the region indexes to the range of the capabilities itself, but neglected to do so for the existing read/write regions which should also be enforced.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80788", "url": "https://ubuntu.com/security/CVE-2026-80788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations When fuzzing the nvme target code, I tripped a kernel warning in nvmet_tcp_map_data() because the length passed into the allocator is controlled by the remote initiator. A remote initiator that sends a command with an SGL claiming a huge number, can create a scatterlist and iovec allocation of over 1 million entries, which causes the backing kmalloc call to exceed MAX_PAGE_ORDER and then the page allocator will trip on a WARN_ON_ONCE_GFP() message: WARNING: mm/page_alloc.c:5280 __alloc_frozen_pages_noprof Workqueue: nvmet_tcp_wq nvmet_tcp_io_work ... sgl_alloc_order nvmet_tcp_map_data nvmet_tcp_try_recv_pdu As it's never good to trip a kernel warning remotely due to many systems having panic-on-warn enabled, let's silence it by just add GFP_NOWARN to the allocation flags.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80790", "url": "https://ubuntu.com/security/CVE-2026-80790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: fix invalid free in LS IOD error path nvmet_fc_alloc_ls_iodlist() advances iod while initializing the LS IOD array. If an rqstbuf allocation or response buffer DMA mapping fails, the unwind loop decrements iod past the start of the array. The final kfree(iod) therefore frees an address before the allocated object. This can be reproduced with nvme-fcloop and failslab by setting fail-nth to 6 before creating a target port. KASAN reports: BUG: KASAN: invalid-free in nvmet_fc_register_targetport Free of addr ffff88816cf8ff48 by task nvmet_fail_nth/9552 Free the original allocation base stored in tgtport->iod instead. With this fix applied, the same sysfs write with fail-nth=6 returns -ENOMEM without any KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80792", "url": "https://ubuntu.com/security/CVE-2026-80792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix use-after-free in ip6_finish_output2() ip6_finish_output2() caches a pointer to the IPv6 destination address (daddr) before invoking lwtunnel_xmit(). The LWT-BPF transmit path or other encapsulation operations within lwtunnel_xmit() can reallocate the skb head, freeing the memory that daddr points to. When lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, the function continues to use the stale daddr pointer to compute the nexthop and to look up or create the neighbour entry. This results in a use-after-free read, which can leak sensitive kernel data, pollute the neighbour table with arbitrary values, misdirect traffic, or crash the system. Fix this by re-fetching the IPv6 header and the destination address pointer after lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, ensuring that the subsequent nexthop computation and neighbour lookup operate on valid memory.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80793", "url": "https://ubuntu.com/security/CVE-2026-80793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: reject undersized MTUs in ip_do_fragment() ip_do_fragment() subtracts the IPv4 header length from the effective MTU and passes the resulting payload MTU to ip_frag_next(). If the effective MTU is smaller than hlen + 8, ip_frag_next() rounds the fragment payload length down to zero. The fragmentation state then never makes forward progress: state->left, state->ptr and state->offset stay unchanged while ip_do_fragment() keeps allocating and transmitting header-only fragments until the softlockup detector fires. This is reproducible with a route installed using \"mtu lock 20\", but it is also reproducible without route MTU lock, for example by forwarding a packet to a device whose MTU is 20. Fix it in ip_do_fragment() by rejecting mtu < hlen + 8 with -EMSGSIZE, matching the existing IPv6 fragmentation check.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80557", "url": "https://ubuntu.com/security/CVE-2026-80557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix OOB read in decode_watchers() via missing bounds check ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80794", "url": "https://ubuntu.com/security/CVE-2026-80794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix uninit-value in the RF discover/activated NTF handlers nci_rf_discover_ntf_packet() and nci_rf_intf_activated_ntf_packet() each parse a notification into an on-stack struct (nci_rf_discover_ntf / nci_rf_intf_activated_ntf) that is not initialised. The RF technology-specific parameters are only extracted when rf_tech_specific_params_len is non-zero, so a notification that reports a zero length leaves the rf_tech_specific_params union uninitialised - and both handlers then pass it to nci_add_new_protocol(), which reads it: - discover: nci_add_new_target() -> nci_add_new_protocol(); - activated: nci_target_auto_activated() -> nci_add_new_protocol(). nci_add_new_protocol() uses nfca_poll->nfcid1_len as both a branch condition and a memcpy() length and copies nfcid1/sens_res/sel_res into ndev->targets, which is later exposed to user space via NFC_CMD_GET_TARGET. BUG: KMSAN: uninit-value in nci_add_new_protocol+0x624/0x6c0 nci_add_new_protocol+0x624/0x6c0 nci_ntf_packet+0x25b2/0x3c30 nci_rx_work+0x318/0x5d0 process_scheduled_works+0x84b/0x17a0 worker_thread+0xc10/0x11b0 kthread+0x376/0x500 Local variable ntf.i created at: nci_ntf_packet+0xbc2/0x3c30 Zero-initialise both on-stack notifications so the union reads back as zero when no technology-specific parameters are present.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80795", "url": "https://ubuntu.com/security/CVE-2026-80795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix out-of-bounds write in nci_target_auto_activated() nci_target_auto_activated() appends a target to the fixed-size array ndev->targets[NCI_MAX_DISCOVERED_TARGETS] and increments ndev->n_targets without first checking the array is full; unlike its sibling nci_add_new_target(), which bails out when n_targets already equals NCI_MAX_DISCOVERED_TARGETS. ndev->n_targets is only cleared by nci_clear_target_list(), so an NFCC that repeatedly re-runs discovery (RF_DISCOVER_RSP, which re-enters NCI_DISCOVERY without clearing the target list) and reports an auto-activated target (RF_INTF_ACTIVATED_NTF) drives n_targets past the limit. The append then writes a struct nfc_target past the end of the array (a slab out-of-bounds write), and nfc_targets_found() goes on to walk the array with the inflated count: BUG: KASAN: slab-out-of-bounds in nci_add_new_protocol+0x94/0x2ac [nci] Write of size 2 at addr ffff0000c7299a18 by task kworker/u8:0/12 Workqueue: nfc0_nci_rx_wq nci_rx_work [nci] Call trace: nci_add_new_protocol+0x94/0x2ac [nci] nci_ntf_packet+0xddc/0x11a0 [nci] nci_rx_work+0x15c/0x1e0 [nci] process_one_work+0x2dc/0x500 worker_thread+0x240/0x460 kthread+0x1c0/0x1d0 ret_from_fork+0x10/0x20 The buggy address belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1024 bytes to the right of allocated 1560-byte region [ffff0000c7299000, ffff0000c7299618) Guard nci_target_auto_activated() with the same check used by nci_add_new_target().", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80823", "url": "https://ubuntu.com/security/CVE-2026-80823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: validate ATR_REQ length against the received frame st21nfca_tm_recv_atr_req() checks that the received ATR_REQ frame is at least ST21NFCA_ATR_REQ_MIN_SIZE and that the self-declared atr_req->length is at least sizeof(struct st21nfca_atr_req), but never checks that atr_req->length does not exceed the actual received length (skb->len). st21nfca_tm_send_atr_res() then trusts the declared length: \tgb_len = atr_req->length - sizeof(struct st21nfca_atr_req); \t... \tmemcpy(atr_res->gbi, atr_req->gbi, gb_len); so an RF peer that sends a short frame but sets atr_req->length larger than the frame makes gb_len exceed the general bytes actually present, and the memcpy reads out of bounds past the received skb. Those bytes are placed in the ATR_RES and sent back to the peer (kernel-memory disclosure to a proximity attacker); a larger declared length is an out-of-bounds read (DoS). Reject frames whose declared length exceeds the received length. The adjacent nfc_tm_activated() path in the same function already derives its general-bytes length from skb->len rather than the declared field. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80797", "url": "https://ubuntu.com/security/CVE-2026-80797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: purge fragmented skbs during cleanup pn53x_common_clean() purges resp_q before freeing the common PN533 state, but it leaves fragment_skb untouched. The fragmentation helpers queue transmit fragments there while sending large initiator or target-mode frames, and those skbs remain owned by the driver until they are sent or discarded. If the device is removed while fragments are still queued, the common cleanup path frees the PN533 state without releasing the queued fragment skbs, leaking them. Purge fragment_skb during cleanup alongside resp_q.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80798", "url": "https://ubuntu.com/security/CVE-2026-80798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: reject PDUs shorter than the LLCP header Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes before parsing it. nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/ nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a CONNECT or CC PDU then computes \ttlv_array_len = skb->len - LLCP_HEADER_SIZE; as a size_t and hands it to the TLV walk. When the frame is shorter than the header the subtraction wraps to a huge value and the walk runs far past the buffer, an out-of-bounds read. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Guard the common receive choke point __nfc_llcp_recv(), shared by both the target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so a short skb is dropped before the rx_work worker parses it. Use pskb_may_pull() rather than a skb->len test so the two header bytes are guaranteed to sit in the skb linear area even for a non-linear skb, matching how the sibling NCI and HCI receive paths validate their headers. Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on linux-next. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80799", "url": "https://ubuntu.com/security/CVE-2026-80799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain three related bugs in their TLV parsing loops: 1. 'offset' is declared u8 but tlv_array_len is u16. When TLV data advances offset past 255 it silently wraps to zero, causing infinite loops or double-processing of buffer data. 2. Before reading tlv[0] (type) and tlv[1] (length) there is no check that offset+2 <= tlv_array_len. A truncated TLV causes an OOB read of one byte past the buffer end. 3. After reading the length field, the value bytes are accessed without checking offset+2+length <= tlv_array_len. A crafted length=0xFF on a short buffer causes up to 255 bytes of OOB read past the buffer end. Both functions are reachable without authentication via nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes directly into nfc_llcp_parse_gb_tlv() with no additional validation. Fix all three issues by widening offset from u8 to u16 and adding bounds checks for both the TLV header and value field before each access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80800", "url": "https://ubuntu.com/security/CVE-2026-80800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound the connect_sn TLV walk to the skb Commit 27256cdb290e (\"nfc: llcp: bound SNL TLV parsing to the skb and add length checks\") fixed the unbounded TLV walk in nfc_llcp_recv_snl(), and commit d8bd2dedbde5 (\"nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers\") subsequently bounded nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv(). One sibling parser sharing the same pattern remains unbounded: nfc_llcp_connect_sn(). nfc_llcp_connect_sn() walks a TLV list, reading a two-byte header (type, length) followed by length bytes of value, without checking that the two header bytes or the declared length stay within the buffer. It returns a pointer to a service name of up to 255 bytes that may point past the end of the skb; it is subsequently consumed by memcmp() in nfc_llcp_sock_from_sn(). In addition tlv_array_len was computed as \"skb->len - LLCP_HEADER_SIZE\" in size_t, so a CONNECT/CC frame shorter than the LLCP header underflows to a huge length and the walk runs far past the buffer. nfc_llcp_connect_sn() is reachable from nfc_llcp_recv_connect() and nfc_llcp_recv_cc(), i.e. from received CONNECT and CC PDUs. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP, and the nfc_llcp_rx_skb() dispatcher applies no minimum-length guard. Walk the TLV list by pointer, bounded by skb_tail_pointer(skb), and validate each declared length before use, matching the approach already used for nfc_llcp_recv_snl(). Starting the walk at &skb->data[LLCP_HEADER_SIZE] against the tail pointer also removes the size_t underflow for short frames. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80801", "url": "https://ubuntu.com/security/CVE-2026-80801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: microread: validate target discovery payload lengths microread_target_discovered() parses target discovery payloads from skb->data according to the HCI gate. The fixed field offsets and UID copies were checked only against the destination nfc_target buffers, not against the actual skb length. Validate that each gate-specific payload contains the fixed fields and UID bytes before reading or copying them.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80802", "url": "https://ubuntu.com/security/CVE-2026-80802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: bound the device-reported read length and fix an skb leak fdp_nci_i2c_read() takes the next packet length from two device-supplied bytes and never validates it. The value is a u16 used as the i2c_master_recv() count into a 261-byte on-stack buffer: a malicious, counterfeit or malfunctioning controller (or an i2c bus interposer) can drive it far past the buffer for a stack out-of-bounds write that clobbers the canary and return address, or below the minimum frame size (directly, or by truncating the computed sum) so the header/LRC strip and the next length read run past a short receive. Reject a length outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD], as a corrupted packet already is, and force resynchronization. The same loop allocates one data skb per iteration and assumes a length packet followed by a data packet; a device that sends two data packets in one call leaks the first skb when the second allocation overwrites it. Free a previously allocated skb before allocating the next.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80803", "url": "https://ubuntu.com/security/CVE-2026-80803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: digital: clamp SENSF_RES length to the destination buffer digital_in_recv_sensf_res() memcpy()s resp->len bytes from a remote NFC-F device response into the NFC_SENSF_RES_MAXSIZE-byte target.sensf_res field without an upper-bound check. A nearby malicious NFC-F device can send an oversized SENSF_RES response to overflow the stack-local struct nfc_target. Clamp resp->len to NFC_SENSF_RES_MAXSIZE before the copy. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80536", "url": "https://ubuntu.com/security/CVE-2026-80536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: bounds-check buffer log item's dirty bitmap xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: \tmemcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), \t\titem->ri_buf[i].iov_base, \t\tnbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80553", "url": "https://ubuntu.com/security/CVE-2026-80553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Cancel existing workqueues The initialization of the io_work and crw_work workqueues begs the question of whether they should be un-initialized. Add the corresponding cleanup tags in _release_dev to ensure work isn't dispatched after the private struct is free'd.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74662", "url": "https://ubuntu.com/security/CVE-2026-74662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: publish queues before arming timer inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74666", "url": "https://ubuntu.com/security/CVE-2026-74666", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: synchronize pressure clearing with ring reconfiguration packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74663", "url": "https://ubuntu.com/security/CVE-2026-74663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: reject overly deep qdisc hierarchies Deep qdisc hierarchies can lead to excessive recursion in qdisc tree walkers and exhaust the kernel stack. The existing loop check does not cover the create-and-graft path, so a hierarchy can still be extended by creating a new child qdisc below an already deep parent. Store the hierarchy depth in struct Qdisc and update it when qdiscs are grafted. Reject new child qdiscs once the parent is already at the maximum allowed depth.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74668", "url": "https://ubuntu.com/security/CVE-2026-74668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in TX_RING send path tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative. Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb(). The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74582", "url": "https://ubuntu.com/security/CVE-2026-74582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in non-ring send paths packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-80737", "url": "https://ubuntu.com/security/CVE-2026-80737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: synchronize DMA teardown dmaengine_terminate_all() does not wait for a running callback, so the TX callback can still touch the TX buffer after it is freed. The RX poll timer reads the RX buffers without the port lock. Switch to dmaengine_terminate_sync() and delete the RX timer before freeing the buffers.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74626", "url": "https://ubuntu.com/security/CVE-2026-74626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_netdev: Preserve RX queue depth on allocation failure ntb_netdev_rx_handler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception. A retry path could refill the queue later, but ntb_netdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74637", "url": "https://ubuntu.com/security/CVE-2026-74637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix group leader use-after-free after sibling detach perf_group_detach() handles leader and sibling detach differently. When the group leader is detached, all siblings are promoted to singleton events and their group_leader pointer is reset to themselves. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. That is harmless when the sibling is being closed and freed immediately, as in the DETACH_DEAD path. It is not safe when the sibling is detached but kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the sibling is removed from the context, while its file descriptor can still keep it alive. A typical failing sequence is: - A group contains leader L and sibling S. - CPU hot-unplug detaches S with DETACH_GROUP, removing it from L->sibling_list but leaving S->group_leader == L. - L is later closed and freed. - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and dereferences the freed leader. This was reproduced by running the perf event fuzzer, CPU hotplug, and a stress workload concurrently: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT pc : perf_ioctl+0x34c/0xc68 x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908) Call trace: perf_ioctl+0x34c/0xc68 (P) __arm64_sys_ioctl+0xa0/0xf4 invoke_syscall+0x58/0xe4 el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x40/0xc0 el0t_64_sync_handler+0x68/0xdc el0t_64_sync+0x1c4/0x1c8 The fault happened in perf_ioctl(), where perf_event_for_each() follows the stale group_leader pointer and perf_event_for_each_child() then dereferences the freed leader's context. Fix the use-after-free by promoting the detached sibling to a singleton. Also fix __event_disable() cgroup accounting and event state change.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74647", "url": "https://ubuntu.com/security/CVE-2026-74647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Remove buffer from list prior to unmap operation fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74632", "url": "https://ubuntu.com/security/CVE-2026-74632", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix huge_zero_pfn race Patch series \"mm/huge_memory: fix huge_zero_pfn race\", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80562", "url": "https://ubuntu.com/security/CVE-2026-80562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: ml-ioh: use raw_spinlock_t for the register lock ioh_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irq_set_type callback additionally emits a dev_warn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same fix as commit a02b8950d619 (\"gpio: pch: use raw_spinlock_t for the register lock\"); this driver shares the same structure as gpio-pch.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80805", "url": "https://ubuntu.com/security/CVE-2026-80805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: validate attr entry pointer before field access xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen, valuelen) before checking if the entry pointer itself is within bounds. If nameidx is crafted to point near the end of the buffer, these field accesses can read out-of-bounds before the bounds check at name_end > buf_end is performed. Add explicit bounds checks for entry pointers before accessing their fields. Use offsetof() to check that the start of the flexible array member (nameval/name) is within bounds, which ensures all preceding fields are safe to access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80808", "url": "https://ubuntu.com/security/CVE-2026-80808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: stop retrying saturated xattr cache entries ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked. Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop. Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition. Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80809", "url": "https://ubuntu.com/security/CVE-2026-80809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix missing metadata reservation for large xattrs [BUG] lsetxattr() panics the kernel when setting a large xattr value on a fragmented filesystem where the file already has an external xattr block. [CAUSE] ocfs2_calc_xattr_set_need() never reserves metadata blocks for a new xattr value's extent tree when the file already has an external xattr block. The not_found path leaves meta_add at zero, so meta_ac is NULL when ocfs2_xattr_extend_allocation() runs. A new value root has room for a single extent record. On a fragmented filesystem, the allocator cannot satisfy the xattr value in one contiguous run, so each non-contiguous run requires its own extent record. When the value root's extent list is full and meta_ac is NULL, ocfs2_add_clusters_in_btree() returns RESTART_META, and ocfs2_xattr_extend_allocation() hits BUG_ON(why == RESTART_META). [FIX] The case where no xattr block exists yet already calls ocfs2_extend_meta_needed(&def_xv.xv.xr_list) to reserve value tree metadata. Add the same reservation to the case where an xattr block already exists, making the two cases consistent. Replace the BUG_ON with a -ENOSPC return so that if RESTART_META is returned despite the reservation, the error propagates to userspace instead of panicking the kernel.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80812", "url": "https://ubuntu.com/security/CVE-2026-80812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dummy: Check card index validity at probe snd_dummy_probe() blindly trusts that the given devptr->id value is within the proper card index range. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80814", "url": "https://ubuntu.com/security/CVE-2026-80814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rndis_host: add overflow check in rndis_rx_fixup() Add an overflow check to ensure that data_offset + data_len + 8 does not wrap, which would enable an OOB read of the USB data buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80819", "url": "https://ubuntu.com/security/CVE-2026-80819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept rfcomm_sock_recvmsg() completes a deferred setup by calling rfcomm_dlc_accept() without holding any RFCOMM lock: \tif (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { \t\trfcomm_dlc_accept(d); \t\treturn 0; \t} and rfcomm_dlc_accept() dereferences the session on its first line: \tstruct sock *sk = d->session->sock->sk; Every other path that touches d->session runs under rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). rfcomm_connect_ind() is even documented as \"called under rfcomm_lock()\". This call site is the only one that skips it. The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against teardown, since __rfcomm_dlc_close() returns early when it wins the test_and_clear. But rfcomm_recv_disc() forces the state first: \td->state = BT_CLOSED; \t__rfcomm_dlc_close(d, err); and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2. With the state already BT_CLOSED that switch does not match, the bit is never consulted, and __rfcomm_dlc_close() falls through to rfcomm_dlc_unlink(), which sets d->session = NULL. So a remote DISC on a deferred dlc clears the session while leaving RFCOMM_DEFER_SETUP set. The next recvmsg() then passes the test_and_clear and dereferences a NULL session. No timing window is needed: once the DISC has been processed, the dereference is unconditional. Give rfcomm_dlc_accept() the same shape as rfcomm_dlc_open() and rfcomm_dlc_close(): an exported wrapper that takes rfcomm_mutex and re-checks the session, around a __rfcomm_dlc_accept() that the two in-core callers, which already hold the mutex, keep using. Reproduced on a KASAN + PROVE_LOCKING kernel with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session, opens a dlc on a channel bound with BT_DEFER_SETUP, and sends DISC after the socket is accepted. recv() on the accepted socket then hits: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10 is the offset of sock in struct rfcomm_session. With this patch the same run completes with recv() returning 0 and no report, and lockdep stays quiet, confirming rfcomm_mutex is still taken before lock_sock on this path as it is on the thread side.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80917", "url": "https://ubuntu.com/security/CVE-2026-80917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems On 32-bit systems the config space is too large to ioremap in one go, so pci_ecam_create() maps each bus segment separately and relies on the ->add_bus callback (pci_ecam_add_bus) to populate the per-bus mapping in cfg->winp[]. pci_ecam_map_bus() then uses that mapping as the base for every config access. The generic ECAM ops (pci_generic_ecam_ops) already provide the ->add_bus and ->remove_bus callbacks, but the CAM (legacy) ops in pci-host-generic.c do not. As a result, on a 32-bit host using \"pci-host-cam-generic\" the per-bus mapping is never set up and the first config read dereferences a NULL base, crashing during bus enumeration: Unable to handle kernel NULL pointer dereference at virtual address 00000800 Oops [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 6.9.7+ #43 Hardware name: Digilent Nexys-Video-A7 RV32 (DT) epc : pci_generic_config_read+0x40/0xb0 ra : pci_generic_config_read+0x2c/0xb0 [] pci_generic_config_read+0x40/0xb0 [] pci_bus_read_config_dword+0x50/0xb0 [] pci_bus_generic_read_dev_vendor_id+0x3c/0x1ec [] pci_scan_single_device+0xa4/0x11c [] pci_scan_slot+0x9c/0x23c [] pci_scan_child_bus_extend+0x58/0x2f4 [] pci_scan_root_bus_bridge+0x64/0xe8 [] pci_host_probe+0x20/0xc8 [] pci_host_common_probe+0x144/0x1e4 Fix this by giving the CAM ops the same ->add_bus/->remove_bus callbacks. Since pci_ecam_add_bus() and pci_ecam_remove_bus() are static to ecam.c, move the CAM ops definition there as pci_generic_cam_ops (mirroring pci_generic_ecam_ops) and export it for pci-host-generic.c to reference. [mani: removed timestamp from log]", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2022-1205", "url": "https://ubuntu.com/security/CVE-2022-1205", "cve_description": "A NULL pointer dereference flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system.", "cve_priority": "high", "cve_public_date": "2022-08-31 16:15:00 UTC" }, { "cve": "CVE-2022-50303", "url": "https://ubuntu.com/security/CVE-2022-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix double release compute pasid If kfd_process_device_init_vm returns failure after vm is converted to compute vm and vm->pasid set to compute pasid, KFD will not take pdd->drm_file reference. As a result, drm close file handler maybe called to release the compute pasid before KFD process destroy worker to release the same pasid and set vm->pasid to zero, this generates below WARNING backtrace and NULL pointer access. Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step of kfd_process_device_init_vm, to ensure vm pasid is the original pasid if acquiring vm failed or is the compute pasid with pdd->drm_file reference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10", "cve_priority": "medium", "cve_public_date": "2025-09-15 15:15:00 UTC" }, { "cve": "CVE-2023-53320", "url": "https://ubuntu.com/security/CVE-2023-53320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info() The function mpi3mr_get_all_tgt_info() has four issues: 1) It calculates valid entry length in alltgt_info assuming the header part of the struct mpi3mr_device_map_info would equal to sizeof(u32). The correct size is sizeof(u64). 2) When it calculates the valid entry length kern_entrylen, it excludes one entry by subtracting 1 from num_devices. 3) It copies num_device by calling memcpy(). Substitution is enough. 4) It does not specify the calculated length to sg_copy_from_buffer(). Instead, it specifies the payload length which is larger than the alltgt_info size. It causes \"BUG: KASAN: slab-out-of-bounds\". Fix the issues by using the correct header size, removing the subtraction from num_devices, replacing the memcpy() with substitution and specifying the correct length to sg_copy_from_buffer().", "cve_priority": "low", "cve_public_date": "2025-09-16 17:15:00 UTC" }, { "cve": "CVE-2025-39726", "url": "https://ubuntu.com/security/CVE-2025-39726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ism: fix concurrency management in ism_cmd() The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that. This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well. A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it. On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.", "cve_priority": "high", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39779", "url": "https://ubuntu.com/security/CVE-2025-39779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: subpage: keep TOWRITE tag until folio is cleaned btrfs_subpage_set_writeback() calls folio_start_writeback() the first time a folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tag even if there are still dirty blocks in the folio. This can break ordering guarantees, such as those required by btrfs_wait_ordered_extents(). That ordering breakage leads to a real failure. For example, running generic/464 on a zoned setup will hit the following ASSERT. This happens because the broken ordering fails to flush existing dirty pages before the file size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode or for compressed writes, it locks several folios for delalloc and starts writing them out. Let's call the last locked folio folio X. Suppose the write range only partially covers folio X, leaving some pages dirty. Process A calls btrfs_subpage_set_writeback() when building a bio. This function call clears the TOWRITE tag of folio X, whose size = 8K and the block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range. Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. It calls tag_pages_for_writeback() to tag dirty folios with PAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then, B collects tagged folios using filemap_get_folios_tag() and must wait for folio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE) However, between tagging and collecting, process A may call btrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY) As a result, process B won't see folio X in its batch, and returns without waiting for it. This breaks the WB_SYNC_ALL ordering requirement. Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retains the TOWRITE tag. We now manually clear the tag only after the folio becomes clean, via the xas operation.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39810", "url": "https://ubuntu.com/security/CVE-2025-39810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix memory corruption when FW resources change during ifdown bnxt_set_dflt_rings() assumes that it is always called before any TC has been created. So it doesn't take bp->num_tc into account and assumes that it is always 0 or 1. In the FW resource or capability change scenario, the FW will return flags in bnxt_hwrm_if_change() that will cause the driver to reinitialize and call bnxt_cancel_reservations(). This will lead to bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc may be greater than 1. This will cause bp->tx_ring[] to be sized too small and cause memory corruption in bnxt_alloc_cp_rings(). Fix it by properly scaling the TX rings by bp->num_tc in the code paths mentioned above. Add 2 helper functions to determine bp->tx_nr_rings and bp->tx_nr_rings_per_tc.", "cve_priority": "low", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-37861", "url": "https://ubuntu.com/security/CVE-2025-37861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.", "cve_priority": "low", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-38643", "url": "https://ubuntu.com/security/CVE-2025-38643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() Callers of wdev_chandef() must hold the wiphy mutex. But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes: WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985", "cve_priority": "low", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38615", "url": "https://ubuntu.com/security/CVE-2025-38615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: cancle set bad inode after removing name fails The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted. The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's \"icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier\". In some it's outright \"we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles\".", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38361", "url": "https://ubuntu.com/security/CVE-2025-38361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check dce_hwseq before dereferencing it [WHAT] hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used. (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)", "cve_priority": "low", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38259", "url": "https://ubuntu.com/security/CVE-2025-38259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd9335: Fix missing free of regulator supplies Driver gets and enables all regulator supplies in probe path (wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup in final error paths and in unbind (missing remove() callback). This leads to leaked memory and unbalanced regulator enable count during probe errors or unbind. Fix this by converting entire code into devm_regulator_bulk_get_enable() which also greatly simplifies the code.", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38239", "url": "https://ubuntu.com/security/CVE-2025-38239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix invalid node index On a system with DRAM interleave enabled, out-of-bound access is detected: megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it accordingly.", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2022-50071", "url": "https://ubuntu.com/security/CVE-2022-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: move subflow cleanup in mptcp_destroy_common() If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE eBPF program, the MPTCP protocol ends-up leaking all the subflows: the related cleanup happens in __mptcp_destroy_sock() that is not invoked in such code path. Address the issue moving the subflow sockets cleanup in the mptcp_destroy_common() helper, which is invoked in every msk cleanup path. Additionally get rid of the intermediate list_splice_init step, which is an unneeded relic from the past. The issue is present since before the reported root cause commit, but any attempt to backport the fix before that hash will require a complete rewrite.", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2025-37920", "url": "https://ubuntu.com/security/CVE-2025-37920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: Fix race condition in AF_XDP generic RX path Move rx_lock from xsk_socket to xsk_buff_pool. Fix synchronization for shared umem mode in generic RX path where multiple sockets share single xsk_buff_pool. RX queue is exclusive to xsk_socket, while FILL queue can be shared between multiple sockets. This could result in race condition where two CPU cores access RX path of two different sockets sharing the same umem. Protect both queues by acquiring spinlock in shared xsk_buff_pool. Lock contention may be minimized in the future by some per-thread FQ buffering. It's safe and necessary to move spin_lock_bh(rx_lock) after xsk_rcv_check(): * xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers. * xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-43456", "url": "https://ubuntu.com/security/CVE-2026-43456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix type confusion in bond_setup_by_slave() kernel BUG at net/core/skbuff.c:2306! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306 RSP: 0018:ffffc90004aff760 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900 RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780 R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0 Call Trace: ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900 dev_hard_header include/linux/netdevice.h:3439 [inline] packet_snd net/packet/af_packet.c:3028 [inline] packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592 ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646 __sys_sendmsg+0x170/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe1a0e6c1a9 When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond, bond_setup_by_slave() directly copies the slave's header_ops to the bond device: bond_dev->header_ops = slave_dev->header_ops; This causes a type confusion when dev_hard_header() is later called on the bond device. Functions like ipgre_header(), ip6gre_header(),all use netdev_priv(dev) to access their device-specific private data. When called with the bond device, netdev_priv() returns the bond's private data (struct bonding) instead of the expected type (e.g. struct ip_tunnel), leading to garbage values being read and kernel crashes. Fix this by introducing bond_header_ops with wrapper functions that delegate to the active slave's header_ops using the slave's own device. This ensures netdev_priv() in the slave's header functions always receives the correct device. The fix is placed in the bonding driver rather than individual device drivers, as the root cause is bond blindly inheriting header_ops from the slave without considering that these callbacks expect a specific netdev_priv() layout. The type confusion can be observed by adding a printk in ipgre_header() and running the following commands: ip link add dummy0 type dummy ip addr add 10.0.0.1/24 dev dummy0 ip link set dummy0 up ip link add gre1 type gre local 10.0.0.1 ip link add bond1 type bond mode active-backup ip link set gre1 master bond1 ip link set gre1 up ip link set bond1 up ip addr add fe80::1/64 dev bond1", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2022-49858", "url": "https://ubuntu.com/security/CVE-2022-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix SQE threshold checking Current way of checking available SQE count which is based on HW updated SQB count could result in driver submitting an SQE even before CQE for the previously transmitted SQE at the same index is processed in NAPI resulting losing SKB pointers, hence a leak. Fix this by checking a consumer index which is updated once CQE is processed.", "cve_priority": "medium", "cve_public_date": "2025-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-22057", "url": "https://ubuntu.com/security/CVE-2025-22057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: decrease cached dst counters in dst_release Upstream fix ac888d58869b (\"net: do not delay dst_entries_add() in dst_release()\") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30 Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-22083", "url": "https://ubuntu.com/security/CVE-2025-22083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang: 1. Use-after-free when no tpgs are found: This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If a scsi request is then sent we do: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend which sees the vs_tpg we just did a kfree on. 2. Tpg dir removal hang: This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1. The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg. Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir. 3. Tpg leak: This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names. The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs. Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2024-58096", "url": "https://ubuntu.com/security/CVE-2024-58096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode ath11k_hal_srng_* should be used with srng->lock to protect srng data. For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock. So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319 So add srng->lock for them to avoid such warnings. Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct hal_srng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_process_rx(). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-21947", "url": "https://ubuntu.com/security/CVE-2025-21947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix type confusion via race condition when using ipc_msg_send_request req->handle is allocated using ksmbd_acquire_id(&ipc_ida), based on ida_alloc. req->handle from ksmbd_ipc_login_request and FSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion between messages, resulting in access to unexpected parts of memory after an incorrect delivery. ksmbd check type of ipc response but missing add continue to check next ipc reponse.", "cve_priority": "high", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2022-49562", "url": "https://ubuntu.com/security/CVE-2022-49562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing \"random\" pfns for pretty much any other VM_PFNMAP case.", "cve_priority": "low", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2025-21812", "url": "https://ubuntu.com/security/CVE-2025-21812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: rcu protect dev->ax25_ptr syzbot found a lockdep issue [1]. We should remove ax25 RTNL dependency in ax25_setsockopt() This should also fix a variety of possible UAF in ax25. [1] WARNING: possible circular locking dependency detected 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted ------------------------------------------------------ syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated---", "cve_priority": "high", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21801", "url": "https://ubuntu.com/security/CVE-2025-21801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ravb: Fix missing rtnl lock in suspend/resume path Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations. Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down", "cve_priority": "low", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-54683", "url": "https://ubuntu.com/security/CVE-2024-54683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: IDLETIMER: Fix for possible ABBA deadlock Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs: | ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20 | | but task is already holding lock: | ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v] | | which lock already depends on the new lock. A simple reproducer is: | #!/bin/bash | | while true; do | iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\" | iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\" | done & | while true; do | cat /sys/class/xt_idletimer/timers/testme >/dev/null | done Avoid this by freeing list_mutex right after deleting the element from the list, then continuing with the teardown.", "cve_priority": "medium", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2024-53220", "url": "https://ubuntu.com/security/CVE-2024-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to account dirty data in __get_secs_required() It will trigger system panic w/ testcase in [1]: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2752! RIP: 0010:new_curseg+0xc81/0x2110 Call Trace: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is if checkpoint_disabling and lfs_mode are both on, it will trigger OPU for all overwritten data, it may cost more free segment than expected, so f2fs must account those data correctly to calculate cosumed free segments later, and return ENOSPC earlier to avoid run out of free segment during block allocation. [1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2025-21759", "url": "https://ubuntu.com/security/CVE-2025-21759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: extend RCU protection in igmp6_send() igmp6_send() can be called without RTNL or RCU being held. Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection.", "cve_priority": "high", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57999", "url": "https://ubuntu.com/security/CVE-2024-57999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing. These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range. The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries Workqueue: events work_for_cpu_fn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100 LR [c00000000005e830] iommu_init_table+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620 [c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 There are 2 issues in the code 1. The index is \"int\" while the address is \"unsigned long\". This results in negative value when setting the bitmap. 2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well.", "cve_priority": "low", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57982", "url": "https://ubuntu.com/security/CVE-2024-57982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: state: fix out-of-bounds read during lookup lookup and resize can run in parallel. The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array. rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask; While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) { This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again). Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent. The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side. xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2022-49651", "url": "https://ubuntu.com/security/CVE-2022-49651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: srcu: Tighten cleanup_srcu_struct() GP checks Currently, cleanup_srcu_struct() checks for a grace period in progress, but it does not check for a grace period that has not yet started but which might start at any time. Such a situation could result in a use-after-free bug, so this commit adds a check for a grace period that is needed but not yet started to cleanup_srcu_struct().", "cve_priority": "low", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2022-49359", "url": "https://ubuntu.com/security/CVE-2022-49359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Job should reference MMU not file_priv For a while now it's been allowed for a MMU context to outlive it's corresponding panfrost_priv, however the job structure still references panfrost_priv to get hold of the MMU context. If panfrost_priv has been freed this is a use-after-free which I've been able to trigger resulting in a splat. To fix this, drop the reference to panfrost_priv in the job structure and add a direct reference to the MMU structure which is what's actually needed.", "cve_priority": "high", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2022-49234", "url": "https://ubuntu.com/security/CVE-2022-49234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: Avoid cross-chip syncing of VLAN filtering Changes to VLAN filtering are not applicable to cross-chip notifications. On a system like this: .-----. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-' '-1-2-' '-1-2-' Before this change, upon sw1p1 leaving a bridge, a call to dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1. In this scenario: .---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-' When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be called for sw2 and sw3 with a non-existing port - leading to array out-of-bounds accesses and crashes on mv88e6xxx.", "cve_priority": "medium", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2024-57945", "url": "https://ubuntu.com/security/CVE-2024-57945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Fix the out of bound issue of vmemmap address In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)). However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page. For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END. This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base.", "cve_priority": "low", "cve_public_date": "2025-01-21 13:15:00 UTC" }, { "cve": "CVE-2024-53210", "url": "https://ubuntu.com/security/CVE-2024-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct() Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skb_queue_purge() and WARN_ON in iucv_sock_destruct() during socket close. To fix this decrease skb refcount by one if MSG_PEEK is set in order to prevent memory leak and WARN_ON. WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53187", "url": "https://ubuntu.com/security/CVE-2024-53187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check for overflows in io_pin_pages WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2170108, 2170970, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168549, 2168549, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168510, 2168199, 2168214, 2107442, 2129861 ], "changes": [ { "cves": [ { "cve": "CVE-2025-68190", "url": "https://ubuntu.com/security/CVE-2025-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked() kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2026-46242", "url": "https://ubuntu.com/security/CVE-2026-46242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s \"*pprev = next\" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays.", "cve_priority": "high", "cve_public_date": "2026-05-30 13:16:00 UTC" }, { "cve": "CVE-2025-38349", "url": "https://ubuntu.com/security/CVE-2025-38349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: don't decrement ep refcount while still holding the ep mutex Jann Horn points out that epoll is decrementing the ep refcount and then doing a mutex_unlock(&ep->mtx); afterwards. That's very wrong, because it can lead to a use-after-free. That pattern is actually fine for the very last reference, because the code in question will delay the actual call to \"ep_free(ep)\" until after it has unlocked the mutex. But it's wrong for the much subtler \"next to last\" case when somebody *else* may also be dropping their reference and free the ep while we're still using the mutex. Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion. A mutex \"unlock\" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up. See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics: \t\"mutex_unlock() may access the mutex structure even after it has \t internally released the lock already - so it's not safe for \t another context to acquire the mutex and assume that the \t mutex_unlock() context is not using the structure anymore\" So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops _their_ reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it. Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole _point_ of refcounts: unlike mutexes, they are inherently about object lifetimes).", "cve_priority": "high", "cve_public_date": "2025-07-18 08:15:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-80726", "url": "https://ubuntu.com/security/CVE-2026-80726", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-46113", "url": "https://ubuntu.com/security/CVE-2026-46113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, \"KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE\", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the \"correct\" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the \"wrong\" shadow page. However, that was only an imprecision until 2032a93d66fa (\"KVM: MMU: Don't allocate gfns page for direct mmu pages\") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-52988", "url": "https://ubuntu.com/security/CVE-2026-52988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase Publish new hooks in the list into the basechain/flowtable using splice_list_rcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on.", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2023-53231", "url": "https://ubuntu.com/security/CVE-2023-53231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: Fix detection of atomic context Current check for atomic context is not sufficient as z_erofs_decompressqueue_endio can be called under rcu lock from blk_mq_flush_plug_list(). See the stacktrace [1] In such case we should hand off the decompression work for async processing rather than trying to do sync decompression in current context. Patch fixes the detection by checking for rcu_read_lock_any_held() and while at it use more appropriate !in_task() check than in_atomic(). Background: Historically erofs would always schedule a kworker for decompression which would incur the scheduling cost regardless of the context. But z_erofs_decompressqueue_endio() may not always be in atomic context and we could actually benefit from doing the decompression in z_erofs_decompressqueue_endio() if we are in thread context, for example when running with dm-verity. This optimization was later added in patch [2] which has shown improvement in performance benchmarks. ============================================== [1] Problem stacktrace [name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291 [name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi [name:core&]preempt_count: 0, expected: 0 [name:core&]RCU nest depth: 1, expected: 0 CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1 Hardware name: MT6897 (DT) Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4 [2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/", "cve_priority": "medium", "cve_public_date": "2025-09-15 15:15:00 UTC" }, { "cve": "CVE-2023-53707", "url": "https://ubuntu.com/security/CVE-2023-53707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1 The type of size is unsigned int, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later.", "cve_priority": "medium", "cve_public_date": "2025-10-22 14:15:00 UTC" }, { "cve": "CVE-2024-49568", "url": "https://ubuntu.com/security/CVE-2024-49568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg When receiving proposal msg in server, the fields v2_ext_offset/ eid_cnt/ism_gid_cnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2_ext_offset, once exceed the max value, there has the chance to access wrong address, and crash may happen. This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt before using them.", "cve_priority": "high", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2026-89560", "url": "https://ubuntu.com/security/CVE-2026-89560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation Whiteout objects are used in the upper layer of an OverlayFS to indicate that the file with this name does not exist in the unified view, even if it is present in one of the lower layer file systems. For the userspace implementations of OverlayFS (fuse-overlayfs), whiteout objects can be created from userspace as well: * mknod(2) with S_IFCHR and makedev(0, 0) * renameat2(2) with RENAME_WHITEOUT, creating the whiteout in the old place of the moved file. This commit guards whiteout creation in both of these cases with LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered character devices and are not bound to a driver. LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a whiteout object: creating one is the only S_IFCHR creation that the VFS exempts from CAP_MKNOD, so it is as unprivileged as creating a regular file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that expose a kernel interface [1]. For the mknod(2) case, introduce a Landlock erratum. The creation of whiteout objects through mknod(2) was previously guarded using LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using LANDLOCK_ACCESS_FS_MAKE_REG. For the renameat2(2) case, fix a bug: Before this commit, renameat2(2) with RENAME_WHITEOUT would create a directory entry even when all LANDLOCK_ACCESS_FS_MAKE_* rights were denied. This does not affect normal renames within layered OverlayFS mounts: When doing a regular rename() on a mounted fuse-overlayfs, it is the fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT, and only the Landlock domain of that daemon is checked there. Depends-on: 49c9e09d9610 (\"landlock: Fix handling of disconnected directories\") Depends-on: fe72ce6710cb (\"landlock: Add errata documentation section\") [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and add link(2) to the user doc]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2024-41062", "url": "https://ubuntu.com/security/CVE-2024-41062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bluetooth/l2cap: sync sock recv cb and release The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work \t l2cap_sock_release hci_acldata_packet \t l2cap_sock_kill l2cap_recv_frame \t sk_free l2cap_conless_channel \t l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.", "cve_priority": "high", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2022-50406", "url": "https://ubuntu.com/security/CVE-2022-50406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: iomap: fix memory corruption when recording errors during writeback Every now and then I see this crash on arm64: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dm_thin_pool dm_persistent_data XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296). dm_bio_prison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0 dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECT potentially unexpected fatal signal 6. nf_reject_ipv6 potentially unexpected fatal signal 6. ipt_REJECT nf_reject_ipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) ip_tables pc : 000003fd6d7df200 x_tables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wb_workfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseq_set+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : __filemap_set_wb_err+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseq_set+0x1c/0x100 __filemap_set_wb_err+0x24/0xe0 iomap_do_writepage+0x5e4/0xd5c write_cache_pages+0x208/0x674 iomap_writepages+0x34/0x60 xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: ---truncated---", "cve_priority": "low", "cve_public_date": "2025-09-18 16:15:00 UTC" }, { "cve": "CVE-2026-97523", "url": "https://ubuntu.com/security/CVE-2026-97523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close race between scheduler and state change The mptcp scheduler may race with subflow sockets state change: data transmission on the selected socket may fail and a later release could try to use mss_now reset to 0 for a divide operation. Address the issue by explicitly checking for the critical scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97524", "url": "https://ubuntu.com/security/CVE-2026-97524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid unneeded actions on subflow reset Once in a blue moon, the mptcp receive path can recursively call mptcp_data_ready() via state change under unlucky error conditions, and then try to hold the data lock again. Break the recursion loop explicitly checking for the exceptional condition. Add a new flag instead of using an existing one like 'closing', to exit early in subflow_state_change(), and explicitly flush the RX queue at reset time. This avoids unneeded processing to check for available data -- calling get_mapping_status() and more on a dying subflow -- but also in error reporting and worker scheduling. Note that we must consume the currently peeked skb before invoking mptcp_dss_corruption to avoid consuming it again after the eventual reset has freed it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-80833", "url": "https://ubuntu.com/security/CVE-2026-80833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ss support which is one of the only remaining ones. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. Also, it had a buffer overread bug in the line 'memcpy(ctx->seed, d + dlen, ctx->slen);'. There's no point in fixing these bugs separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80834", "url": "https://ubuntu.com/security/CVE-2026-80834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ce support which is one of the only remaining ones. Note that the sun8i-ce support for hwrng remains in place. That is the interface that actually matters. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. There's no point in fixing this separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-74496", "url": "https://ubuntu.com/security/CVE-2026-74496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Fix use-after-free in fou_create() fou_create() publishes struct fou through sk_user_data before adding the new FOU port to the per-netns list. If fou_add_to_port_list() fails, the error path frees fou while it is still reachable through sk_user_data. A concurrent receive can then dereference the freed object in fou_from_sock(). This ordering issue was previously noted in the linked discussion. The failure is reachable when local port 0 is requested. Each socket binds to a different ephemeral port, but fou_cfg_cmp() compares the requested port 0 and reports -EALREADY once an entry already exists. Release the tunnel socket before freeing fou so sk_user_data is cleared first, and defer reclamation with kfree_rcu() to protect concurrent RCU readers. This matches the lifetime handling in fou_release().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-93286", "url": "https://ubuntu.com/security/CVE-2026-93286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: appletalk: fix NULL pointer dereference in aarp_send_ddp() aarp_send_ddp() calls atalk_find_dev_addr(dev) in the LocalTalk fast path without checking for NULL. When the device has no AppleTalk interface configured (dev->atalk_ptr == NULL), this leads to a NULL pointer dereference at the at->s_net access. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:aarp_send_ddp (net/appletalk/aarp.c:552 (discriminator 2)) Call Trace: atalk_sendmsg (net/appletalk/ddp.c:1715) __sys_sendto (net/socket.c:2265 (discriminator 1)) __x64_sys_sendto (net/socket.c:2272) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Add a NULL check consistent with the other callers of atalk_find_dev_addr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93287", "url": "https://ubuntu.com/security/CVE-2026-93287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: reject oversized block transfers in the common path The SMBus block transfer length data->block[0] is validated in i2c_smbus_xfer_emulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbus_xfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked. Add an early validation in __i2c_smbus_xfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback runs. data->block[0] is filled in by the device on SMBus block reads, so the check is scoped to operations where the length is actually supplied by the caller. This is consistent with the existing -EINVAL convention in the emulated path and protects all downstream consumers at once: the smbus_write tracepoint, all native smbus_xfer driver implementations, and the emulated path. Two distinct bugs are fixed by this change: Bug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h) trace_smbus_write() fires before any validation and copies data->block[0]+1 bytes into a 34-byte event buffer. With block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221. BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91 Call Trace: __asan_memcpy+0x23/0x80 trace_event_raw_event_smbus_write+0x27c/0x530 __i2c_smbus_xfer+0x43a/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c) stub_xfer() implements .smbus_xfer directly and only clamps block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With block[0]=0xff and command=0 the loop accesses block[1+i] for i up to 254, far past the 34-byte union. UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44 index 34 is out of range for type '__u8 [34]' Call Trace: __ubsan_handle_out_of_bounds+0xd7/0x120 stub_xfer+0x1971/0x198f [i2c_stub] __i2c_smbus_xfer+0x306/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97931", "url": "https://ubuntu.com/security/CVE-2026-97931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: us122l: Prevent write upgrades for read mappings The hwdep mmap callback rejects read-buffer mappings that are initially writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ. A process that can open the hwdep node O_RDWR can later use mprotect() to make the mapping writable. The read allocation begins with struct usb_stream. Its read_size member is used by the fault handler to decide which pages belong to the read buffer. The read VMA intentionally remains expandable because pcm_usb_stream uses mremap() after reading that size. Changing read_size first can therefore map and access pages beyond the allocation. The same member is also consumed by usb_stream_free(), where changing it can make free_pages_exact() release pages outside the allocation. Clear VM_MAYWRITE for read-buffer mappings after rejecting an initially writable VMA. This keeps the separate output-buffer mapping writable while preventing later permission upgrades.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97568", "url": "https://ubuntu.com/security/CVE-2026-97568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: syncookies: remember the request backup flag Instead of using an uninitialised bit when copying the info in subflow_ulp_clone(). To fix this, no need to extend the join_entry structure: backup is coming from struct mptcp_subflow_request_sock, only one bit. Do the same here by using one bit for both.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97572", "url": "https://ubuntu.com/security/CVE-2026-97572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Propagate RX ring init failures in bnxt_init_nic() bnxt_init_rx_rings() returns an error when bnxt_alloc_one_rx_ring() fails, but bnxt_init_nic() discards that return value and calls bnxt_init_chip(), which enables TPA. If an allocation fails, this could leave rxr->rx_tpa[] partially zeroed and TPA would be enabled over an array with zeroed entries. This would lead to a zeroed DMA address being handed out if the agg_idx is translated to a SW index at a zeroed entry. Fix this by propagating the error out of bnxt_init_nic(). Both callers already check its return value and unwind with bnxt_free_skbs() and bnxt_free_mem(), which tolerate a partially initialized RX ring.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97573", "url": "https://ubuntu.com/security/CVE-2026-97573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset() bnxt_rx_ring_reset() frees the ring buffers and then reallocates them, ignoring the result. bnxt_alloc_one_rx_ring() can fail in bnxt_alloc_one_tpa_info_data(), which returns -ENOMEM on the first failed allocation and leaves the remaining rxr->rx_tpa[] entries zeroed. The error isn't propagated up, so the loop in bnxt_rx_ring_reset continues and at the end the code re-enables TPA with partially unallocated rx_tpa array. This means that when the agg_id from hardware is mapped to a SW index in rxr->rx_tpa[], an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by falling back to a global reset, which is what the existing code already does when other functions fail, but unlike the other failure cases this particular failure has to return because TPA can't be re-enabled since the allocation failed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97576", "url": "https://ubuntu.com/security/CVE-2026-97576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC tile counts The stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from column_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[] and use them as tile-loop bounds, but std_validate_compound() does not bound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling enabled whose tile counts exceed the uAPI array capacity, mirroring the existing compound-control range checks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97582", "url": "https://ubuntu.com/security/CVE-2026-97582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gpio-fan) Fix use-after-free in alarm work fan_alarm_irq_handler() queues fan_data->alarm_work, but nothing cancels it. fan_alarm_notify() dereferences fan_data and its hwmon device. On unbind, devres frees the interrupt, which only waits for the handler itself, and then releases the hwmon device and fan_data, so a pending fan_alarm_notify() can run after those frees. Replace INIT_WORK() with devm_work_autocancel(), registered before devm_request_irq(). The devres cleanup then frees the interrupt first, so no new work can be queued, and cancels the work while fan_data and the hwmon device are still alive. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97592", "url": "https://ubuntu.com/security/CVE-2026-97592", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done. Similar with the buffers which are part of the gcm_sg_walk structs from the variables gw_in and gw_out.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97596", "url": "https://ubuntu.com/security/CVE-2026-97596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reject invalid states in connection template sync records IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6 records.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97598", "url": "https://ubuntu.com/security/CVE-2026-97598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: bound automatic table ID allocation fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment (\"ip rule ... table 0\") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TABLE_MAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable. The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97601", "url": "https://ubuntu.com/security/CVE-2026-97601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97604", "url": "https://ubuntu.com/security/CVE-2026-97604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vfb: defer cleanup until the last reference FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114) Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489) unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97608", "url": "https://ubuntu.com/security/CVE-2026-97608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: unregister loggers before per-net teardown nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL lock nf_log_mutex find logger in loggers[][] net->nf.nf_loggers[pf] = logger unlock nf_log_mutex nf_log_unregister(logger) lock nf_log_mutex loggers[pf][type] = NULL unlock nf_log_mutex synchronize_rcu() module exit returns module core frees backend memory Later, a sysctl read or packet logging operation can dereference the stale per-net logger pointer. Fix this by unregistering the global logger backends before tearing down per-net state. Once the global registrations are gone, later writers can no longer rebind the logger. unregister_pernet_subsys() already waits for an RCU grace period after the pre-exit callback clears the per-net selection, while nf_log_unregister() continues to cover readers of the global logger table. Apply this ordering fix to both nf_log backends that combine per-net teardown with global logger registration.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97611", "url": "https://ubuntu.com/security/CVE-2026-97611", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix use-after-free of the flow table mask array tbl_mask_array_realloc() retires the old mask_array before it stops being reachable: \told = ovsl_dereference(tbl->mask_array); \tif (old) { \t\t... \t\tcall_rcu(&old->rcu, mask_array_rcu_cb); \t} \trcu_assign_pointer(tbl->mask_array, new); call_rcu() only waits for read-side critical sections already in flight. tbl->mask_array still points at old between the call_rcu() and the rcu_assign_pointer(), so a reader entering ovs_flow_tbl_lookup_stats() in that window picks up old in a fresh critical section that the pending grace period does not cover. tbl_mask_array_realloc() runs in process context under ovs_mutex, so the window is preemptible and can outlast the grace period. Then mask_array_rcu_cb() frees old before the swap runs: BUG: KASAN: slab-use-after-free in flow_lookup.constprop.0+0x2bf/0x2f0 Read of size 8 at addr ffff888020b3e018 by task poc/741 flow_lookup.constprop.0+0x2bf/0x2f0 ovs_flow_tbl_lookup_stats+0x4a3/0x5c0 ovs_dp_process_packet+0x19c/0x710 ovs_vport_receive+0x243/0x390 internal_dev_xmit+0x81/0x170 Freed by task 728: kfree+0x16a/0x4e0 rcu_core+0x853/0x1030 Publish the new array before retiring the old one. The kfree_rcu() that call_rcu() replaced ran after the swap.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97612", "url": "https://ubuntu.com/security/CVE-2026-97612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: clear inner_protocol when the last label is popped skb_mpls_push() records the pre-encapsulation network header once, gated on !skb->inner_protocol. skb_mpls_pop() never clears that record, so it outlives the encapsulation it describes. Open vSwitch can then re-push MPLS onto a packet whose inner_network_header still points at the older, deeper offset: push a label, pop every label, recirculate (ovs_flow_key_update() re-derives key->eth.type and resets network_header, but leaves inner_*), then push again. ovs_fragment() trusts the record: \tskb->network_header = skb->inner_network_header; so skb_network_offset() goes negative. The bound check is signed: \tif (skb_network_offset(skb) > MAX_L2_LEN) a negative offset passes it, and prepare_frag() widens the value: \tunsigned int hlen = skb_network_offset(skb); \tmemcpy(&data->l2_data, skb->data, hlen); which is a ~4GiB memcpy out of a 30-byte per-CPU buffer. Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8): BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 prepare_frag+0x3df/0x4e0 ovs_fragment+0x589/0x7e0 do_output+0x4ce/0x5e0 do_execute_actions+0x55d2/0x7b30 ovs_execute_actions+0xea/0x450 Same root-cause shape as commit 975b5b067f52 (\"ipv6: sr: restore network header before routing and forwarding\"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path. Clear inner_protocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/act_mpls.c is the only other skb_mpls_pop() caller and gets the same fix; sch_frag.c saves and restores inner_protocol around fragmentation in the same way OVS does.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97899", "url": "https://ubuntu.com/security/CVE-2026-97899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix memory leak in query_perf_config_list() When krealloc() fails, free the original oa_config_ids before returning to avoid a memory leak. (cherry picked from commit 9977e9d84f46d4f12ad35fbbc0ec4638554bce87)", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97904", "url": "https://ubuntu.com/security/CVE-2026-97904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: initialize policy rwsem before sysfs publication cpufreq_policy_alloc() initializes policy->rwsem after kobject_init_and_add() has created the policy sysfs directory and its default attributes. A sysfs access can therefore reach a policy callback before the semaphore has been initialized. Initialize policy->rwsem before publishing the policy kobject so sysfs callbacks always see an initialized semaphore.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97905", "url": "https://ubuntu.com/security/CVE-2026-97905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: zero-initialize policy cpumask before sysfs publication cpufreq_policy_alloc() allocates policy->cpus with alloc_cpumask_var(), i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate kmalloc_node() allocation, so its bitmap holds whatever the slab allocator left behind: cpufreq_online() cpufreq_policy_alloc() alloc_cpumask_var(&policy->cpus) /* bitmap is uninitialized */ kobject_init_and_add() /* policy%u/ appears in sysfs */ cpufreq_policy_online() cpumask_copy(policy->cpus, cpumask_of(cpu)) /* first valid value */ This leaves a window in which the sysfs attributes are already reachable while policy->cpus is still garbage. show()/store() gate on policy_is_inactive(), i.e. cpumask_empty(policy->cpus), so a non-zero bitmap makes them run the attribute callbacks on a policy that is not initialized yet. Fix this by using zalloc_cpumask_var() for policy->cpus.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97909", "url": "https://ubuntu.com/security/CVE-2026-97909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: initialize IRQ lock before requesting IRQ uni_reader_init() registers the shared IRQ before initializing reader->irq_lock. A pending interrupt can invoke the handler while the lock is still uninitialized. Initialize the lock before registering the IRQ so the interrupt path always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97910", "url": "https://ubuntu.com/security/CVE-2026-97910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sprd: validate compress buffer sizes against fixed allocations sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the fixed allocations. A fragment_size larger than the 32K IRAM data area makes the stage 0 copy_from_user() overflow past the IRAM allocation, and a buffer_size larger than the 2M DDR buffer makes the wrapping copy at the end of sprd_platform_compr_copy() write fully user controlled data past the buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP state reaches the copy callback directly. Reject parameters that do not fit into the fixed buffers in set_params(), and fix the advertised max fragment size: 128K never fitted into the 32K IRAM buffer. The caps values may have been carried over from the qdsp6 driver, which allocates its buffers according to the advertised maxima, unlike this driver. With 32K as max fragment size the advertised limits are self-consistent: 32K * 64 = 2M equals the DDR buffer size. Discovered by Atuin - Automated Vulnerability Discovery Engine.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97923", "url": "https://ubuntu.com/security/CVE-2026-97923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the var ref when its initialization fails create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 (\"tracing: Use hist trigger's var_ref array to destroy var_refs\") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it. The call was correct when it was written, before var refs were taken out of destroy_hist_field(). init_var_ref() cannot free it either. The caller owns the field, so init_var_ref() undoes only its own string allocations and leaves the field alone. Freeing it there would leave create_var_ref() passing freed memory to destroy_hist_field(), which reads its flags. Call __destroy_hist_field(), which frees the field without consulting the flag.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97926", "url": "https://ubuntu.com/security/CVE-2026-97926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: validate cylinder group metadata before caching it ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: \tucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); \tucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); \tucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); \tucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: - c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32 bit count outside the s_csp allocation. - c_frotor becomes a bitmap scan start, start = c_frotor >> 3, and then length = ((s_fpg + 7) >> 3) - start. A start beyond the block bitmap wraps the unsigned length to a huge value, so ubh_scanc() walks far past the cylinder group buffers. c_irotor drives the inode bitmap the same way. A crafted image can set any of these freely, turning an ordinary allocation into an out of bounds access. Reject a cylinder group whose recorded index does not match the group being read, or whose rotors fall outside the group, before the metadata is cached. Valid filesystems keep cg_cgx equal to the group number and the rotors within the group, so only malformed images are rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97927", "url": "https://ubuntu.com/security/CVE-2026-97927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: create the root dentry after loading cylinder metadata ufs_fill_super() installed sb->s_root before it loaded the cylinder group structures for a writable mount: \tsb->s_root = d_make_root(inode); \t... \tif (!sb_rdonly(sb)) \t\tif (!ufs_read_cylinder_structures(sb)) \t\t\tgoto failed; When ufs_read_cylinder_structures() failed, the error path freed the in-core superblock information and set sb->s_fs_info to NULL while sb->s_root stayed installed. get_tree_bdev() then reached deactivate_locked_super(), and because s_root was present, generic_shutdown_super() called sync_filesystem() and the put_super operation. Both dereference UFS_SB(sb), which is now NULL, so a mount that fails only while reading the cylinder groups oopses during teardown. A crafted image whose first cylinder group cannot be read reaches this path. Load the cylinder group metadata first and create the root dentry last, so the superblock is published to the VFS only once it is fully set up. ufs_setup_cstotal() and ufs_read_cylinder_structures() take only the super_block and do not use the root inode, so the reordering is safe.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97930", "url": "https://ubuntu.com/security/CVE-2026-97930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf The in04_last array in struct usx2ydev is declared as char[24], but in04_buf is allocated as sizeof(struct us428_ctls) which is 21 bytes. In i_usx2y_in04_int(), when ctl_snapshot_last == -2 (initialization path): memcpy(usx2y->in04_last, usx2y->in04_buf, sizeof(usx2y->in04_last)); This copies 24 bytes from a 21-byte slab allocation, reading 3 bytes past the end of the source object. Introduce a USX2Y_IN04_SIZE constant defined as sizeof(struct us428_ctls) and use it consistently for the in04_last array, the in04_buf allocation, the URB transfer length, and the comparison loop, replacing the bare 24 and 21 literals throughout.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97940", "url": "https://ubuntu.com/security/CVE-2026-97940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix fib6 walker UAF on seq stop ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a never-started iterator with a zeroed private object is not treated as linked. The same stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only widens the race.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97948", "url": "https://ubuntu.com/security/CVE-2026-97948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver The commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") refactored the EEH code such that the pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken. [<0>] 0xc00000011c78f870 [<0>] __switch_to+0xfc/0x1a0 [<0>] pci_lock_rescan_remove+0x30/0x44 [<0>] eeh_rmv_device+0x290/0x2e0 [<0>] eeh_pe_dev_traverse+0x80/0x130 [<0>] eeh_reset_device+0xcc/0x23c [<0>] eeh_handle_normal_event+0x830/0xa80 [<0>] eeh_event_handler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] start_kernel_thread+0x14/0x18 The issue is seen for cases where the errors are detected on the PHB directly AND|OR for devices where the driver error_detected() returns PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no error handlers like slot_reset(), resume() etc defined).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-74743", "url": "https://ubuntu.com/security/CVE-2026-74743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: inherit needed_headroom and needed_tailroom from lowerdev macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-89792", "url": "https://ubuntu.com/security/CVE-2026-89792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds reads in share config responses Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-97951", "url": "https://ubuntu.com/security/CVE-2026-97951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands When a LUN_RESET aborts a WRITE command that is in the TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and waits for the frontend to finish processing. If the initiator subsequently sends the remaining dataout PDUs, __iscsit_check_dataout_hdr() catches the payload, stops the dataout timer if the sequence is final and finally dumps the data. However, the iSCSI target doesn't trigger the completion process for these aborted commands. Because of this, the abort path hangs indefinitely in target_put_cmd_and_wait(), leading to a deadlocked target worker thread. Fix this by explicitly calling target_complete_cmd() when the final dataout PDU is received for an aborted WRITE command. target_complete_cmd() detects the CMD_T_ABORTED flag and cleanly routes the command into target_abort_work, allowing the abort completion to successfully unblock.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-97952", "url": "https://ubuntu.com/security/CVE-2026-97952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunvdc: unmap LDC cookies when the descriptor send fails __send_request() maps the request's pages into the LDC channel's map table (ldc_map_sg()), fills in the descriptor and marks it VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger(). When the trigger fails, the error path only prints a message: the descriptor stays READY and the cookies are never unmapped. The mapping is normally released in vdc_end_one() when the peer completes the descriptor - but a descriptor whose doorbell was never sent will never complete, and since dr->prod is not advanced on failure, the reset path (vdc_requeue_inflight(), which walks [cons, prod)) never visits it either. The map table entries are leaked permanently. Since commit a11f6ca9aef9 (\"sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN\") trigger failures occur in practice under load, so every resulting I/O error also leaks one request's worth of entries from the fixed-size (8192 entries per channel) map table. Because the allocator hands out contiguous ranges, fragmentation makes large multi-segment requests fail first as the table drains, until ldc_map_sg() fails permanently and the disk is dead until reboot. It also makes any retry-based recovery unusable: requeuing the request on -EAGAIN remaps the pages on every attempt, overwriting desc->cookies and orphaning the previous mapping, so the table drains at the retry rate. This is the memory exhaustion observed when the requeue approach was first tested in October 2025. Roll back on failure: unmap the cookies, mark the descriptor FREE again and clear the request entry. If the trigger failed with -ENOTCONN, __vdc_tx_trigger() has already reset the port, which tears down and reallocates both the dring and the LDC channel including its map table - nothing to roll back, and the stale descriptor must not be touched.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97954", "url": "https://ubuntu.com/security/CVE-2026-97954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix tcp stream corruption with large pages rds_message_map_pages() assigns PAGE_SIZE bytes to every scatterlist entry, even when total_len ends in a partial page. The RDS congestion map is defined as 8192 bytes, so on systems with PAGE_SIZE greater than 8192 the scatterlist maps bytes beyond the end of the congestion map. RDS-TCP transmits the SG contents according to those lengths, so the extra bytes become part of the TCP RDS stream and are interpreted as subsequent RDS message headers, corrupting the stream. Limit the final scatterlist mapping to the number of bytes remaining. This has no effect on systems with a 4K page size and allows RDS-TCP to be used on systems with 16K and larger page sizes. The RDS selftest, which previously hung on 16K pages, now passes.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97957", "url": "https://ubuntu.com/security/CVE-2026-97957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix mailbox segment buffer overflow check_mbox_seq_id_and_seg_len() validates that seq_id does not exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed MBOX_SEG_LEN (48). However, this allows the last segment (seq_id=42) to carry a full 48-byte payload, writing to offset 42*48=2016 for 48 bytes (ending at byte 2064). The receive buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a 16-byte heap buffer overflow. The hinic3 driver already handles this correctly by defining MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it exceeds the remaining buffer space. Apply the same fix to the hinic driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97958", "url": "https://ubuntu.com/security/CVE-2026-97958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain(). If a netlink socket sends RTM_GETCHAIN requests repeatedly without recv()ing the responses, tc_ctl_chain() hogs CPU and triggers Hung Task splat. [0] As caught in the stack trace, netlink_attachskb() could confuse tc_ctl_chain() by returning -EAGAIN when the userspace netlink socket's receive buffer is full. The replay: label exists since commit 32a4f5ecd738 (\"net: sched: introduce chain object to uapi\") but was not used initially. Since commit 9f407f1768d3 (\"net: sched: introduce chain templates\"), the label is needed for RTM_NEWCHAIN because tcf_proto_lookup_ops() may release RTNL to call request_module(). However, the replay logic is unnecessary for RTM_GETCHAIN. Let's apply the replay logic only for RTM_NEWCHAIN. [0]: INFO: task repro:1018 is blocked on a mutex likely owned by task repro:1022. task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 task_flags:0x400040 flags:0x00080000 Call Trace: ? clockevents_program_event (kernel/time/clockevents.c:372) ? pskb_expand_head (net/core/skbuff.c:615) ? skb_release_data (net/core/skbuff.c:1122) ? netlink_attachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/af_netlink.c:1232) ? __netlink_lookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/af_netlink.c:499) ? tc_chain_notify (net/sched/cls_api.c:3045) ? tc_chain_notify (./include/linux/skbuff.h:1384 net/sched/cls_api.c:3041) ? netlink_unicast (net/netlink/af_netlink.c:1335) ? rtnl_unicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985) ? tc_ctl_chain (net/sched/cls_api.c:3242) ? rtnetlink_rcv_msg (net/core/rtnetlink.c:7146) ? netlink_unicast (net/netlink/af_netlink.c:1354) ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:7177) ? netlink_rcv_skb (net/netlink/af_netlink.c:2556) ? netlink_unicast (net/netlink/af_netlink.c:1319) ? netlink_sendmsg (net/netlink/af_netlink.c:1900) ? __sock_sendmsg (net/socket.c:800) ? __sys_sendto (net/socket.c:2281) ? __x64_sys_sendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284) ? do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97959", "url": "https://ubuntu.com/security/CVE-2026-97959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_route: free emptied bucket on filter move route4_change can move an existing filter to a different top-level bucket: route4_set_parms recomputes the handle from TCA_ROUTE4_TO/ FROM/IIF, and the handle-mismatch check is gated on the 'new' flag, so for an existing filter the new handle may differ from the old one and land in a different bucket. When this happens, the filter is unlinked from the old bucket, but the bucket itself is never freed once it goes empty. The stale empty bucket remains in head->table[], causing route4_delete to report *last=false even after the last live filter is gone. That pins the empty tcf_proto and causes a leak. Fix this by refcounting the filters linked to a bucket and freeing the bucket when the count drops to zero. The existing scan in route4_delete goes away with it. The count is updated at all sites that link or unlink a filter during add, change and delete, and the bucket is dropped from head->table[] as soon as it reaches zero. Conditions to recreate the bug: CONFIG_NET_CLS_ROUTE4=y, CONFIG_NET_SCH_INGRESS=y, CONFIG_NET_CLS_ACT=y. tc qdisc replace dev lo clsact tc filter add dev lo ingress protocol ip pref 100 route from 1 to 1 tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \\ route from 1 to 2 tc filter del dev lo ingress protocol ip pref 100 handle 0x10002 \\ route from 1 to 2 tc filter show dev lo ingress | grep -c 'pref 100 route chain 0 '", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97963", "url": "https://ubuntu.com/security/CVE-2026-97963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: initialize ptp_lock at probe time priv->ptp_lock is only initialized in stmmac_ptp_register(), which runs during __stmmac_open(). However, the lock is also used while the interface is down and has never been opened: tc_taprio_configure() invokes the PTP gettime64() callback to compute the EST base time when offloading a TAPRIO schedule, and stmmac_get_time() takes priv->ptp_lock. Using an uninitialized rwlock is undefined behaviour. Move the rwlock_init() to __stmmac_dvr_probe(), together with the other private locks, so that ptp_lock is always valid regardless of the interface state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97964", "url": "https://ubuntu.com/security/CVE-2026-97964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_synctty: ensure a writeable skb header ppp_sync_txmunge() checks headroom before prepending the address and control bytes, but does not ensure that the skb header is writable. A received skb can reach this function through PPP channel bridging without passing through ppp_start_xmit(), which calls skb_cow_head(). For example, a PPPoE frame may share its buffer with a clone queued to an AF_PACKET socket. If it is bridged to a synchronous tty channel, the address/control bytes can overwrite data still visible to that socket. Use skb_cow_head() to ensure both sufficient headroom and a writable header.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97969", "url": "https://ubuntu.com/security/CVE-2026-97969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix clock leak and spurious timer in settimeout() msc313e_wdt_settimeout() unconditionally calls msc313e_wdt_start() which introduces two severe bugs: 1. If the watchdog is already active, calling start() again will increase the reference count of the clock again. However stop() is only called once, the reference count is unbalance. 2. If the watchdog is stopped, calling settimeout() will start the hardware timer accidentally. Factor out the register-writing logic into a helper function. Only call it in settimeout() if the watchdog is running. Otherwise, simply update `wdev->timeout`.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97970", "url": "https://ubuntu.com/security/CVE-2026-97970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Avoid division by zero clk_get_rate() could return 0. Avoid a division by zero panic.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97981", "url": "https://ubuntu.com/security/CVE-2026-97981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Count dropped frames as NAPI work The RX loop only consumes budget when it successfully delivers a frame. Error paths keep consuming descriptors without reducing the budget, so a stream of bad frames can process the entire receive ring in one poll. Move the budget accounting to a common end-of-frame path. This counts each completed frame as NAPI work whether it was delivered or dropped, matching the behavior of the vendor driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97982", "url": "https://ubuntu.com/security/CVE-2026-97982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Fix budget accounting The gmac_rx() function returns the remaining NAPI budget, but its caller treats the return value as the number of packets received. An idle poll therefore reports a full budget and remains scheduled. Return the number of received packets instead. Preserve the existing free queue refill accounting by adding that count directly; continuing to subtract it from the budget would invert the refill behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97991", "url": "https://ubuntu.com/security/CVE-2026-97991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim_blk: reject out-of-range sector starts vdpasim_blk_check_range() logs an invalid start sector but continues validating the request. The subsequent unsigned capacity subtraction can underflow and let an out-of-range buffer offset reach the data path. The invalid offset is used by three request paths. VIRTIO_BLK_T_OUT copies guest data to blk->buffer + offset through vringh_iov_pull_iotlb(), causing an out-of-bounds write in _copy_from_iter() or memcpy(). VIRTIO_BLK_T_IN copies from blk->buffer + offset to the guest through vringh_iov_push_iotlb(), causing an out-of-bounds read in _copy_to_iter(). VIRTIO_BLK_T_WRITE_ZEROES passes blk->buffer + offset to memset(), causing an out-of-bounds write. Reject starts at or beyond the capacity before the subtraction. Treat the capacity boundary as invalid because the IN and OUT paths round byte counts down to sectors for validation but later copy the original byte counts. A sub-sector request at the capacity boundary would otherwise still access past the end of the buffer. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97993", "url": "https://ubuntu.com/security/CVE-2026-97993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx vhost_vdpa_set_config_call() swaps the eventfd_ctx_fdget() return value into v->config_ctx before checking it, so on failure the field briefly holds an ERR_PTR: \tctx = fd == VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd); \tswap(ctx, v->config_ctx); \tif (!IS_ERR_OR_NULL(ctx)) \t\teventfd_ctx_put(ctx); \tif (IS_ERR(v->config_ctx)) { \t\tlong ret = PTR_ERR(v->config_ctx); \t\tv->config_ctx = NULL; \t\treturn ret; \t} Commit 0bde59c1723a (\"vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails\") added that clearing, and spelled out the invariant the rest of the file relies on: \"we consider 'v->config_ctx' valid if it is not NULL\". The window between the swap and the clearing still breaks it. vhost_vdpa_config_cb() only tests for NULL, so a config interrupt delivered inside the window hands the ERR_PTR to eventfd_signal(). Check the fd before installing it instead. That closes the window and matches how vhost_vring_ioctl() handles the same failure for the vq call fd. It also stops a rejected fd from tearing down a config interrupt that was working: until now the swap replaced the live context and put it, so after an EBADF the device silently stopped delivering config interrupts until userspace installed a new fd.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97995", "url": "https://ubuntu.com/security/CVE-2026-97995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_console: do not free control-out buffers on remove __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): \tfree_buf \tremove_vqs \tvirtcons_remove \tunbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97998", "url": "https://ubuntu.com/security/CVE-2026-97998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: cope with concurrent instance destruction Instances are refcounted. However, only memory release happens on the 1 -> 0 transition; the unlink from hashes can occur with any refcount. Uncooperative userspace can force a situation where a queue is pending for destruction from netlink event while a different socket with same portid processes an UNBIND request. With right timing, this will unhash the instance again: Oops: general protection fault, [..] Call Trace: nfulnl_recv_config+0x31a/0xd50 nfnetlink_rcv_msg+0x7c2/0xeb0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98006", "url": "https://ubuntu.com/security/CVE-2026-98006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev The epq_in_urb object belonging to the caiaq device is coupled within the struct snd_usb_caiaqdev. After usb_submit_urb(epq_in_urb, GFP_KERNEL) executes successfully, epq_in_urb is successfully added to the urbp_list queue of the dummy HCD driver (userspace specifies dummy_hcd as the HCD layer driver for the caiaq USB device). When init_card() calls snd_usb_caiaq_send_command() which subsequently fails due to a timeout, and proceeds to call snd_card_free() to release the card, the embedded ep1_in_urb object is also freed. When the dummy HCD driver detects that the URB has been unlinked, it returns the URB (by usb_hcd_giveback_urb()), which triggers [1]. Decouple the ep1_in_urb object from the struct snd_usb_caiaqdev and switch to using a pointer instead. Separately allocate and manage the memory for ep1_in_urb to prevent the release of the snd_card memory object from interfering with it. midi_out_urb has the same issue as ep1_in_urb and is handled in the same way. [1] BUG: KASAN: slab-use-after-free in usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 Write of size 4 at addr ffff88803cee1050 by task ktimers/1/29 Call Trace: usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 dummy_timer+0xaac/0x4d50 drivers/usb/gadget/udc/dummy_hcd.c:2019 __run_hrtimer kernel/time/hrtimer.c:2067 [inline] __hrtimer_run_queues+0x3eb/0xaf0 kernel/time/hrtimer.c:2124 hrtimer_run_softirq+0x1e1/0x2e0 kernel/time/hrtimer.c:2141 Allocated by task 36: snd_card_new+0x7b/0x110 sound/core/init.c:184 create_card sound/usb/caiaq/device.c:429 [inline] snd_probe+0x236/0x1af0 sound/usb/caiaq/device.c:544 Freed by task 36: snd_card_free_when_closed sound/core/init.c:630 [inline] snd_card_free+0x138/0x1d0 sound/core/init.c:662 snd_probe+0x162b/0x1af0 sound/usb/caiaq/device.c:553", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98009", "url": "https://ubuntu.com/security/CVE-2026-98009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: clamp quantum in parse and fallback paths ets_qdisc_change() falls back to psched_mtu() with no floor for bands without an explicit quantum. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so a zero psched_mtu on a headerless device makes the deficit-refill loop spin under the qdisc lock. Move the floor into ets_quantum_parse() so explicitly configured quanta are also clamped to [256, 1<<20], not just the fallback path. Conditions to recreate the bug: CONFIG_NET_SCH_ETS=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root ets bands 3 strict 2 quanta 1 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98010", "url": "https://ubuntu.com/security/CVE-2026-98010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: drr: clamp quantum in change class drr_change_class() rejects explicit quantum==0 but falls back to psched_mtu() with no floor. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 (or a zero psched_mtu on a headerless device) makes the deficit-refill loop spin under the qdisc lock. Add clamp_t(u32, quantum, 256, 1<<20) after the zero reject and on the fallback path. The explicit-zero reject is preserved. Conditions to recreate the bug: CONFIG_NET_SCH_DRR=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root drr tc class add dev dummy0 parent 1: classid 1:1 drr quantum 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98011", "url": "https://ubuntu.com/security/CVE-2026-98011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum in change and init paths hhf_change() accepts any quantum from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) in hhf_change() matching fq_codel_change(). Clamp hhf_init() to [256, 1<<20] matching the siblings, and remove the old fallback that only set quantum=256 on overflow. Conditions to recreate the bug: CONFIG_NET_SCH_HHF=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root hhf tc qdisc change dev dummy0 root hhf quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98012", "url": "https://ubuntu.com/security/CVE-2026-98012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum in change path sfq_change() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and the init clamp. Conditions to recreate the bug: CONFIG_NET_SCH_SFQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root sfq tc qdisc change dev dummy0 root sfq quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98013", "url": "https://ubuntu.com/security/CVE-2026-98013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp quantum in change path fq_pie_change() accepts any quantum value from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Conditions to recreate the bug: CONFIG_NET_SCH_FQ_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq_pie tc qdisc change dev dummy0 root fq_pie quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98014", "url": "https://ubuntu.com/security/CVE-2026-98014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch, prevent mc_list repopulation during vport disable In mlx5_esw_vport_disable(), move esw_apply_vport_rx_mode() ahead of esw_vport_change_handle_locked() so vport->allmulti_rule is NULL before the change handler observes it. During FW-fatal recovery the disable runs while dev->state == INTERNAL_ERROR. The promisc query inside esw_update_vport_rx_mode() fails and returns early, leaving vport->allmulti_rule intact, so esw_update_vport_mc_promisc() runs and adds MLX5_ACTION_ADD entries to vport->mc_list whose flow rules are then installed in the FDB by esw_add_mc_addr(). esw_destroy_legacy_table() tears down the FDB with those refs still held, corrupting the sub-tree and leaving dangling flow_rule pointers in vport->mc_list. Two-stage failure on `echo 1 > /sys/bus/pci/devices//reset`: refcount_t: underflow; use-after-free. tree_put_node+0xef/0x110 [mlx5_core] clean_tree+0x44/0xd0 [mlx5_core] (x5) mlx5_fs_core_cleanup+0x57/0x1c0 [mlx5_core] mlx5_unload+0x65/0xd0 [mlx5_core] ... mlx5_health_try_recover BUG: unable to handle page fault for address: 0000000003000055 down_write+0x1c/0x60 mlx5_del_flow_rules+0x33/0x1f0 [mlx5_core] esw_del_mc_addr+0x7b/0x170 [mlx5_core] esw_apply_vport_addr_list+0x56/0xf0 [mlx5_core] esw_vport_change_handle_locked+0x28b/0x310 [mlx5_core] mlx5_esw_vport_enable+0x270/0x4a0 [mlx5_core] ... mlx5_load ... mlx5_health_try_recover esw_apply_vport_rx_mode(false, false) clears vport->allmulti_rule via its local state machine even when the FW del fails. With the rule NULL the !IS_ERR_OR_NULL(allmulti_rule) gate in the change handler closes, no rules are installed during disable, and the reload starts with a clean mc_list.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98015", "url": "https://ubuntu.com/security/CVE-2026-98015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put In mlx5_eswitch_termtbl_put(), the zero-ref cleanup check reads tt->ref_count after termtbl_mutex has been released. Two concurrent callers on the same mlx5_termtbl_handle race: one decrements ref_count to zero, removes the hash entry, and calls kfree(tt) while the other has already dropped the mutex and is about to evaluate if (!tt->ref_count), producing a use-after-free. Fix this by capturing the result of the decrement into a stack-local last variable before dropping the mutex. The cleanup decision is now made entirely under termtbl_mutex, and tt is not touched after kfree.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98016", "url": "https://ubuntu.com/security/CVE-2026-98016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free race in sample_restore_put() Concurrent teardown of TC sample rules sharing the same restore context may re-read restore->count after dropping restore_lock. At that point another thread may already have completed cleanup and freed the restore object. Use the result of the refcount decrement while holding restore_lock to determine whether cleanup is needed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98022", "url": "https://ubuntu.com/security/CVE-2026-98022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations Several subsystems allocate ring buffers sized by dev->tx_queue_len with no upper bound. An unprivileged user (via unshare -Urn) can set a huge tx_queue_len and exhaust global memory with ring allocations: - pfifo_fast: pfifo_fast_init() and pfifo_fast_change_tx_queue_len() allocate 3 skb_array rings of tx_queue_len entries each. - tun: tun_queue_resize() and the queue-attach path resize ptr_rings to tx_queue_len on the NETDEV_CHANGE_TX_QUEUE_LEN notifier. - tap (macvtap/ipvtap): tap_queue_resize() and tap_init() resize/init ptr_rings to tx_queue_len on the same notifier. netif_change_tx_queue_len() is the single entry point for IFLA_TXQLEN, sysfs, and the SIOCSIFTXQLEN ioctl. Cap new_len at S16_MAX (32767) there so the oversized value is rejected at set time. This takes effect whether the device is up or down, before dev->tx_queue_len is written, before any notifier fires, and before any ring is allocated. The \"> S16_MAX\" check also subsumes the previous unsigned-long truncation test, and a negative ifr_qlen from the ioctl lands far above the cap after conversion, so both old failure modes are covered by the one comparison. tx_queue_len is ambigious: both a per-ring sizing multiplier and a default queue-length/limit knob for consumers that allocate nothing at set time (pfifo/bfifo/gred/plug/sfb limits, htb direct_qlen, qfq max_classes, teql). 32767 is chosen as the largest value NLA_POLICY_FULL_RANGE can express for the u32 IFLA_TXQLEN policy in patch 2/3 while staying a legitimate queue length on high-BDP paths; the ring-memory trade-off of a shared knob is disclosed below. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn). - pfifo_fast: create veth pairs, set tx_queue_len to 500000, attach mq+pfifo_fast. ~28 iterations OOMs a 2GB guest. - tun: create 50 tun devices with IFF_MULTI_QUEUE, set tx_queue_len to 500000, open 8 queues each. ~1.6GB of ptr_ring allocations OOMs a 512MB guest. - tap: same as tun with IFF_TAP. ~960MB OOMs a 512MB guest. - On the fixed kernel the oversized tx_queue_len is rejected with -ERANGE at set time (all four paths: RTM_SETLINK, RTM_NEWLINK create, sysfs, ioctl - the latter two via this check, the former two via this check and the 2/3 parse policy respectively).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98023", "url": "https://ubuntu.com/security/CVE-2026-98023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: reject dynamic fdb entries that reference a nexthop id The commit cited in the Fixes tag allowed VXLAN FDB entries to point to FDB nexthops so that overlay traffic could be load balanced across multiple VTEPs. Such entries can only be configured from user space, cannot be learned and cannot roam. They only make sense with a user space control plane such as E-VPN where data plane learning is disabled. Despite that, the VXLAN driver does not currently prevent such entries from being configured with the \"dynamic\" flag. The per-nexthop FDB list is only protected by the per-device hash lock, which is not sufficient when two VXLAN devices point to the same FDB nexthop and therefore share the list. Aging runs in softirq context without RTNL, so an entry deleted by one device can race with an addition or deletion from the other, leading to list corruption: list_del corruption. next->prev should be ffff8881069d9548, but was dead000000000122. (next=ffff8881069d9448) WARNING: CPU: 0 PID: 90 at lib/list_debug.c:65 __list_del_entry_valid_or_report+0x1aa/0x210 ... vxlan_fdb_destroy+0x5b8/0xad0 vxlan_cleanup+0x328/0x450 call_timer_fn+0x2a/0x1c0 run_timer_softirq+0x18c/0x210 BUG: KASAN: slab-use-after-free in vxlan_fdb_destroy Fix this by rejecting the bogus configuration of dynamic FDB entries that point to FDB nexthops, both when created and when an existing entry is updated. As such, the per-nexthop FDB list is only ever mutated under the RTNL lock. Add test cases to make sure that this does not regress in the future.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98025", "url": "https://ubuntu.com/security/CVE-2026-98025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is \t} else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB \"frame\" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98027", "url": "https://ubuntu.com/security/CVE-2026-98027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer size mv88e6xxx_get_rxnfc() uses rxnfc->rule_cnt as the write index while dumping the policy IDR, clobbering the input value before it has been looked at. That input is the number of entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed policy rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Count into a local so the caller's limit survives the walk, and stop with -EMSGSIZE once it is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98030", "url": "https://ubuntu.com/security/CVE-2026-98030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size bcm_sf2_cfp_rule_get_all() walks the whole cfp.unique bitmap into rule_locs[] without consulting nfc->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed CFP rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98031", "url": "https://ubuntu.com/security/CVE-2026-98031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: Initialize extack in remove_nh_grp_entry() remove_nh_grp_entry() prints the extack message when a listener fails to replace the reduced nexthop group. However, extack is not initialized and listeners are not required to set a message when returning an error. Neither netdevsim nor mlxsw do so when an allocation fails, resulting in the dereference of an uninitialized stack pointer. Fix by zero-initializing extack, as was done in commit 6347c5314cee (\"nexthop: initialize extack in nh_res_bucket_migrate()\").", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98063", "url": "https://ubuntu.com/security/CVE-2026-98063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref in btf_var_show() btf_var_show() calls btf_type_id_resolve() unconditionally, which dereferences btf->resolved_ids. That is NULL for a base BTF - e.g. the vmlinux BTF that bpf_snprintf_btf() renders against - since base BTF is not resolved during parsing. btf_modifier_show() guards this with 'if (btf->resolved_ids)', but btf_var_show() does not. A BPF program that passes the type_id of a BTF_KIND_VAR from the vmlinux BTF to bpf_snprintf_btf() thus NULL-derefs: KASAN: probably user-memory-access in range [0x46638-0x4663f] RIP: 0010:btf_var_show (kernel/bpf/btf.c:2929) Call Trace: btf_type_show (kernel/bpf/btf.c:8259) btf_type_snprintf_show (kernel/bpf/btf.c:8329) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Resolve the var's type directly with btf_type_skip_modifiers() when resolved_ids is NULL, mirroring btf_modifier_show().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98064", "url": "https://ubuntu.com/security/CVE-2026-98064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref when showing a void BTF type btf_modifier_show() resolves the modifier and then calls btf_type_ops(t)->show() unconditionally. For the void type (type_id 0, BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL. A \"const void\" (a modifier resolving to void) cannot be a map key or value - map_check_btf() rejects it because void has no size - so the map dump path does not reach it. But bpf_snprintf_btf() takes a type_id straight from the BPF program, and passing such a \"const void\" from the vmlinux BTF NULL-derefs: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:btf_modifier_show (kernel/bpf/btf.c:2914) Call Trace: btf_type_show (kernel/bpf/btf.c:8251) btf_type_snprintf_show (kernel/bpf/btf.c:8321) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fall back to btf_df_show() when the resolved type has no show op; it emits the \"\" placeholder already used for kinds like FWD and FUNC. bpf_snprintf_btf() then returns the length as usual.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98066", "url": "https://ubuntu.com/security/CVE-2026-98066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Fix potential double-free at error path The fix for caiaq driver's resource management to handle the errors tries to release the resources in a common destructor call, but as a sashiko review for another patch suggested, some of the audio resources such as URBs have been already freed, and this may lead to a double-free. For addressing the double-free, call the common destructor function from each place, and assure that the resource pointers get cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98068", "url": "https://ubuntu.com/security/CVE-2026-98068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: don't let rds_conn_shutdown() consume a concurrent drop rds_conn_shutdown() finishes by moving the path from RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts RDS_CONN_ERROR as the starting state of that final transition, so that a FIN processed in softirq context during the teardown does not derail the shutdown into a noisy error path. But consuming that RDS_CONN_ERROR also consumes the shutdown pass that came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN is a no-op. For the FIN case that is harmless - the socket the FIN arrived on is the very socket the teardown just released. It is not harmless for a dropper that attached something to the path first. rds_tcp_accept_one() is such a dropper. Its path claim in rds_tcp_accept_one_path() transitions RDS_CONN_DOWN -> RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous socket in softirq context, an administrative reset - can put the path into RDS_CONN_ERROR between that claim and the state check that follows, which accepts RDS_CONN_ERROR. The accept then installs the freshly accepted socket with rds_tcp_set_callbacks() while the queued teardown - which sampled tc->t_sock before this socket existed - is still running. rds_connect_path_complete() fails its transition to RDS_CONN_UP and drops the path again, queueing the pass that should reap the socket it just installed. If the in-flight shutdown's final transition consumes that drop's RDS_CONN_ERROR, the queued pass finds the path in RDS_CONN_DOWN and does nothing. The installed socket is never torn down: it sits established with its callbacks armed and its rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some later event drops it again. Reproduced with widened race windows as an ever-growing receive queue on a socket owned by a path stuck in RDS_CONN_DOWN, with the peer's send path wedged behind it. Make the final transition only DISCONNECTING -> DOWN. If it fails because the path is in RDS_CONN_ERROR, a drop raced the teardown: cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one piece of the skipped tail that must not be left behind - and return, letting the pass the drop queued finish the job: it tears down whatever attached to the path in the meantime, completes the transition to RDS_CONN_DOWN, and re-arms the reconnect from its own tail. The timer quiesce in that branch matters because the racing drop does not always queue that pass: rds_conn_path_drop() returns without queueing when a destroy is pending - exactly the situation during a netns teardown or module unload, when a FIN on the dying socket is processed while rds_conn_path_destroy() flushes cp_down_w. If the flushed pass is the one that takes this return, no later pass exists, and rds_conn_path_destroy() would find cp_conn_w still armed (WARN_ON) and then free a path whose reconnect timer can still fire. With the cancel in the branch, every exit of a shutdown pass leaves the timer quiesced no matter which pass completes the transition. The FIN case keeps making progress, one pass later and still without noisy logging. Any other state keeps today's rds_conn_path_error() handling; no current cp_state writer can leave a DISCONNECTING path in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from a non-DISCONNECTING state), so that branch is defensive. On kernels without the preceding patches the same hazard exists with the sample-based quiesce; the fix applies there equally.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98069", "url": "https://ubuntu.com/security/CVE-2026-98069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire the fastpath locks in rds_conn_shutdown() rds_conn_shutdown() quiesces the transmit and receive-refill paths by waiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and then runs the transport shutdown and rds_conn_path_reset(). Sampling the bits clear is not the same as owning them: the moment after the wait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or rds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run concurrently with the teardown. The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the transmit state under it. Oracle UEK fixed the same class of crashes - a 14-year tail of BUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL dereferences in rds_ib_send_cqe_handler() during failover testing - by making the teardown path *acquire* the fastpath bit locks instead of testing them (\"rds: Make sure transmit path and connection tear-down does not run concurrently\"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed. Do the same here: take both locks before calling the transport shutdown, hold them across rds_conn_path_reset(), and release them explicitly with a wake-up afterwards. Both are released with clear_bit_unlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rds_send_path_reset() are ordered before either bit is seen clear by the next acquire_in_xmit() or acquire_refill(). The fastpath users of these bits - rds_send_xmit() and rds_ib_recv_refill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rds_tcp_reset_callbacks() is different: since the previous patch it acquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rds_tcp_accept_one() on the single-threaded krdsd workqueue and holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown(). An IB path's drain in rds_ib_conn_path_shutdown() has no round cap, but no blocking waiter either: rds_tcp_reset_callbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDS_CONN_DISCONNECTING. Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on the path's ordered cp_wq, whose only execution slot is occupied by the blocked cp_down_w itself, so they are pending at most and cancel without flushing - a reliance on cp_wq being ordered that is now noted next to those cancels (on ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98070", "url": "https://ubuntu.com/security/CVE-2026-98070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks() rds_tcp_reset_callbacks() quiesces the transmit path by setting the path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to be sampled clear before swapping the underlying socket and calling rds_send_path_reset(). Sampling the bit clear is not the same as owning it: rds_send_xmit() can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its state recheck after taking the lock is a store-buffering pattern (the resetter writes the state and reads the bit, the sender writes the bit and reads the state) and acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write and the transmit path then runs concurrently with rds_send_path_reset() rewriting cp_xmit_* state - which is exactly what the comment above rds_send_path_reset() tells its callers to prevent. Take the lock instead, hold it across the socket swap and rds_send_path_reset(), and release it with a wake-up at the end. The lock-ordering constraint documented above the wait still holds: the lock is acquired before lock_sock(), so a sender inside tcp_sendmsg() can never be waited on while we hold the socket lock. Two details of the old code go away with the same change: - t_sock is now read only after the lock is acquired. The old code cached it before waiting; the teardown in rds_conn_shutdown() releases that socket and clears t_sock, so a pointer cached before the wait can be stale by the time the accept path resumes. Reading it under RDS_IN_XMIT is what makes the exclusion complete once the teardown owns the same lock, which the next patch arranges; until then the teardown still only samples the bit, and the two paths remain as exposed to each other as they are today. - The old !osock early path called rds_send_path_reset() with no serialization at all. It now runs under the lock like the normal path. The conditional RDS_CONN_RESETTING transition of the previous patch happens before the socket check either way: a path found without a socket is either still connecting (its reconnect worker blocked on t_conn_path_lock) and legitimately goes RESETTING -> UP on the new socket, or it has been torn down meanwhile and is dropped. The in-function comment describing the old wait-based quiesce is rewritten to describe the lock-based one, and the stale block comment above the function (which still described a return value and an incomplete list of t_sock writers) is refreshed to name all four writers - the connect, accept, teardown and swap paths - and what serializes each of them.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98071", "url": "https://ubuntu.com/security/CVE-2026-98071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: clear cp_flags bits individually in rds_conn_path_reset() rds_conn_path_reset() wipes the whole flag word with a plain cp->cp_flags = 0 store. Every other accessor of that word uses atomic bitops, and some of them can run concurrently with the reset: RDS_LL_SEND_FULL is set from rds_send_xmit() and cleared from the transport completion paths, neither of which holds anything that excludes the shutdown worker. A plain store racing an atomic read-modify-write on the same word is a data race, and whichever side loses has its update silently discarded. Clear the two bits the reset is actually responsible for instead. RDS_IN_XMIT and RDS_RECV_REFILL need no store at all here: they belong to the caller, rds_conn_shutdown(), which waits for both to be clear before calling the transport shutdown and this reset. This also gives every bit in cp_flags a single well-defined writer discipline, which the following patches rely on when they turn RDS_IN_XMIT and RDS_RECV_REFILL into bit locks held across the teardown: a blanket store mid-teardown would destroy lock ownership that an atomic clear preserves. Oracle UEK carries the same conversion (\"net/rds: Preserve essential connection state flags\"), motivated by its asynchronous shutdown state machine, whose progress and destroy flags must survive the reset. UEK's variant also clears RDS_IN_XMIT and RDS_RECV_REFILL because there the reset runs as the final step of a teardown that owns both bits, making those clears its unlock. Upstream that release belongs in rds_conn_shutdown(): once a later patch in this series turns the two bits into locks held across the teardown, ending ownership needs release semantics and a wake-up that a plain clear inside the reset would not provide. Based on Oracle UEK commit \"net/rds: Preserve essential connection state flags\" by Gerd Rausch.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98072", "url": "https://ubuntu.com/security/CVE-2026-98072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in release_in_xmit() release_in_xmit() clears RDS_IN_XMIT with clear_bit_unlock() and then checks waitqueue_active() to decide whether anyone needs waking. clear_bit_unlock() is only a release operation: it orders the critical section before the bit clear, but does not order the subsequent plain load of the wait queue head after it. The waiter side does the mirror image - it adds itself to the wait queue and then tests the bit. That is the classic store-buffering pattern: the releasing CPU can read the wait queue as empty while the waiting CPU still reads the bit as set, so the sleeper is never woken. The waiters are rds_conn_shutdown() and rds_tcp_reset_callbacks(), both in uninterruptible wait_event() with no timeout. A lost wake-up strands the shutdown worker on its single-threaded workqueue until some other sender releases the bit again - and on a connection that is being torn down precisely because it failed, there may never be another sender. The barrier used to be there: release_in_xmit() did clear_bit() followed by smp_mb__after_atomic() until commit 1422f28826d2 (\"rds: introduce acquire/release ordering in acquire/release_in_xmit()\") folded both into clear_bit_unlock(), which strengthened the lock hand-off but silently dropped the full barrier the wake-up check depends on. The refill counterpart, release_refill() in net/rds/ib_recv.c, still carries its smp_mb__after_atomic() for exactly this reason. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98074", "url": "https://ubuntu.com/security/CVE-2026-98074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: do not clear curr_active_slave prematurely when releasing all slaves When releasing all slaves during bond destruction (all == true), __bond_release_one() unconditionally clears bond->curr_active_slave to NULL in every iteration. If a backup slave is released before the active slave, bond_alb_deinit_slave() triggers rlb_teach_disabled_mac_on_primary(), which increments the active slave dev promiscuity counter and sets bond_info->primary_is_promisc = 1. Because bond->curr_active_slave was prematurely cleared to NULL when releasing the backup slave, the subsequent iteration releasing the active slave evaluates oldcurrent as NULL, so bond_change_active_slave(bond, NULL) is skipped. Consequently, bond_alb_handle_active_change() is never called to decrement the promiscuity counter, permanently leaking promiscuous mode on the physical device after bond teardown. When oldcurrent == slave, bond_change_active_slave(bond, NULL) already sets bond->curr_active_slave to NULL. We only need to avoid selecting a new active slave when all == true. Replace the if (all) branch with if (!all && oldcurrent == slave).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98075", "url": "https://ubuntu.com/security/CVE-2026-98075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject BPF_PSEUDO_FUNC reference to the main program fixups.c:jit_subprogs() rewrites BPF_PSEUDO_FUNC loads to contain real function addresses. This function is invoked from bpf_jit_subprogs() only when env->subprog_cnt > 1. Meaning that for any program like below: int main(void *ctx) { void *ptr = main; ... bpf_timer_set_callback(..., ptr); ... } The 'ptr' won't be ever converted to contain an address. In combination with e.g. bpf_timer_set_callback() this would lead to a function call at a bogus address. Instead of complicating the implementation, just assume that no useful program needs main to be a sync or async callback and reject BPF_PSEUDO_FUNC loads for the main subprogram.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98076", "url": "https://ubuntu.com/security/CVE-2026-98076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/probes: Fix use-after-free on field name/type of events with multiple probes The fields of a probe-based dynamic event (kprobe, uprobe, eprobe and fprobe events) are created in traceprobe_define_arg_fields() by handing the probe_arg name/type strings to trace_define_field(), which only stores the pointers without copying. Those strings are owned by the trace_probe and are freed when that probe is removed. An event can have several probes attached. The field list is defined only once, by the first probe that registers the event, but it is kept alive by any surviving sibling probe. Deleting just that first probe by symbol - # primary A: fields are defined from A's args echo 'p:kprobes/ev vfs_read a1=$arg1' > kprobe_events # append B: shares A's event call echo 'p:kprobes/ev vfs_write a1=$arg1' >> kprobe_events # delete only A (matched by symbol), B survives echo '-:kprobes/ev vfs_read' >> kprobe_events frees A's args (trace_probe_cleanup() -> traceprobe_free_probe_arg()), but trace_probe_unlink() keeps the trace_probe_event because the probe list is not empty. The event call stays registered via B while its fields now reference freed memory. Any field lookup then reads it, e.g. echo 'a1 == 1' > events/kprobes/ev/filter BUG: KASAN: slab-use-after-free in strcmp+0xa7/0xb0 Call Trace: strcmp trace_find_event_field parse_pred process_preds create_filter apply_event_filter event_filter_write field->name references parg->name (kstrdup'd, freed with the probe) and, for array arguments, field->type references parg->fmt (kmalloc'd, freed with the probe) - the scalar type otherwise points at the static fmttype rodata, which is safe. Have traceprobe_define_arg_fields() duplicate the name and type strings and anchor the copies on the trace_probe_event, which embeds the event call and outlives every individual probe; trace_probe_event_free() releases them. The reproducer above triggers reliably; the field lookup and the delete both run under event_mutex, so this is a dangling reference after removal rather than a race. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98077", "url": "https://ubuntu.com/security/CVE-2026-98077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace() sip_skip_whitespace() returns dptr unchanged when its own loop exhausts the buffer (dptr == limit), instead of NULL like its sibling sip_follow_continuation() returns on its own \"no more data\" path. ct_sip_get_header() only checks for NULL after calling it: dptr = sip_skip_whitespace(dptr, limit); if (dptr == NULL) break; if (*dptr != ':' || ++dptr >= limit) break; so a recognized header name followed only by spaces/tabs running to the exact end of the SIP payload, with no colon, makes the very next statement read one byte past the buffer. Make both \"no more data\" outcomes return NULL, matching the convention sip_follow_continuation() already uses and that both existing callers already check for.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98078", "url": "https://ubuntu.com/security/CVE-2026-98078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix reversed sequence option serialization hton_seq() expects the host-order source first and the unaligned network-order destination second. The version 1 sync sender passes these arguments in reverse for both sequence blocks. This leaves 24 bytes of the kmalloc-backed message unwritten. It may disclose stale heap data and replace the live connection sequence state with values read from the buffer. Pass the connection sequence state as the source and the message payload as the destination for both blocks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98080", "url": "https://ubuntu.com/security/CVE-2026-98080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not force reloc root creation during qgroup_account_snapshot() [BUG] When running btrfs/252 with quota enabled through MKFS_OPTIONS=\"-O quota\", it has a high chance to trigger the following kernel warning and flips the fs RO: BTRFS info (device dm-2): relocating block group 30408704 flags metadata|dup ------------[ cut here ]------------ WARNING: fs/btrfs/extent-tree.c:879 at lookup_inline_extent_backref+0x74b/0x960 [btrfs], CPU#4: btrfs/2173 CPU: 4 UID: 0 PID: 2173 Comm: btrfs Not tainted 7.2.0-rc6-custom+ #457 PREEMPT(full) 3adc6528fb66f7a55fe1095385818e742f200aab Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:lookup_inline_extent_backref+0x74b/0x960 [btrfs] Call Trace: insert_inline_extent_backref+0x7c/0x160 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_inc_extent_ref+0xa9/0x270 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_run_delayed_refs+0x4af/0x11c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_run_delayed_refs+0x9d/0xf0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshot+0x39d/0xf00 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshots+0x9b/0xc0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_commit_transaction+0x280/0xeb0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] prepare_to_relocate+0x147/0x200 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] relocate_block_group+0x6b/0x5e0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_block_group+0x92c/0x2380 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_balance+0xa2c/0x19c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_ioctl+0x2839/0x2d30 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS info (device dm-2): leaf 4593991680 gen 233 total ptrs 175 free space 5953 owner 2 BTRFS info (device dm-2): refs 3 lock_owner 2173 current 2173 \titem 0 key (166772736 METADATA_ITEM 1) itemoff 16250 itemsize 33 \t\textent refs 1 gen 222 flags 2 \t\tref#0: tree block backref root 266 [ Skip the tree dump ] \titem 174 key (263225344 METADATA_ITEM 0) itemoff 10328 itemsize 33 \t\textent refs 1 gen 162 flags 258 \t\tref#0: tree block backref root 267 BTRFS error (device dm-2): extent item not found for insert, bytenr 179847168 num_bytes 16384 parent 4594335744 root_objectid 273 owner 0 offset 0 BTRFS error (device dm-2): failed to run delayed ref for logical 179847168 num_bytes 16384 type 182 action 1 ref_mod 1: -117 [CAUSE] The above error is showing that there is a tree reference to a metadata extent that is no longer there. With \"ref_verify\" mount option (requires CONFIG_BTRFS_DEBUG), there is some extra debug output: BTRFS error (device dm-2): dumping block entry [180961280 16384], num_refs 0, metadata 1, from disk 0 BTRFS error (device dm-2): root entry 256, num_refs 18446744073709551615 BTRFS error (device dm-2): root entry 273, num_refs 18446744073709551615 BTRFS error (device dm-2): Ref action 3, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 1 btrfs_force_cow_block+0x129/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_insert_empty_items+0x3a/0x70 [btrfs] insert_with_overflow+0x53/0x130 [btrfs] btrfs_insert_dir_item+0x125/0x290 [btrfs] btrfs_add_link+0xaa/0x410 [btrfs] btrfs_rename+0x5ea/0xcd0 [btrfs] btrfs_rename2+0x28/0x60 [btrfs] vfs_rename+0x5b2/0xe10 filename_renameat2+0x244/0x430 __x64_sys_rename+0x48/0x70 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98088", "url": "https://ubuntu.com/security/CVE-2026-98088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() dev_to_node() can return NUMA_NO_NODE (-1) on systems without NUMA topology information for the PCI device, such as single-socket boards that don't expose device-to-node affinity. Passing -1 directly into cpumask_of_node() indexes node_to_cpumask_map[-1], an out-of-bounds array read caught by UBSAN: UBSAN: array-index-out-of-bounds in arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' Fall back to cpu_online_mask when no NUMA node is available, rather than assuming dev_to_node() always returns a valid node index.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98090", "url": "https://ubuntu.com/security/CVE-2026-98090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: restore active device pointers after failed sprout btrfs_init_new_device() switches latest_dev and possibly s_bdev from the seed device to the new sprout device before creating the first writable chunks. If chunk creation or the subsequent sprout setup fails, the error path releases the new device without switching those pointers back. btrfs_show_devname() can then dereference the freed latest_dev and crash. Restore the active device pointers to the latest seed device before removing and releasing the failed sprout device.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98091", "url": "https://ubuntu.com/security/CVE-2026-98091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: detach failed sprout device from transaction update list When creating the first metadata chunk for a sprout filesystem, create_chunk() adds the new device to the transaction dev_update_list through device->post_commit_list. If the subsequent system chunk creation fails, btrfs_init_new_device() aborts the transaction and releases the device while post_commit_list is still linked. This triggers a warning in btrfs_free_device() and leaves the transaction list referencing freed memory. Detach the device while holding chunk_mutex before releasing it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98094", "url": "https://ubuntu.com/security/CVE-2026-98094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: fbtft: make dirty_lock IRQ-safe fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled. Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again. The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled: WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2} CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); lock(console_owner); *** DEADLOCK *** Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98095", "url": "https://ubuntu.com/security/CVE-2026-98095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_packet: Don't cast tpacket_hdr.tp_len to int in tpacket_parse_header(). syzbot reported BUG() in sock_sendmsg_nosec(). [0] The problem is that tpacket_parse_header() casts user-provided tpacket_hdr.tp_len, which is u32, to int. If the length is larger than INT_MAX, the following condition in tpacket_parse_header() passes, if (unlikely(tp_len > size_max)) and any negative value can be returned to the caller, up to sock_sendmsg_nosec(). The repro set tpacket_hdr.tp_len to 0xfffffdef, which is cast to -EIOCBQUEUED (-529), triggering BUG() in sock_sendmsg_nosec(). *(uint64_t*)0x200000000008 = 0xfffffdef; ... syscall(__NR_write, /*fd=*/r[0], /*buf=*/0x200000000000ul, /*count=*/1ul); Let's define the local tp_len as u32 in tpacket_parse_header(). [0]: kernel BUG at net/socket.c:803! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 5628 Comm: syz-executor176 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 RIP: 0010:sock_sendmsg_nosec+0x145/0x180 net/socket.c:803 Code: 06 67 48 0f b9 3a eb 95 e8 e8 3a 22 f8 48 89 df 4c 89 f6 4c 89 e2 4d 89 fb 2e e8 32 a5 5c 16 e9 51 ff ff ff e8 cc 3a 22 f8 90 <0f> 0b e8 c4 3a 22 f8 48 83 c3 18 48 89 d8 48 c1 e8 03 42 80 3c 28 RSP: 0018:ffffc90003aefb48 EFLAGS: 00010293 RAX: ffffffff89a578d4 RBX: ffff8880764c67c0 RCX: ffff88807fb23e80 RDX: 0000000000000000 RSI: 00000000fffffdef RDI: 00000000fffffdef RBP: 00000000fffffdef R08: ffffc90003aef747 R09: 1ffff9200075dee8 R10: dffffc0000000000 R11: fffff5200075dee9 R12: 0000000000000001 R13: dffffc0000000000 R14: ffffc90003aefbc0 R15: ffffffff8aac4310 FS: 000055559101b400(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000210 CR3: 0000000073dca000 CR4: 00000000003526f0 Call Trace: __sock_sendmsg net/socket.c:815 [inline] sock_write_iter+0x2de/0x3e0 net/socket.c:1266 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x612/0xba0 fs/read_write.c:687 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f173130ecb9 Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 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 d8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd67e44248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f173130ecb9 RDX: 0000000000000001 RSI: 0000200000000000 RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd67e44388 R13: 0000000000000002 R14: 00002000000000c0 R15: 0000000000000002 ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98096", "url": "https://ubuntu.com/security/CVE-2026-98096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: restore network header before routing and forwarding ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative. This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows. Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98098", "url": "https://ubuntu.com/security/CVE-2026-98098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL deref in tipc_named_node_up() on empty publication list User-space applications can bind a large number of service addresses to one or more sockets. Each binding of a local-scope service address inserts one entry (publication) into the TIPC name table. If the number of these publications exceeds TIPC_MAX_PUBL (65535), protocol service types (such as node state and link state) are no longer inserted into the name table. This causes two issues: 1. User-space applications subscribing to node or link up/down events stop receiving notifications. 2. A NULL pointer dereference can occur: BUG: kernel NULL pointer dereference, address: 00000000000000d0 ... CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full) ... RIP: 0010:tipc_named_node_up (./include/linux/skbuff.h:2251 net/tipc/name_distr.c:195 net/tipc/name_distr.c:221) ... Call Trace: tipc_node_write_unlock (net/tipc/node.c:428) tipc_rcv (net/tipc/node.c:934 net/tipc/node.c:2189) tipc_udp_recv (net/tipc/udp_media.c:389) Thread 1 (tipc_net_finalize) | Thread 2 (named_distribute) -----------------------------|----------------------------- | ... | list_for_each_entry(publ, pls, binding_node) { | ... | __skb_queue_tail(list, skb); | ... | } | ... | hdr = buf_msg(skb_peek_tail(list)); ... | tipc_nametbl_publish(); | If 'tipc_nametbl_publish()' (Thread 1) fails because the number of local publications reaches TIPC_MAX_PUBL, list (Thread 2) will be empty. As a result, NULL is passed to 'buf_msg()', leading to a NULL pointer dereference. Fix these issues by allowing protocol service types (node state, link state, and topology server) to be inserted into the name table unconditionally. This ensures that users subscribing to these types always receive notifications. In addition, the maximum number of local user publications is reduced to (TIPC_MAX_PUBL - 1). This ensures that the maximum bulk size calculated in tipc_link_set_queue_limits() remains valid.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98108", "url": "https://ubuntu.com/security/CVE-2026-98108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan l2cap_new_connection() sets default value of channel mode to match the parent channel. l2cap_le_connect_req() left this at the default, and created L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that mode. This causes FLAG_DEFER_SETUP channels to reply to L2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect. It can also result to stack OOB write (of l2cap_alloc_cid determined values) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not limit maximum number of deferred channels or check for duplicate ident. Fix by setting chan->mode correctly in l2cap_le_connect_req(). Also check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE instead of OOB write to make it less brittle.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98113", "url": "https://ubuntu.com/security/CVE-2026-98113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: rate limit unmapped SID errors A client can include many structurally valid but unmapped SIDs in a DACL. Logging every mapping failure lets one request generate hundreds of kernel error messages. Rate limit the message to prevent an authenticated client from flooding the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98116", "url": "https://ubuntu.com/security/CVE-2026-98116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation with an mmap_count check performed under the PCM stream lock, but the lock is released long before the buffer is actually freed: snd_pcm_sync_stop(), constraint refinement and do_free_pages() all happen in between. snd_pcm_mmap_data(), on the other hand, takes no lock at all: it validates against the old buffer's state and dma_bytes, remaps its pages into the VMA, and only then increments mmap_count. A concurrent mmap() can therefore slip in between the check and the free. remap_pfn_range() installs writable PTEs for the old buffer's pages without taking page references, and the subsequent do_free_pages() returns those pages to the page allocator while the VMA still maps them. This leaves a stale, writable mapping of freed pages: a page-level use-after-free that can be leveraged for local privilege escalation. Make snd_pcm_mmap_data() participate in the buffer-access scheme introduced for hw_params/hw_free: acquire runtime->buffer_accessing before validating and remapping, and release it afterwards. Buffer reallocation already fails with -EBUSY while accessors are active, and the mmap side now fails with -EBUSY while a reallocation is in progress, so the validate/remap sequence and the check/free sequence can no longer interleave. A reproducer that turns this race into a stale writable mapping of the freed DMA buffer pages is available on request.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98121", "url": "https://ubuntu.com/security/CVE-2026-98121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix NULL pointer dereference in PM callbacks msc313e_wdt_probe() doesn't set the driver data for the platform device. As a result, dev_get_drvdata() in msc313e_wdt_suspend() and msc313e_wdt_resume() will return NULL, leading to a NULL pointer dereference afterward. Set the platform device driver data in msc313e_wdt_probe().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98123", "url": "https://ubuntu.com/security/CVE-2026-98123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration sctp_verify_asconf() walks ASCONF-ACK parameters with sctp_walk_params(), which advances by SCTP_PAD4(length), while the consumer sctp_get_asconf_response() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset. When those bytes yield a length of zero, the while loop over asconf_ack_len makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help). The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read. Reject SCTP_PARAM_ERR_CAUSE parameters shorter than sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERR_CAUSE parameter the consumer can see, so the consumer's asconf_ack_len check is dropped and it returns err_param->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTP_PARAM_ERR_CAUSE per RFC 5061. The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98130", "url": "https://ubuntu.com/security/CVE-2026-98130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START The SCTP_CMD_TIMER_START handler checks timer_pending() before calling timer_reduce(). The timer can expire and detach between these operations, causing timer_reduce() to rearm the timer without taking the association reference required for the newly armed timer. The timer callback later unconditionally drops its association reference, which can leave the association reference count unbalanced and result in use-after-free during association teardown. Use the return value of timer_reduce() to determine whether the timer was actually armed. Take the association reference only when timer_reduce() successfully starts a new timer, closing the race between checking the timer state and rearming it. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98154", "url": "https://ubuntu.com/security/CVE-2026-98154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix -EIO cleanup order in queue_rq On -EIO, the RDMA queue_rq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete. Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98157", "url": "https://ubuntu.com/security/CVE-2026-98157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation The poll_msec sysfs store file uses simple_strtoul() which accepts an unsigned long, but the target field (poll_msec) is unsigned int. On 64-bit systems, a value > UINT_MAX is silently truncated when stored. Fix the mismatch by using kstrtouint() instead. This rejects values larger than UINT_MAX at parse time, making truncation impossible. Also add a check for value < 1 to reject the 0-delay case, which would cause the poll work to spin without delay and consume 100% CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89796", "url": "https://ubuntu.com/security/CVE-2026-89796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid infinite kdamond_merge_regions() internal loop Patch series \"mm/damon: unurgent fixes for infinite loop, NULL de-ref and races\", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-98158", "url": "https://ubuntu.com/security/CVE-2026-98158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_async: drop the errored frame instead of resetting its headroom ppp_receive_nonmp_frame() prepends a two-byte direction tag before running the pass/active BPF filters: \t*(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG); Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in ppp_async's process_input_packet() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD: \terr: \t\tif (skb) { \t\t\t/* make skb appear as freshly allocated */ \t\t\tskb_trim(skb, 0); \t\t\tskb_reserve(skb, - skb_headroom(skb)); \t\t} ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head: skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev: kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled ppp_decompress_frame() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason. Rather than restore the headroom, drop the errored frame - as ppp_synctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read. The original V1 of this patch made room in ppp_receive_nonmp_frame() with skb_cow_head(); Eric pointed out that fixing the root cause in the transport is the right approach. Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-93288", "url": "https://ubuntu.com/security/CVE-2026-93288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state sashiko reports: \"nfnl_log_net_exit() calls nf_log_unset(), which clears the logger pointer without an RCU grace period. Immediately after, ops_free_list() frees the per-net state while concurrent packets might still be executing nf_log_packet() under rcu_read_lock().\" Clear the pointer via .pre_exit to make sure rcu readers have completed before pernet storage is free'd. The change in nf_log_syslog.c is only done for consistency: it doesn't use pernet data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93782", "url": "https://ubuntu.com/security/CVE-2026-93782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: flush backend after device ioctls vhost-scsi translates guest response descriptors into userspace iovecs when commands are submitted. Target-core completes those commands asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while an in-flight command still retains response iovecs translated through the old table. If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command completion can write the response to an unrelated userspace object. Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device ioctl. This waits for in-flight commands that can still use the old response iovecs before the ioctl returns.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93783", "url": "https://ubuntu.com/security/CVE-2026-93783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr and dereferences hdr->addr and hdr->ctrl without validating skb->len first. A truncated frame with skb->len less than the minimum header size causes an out-of-bounds read of uninitialized memory. Additionally, a zero-length frame causes skb->len-- to underflow to UINT_MAX, making skb_tail_pointer() read far past the buffer. Commit 23882b828c3c (\"Bluetooth: RFCOMM: validate skb length in MCC handlers\") fixed the same class of missing-length-check bugs in the MCC sub-handlers, but the top-level rfcomm_recv_frame() was left unfixed. KMSAN reports: BUG: KMSAN: uninit-value in rfcomm_run ... Uninit was created at: __alloc_skb+0x474/0xb60 vhci_write+0xe9/0x870 Fix this by rejecting frames smaller than sizeof(struct rfcomm_hdr) + 1 (the minimum frame must have a 3-byte header and a 1-byte FCS).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93784", "url": "https://ubuntu.com/security/CVE-2026-93784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie() The KASAN allocation trace shows that a malformed IE buffer is stored via SIOCSIWGENIE (cfg80211_wext_siwgenie()) without any validation. The crash trace shows that a subsequent SIOCSIWESSID triggers a connection attempt which calls cfg80211_sme_get_conn_ies() to process the stored IE buffer, causing: - An out-of-bounds read in skip_ie() which reads ies[pos+1] (the length byte) past the end of the 1-byte buffer. - An integer underflow in the memcpy size argument when offs returned by ieee80211_ie_split() exceeds ies_len, causing unsigned subtraction to wrap to SIZE_MAX and triggering a fortify panic. Fix this by validating the IE buffer in cfg80211_wext_siwgenie() before storing it. [drop unnecessary ie_len check, update commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93785", "url": "https://ubuntu.com/security/CVE-2026-93785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate idmap key payload length The cifs.idmap key type stores its payload length in key->datalen, which is limited to U16_MAX. Accepting a larger key payload truncates the recorded length and can make later users interpret the payload using inconsistent bounds. Reject oversized preparsed payloads before allocating or copying them. This keeps key->datalen consistent with the stored data for both inline and separately allocated idmap payloads.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93789", "url": "https://ubuntu.com/security/CVE-2026-93789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: bound aligned TLV advance in FW parser Validate ALIGN(tlv_len, 4) against remaining parser length before consuming bytes from the firmware image. This avoids length underflow on malformed TLVs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93795", "url": "https://ubuntu.com/security/CVE-2026-93795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix leaks and online flag on radix_tree_insert failure When radix_tree_insert() fails in blkg_create(), the error path has two issues: 1. blkg->online is set to true unconditionally, even when the blkg was never fully inserted. Move the assignment inside the success block. 2. The error path calls blkg_put() without first calling percpu_ref_kill(). Because the refcount is still in percpu mode, percpu_ref_put() only does this_cpu_sub() without checking for zero, so blkg_release() is never triggered. This permanently leaks the blkg memory, its percpu iostat, policy data, the parent blkg reference, and the cgroup css reference — the latter preventing the cgroup from ever being destroyed. Fix by replacing blkg_put() with percpu_ref_kill(), matching the pattern used in blkg_destroy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93797", "url": "https://ubuntu.com/security/CVE-2026-93797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix an off-by-1 boundary check Before looking at the 11th byte, check the length is big enough.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93798", "url": "https://ubuntu.com/security/CVE-2026-93798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix reloc root cleanup in merge_reloc_roots() If the root we got has zero root refs in its root item, we are resetting the root's ->reloc_root without using barriers like we do everywhere else. Sashiko complained about this while reviewing another patch, and it's correct (see the Link tag below). Also, we should not clear BTRFS_ROOT_DEAD_RELOC_TREE from the root unless the root points to the reloc root we have. Fix this by using clear_reloc_root(), which issues the memory barrier after setting the root's ->reloc_root to NULL and before clearing the bit BTRFS_ROOT_DEAD_RELOC_TREE from the root.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93800", "url": "https://ubuntu.com/security/CVE-2026-93800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol() If during relocation we fail in insert_dirty_subvol() because btrfs_update_reloc_root() returned an error, we will leave a root's reloc_root field pointing to a reloc root that was freed instead of NULL, resulting later in a use-after-free, or double free attempt during unmount. The sequence of steps is this: 1) During relocation the call to btrfs_update_reloc_root() in insert_dirty_subvol() fails, so insert_dirty_subvol() returns the error to merge_reloc_root() without adding the root to the list rc->dirty_subvol_roots; 2) Then merge_reloc_root() aborts the current transaction because insert_dirty_subvol() returned an error; 3) Up the call chain, merge_reloc_roots() gets the error, adds the reloc root for root X to the local reloc_roots list and jumps to the 'out' label, where it calls free_reloc_roots() to free all the reloc roots in the local reloc_roots list. This frees the reloc root for root X; 4) We go up the call chain to relocate_block_group() which calls clean_dirty_subvols() to go over dirty roots and set their ->reloc_root field to NULL, but root X is not in the dirty_subvol_roots list, so its ->reloc_root still points to a reloc root; 5) Relocation finishes, with an error and a transaction abort, but the ->reloc_root field for root X still points to the reloc root that was freed in step 3; 6) When unmounting the fs we end up calling: btrfs_free_fs_roots() btrfs_drop_and_free_fs_root() --> calls btrfs_put_root() against root X's ->reloc_root which is not NULL and points to the already freed reloc root in step 4 above Resulting in a use-after-free to a double free attempt. Syzbot reported this with the following dmesg/syslog: [ 106.004389][ T5339] BTRFS error (device loop0 state A): Transaction aborted (error -5) [ 106.014266][ T5339] BTRFS: error (device loop0 state A) in merge_reloc_root:1655: errno=-5 IO failure [ 106.021891][ T1061] BTRFS error (device loop0 state A): error while writing out transaction: -5 [ 106.026964][ T1061] BTRFS warning (device loop0 state A): Skipping commit of aborted transaction. [ 106.033807][ T5340] BTRFS error (device loop0 state A): bdev /dev/loop0 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 [ 106.039265][ T1061] BTRFS: error (device loop0 state A) in cleanup_transaction:2067: errno=-5 IO failure [ 106.044382][ T5339] BTRFS info (device loop0 state EA): forced readonly [ 106.074329][ T5339] BTRFS: error (device loop0 state EA) in merge_reloc_roots:1887: errno=-5 IO failure [ 106.081004][ T5356] BTRFS info (device loop0 state EA): scrub: started on devid 1 [ 106.085611][ T5339] BTRFS info (device loop0 state EA): balance: ended with status: -30 [ 106.089517][ T5356] BTRFS info (device loop0 state EA): scrub: not finished on devid 1 with status: -30 [ 106.662365][ T5338] BTRFS info (device loop0 state EA): last unmount of filesystem 3a375e4e-b156-4d76-a2ad-16e198ce1409 [ 106.682946][ T5338] ================================================================== [ 106.686574][ T5338] BUG: KASAN: slab-use-after-free in btrfs_put_root+0x2f/0x250 [ 106.690090][ T5338] Write of size 4 at addr ffff88803f978630 by task syz.0.0/5338 [ 106.693173][ T5338] [ 106.694279][ T5338] CPU: 0 UID: 0 PID: 5338 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) [ 106.694293][ T5338] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 106.694300][ T5338] Call Trace: [ 106.694308][ T5338] [ 106.694314][ T5338] dump_stack_lvl+0xe8/0x150 [ 106.694331][ T5338] print_address_description+0x55/0x1e0 [ 106.694343][ T5338] ? btrfs_put_root+0x2f/0x250 [ 106.694358][ T5338] print_report+0x58/0x70 [ 106. ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93802", "url": "https://ubuntu.com/security/CVE-2026-93802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: validate beacon length before fixed buffer copy rsi_prepare_beacon() copies the mac80211 beacon frame after FRAME_DESC_SZ into a management skb whose usable tailroom may be smaller than MAX_MGMT_PKT_SIZE after alignment. Validate the beacon length against the actual tailroom before the copy and skb_put(). Leave ownership of the management skb with the caller on error, matching the existing rsi_send_beacon() cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93803", "url": "https://ubuntu.com/security/CVE-2026-93803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libipw: fix key index receive bound checks libipw_rx() reads skb->data[hdrlen + 3] to extract the WEP key index in both the software-decrypt key selection path and the hardware-decrypted IV/ICV strip path. In both places the existing guard only checks skb->len >= hdrlen + 3, which proves bytes up to hdrlen + 2 but not the byte at hdrlen + 3. Require hdrlen + 4 bytes before reading that item in both paths. This is a local source-boundary check only; it does not change the key index semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93805", "url": "https://ubuntu.com/security/CVE-2026-93805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate rx/tx MLME callback frame lengths before access cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints before rejecting frames shorter than the frame-control field. After that, they only require len >= 2 before dispatching into subtype handlers that assume their fixed fields are present. The frames that trip this are not shorter than 2 bytes; they are short relative to their subtype. mwifiex is a concrete in-tree example on the length side: mwifiex_process_mgmt_packet() only requires a 4-address ieee80211_hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and removing addr4, pkt_len can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARN_ON(len < 2) does not fire on such a frame, and cfg80211_process_deauth() then reads u.deauth.reason_code as a two-byte access starting at offset 24, immediately past the 24-byte buffer. Add a frame-control length gate, then validate each subtype's minimum frame size in an if/else-if chain that mirrors the dispatch logic. Trace only after the frame is known to be well-formed. Side effects of this change: - The WARN_ON(len < 2) is dropped. It only guarded the frame_control read, never the subtype fixed fields, and it does not fire on the frames that actually trigger the out-of-bounds read (which are >= 2). The len >= 2 check is kept as the guard before dereferencing frame_control, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93807", "url": "https://ubuntu.com/security/CVE-2026-93807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers rsi_hal_load_key() copies tx_mic_key and rx_mic_key from data[16] and data[24] whenever key data is present. Those offsets are only part of the 32-byte TKIP key layout. Shorter keys used by other ciphers, such as CCMP, do not provide those bytes, so the unconditional copies can read past the supplied key buffer. Only copy the MIC keys for TKIP, and reject malformed TKIP keys that are shorter than the expected 32-byte layout. [drop useless length check]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93808", "url": "https://ubuntu.com/security/CVE-2026-93808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: caiaq: validate EP1 reply lengths usb_ep1_command_reply_dispatch() uses buf[0] as a command byte and then reads command-specific fixed items from the same URB buffer. Several paths use buf + 1, buf[1], buf[2], or buf + 3 without first proving that urb->actual_length contains those bytes. Add per-command length checks, use a payload length derived from the bytes after the command byte for the control-state copy, and reject short analog input payloads before the input helper reads fixed offsets from the EP1 reply.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93811", "url": "https://ubuntu.com/security/CVE-2026-93811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling 1. When ndr_decode_v4_ntacl() fails, the code jumped to free_n_data which only freed n.data, skipping kfree(acl.sd_buf) and leaking the buffer. Zero-initialize struct xattr_ntacl acl, reorder error labels to out_free to release acl.sd_buf on all error paths. 2. if (acl.sd_size < sizeof(struct smb_ntsd)) is true, original code returned success without freeing sd_buf and left stale *pntsd. Set rc = -EINVAL before jumping to out_free to return error code and free buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93812", "url": "https://ubuntu.com/security/CVE-2026-93812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr ndr_encode_v4_ntacl() allocates sd_ndr.data via kzalloc() at entry. If any subsequent ndr_write_*() call returns error during encoding, the allocated sd_ndr.data won't be freed and causes memory leak. Move kfree(sd_ndr.data) into out label to ensure the buffer gets released on all success and error return paths.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93813", "url": "https://ubuntu.com/security/CVE-2026-93813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tree-checker: validate INODE_REF's namelen [BUG] A crafted btrfs image can trigger the following crash: BUG: unable to handle page fault for address: ffffd1dc42884000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page CPU: 9 UID: 0 PID: 1034 Comm: poc Not tainted 7.1.0-rc4-custom+ #383 PREEMPT(full) 46af0a92938a63be7132e0dfd71e62327c51d5c2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:memcpy+0xc/0x10 Call Trace: read_extent_buffer+0xe4/0x100 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] btrfs_get_name+0x15e/0x1e0 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] reconnect_path+0x165/0x390 exportfs_decode_fh_raw+0x337/0x400 ? drop_caches_sysctl_handler+0xb0/0xb0 ---[ end trace 0000000000000000 ]--- RIP: 0010:memcpy+0xc/0x10 Kernel panic - not syncing: Fatal exception [CAUSE] TThe crafted image has the following corrupted INODE_REF item: item 9 key (258 INODE_REF 257) itemoff 11544 itemsize 4106 \tindex 2 namelen 4096 name: d\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000 The itemsize matches the namelen, but the namelen is 4096, way larger than normal name length limit (BTRFS_NAME_LEN, 255). Meanwhile the memory of the @name is only 255 byte sized, this will cause out-of-boundary access, and cause the above crash. [FIX] Add extra namelen verification for INODE_REF, just like what we have done in ROOT_REF checks. Now the crafted image can be rejected gracefully: BTRFS critical (device dm-2): corrupt leaf: root=5 block=30572544 slot=14 ino=259, invalid inode ref name length, has 4096 expect [1, 255] BTRFS error (device dm-2): read time tree block corruption detected on logical 30572544 mirror 2 [ Rebase, add a Link: tag, add an simple cause analyze ]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93815", "url": "https://ubuntu.com/security/CVE-2026-93815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: au1000: move free_irq out of the close-time spinlocked section au1000_close() calls free_irq() while aup->lock is still held with spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ descriptor request mutex, so it does not belong inside the close-time spinlocked section. This was found by our static analysis tool and then confirmed by manual review of the in-tree au1000_close() .ndo_stop path. The reviewed path keeps aup->lock held across the MAC reset, queue stop and free_irq(dev->irq, dev). A directed runtime validation kept that ndo_stop carrier and the same free_irq(dev->irq, dev) operation under the driver lock. Lockdep reported \"BUG: sleeping function called from invalid context\" and \"Invalid wait context\" while free_irq() was taking desc->request_mutex, with au1000_close() and free_irq() on the stack. Drop aup->lock before freeing the IRQ. The protected close-time work still stops the device and queue before IRQ teardown, but the sleepable IRQ core path now runs outside the spinlocked section.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93816", "url": "https://ubuntu.com/security/CVE-2026-93816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate inline dentry name lengths before conversion Inline dentry conversion copies names out of the inline dentry area before checking that each recorded name length fits in the available filename slots. A corrupted image can therefore make the conversion path read past the inline filename storage while building the regular dentry block. Validate each inline dentry name length against the inline filename area before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93819", "url": "https://ubuntu.com/security/CVE-2026-93819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93820", "url": "https://ubuntu.com/security/CVE-2026-93820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rockchip: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93821", "url": "https://ubuntu.com/security/CVE-2026-93821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93822", "url": "https://ubuntu.com/security/CVE-2026-93822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: iproc: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93825", "url": "https://ubuntu.com/security/CVE-2026-93825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: Add NULL check for spi_get_device_id() in spi_get_device_match_data() Prevent NULL pointer dereference when spi_get_device_id() returns NULL, which can happen when using driver_override without matching SPI ID entry.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93830", "url": "https://ubuntu.com/security/CVE-2026-93830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac2: disable RBUE in default RX interrupt mask Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97407", "url": "https://ubuntu.com/security/CVE-2026-97407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in set_fmt rockchip_pdm_set_fmt() calls pm_runtime_get_sync() before accessing hardware registers, but ignores its return value. If the runtime resume fails, the function continues to perform register accesses while the device state is undefined. Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() and return early on failure to avoid unpowered register accesses.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97408", "url": "https://ubuntu.com/security/CVE-2026-97408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate connectionless PSM length Connectionless L2CAP frames carry a two-byte PSM at the start of the payload. l2cap_recv_frame() currently reads that PSM unconditionally after validating only the outer L2CAP length. A malformed connectionless frame with a zero- or one-byte payload can therefore make the parser read beyond the advertised skb payload and use tailroom bytes as part of the PSM. A VHCI-backed QEMU reproducer injected a one-byte connectionless payload and reached the unchecked read. Reject connectionless frames that cannot contain the PSM before reading or pulling it. This preserves all valid connectionless frames while dropping only structurally incomplete packets.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97411", "url": "https://ubuntu.com/security/CVE-2026-97411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ibm: emac: mal: fix potential system hang in mal_remove() napi_disable() is not idempotent and calling it on an already-disabled or unenabled NAPI context will cause the kernel to spin indefinitely waiting for the NAPI_STATE_SCHED bit to clear. In mal_remove(), napi_disable() is called unconditionally. If no MACs were registered, NAPI was never enabled. Also, if they were registered but subsequently unregistered, NAPI was already disabled in mal_unregister_commac(). In either case, calling napi_disable() causes the kernel to hang upon module removal. Fix this by only calling napi_disable() in mal_remove() if the commac list is not empty (which implies NAPI is enabled).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97413", "url": "https://ubuntu.com/security/CVE-2026-97413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Fix integer underflow in process_read and process_write usr_len is read from a network-supplied message field (le16_to_cpu) and used to compute data_len = off - usr_len without validating that usr_len <= off. A malicious RDMA client can send usr_len > off causing an integer underflow, resulting in data_len wrapping to a huge size_t value which is then passed to the rdma_ev callback as a memory length, leading to out-of-bounds memory access. Fix by reading and validating usr_len <= off before rtrs_srv_get_ops_ids() in both process_read() and process_write(), ensuring the early return path acquires no reference and has no resource leak.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97416", "url": "https://ubuntu.com/security/CVE-2026-97416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: balance: fix potential bg lookup failure in btrfs_may_alloc_data_chunk() [BUG] Running btrfs balance can trigger a null-ptr-deref before relocating a data chunk when metadata corruption leaves a chunk in the chunk tree without a corresponding block group in the in-memory cache: KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] RIP: 0010:btrfs_may_alloc_data_chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601 Call Trace: __btrfs_balance fs/btrfs/volumes.c:4217 [inline] btrfs_balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604 btrfs_ioctl_balance fs/btrfs/ioctl.c:3577 [inline] btrfs_ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313 ... [CAUSE] __btrfs_balance() iterates the on-disk chunk tree and passes the chunk logical bytenr to btrfs_may_alloc_data_chunk() before relocating a data chunk. That helper then queries the in-memory block group cache: cache = btrfs_lookup_block_group(fs_info, chunk_offset); chunk_type = cache->flags; /* cache may be NULL */ A corrupt image can contain a chunk item whose matching block group item is missing, so no block group is ever inserted into the cache. In that case btrfs_lookup_block_group() returns NULL. The code only guards this with ASSERT(cache), which becomes a no-op when CONFIG_BTRFS_ASSERT is disabled. The subsequent dereference of cache->flags therefore crashes the kernel. [FIX] Add a NULL check after btrfs_lookup_block_group() in btrfs_may_alloc_data_chunk() and print and error message for clarity.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97417", "url": "https://ubuntu.com/security/CVE-2026-97417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack() The timestamp-only fast path dereferences the option stream as *(__be32 *)ptr, which assumes 4-byte alignment that the TCP option stream does not guarantee. Use get_unaligned_be32() instead, which reads the value safely and already returns host byte order, so the htonl() on the comparison constant can be dropped. This matches the existing get_unaligned_be32() use later in the same function.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97418", "url": "https://ubuntu.com/security/CVE-2026-97418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es18xx: check control allocation before private data setup snd_es18xx_mixer() creates controls with snd_ctl_new1() and then stores bookkeeping pointers or sets private_free before calling snd_ctl_add(). snd_ctl_new1() can return NULL on allocation failure, so those writes can dereference a NULL control pointer. Check the returned control pointers before using them and return -ENOMEM on allocation failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97419", "url": "https://ubuntu.com/security/CVE-2026-97419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: broadcast netlink notifications in the device's net namespace The HSR generic netlink family sets .netnsok = true. HSR devices can live in network namespaces other than init_net. Two async notifiers broadcast events with genlmsg_multicast(). They are hsr_nl_ringerror() and hsr_nl_nodedown(). That helper delivers only on the default genl socket in init_net. So the events always land in init_net. The network namespace of the device does not matter. This has two effects. A listener in the device's own namespace never sees its own ring error and node down events. A privileged listener in init_net receives events from HSR devices in other namespaces. The payload carries the peer node MAC (HSR_A_NODE_ADDR) and the slave port ifindex (HSR_A_IFINDEX). Switch both callers to genlmsg_multicast_netns(). Other families with .netnsok = true already do this. Examples are gtp, ovpn, team, batman-adv, netdev-genl, ethtool and handshake. hsr_nl_ringerror() already has the slave port. It uses dev_net(port->dev). hsr_nl_nodedown() takes the namespace from the master port via hsr_port_get_hsr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97420", "url": "https://ubuntu.com/security/CVE-2026-97420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: NUL-terminate replaced sysctl value When writing to sysctls, proc_sys_call_handler() guarantees that the buffer passed to proc handlers is NUL-terminated. If bpf_sysctl_set_new_value() replaces the pending sysctl value, it can hand a replacement buffer directly to proc handlers. However, the helper currently copies only buf_len bytes into that buffer without appending a NUL terminator, leaving downstream parsers vulnerable to out-of-bounds access. Fix this by appending a '\\0' after the replaced value to restore the expected sysctl semantics. Since the helper already rejects buf_len greater than PAGE_SIZE - 1, there is always room for the extra byte. Reproduced in a QEMU x86_64 guest booted with KASAN while exercising the sysctl replacement path with a cgroup/sysctl BPF program. The reproducer targets `/proc/sys/net/core/flow_limit_cpu_bitmap`, fills the original user write buffer with non-zero bytes, and overrides the sysctl value so the replacement buffer lacks a terminating NUL. Under that setup, the pre-fix kernel reported: BUG: KASAN: slab-out-of-bounds in strnchrnul+0x72/0x90 Read of size 1 at addr ffff88800de57000 by task repro_patch3/66 CPU: 0 UID: 0 PID: 66 Comm: repro_patch3 Not tainted 7.1.0-rc3-00269-g8370ca1f87cc #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? strnchrnul+0x72/0x90 ? strnchrnul+0x72/0x90 kasan_report+0xca/0x100 ? strnchrnul+0x72/0x90 strnchrnul+0x72/0x90 bitmap_parse+0x37/0x2e0 flow_limit_cpu_sysctl+0xc6/0x840 ? __pfx_flow_limit_cpu_sysctl+0x10/0x10 ? __kvmalloc_node_noprof+0x5ba/0x870 proc_sys_call_handler+0x31d/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? selinux_file_permission+0x39f/0x500 ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... The buggy address is located 0 bytes to the right of allocated 4096-byte region [ffff88800de56000, ffff88800de57000) With this fix applied, rerunning the same sysctl-targeted path yields no corresponding KASAN reports.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97421", "url": "https://ubuntu.com/security/CVE-2026-97421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz() Several corner cases, especially important on 32 bits: - umem->iova is u64, the function argument should pass in u64 or iova will be truncated - Check that the length is not too large for the iova - Check that lengths > 4G don't overflow the GENMASK", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97430", "url": "https://ubuntu.com/security/CVE-2026-97430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: Prevent queuing new commands if xhci is inaccessible Refuse to queue a new command on the command ring if xHC is marked inaccessible with the HCD_FLAG_HW_ACCESSIBLE. HCD_FLAG_HW_ACCESSIBLE is set and cleared in suspend and resume. Also print a warning if xhci is being suspended with commands still pending on the command ring.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97434", "url": "https://ubuntu.com/security/CVE-2026-97434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: fix handling of NAPI on the remove path All the NAPI instances for a DPSW device are attached to the first switch port's net_device but shared by all ports. The NAPI instances get disabled only once the last port goes down. This causes an issue on the .remove() path where each port is unregistered and freed one at a time, causing the NAPI instances to be deleted even though they are not disabled. In order to avoid this, split up the unregister_netdev() calls from the free_netdev() so that we make sure all ports go down before we attempt a deletion of NAPI instances. Also, make the netif_napi_del() explicit as it is on the .probe() path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97435", "url": "https://ubuntu.com/security/CVE-2026-97435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: flower: reject cross-chip redirect dsa_port_from_netdev() may return a valid port from a different switch chip. Programming another chip's port index into the local hardware causes redirection to the wrong port, or an out-of-bounds access if the index exceeds the local chip's port count. Apply a minimal fix that adds a check to catch this case and adjusts the extack message. When cls->common.skip_sw is not set, the operation could instead redirect to the upstream port and let the software or upstream switch(es) handle the forward, but that is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97436", "url": "https://ubuntu.com/security/CVE-2026-97436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: rework FDB management on the bridge leave path On bridge leave, the dpaa2_switch_port_set_fdb() function always allocates a new FDB for the port which is becoming standalone. In case no FDB is found, then the port leaving a bridge will continue to use the current one. The above logic does not cover the case in which there are multiple bridges which have ports from the same DPSW instance. In this case, when the last port leaves bridge #1, it finds an unused FDB to switch to, but the old FDB is not marked as unused. Since the number of FDBs is equal to the number of DPSW interfaces, this will eventually lead to multiple ports sharing the same FDB. Fix this by changing how we are managing the FDBs on the leave path. Instead of directly allocating a new FDB, first verify if the current port is the last one to leave a bridge. If this is the case, then continue to use the current FDB and only allocate another FDB if there are other ports remaining in the bridge.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97437", "url": "https://ubuntu.com/security/CVE-2026-97437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e() The bounds check in ntfs_dir_emit() compares fname->name_len (a character count) against e->size (a byte count) without accounting for the 2-byte-per-character UTF-16LE encoding or the ATTR_FILE_NAME header size: if (fname->name_len + sizeof(struct NTFS_DE) > le16_to_cpu(e->size)) This computes: name_len + 16 > e_size The correct check must account for the ATTR_FILE_NAME header (66 bytes before the name) and the UTF-16LE character size (2 bytes each): sizeof(NTFS_DE) + offsetof(ATTR_FILE_NAME, name) + name_len * sizeof(short) > e_size Which computes: 16 + 66 + name_len * 2 > e_size The correct calculation already exists as fname_full_size() in ntfs.h and is used in cmp_fnames(), namei.c, and fslog.c, but was not used in the readdir path. A crafted NTFS image with an index entry containing a small e->size but large fname->name_len bypasses the current check, causing ntfs_utf16_to_nls() to read past the entry boundary. Additionally, add a key_size validation in hdr_find_e() to ensure the declared key_size does not exceed the available entry data, preventing comparison functions from reading past entry boundaries on the lookup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97438", "url": "https://ubuntu.com/security/CVE-2026-97438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate index entry key bounds [BUG] A malformed NTFS directory index entry can advertise a key_size larger than the bytes actually present in its NTFS_DE payload. Directory lookup then passes that malformed key to cmp_fnames(), which can read past the end of the kmalloc'ed index buffer. BUG: KASAN: slab-out-of-bounds in fname_full_size fs/ntfs3/ntfs.h:590 [inline] BUG: KASAN: slab-out-of-bounds in cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 Read of size 1 at addr ffff88801c313018 by task syz.6.3365/9279 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 __asan_report_load1_noabort+0x14/0x30 mm/kasan/report_generic.c:378 fname_full_size fs/ntfs3/ntfs.h:590 [inline] cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 hdr_find_e.isra.0+0x3ed/0x670 fs/ntfs3/index.c:762 indx_find+0x4b5/0x900 fs/ntfs3/index.c:1186 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... Allocated by task 9279: kasan_save_stack+0x39/0x70 mm/kasan/common.c:56 kasan_save_track+0x14/0x40 mm/kasan/common.c:77 kasan_save_alloc_info+0x37/0x60 mm/kasan/generic.c:573 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0xc3/0xd0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __do_kmalloc_node mm/slub.c:5650 [inline] __kmalloc_noprof+0x2bd/0x900 mm/slub.c:5662 kmalloc_noprof include/linux/slab.h:961 [inline] indx_read+0x41d/0xad0 fs/ntfs3/index.c:1059 indx_find+0x447/0x900 fs/ntfs3/index.c:1179 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... [CAUSE] The index-header validators only validated INDEX_HDR-level geometry. They did not walk each NTFS_DE to verify entry alignment, subnode layout, or that key_size fit inside the entry payload. They also allowed a last sentinel entry to carry a non-zero key_size. [FIX] Walk every NTFS_DE in ntfs3's index-header validators and reject entries with invalid layout, mismatched subnode state, oversized key_size, or non-zero sentinel keys before lookup or log replay can consume them.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97439", "url": "https://ubuntu.com/security/CVE-2026-97439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib [BUG] A corrupted ntfs3 image can hit a NULL function pointer call in generic_perform_write() after toggling system.ntfs_attrib and then overwriting system.dos_attrib on the same file. BUG: kernel NULL pointer dereference, address: 0000000000000000 \\#PF: supervisor instruction fetch in kernel mode \\#PF: error_code(0x0010) - not-present page PGD bed5067 P4D bed5067 PUD 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffff88801025f988 EFLAGS: 00010246 Call Trace: generic_perform_write+0x409/0x8c0 mm/filemap.c:4255 __generic_file_write_iter+0x1bb/0x200 mm/filemap.c:4372 ntfs_file_write_iter+0xcd9/0x1c20 fs/ntfs3/file.c:1253 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x63b/0xf70 fs/read_write.c:686 ksys_write+0x133/0x250 fs/read_write.c:738 __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x77/0xc0 fs/read_write.c:746 ... [CAUSE] system.ntfs_attrib updates ATTR_DATA flags via ni_new_attr_flags() and switches i_mapping->a_ops to ntfs_aops_cmpr when FILE_ATTRIBUTE_COMPRESSED is set. system.dos_attrib then overwrites ni->std_fa from a one-byte DOS attribute value, clearing the compression bit without updating ATTR_DATA or the mapping operations. Old buffered writes use is_compressed(ni) to choose __generic_file_write_iter(). That leaves generic_perform_write() calling a NULL write_begin callback from ntfs_aops_cmpr. [FIX] Treat system.dos_attrib as a low-byte DOS attribute update and preserve the existing non-DOS attribute bits in ni->std_fa. This keeps compressed and sparse state consistent with ATTR_DATA and the mapping operations while keeping the existing DOS attribute semantics intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97440", "url": "https://ubuntu.com/security/CVE-2026-97440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix node refcount leak on ctrl packet alloc failure qrtr_send_resume_tx() calls qrtr_node_lookup() which takes a reference on the returned node. If the subsequent call to qrtr_alloc_ctrl_packet() fails due to memory allocation failure, the function returns -ENOMEM without calling qrtr_node_release() to release the node reference. Add qrtr_node_release(node) before returning on the allocation failure path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97441", "url": "https://ubuntu.com/security/CVE-2026-97441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: ahci: fail probe if BAR too small for claimed ports When an AHCI controller is disabled in BIOS, its HOST_CAP register may contain a bogus value, e.g. 0xFFFFFFFF. Since CAP.NP (Number of Ports) is a zeroes based 5-bit register field, a value of 0x1f means 32 ports. If CAP.NP claims more ports than can physically fit within the mapped BAR region, accessing port registers beyond the BAR boundary causes a kernel panic. Add validation in ahci_init_one() to check that the BAR size is sufficient for the number of ports claimed in CAP.NP. The check calculates the required MMIO size as: required_size = 0x100 (global registers) + max_ports * 0x80 If required_size exceeds the actual BAR size, the probe fails with -ENODEV, preventing the panic and providing a clear error message. [cassel: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97443", "url": "https://ubuntu.com/security/CVE-2026-97443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/ftrace: Fix WARNING in __unregister_ftrace_function perf_ftrace_function_unregister() unconditionally calls unregister_ftrace_function() without checking whether the ftrace_ops was ever successfully registered. This triggers a WARN_ON in __unregister_ftrace_function() when the ops doesn't have FTRACE_OPS_FL_ENABLED set. This can happen during perf_event_alloc() error cleanup when perf_trace_destroy() is called via __free_event() on an event whose ftrace_ops registration failed or was already torn down by perf_try_init_event()'s err_destroy path. The call path is: perf_event_alloc() error cleanup -> __free_event() -> event->destroy() [tp_perf_event_destroy] -> perf_trace_destroy() -> perf_trace_event_close() -> TRACE_REG_PERF_CLOSE -> perf_ftrace_function_unregister() -> unregister_ftrace_function() -> __unregister_ftrace_function() -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to unregister. If the ops is not enabled, just free the filter and return success.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97444", "url": "https://ubuntu.com/security/CVE-2026-97444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in two places Add boundary checks in acpi_ps_get_next_namestring() and acpi_ps_peek_opcode() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97445", "url": "https://ubuntu.com/security/CVE-2026-97445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources() Enhance buffer validation in acpi_ut_walk_aml_resources() to prevent buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97446", "url": "https://ubuntu.com/security/CVE-2026-97446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package() acpi_ns_custom_package() unconditionally dereferences the first element of the package to read the _BIX version number, without checking for NULL: if ((*Elements)->Common.Type != ACPI_TYPE_INTEGER) When firmware returns a _BIX package whose first element is an unresolvable reference, ACPICA evaluates that entry to NULL. acpi_ns_remove_null_elements() does not strip NULL entries for ACPI_PTYPE_CUSTOM packages (fixed-position format would break if elements were shifted), so acpi_ns_custom_package() sees the NULL and causes a crash. Add a NULL check for the first element (version field) before dereferencing it. The caller then receives AE_AML_OPERAND_TYPE instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97448", "url": "https://ubuntu.com/security/CVE-2026-97448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add validation for node in acpi_ns_build_normalized_path() Add validation for node in acpi_ns_build_normalized_path() to prevent use-after-free vulnerabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97449", "url": "https://ubuntu.com/security/CVE-2026-97449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add package limit checks in parser functions Add package limit checks in parser functions to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97450", "url": "https://ubuntu.com/security/CVE-2026-97450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate handler object type in two places ACPICA: validate handler object type in acpi_ev_has_default_handler() and acpi_ev_find_region_handler().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97451", "url": "https://ubuntu.com/security/CVE-2026-97451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op) Add overflow check for Index + Length to prevent integer overflow when calculating the truncation length. This prevents negative size parameter being passed to memcpy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97452", "url": "https://ubuntu.com/security/CVE-2026-97452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Prevent adding invalid references Prevent adding references for local, argument, and debug objects in acpi_ut_copy_simple_object().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97453", "url": "https://ubuntu.com/security/CVE-2026-97453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate byte_count in acpi_ps_get_next_package_length() Validate package length reading in acpi_ps_get_next_package_length().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97454", "url": "https://ubuntu.com/security/CVE-2026-97454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in acpi_ps_get_next_field() Add boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97455", "url": "https://ubuntu.com/security/CVE-2026-97455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix use-after-free in acpi_ds_terminate_control_method() Fix use-after-free issue in acpi_ds_terminate_control_method() by clearing references to method locals and arguments.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97456", "url": "https://ubuntu.com/security/CVE-2026-97456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix condition check in acpi_ps_parse_loop() Fix condition check for AML_ELSE_OP in acpi_ps_parse_loop() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97472", "url": "https://ubuntu.com/security/CVE-2026-97472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: fix temp address generation after prefix deprecation When a router temporarily deprecates an IPv6 prefix (either by sending a Router Advertisement with Preferred Lifetime = 0 or by letting the lifetime expire) and later restores it, the kernel permanently loses its ability to generate temporary privacy addresses (RFC 8981) for that prefix. This happens because the address worker attempts to generate a replacement temporary address when the current one nears expiration. As the base prefix is deprecated already, the generation fails after marking the temporary address as already having spawned a replacement (ifp->regen_count++). When the router eventually restores the prefix, the temporary address becomes active again. However, once it naturally expires, the address worker sees this temporary address already tried to generate one and skips the regeneration. Fix the issue by resetting the regen_count check of the latest temp address generated for the prefix updated by the incoming RA.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97475", "url": "https://ubuntu.com/security/CVE-2026-97475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tegra/soctherma: Switch to devm cooling device registration Use devm_thermal_of_cooling_device_register() to simplify resource management and avoid manual cleanup in error paths. As a side effect this change has the benefit of solving an existing issue. Before, the function tegra_soctherm_remove() only called debugfs_remove_recursive() and never called thermal_cooling_device_unregister() for any of the cooling devices registered here. After the driver removal, the thermal framework's cdev list would still hold references to thermal_cooling_device objects whose devdata pointer (ts) pointed to memory already freed by the platform device's devm cleanup. With this change, the cooling device is unregistered when the driver is removed, thus fixing the issue above.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97476", "url": "https://ubuntu.com/security/CVE-2026-97476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: filter RDS_INFO_* getsockopt by caller's netns The RDS_INFO_* family of getsockopt(2) options reads several file-scope global lists that are not per-netns: rds_sock_info / rds6_sock_info, rds_sock_inc_info / rds6_sock_inc_info -> rds_sock_list rds_tcp_tc_info / rds6_tcp_tc_info -> rds_tcp_tc_list rds_conn_info / rds6_conn_info, rds_conn_message_info_cmn (for the *_SEND_MESSAGES and *_RETRANS_MESSAGES variants), rds_for_each_conn_info (for RDS_INFO_IB_CONNECTIONS) -> rds_conn_hash[] The handlers do not filter by the caller's network namespace. rds_info_getsockopt() has no netns or capable() check, and rds_create() has no capable() check, so AF_RDS is reachable from an unprivileged user namespace. As a result, an unprivileged caller in a fresh user_ns plus netns can read the bound address and sock inode of every RDS socket on the host, the peer address of incoming messages on every RDS socket on the host, the peer address and TCP sequence numbers of every rds-tcp connection on the host, and the peer address and RDS sequence numbers of every RDS connection on the host. The rds-tcp transport is reachable from a non-initial netns (see rds_set_transport()), so a one-shot init_net gate at rds_info_getsockopt() would deny legitimate per-netns visibility to rds-tcp callers. Instead, filter at each handler by comparing the netns of the caller's socket to the netns of the list entry, or to rds_conn_net(conn) for connection paths. Only copy entries whose netns matches the caller. Counters (RDS_INFO_COUNTERS) are aggregate statistics and remain global. Reproducer (KASAN VM, rds and rds_tcp loaded): an AF_RDS socket binds 127.0.0.1:4242 in init_net as root. A child process enters a fresh user_ns plus netns and opens AF_RDS there, then calls getsockopt(SOL_RDS, RDS_INFO_SOCKETS). Before this change, the child sees the init_net socket. After this change, the child sees zero entries. Drop the rds_sock_count, rds_tcp_tc_count, and rds6_tcp_tc_count globals. v2 used them for the size precheck and lens->nr; v3 replaced the precheck with a per-ns count from a first pass over the list, so the globals have no remaining readers. The matching increments and decrements in rds_create()/rds_destroy_sock() and rds_tcp_set_callbacks()/rds_tcp_restore_callbacks() go away with them. Reported by the kernel test robot under clang W=1.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97481", "url": "https://ubuntu.com/security/CVE-2026-97481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix possible ISR soft lockup There are rare cases in which the host gets stuck in the ISR because it is flooded with messages during the startup phase. The reason for the soft lockup in the ISR is the missing FIFO error IRQ (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers the IRQ immediately again. Fix this by adding a check for the FIFOE status and clearing the FIFO if no data is ready (DR). This behavior was observed on an AM62L device which uses the OMAP 8250 driver. Fix it for all 8250 drivers, since the OMAP driver's special IRQ setup handling may trigger this behavior more frequently, but it is not ensured that other 8250 drivers aren't affected.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97482", "url": "https://ubuntu.com/security/CVE-2026-97482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET log goku_irq() handles a number of bus events under a single ep0 path. It already guards the gadget driver suspend/resume callbacks against a NULL ->driver: \tif (dev->gadget.speed != USB_SPEED_UNKNOWN \t\t\t&& dev->driver \t\t\t&& dev->driver->resume) { \t\tspin_unlock(&dev->lock); \t\tdev->driver->resume(&dev->gadget); \t\t... \t} but the very next branch unconditionally dereferences dev->driver when an INT_USBRESET arrives: \tif (stat & INT_USBRESET) { \t\tACK(INT_USBRESET); \t\tINFO(dev, \"USB reset done, gadget %s\\n\", \t\t\tdev->driver->driver.name); \t} If the controller raises INT_USBRESET before any gadget driver has been bound (or after one has been unbound), dev->driver is NULL and the printk dereferences NULL. smatch flags the inconsistency: drivers/usb/gadget/udc/goku_udc.c:1618 goku_irq() error: we previously assumed 'dev->driver' could be null (see line 1607) Fall back to a placeholder when the gadget driver is not bound. No functional change while a gadget driver is bound.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97483", "url": "https://ubuntu.com/security/CVE-2026-97483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: hcd: fix possible deadlock in rh control transfers >From within the SCSI error handler memory allocations must not trigger IO. Handling errors in UAS and the storage driver may involve resetting a device. The thread doing the reset itself relies on VM magic. However, that is insufficient, as resetting a device involves resuming it. Resumption as well as resetting involves conrol transfers to the parent of the device to be reset. That may be a root hub. Hence usbcore must heed the flags passed to usb_submit_urb() processing control transfers to root hubs. The problem exist since the storage driver has been merged.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97484", "url": "https://ubuntu.com/security/CVE-2026-97484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vhci_hcd: fix NULL deref in status_show_vhci platform_get_drvdata() can return NULL if a VHCI host controller's probe failed (e.g. due to USB bus number exhaustion). status_show_vhci() checked for a NULL pdev but not for a NULL hcd returned by platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not return NULL - it returns a pointer offset of 0x260, causing a NULL pointer dereference when that value is subsequently dereferenced. Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move status_show_not_ready() above status_show_vhci() to make it callable from the new error path without a forward declaration.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97485", "url": "https://ubuntu.com/security/CVE-2026-97485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: omfs: handle set_blocksize failures omfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97486", "url": "https://ubuntu.com/security/CVE-2026-97486", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hpfs: handle set_blocksize failures hpfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97487", "url": "https://ubuntu.com/security/CVE-2026-97487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: handle set_blocksize failures jfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97488", "url": "https://ubuntu.com/security/CVE-2026-97488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qnx4: handle set_blocksize failures qnx4 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97489", "url": "https://ubuntu.com/security/CVE-2026-97489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bfs: handle set_blocksize failures bfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the \tBUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97490", "url": "https://ubuntu.com/security/CVE-2026-97490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: affs: handle set_blocksize failures affs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97491", "url": "https://ubuntu.com/security/CVE-2026-97491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Don't sleep inside rds_ib_conn_path_shutdown New rds rdma self tests exposed a hang when tearing down the ib network configs. This is caused by the shutdown worker thread sleeping on the wait_event call, which blocks other work items in the queue. Fix this by changing wait_event to wait_event timeout, and looping until the wait check succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97492", "url": "https://ubuntu.com/security/CVE-2026-97492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed In case reconfiguration of NAN fails, we call ieee80211_handle_reconfig_failure, that marks all interfaces as not in the driver. Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces is called to destroy all the interfaces. If we have any other interface but the NAN one, for example a BSS station, then when its state (links, stations) will be removed, we won't tell the driver about this, because we will think that the interfaces are not in the driver, and then drivers might remain with dangling pointers to objects like stations and links (at least for iwlwifi this is the case). ieee80211_handle_reconfig_failure is meant to be called after we cleaned up the state in the driver, there is no reason to call it for NAN reconfiguration failure. Fix the code to just warn in such a case, as we do in other error paths in reconfig where it is too complicated to rewind.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97502", "url": "https://ubuntu.com/security/CVE-2026-97502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: avoid NULL deref of host->data in IRQ handler mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL: if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; } So we may legitimately reach the rest of the handler with host->data == NULL (and therefore data == NULL). The DATDNE branch already guards against this with an explicit \"if (data != NULL)\" check, but the subsequent TOUTRD (\"read data timeout\") and CRCWR/CRCRD (\"data CRC error\") branches dereference data unconditionally: if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); } if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... } If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this: drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914) Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch. No functional change for callers where data is non-NULL, which is the only case in which these branches did meaningful work before this change.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97506", "url": "https://ubuntu.com/security/CVE-2026-97506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ixp4xx - fix buffer chain unwind on allocation failure chainup_buffers() builds a linked list of buffer descriptors for a scatterlist. If dma_pool_alloc() fails while constructing the list, the current code sets buf to NULL and later dereferences it unconditionally at the end of the function: buf->next = NULL; buf->phys_next = 0; This can lead to a null-pointer dereference on allocation failure. If the failure happens after part of the descriptor chain has already been allocated and DMA-mapped, the partially constructed chain also needs to be released. Fix this by terminating the partially constructed chain on allocation failure and letting the callers unwind it via their existing cleanup paths. Also fix ablk_perform() to preserve the hook pointers before checking for failure, so partially built chains can be freed correctly.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97507", "url": "https://ubuntu.com/security/CVE-2026-97507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dm1105: fix missing error check for dma_alloc_coherent The return value of dm1105_dma_map(), which handles DMA memory allocation, is ignored in dm1105_hw_init(). If dma_alloc_coherent() fails, the driver will proceed using a NULL pointer for DMA transfers, leading to a kernel oops or invalid hardware access. Fix this by checking the return value and propagating -ENOMEM on failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97508", "url": "https://ubuntu.com/security/CVE-2026-97508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Set tb->root_switch to NULL when domain is stopped Similarly what we do with the firmware connection manager. This makes tb_xdp_handle_request() return error to the remote host. However, we need to make sure we keep the uuid alive so that we can reply until the whole domain is released.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97510", "url": "https://ubuntu.com/security/CVE-2026-97510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Release request if tb_cfg_request() fails in __tb_xdomain_response() If tb_cfg_request() fails setting up the request (for example the control channel is shut down already) it returns an error without calling the callback. To avoid leaking that memory, call tb_cfg_request_put() if tb_cfg_request() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-90053", "url": "https://ubuntu.com/security/CVE-2026-90053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_htb: limit htb_classify inner-class filter hops htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent. The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification. htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90054", "url": "https://ubuntu.com/security/CVE-2026-90054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix corruption of urgent data on multi-segment retransmit On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: \t/* tcp_write_xmit() */ \tlimit = mss_now; \tif (tso_segs > 1 && !tcp_urg_mode(tp)) \t\tlimit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: \t/* __tcp_retransmit_skb() */ \tlen = cur_mss * segs;\t\t/* segs > 1, no urg_mode check */ \t... \t/* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: \tseg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) \tseg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) \tseg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90055", "url": "https://ubuntu.com/security/CVE-2026-90055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90056", "url": "https://ubuntu.com/security/CVE-2026-90056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: only stop PTP if it was initialized fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90058", "url": "https://ubuntu.com/security/CVE-2026-90058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai. Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted. Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90062", "url": "https://ubuntu.com/security/CVE-2026-90062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: move hardware offload step after building the chain blob Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90063", "url": "https://ubuntu.com/security/CVE-2026-90063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90067", "url": "https://ubuntu.com/security/CVE-2026-90067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: validate banner payload length When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (`server_feat` and `server_req_feat`). Therefore, `payload_len` must be at least 16 bytes. Fix this by adding a check in `process_banner_prefix()` to reject a `payload_len` smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90068", "url": "https://ubuntu.com/security/CVE-2026-90068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix off-by-one check on the second enum channel The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80x_mux_values. The core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which defaults off.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-93245", "url": "https://ubuntu.com/security/CVE-2026-93245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: policy_int make sure list heads are initialized before fail path If profile create fails before policy_init is complete the list heads are not properly initialized causing profile_free() sanity checks to trigger the following splat. AppArmor WARN aa_policy_destroy: (((!list_empty(&policy->profiles) && (&policy->profiles)->prev != ((void *) 0x122 + (0xdead000000000000UL))))): WARNING: security/apparmor/lib.c:509 at aa_policy_destroy+0x164/0x1b0 security/apparmor/lib.c:509, CPU#0: syz.0.17/5541 Modules linked in: CPU: 0 UID: 0 PID: 5541 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:aa_policy_destroy+0x16b/0x1b0 security/apparmor/lib.c:509 Code: 85 ed 7e 4d e8 96 bc 37 fd 5b 41 5c 41 5e 41 5f 5d e9 19 27 4e 07 cc e8 83 bc 37 fd 48 8d 3d 0c f0 d3 0b 48 c7 c6 a4 eb 38 8e <67> 48 0f b9 3a e9 04 ff ff ff e8 66 bc 37 fd 48 8d 3d ff ef d3 0b RSP: 0018:ffffc9000345eaa0 EFLAGS: 00010293 RAX: ffffffff848f530d RBX: ffff88803f734800 RCX: ffff88801af2a580 RDX: 0000000000000000 RSI: ffffffff8e38eba4 RDI: ffffffff90634320 RBP: 0000000000000000 R08: 0000000000000cc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d95913 R12: dead000000000122 R13: ffff88803f734800 R14: ffff88803f734828 R15: dffffc0000000000 FS: 00007f5f6a1836c0(0000) GS:ffff88808c519000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d02407b048 CR3: 0000000012aa9000 CR4: 0000000000352ef0 Call Trace: aa_free_profile+0x9d/0x9f0 security/apparmor/policy.c:334 aa_alloc_profile+0x1e4/0x3e0 security/apparmor/policy.c:416 unpack_profile security/apparmor/policy_unpack.c:1153 [inline] aa_unpack+0x17db/0x7430 security/apparmor/policy_unpack.c:1748 aa_replace_profiles+0x226/0x2a20 security/apparmor/policy.c:1183 policy_update+0x234/0x4a0 security/apparmor/apparmorfs.c:505 profile_load+0x1cb/0x320 security/apparmor/apparmorfs.c:522 vfs_write+0x296/0xba0 fs/read_write.c:685 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f6939e0d9 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:00007f5f6a183028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f5f69625fa0 RCX: 00007f5f6939e0d9 RDX: 0000000000000041 RSI: 0000200000000400 RDI: 0000000000000003 RBP: 00007f5f6a183090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f5f69626038 R14: 00007f5f69625fa0 R15: 00007ffe23725c18", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90070", "url": "https://ubuntu.com/security/CVE-2026-90070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Return zero on status read failure st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or error path instead of acting on an invalid status value. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90071", "url": "https://ubuntu.com/security/CVE-2026-90071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: restore skb->dev on the slave failure path teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90072", "url": "https://ubuntu.com/security/CVE-2026-90072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90073", "url": "https://ubuntu.com/security/CVE-2026-90073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare \"tc qdisc add ... hhf\" succeeds with a clamped quantum but \"tc qdisc add ... hhf limit 1000\" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90074", "url": "https://ubuntu.com/security/CVE-2026-90074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp default quantum to avoid signed overflow fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90075", "url": "https://ubuntu.com/security/CVE-2026-90075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_codel: clamp default quantum and mtu fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests \"*backlog <= params->mtu\"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memory_limit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double psched_mtu() call. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90078", "url": "https://ubuntu.com/security/CVE-2026-90078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: fix length calculations and avoid invalid header warnings syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act(): !skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55 There are a few issues in tcf_skbmod_act(): 1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets). Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90081", "url": "https://ubuntu.com/security/CVE-2026-90081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in rds_cong_map_updated() rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-89780", "url": "https://ubuntu.com/security/CVE-2026-89780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: restore skb->dev on deaggregated frames rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89789", "url": "https://ubuntu.com/security/CVE-2026-89789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets().", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90088", "url": "https://ubuntu.com/security/CVE-2026-90088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90102", "url": "https://ubuntu.com/security/CVE-2026-90102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: key the data server cache on the NFS version nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4. Two deviceids on one address with different ds_versions[0].version therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL. Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90103", "url": "https://ubuntu.com/security/CVE-2026-90103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix LAYOUTSTATS send buffer exhaustion encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that. ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for. The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held. Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90107", "url": "https://ubuntu.com/security/CVE-2026-90107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free pending qentry in smc_llc_flow_stop() before memset smc_llc_flow_stop() resets a flow struct with a blind memset: \tspin_lock_bh(&lgr->llc_flow_lock); \tmemset(flow, 0, sizeof(*flow)); \tflow->type = SMC_LLC_FLOW_NONE; \tspin_unlock_bh(&lgr->llc_flow_lock); If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object. A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct. Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90114", "url": "https://ubuntu.com/security/CVE-2026-90114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: Reject descending VLAN tunnel ranges A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90126", "url": "https://ubuntu.com/security/CVE-2026-90126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf8563: fix clock provider leak on unbind pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference. The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90128", "url": "https://ubuntu.com/security/CVE-2026-90128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: fix wrong list iterated in add_direct_chain error path In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89779", "url": "https://ubuntu.com/security/CVE-2026-89779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate ef->size covers the record's name and value When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to cover it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89781", "url": "https://ubuntu.com/security/CVE-2026-89781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read in read_log_rec_buf() read_log_rec_buf() copies a log record into a caller buffer starting at \tu32 off = lsn_to_page_off(log, lsn) + log->record_header_len; log->record_header_len (and log->data_off, used for the following pages) comes verbatim from the on-disk restart area and is only checked for 8-byte alignment in is_rst_area_valid(), so off can exceed log->page_size. \"tail = log->page_size - off\" then underflows and memcpy() reads past the page_size-sized buffer returned by read_log_page(), spilling adjacent slab memory into the replay buffer. This is reachable by mounting a crafted NTFS image: BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580 Read of size 64 at addr ffff88800a877ff8 by task exploit/127 read_log_rec_buf fs/ntfs3/fslog.c:2299 log_replay fs/ntfs3/fslog.c:4216 ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324 ntfs_fill_super fs/ntfs3/super.c:1392 get_tree_bdev_flags fs/super.c:1694 __x64_sys_mount fs/namespace.c:4360 The buggy address is located 4088 bytes to the right of the 4096-byte region [ffff88800a876000, ffff88800a877000) Reject an in-page offset outside the current page before the copy. [almaz.alexandrovich@paragon-software.com: replaced the >= sign with >]", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90140", "url": "https://ubuntu.com/security/CVE-2026-90140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cuse: wait for pending RCU callbacks on module exit Since commit 053fc4f755ad (\"fuse: fix UAF in rcu pathwalks\"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory: userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text! The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour). Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90141", "url": "https://ubuntu.com/security/CVE-2026-90141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix integer overflow in ftp helper port/address parsing ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16 (hport) and into unsigned char (p[]) without checking for overflow. A crafted FTP PASV/EPSV response with an over-long port or address octet wraps the value, so the helper configures the data connection with a truncated port/address. The netfilter conntrack FTP helper had the same defect, fixed in commit 2b413fc689ba (\"netfilter: nf_conntrack_ftp: avoid u16 overflows\"). Apply the equivalent fix here: widen the port accumulator to u32 and reject values above 65535, and reject address octets above 255.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90143", "url": "https://ubuntu.com/security/CVE-2026-90143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: kcm: Hold RCU read lock while running BPF parser kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser program. Hold the RCU read lock while running the program.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90151", "url": "https://ubuntu.com/security/CVE-2026-90151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: remove callback IDR entry on client allocation failure nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown. A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it. Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client. This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90157", "url": "https://ubuntu.com/security/CVE-2026-90157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative optlen in cgroup getsockopt hook A cgroup getsockopt BPF program can shrink ctx->optlen after the kernel getsockopt handler has run. The kernel-buffer variant, used by TCP_ZEROCOPY_RECEIVE, only rejects values larger than the original length. If BPF writes a negative optlen, that value is accepted and propagated back to the TCP getsockopt code. It can then be passed to copy_to_sockptr() as a size_t and trigger the hardened usercopy bytes > INT_MAX warning. Reject negative ctx.optlen in __cgroup_bpf_run_filter_getsockopt_kern(), matching the lower-bound validation already present in the sockptr-based getsockopt hook.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90160", "url": "https://ubuntu.com/security/CVE-2026-90160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lwt_bpf: Restore reserved headroom after xmit program ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output. That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise. On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb. Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90198", "url": "https://ubuntu.com/security/CVE-2026-90198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix use-after-free in snd_card_do_free() A use-after-free was detected in snd_card_do_free() when a sound card managed by devres is unbound while a user-space application still holds an open file descriptor. For managed cards, the memory is allocated using devres_alloc(), and its release function is set to __snd_card_release(), which calls snd_card_free(). When the device is unbound, the unbind thread calls snd_card_free(), which drops a reference to the card's device. If the user thread still has an open file descriptor, the reference count does not reach zero, and the unbind thread blocks on wait_for_completion(&released). When the user thread closes the file descriptor, it drops the final reference, invoking the device release callback release_card_device(), which calls snd_card_do_free(). snd_card_do_free() performs cleanup and calls complete(card->release_completion). This wakes up the unbind thread, which returns from snd_card_free() and __snd_card_release(). The devres core then immediately frees the memory block containing the snd_card structure. Meanwhile, the user thread continues execution in snd_card_do_free() and evaluates `if (!card->managed)`. It reads the `managed` boolean from the snd_card structure that was just freed by the unbind thread, triggering a KASAN use-after-free. Fix this by caching the value of card->managed in a local variable before calling complete(). This ensures that the card pointer is not dereferenced after the unbind thread has been woken up and potentially freed the card. BUG: KASAN: use-after-free in snd_card_do_free sound/core/init.c:604 [inline] BUG: KASAN: use-after-free in release_card_device+0x1ab/0x1b0 sound/core/init.c:153 Read of size 1 at addr ffff8881912ec909 by task syz-executor130/5857 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description+0x55/0x1e0 mm/kasan/report.c:378 print_report+0x58/0x70 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 snd_card_do_free sound/core/init.c:604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c:153 device_release+0xc4/0x1f0 drivers/base/core.c:-1 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x222/0x550 lib/kobject.c:737 snd_card_file_remove+0x331/0x390 sound/core/init.c:1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c:2986 __fput+0x418/0xa50 fs/file_table.c:512 fput_close_sync+0x11f/0x240 fs/file_table.c:617 __do_sys_close fs/open.c:1511 [inline] __se_sys_close fs/open.c:1496 [inline] __x64_sys_close+0x7e/0x110 fs/open.c:1496 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90202", "url": "https://ubuntu.com/security/CVE-2026-90202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers _base_release_memory_pools() unconditionally frees every ioc->pcie_sg_lookup[] entry, including ones the setup loop never allocated after a partial failure, causing a \"bad dma\" warning on debug kernels or a NULL pointer dereference otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90203", "url": "https://ubuntu.com/security/CVE-2026-90203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check block offset is not negative If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93252", "url": "https://ubuntu.com/security/CVE-2026-93252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix circular locking dependency in ocfs2_init_acl() A lockdep warning indicates a circular locking dependency between `&oi->ip_xattr_sem` and `&journal->j_trans_barrier`: WARNING: possible circular locking dependency detected is trying to acquire lock: (&oi->ip_xattr_sem){++++}-{4:4}, at: ocfs2_init_acl+0x2fd/0x7e0 fs/ocfs2/acl.c:367 but task is already holding lock: (&journal->j_trans_barrier){.+.+}-{4:4}, at: ocfs2_start_trans+0x3ab/0x700 fs/ocfs2/journal.c:369 The deadlock involves two code paths: Path 1 (setxattr) where `ocfs2_xattr_set()` acquires `ip_xattr_sem` (write) and then starts a transaction, which acquires `j_trans_barrier` (read); and Path 2 (mkdir/mknod) where `ocfs2_mknod()` starts a transaction (`j_trans_barrier` read) and then calls `ocfs2_init_acl()`, which attempts to acquire `ip_xattr_sem` (read) on the parent directory to retrieve the default ACL. Because rw_semaphores are subject to writer priority, a pending writer on `j_trans_barrier` (e.g., the journal commit thread) can cause Path 1 to block, while Path 2 is blocked waiting for Path 1 to release `ip_xattr_sem`. The patch fixes the lock ordering by precomputing the ACL state before starting the OCFS2 transaction, while preserving POSIX ACL storage semantics and the existing inode/security initialization order. By reading the parent directory's default ACL and preparing the new inode's ACLs outside the transaction, `ip_xattr_sem` is always acquired before `j_trans_barrier`. `struct ocfs2_acl_state` encapsulates the prepared ACL state, while `ocfs2_acl_init_prepare()` and `ocfs2_acl_init_release()` avoid code duplication between `ocfs2_mknod()` and `ocfs2_init_security_and_acl()`. `ocfs2_calc_xattr_init()` and `ocfs2_init_acl()` use this precomputed state, removing internal `ip_xattr_sem` acquisition and redundant disk reads. Additionally, remove the `ip_xattr_sem` acquisition from `ocfs2_xattr_set_handle()`. This function is only used while initializing a new inode that has not yet been inserted into the inode hash or attached to a dentry, meaning there is no risk of concurrent access and the lock is unnecessary.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90209", "url": "https://ubuntu.com/security/CVE-2026-90209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/debug: Fix deadlock during unregister Unregistering an s390dbf debug area while one of the associated debugfs files is being written to can cause a deadlock: $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs write debugfs_file_get() debug_unregister() mutex_lock(debug_mutex) debugfs_remove() wait for debugfs_file_put() debug_file_ops.write() debug_input() mutex_lock(debug_mutex) ==> DEADLOCK Fix this by splitting debug_unregister() into an s390dbf and debugfs part, and running only the s390dbf part with debug_mutex locked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90214", "url": "https://ubuntu.com/security/CVE-2026-90214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: fix stream_data leak on open error In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream. Free stream_data and clear the stream pointer on the error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90216", "url": "https://ubuntu.com/security/CVE-2026-90216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubi: Fix rollback for explicit UBI device numbers ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90218", "url": "https://ubuntu.com/security/CVE-2026-90218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix WARNING in res_to_rt syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via addr_handler() during asynchronous address resolution: \" WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ib_addr process_one_req RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c:624 process_one_work kernel/workqueue.c:3375 [inline] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c:3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 \" In addr_handler(), cma_acquire_dev_by_src_ip() is called to populate id_priv->cma_dev and bind the associated ib_device to id_priv->id.device. If cma_acquire_dev_by_src_ip() returns an error (non-zero status), the ID remains unassociated with any RDMA device. Previously, rdma_restrack_add(&id_priv->res) was invoked unconditionally even when cma_acquire_dev_by_src_ip() failed, passing a resource with a NULL dev pointer and triggering the WARN_ON assertion in res_to_rt(). Fix this by only adding the resource to restrack when acquiring the device succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90219", "url": "https://ubuntu.com/security/CVE-2026-90219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Free debugfs on registration failure c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev. Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90221", "url": "https://ubuntu.com/security/CVE-2026-90221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing nci_core_init_rsp_packet_v1() and nci_core_init_rsp_packet_v2() parse the CORE_INIT_RSP packet without validating that the skb contains enough data. A malformed response (e.g. injected via virtual_ncidev) can declare a large num_supported_rf_interfaces while providing insufficient data, causing reads of uninitialized slab memory. This is later used in nci_init_complete_req(), triggering a KMSAN uninit-value warning. Add skb length checks before accessing packet fields: - Validate the skb has at least 1 byte for the status field. - Validate the skb can hold the fixed-size header before parsing. - In v2, bounds-check each variable-length rf_interface entry and its extension parameters within the parsing loop. - In v1, verify the skb is large enough for both the variable-length rf_interfaces array and the trailing rsp_2 structure.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90222", "url": "https://ubuntu.com/security/CVE-2026-90222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: hold a reference to the request skb during send_frame __pn533_send_async() publishes the command and then calls dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame can be matched to this command: the I2C threaded IRQ runs pn533_recv_frame(), which queues cmd_complete_work, and pn533_send_async_complete() frees cmd->req with consume_skb(). On the I2C transport, pn533_i2c_send_frame() still dereferences the same skb after i2c_master_send() returns, so a completion that races the send can free the skb while the transport is still using it. The request skb is owned by the command object and may be freed by command completion at any time after dev->cmd is published, so the transport send path must not assume it stays alive. Hold a temporary reference to the request skb across the send_frame() call so the transport always sees a live skb even if completion races the send. Add a pn533_send_cmd_frame() helper and use it from all three send paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90223", "url": "https://ubuntu.com/security/CVE-2026-90223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound SNL TLV parsing to the skb and add length checks nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed: - For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made \"service_name_len = length - 1\" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90224", "url": "https://ubuntu.com/security/CVE-2026-90224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix double completion race in nci_data_exchange_complete nci_close_device() and nci_rx_work can both call nci_data_exchange_complete() concurrently. After commit 4527025d440ce8 (\"nfc: nci: fix circular locking dependency in nci_close_device\") moved flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock), rx_work is no longer serialized with the explicit completion call in the close path. Both callers read the non-NULL callback pointer and invoke rawsock_data_exchange_complete(), which calls sock_put() -- but only one sock_hold() was taken, so the second sock_put() underflows the refcount and frees the socket while it is still in use. Replace the bare clear_bit(NCI_DATA_EXCHANGE) with test_and_clear_bit() so that only the first caller proceeds to invoke the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90225", "url": "https://ubuntu.com/security/CVE-2026-90225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: read llcp_sock->local under the socket lock in getsockopt nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and then dereferenced the cached pointer inside the locked region. llcp_sock_bind() assigns and clears llcp_sock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on lock_sock(), and then dereference a freed nfc_llcp_local once bind() has unwound. Move the llcp_sock->local read and the NULL check inside the lock_sock(sk) region so bind() cannot mutate or free the pointer between the load and the use.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90226", "url": "https://ubuntu.com/security/CVE-2026-90226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: avoid userspace overflow on invalid optlen nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90228", "url": "https://ubuntu.com/security/CVE-2026-90228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() When a host issues an Identify command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89784", "url": "https://ubuntu.com/security/CVE-2026-89784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6 rpcb_register_inet4() and rpcb_register_inet6() store the result of rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL. rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROC_SET encode path: rpcb_register_call() -> rpc_call_sync() -> rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel. The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890) rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910) rpcauth_wrap_req_encode (net/sunrpc/auth.c:745) call_encode (net/sunrpc/clnt.c:1966) __rpc_execute (net/sunrpc/sched.c:952) rpc_run_task (net/sunrpc/clnt.c:1243) rpc_call_sync (net/sunrpc/clnt.c:1272) rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500) svc_generic_rpcbind_set nfsd_rpcbind_set svc_register svc_setup_socket svc_addsock write_ports nfsctl_transaction_write vfs_write The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFP_KERNEL kstrdup() in rpc_sockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check. Mirror that handling: bail out with -ENOMEM when rpc_sockaddr2uaddr() returns NULL, before the address is fed into the encoder.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90245", "url": "https://ubuntu.com/security/CVE-2026-90245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: kyro: Validate overlay viewport coordinates The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90248", "url": "https://ubuntu.com/security/CVE-2026-90248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: fix teardown of an adopted proto on insert-race loss In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90249", "url": "https://ubuntu.com/security/CVE-2026-90249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes The IIO core does not filter duplicate writes to the event enable attribute, so writing the same value twice invokes write_event_config() twice. Enabling twice leaks a runtime PM reference, preventing the device from ever suspending again; disabling twice underflows the usage count and triggers a \"Runtime PM usage count underflow\" warning. Bail out early when the requested state matches the current state. While at it, switch to pm_runtime_resume_and_get() so a failed resume is propagated to userspace instead of silently marking the event enabled.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90251", "url": "https://ubuntu.com/security/CVE-2026-90251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: \tif (skb->len < sizeof(*rp)) { \t\tbt_dev_err(hdev, \"MSFT supported features length mismatch\"); \t\tgoto failed; \t} evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so \tmsft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, \t\t\t\t GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes (\"skb->len=11 evt_prefix_len=255\", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with \"MSFT event prefix length mismatch\" and msft->evt_prefix is left unset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90257", "url": "https://ubuntu.com/security/CVE-2026-90257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: avoid OOB read of build info string The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read Build Information) and hands the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length. A backend that answers with status only leaves that pointer past the end of the received data, so the walk reads adjacent slab memory until it meets a NUL. Those bytes reach the kernel log and the firmware-info debugfs file. To fix this, print the string with a bounded \"%.*s\" limited to skb->len - 1. A short or unterminated response then prints as much as arrived instead of failing setup. This mirrors commit dd068ef04412 (\"Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()\"), which fixed the identical pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90274", "url": "https://ubuntu.com/security/CVE-2026-90274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: etm4x: fix underflow for usage of (nrseqstate - 1) According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR is implemented only when TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000. IOW, the number of usage in the initialisation or setting TRCSEQEVR with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000. Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR relevant fields setup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90281", "url": "https://ubuntu.com/security/CVE-2026-90281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend Runtime PM must be enabled before creating the PHY, since phy_create() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference. Take a runtime PM usage reference with pm_runtime_get_noresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90283", "url": "https://ubuntu.com/security/CVE-2026-90283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: release subpool on fill_super failure hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size mount options are specified. hugepage_new_subpool() may also reserve huge pages for min_size. If root dentry creation fails after the subpool is created, the failure path frees the subpool with kfree(). This bypasses hugepage_put_subpool() and can leave min_size reservations charged. Use hugepage_put_subpool() on the failure path, matching the normal put_super path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90284", "url": "https://ubuntu.com/security/CVE-2026-90284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: do not queue completed sysfs fallback requests fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to pending_fw_head. device_add() publishes the fallback loading interface, so a userspace helper which discovers the device by scanning sysfs can write 0 to the loading attribute and complete the request before it is queued as pending. In that interleaving firmware_loading_store() calls fw_state_done() while pending_list still points to itself, so it cannot remove an entry from pending_fw_head. The subsequent unconditional list_add() then queues an already-completed fw_priv. Once the request is released, pending_fw_head can retain a pointer to freed memory and the next fallback request can fault while validating the list. Only in-flight fallback requests need suspend or reboot abort handling. If the request is already DONE after device_add(), return success from the fallback path without sending another uevent, waiting again, or queueing it as pending. This preserves the invariant that pending_fw_head contains only active fallback requests.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90285", "url": "https://ubuntu.com/security/CVE-2026-90285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path qla2x00_sysfs_read_vpd() called ha->isp_ops->read_optrom() a second time after releasing optrom_mutex. The repeated read is redundant and, unlike the first, runs without optrom_mutex held, exposing flash access to concurrent optrom operations. Drop the duplicate call.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90286", "url": "https://ubuntu.com/security/CVE-2026-90286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx6: Use PFP on the compute queues too On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90290", "url": "https://ubuntu.com/security/CVE-2026-90290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Restore DAIF state on error Sashiko AI has reported that if swsusp_mte_save_tags() for some reason fails we return from swsusp_arch_suspend() with DAIF being masked - that is not what we'd expect. Restore the saved DAIF state before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93256", "url": "https://ubuntu.com/security/CVE-2026-93256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: mask DAIF before restoring hibernated kernel The arm64 hibernate code manages the exception masking in an unsound way, leading to potential crashes and/or warnings during resume. When a hibernation image is saved in `swsusp_arch_suspend()`, all DAIF exceptions are masked (by virtue of `local_daif_save()`), and the suspended image is saved assuming that all DAIF exceptions will remain masked when the image is restored. When a hibernation image is resumed by `swsusp_arch_resume()`, only interrupts are masked (by virtue of `local_irq_disable()` in `resume_target_kernel()`). When pseudo-NMI is enabled the DAIF.IF bits will be clear, and regardless of pseudo-NMI the DAIF.DA bits will be clear. This means that there are two problems: (1) It is possible to take Debug, SError, or pseudo-NMI exceptions during the resume process. This is unsafe, as during the resume process both the old ane new kernels will tranisently be in an inconsistent state, and swsusp_arch_suspend_exit() won't retain an executable mapping of any exception vectors. Any exception taken here will be fatal and silent. (2) When re-entering the resumed kernel, some DAIF bits will be clear unexpectedly. This permits Debug, SError, or pseudo-NMI exceptions to be taken for a short period while the resumed kernel is not yet in a consistent state. This is detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING. Avoid these issues by masking all DAIF exceptions during resume.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90292", "url": "https://ubuntu.com/security/CVE-2026-90292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix use-after-free in siw_accept() siw_accept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it. The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association. Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90293", "url": "https://ubuntu.com/security/CVE-2026-90293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: post the full-feature receive buffers after session registration isert_put_login_tx() posts the full-feature receive buffers before __transport_register_session() runs, so an initiator that does not wait for the final Login Response can still have a SCSI command executed against an se_session whose se_tpg is NULL - the same oops as the previous patch, at target_submit+0xbe. Post them from isert_get_rx_pdu(), which the previous patch already uses to send that response, and post them before that send: the receive queue is filled at the moment the initiator is told it may use it. Allocating there keeps the existing property that a memory allocation failure cannot happen once the final Login Response is on the wire. The receive queue is already empty between the final Login Request and isert_post_recvm(); this moves the second point later, from a median of 92 us to 172 us over 1200 logins. Only an initiator that sends before it has been told to can reach that window, and on IB and RoCE its send is retried there until the buffers appear - isert_rdma_accept() asks for rnr_retry_count = 7. iWARP has no RNR flow control, so there the same send terminates the connection instead. Measured over rxe, 400 login cycles per run, with an initiator that does not wait: an instrumented build counted no entries to isert_recv_done() before the buffers are posted in 10 runs, where that initiator oopsed 8 of 10 unpatched runs and 5 of 10 with only the previous patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90294", "url": "https://ubuntu.com/security/CVE-2026-90294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: delay the final Login Response until the session is registered isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90295", "url": "https://ubuntu.com/security/CVE-2026-90295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: \timx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), \t\t\t\t GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90296", "url": "https://ubuntu.com/security/CVE-2026-90296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix devres accumulation across driver rebind imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system. Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver(). That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release. Tested by rebinding the driver on qemu's mcimx6ul-evk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90297", "url": "https://ubuntu.com/security/CVE-2026-90297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: crtc: Propagate layer initialization error sun4i_crtc_init() returns plain NULL when layer initialization fails, while all its other error paths return an error pointer. The only caller, sun4i_tcon_bind(), checks the result with IS_ERR() and happily continues with tcon->crtc set to NULL. sun4i_rgb_init() and sun4i_lvds_init() then dereference it in drm_crtc_mask(), which oopses. Return the error pointer instead.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90298", "url": "https://ubuntu.com/security/CVE-2026-90298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: tcon: Drop TCON TOP device reference of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90302", "url": "https://ubuntu.com/security/CVE-2026-90302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: synchronize heartbeat callbacks with o2net teardown Patch series \"ocfs2: harden heartbeat teardown races\". This series fixes two OCFS2 heartbeat/o2net teardown races found by KASAN. This patch (of 2): Heartbeat callbacks stay registered while configfs local-node teardown enters o2net_stop_listening(). A node-down event can still run through o2net_disconnect_node() and o2net_set_nn_state() while teardown is destroying o2net_wq, so the later queue/flush operations can hit a dead workqueue. KASAN has caught this as a slab-use-after-free in __queue_work() with the call chain: KASAN slab-use-after-free in __queue_work+0x56/0xa90 Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __queue_work+0x56/0xa90 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __queue_delayed_work+0x58/0x1e0 queue_delayed_work_on+0xb4/0xc0 o2net_set_nn_state+0x467/0x840 o2net_disconnect_node+0x7b/0xe0 o2net_hb_node_down_cb+0x54/0x60 o2hb_run_event_list+0x236/0x2d0 o2hb_check_slot+0xad4/0xbc0 lock_release+0xc8/0x290 o2hb_check_slot+0x9ea/0xbc0 trace_hardirqs_on+0x18/0x130 o2hb_do_disk_heartbeat+0x646/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) __lock_acquire+0x466/0x2260 lockdep_hardirqs_on_prepare+0xea/0x1a0 ktime_get_with_offset+0xe9/0x230 o2hb_thread+0x14e/0x770 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 __switch_to+0x2e9/0x730 ret_from_fork_asm+0x1a/0x30 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x292/0x760 __alloc_workqueue+0x736/0xc60 alloc_workqueue_noprof+0xb1/0x110 o2net_start_listening+0xe5/0x430 o2nm_node_local_store+0x184/0x310 configfs_write_iter+0x18a/0x210 vfs_write+0x469/0x810 ksys_write+0xd2/0x170 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 rcu_core+0x4f4/0x1320 handle_softirqs+0x156/0x660 queue_delayed_work_on o2net_set_nn_state o2net_disconnect_node o2net_hb_node_down_cb o2hb_run_event_list Keep heartbeat callbacks registered so quorum state still tracks node state, but stop them from driving o2net reconnect/disconnect work once local teardown starts. Mark the transport offline before destroying o2net_wq, wait for any in-flight heartbeat callback to finish, and delay bring-up replay until the new local node is published through o2nm_this_node(). The replay also has to stay serialized with heartbeat callback delivery. Otherwise a live-node snapshot can be copied, a real hb_down callback can install -ENOTCONN for a peer, and the stale replay can call o2net_hb_node_up() for that same peer and queue reconnect work even though heartbeat is already down. The buggy scenario involves two paths, with each column showing the order within that path: local-node teardown: heartbeat node-down callback: 1. configfs local-off enters 1. o2hb_run_event_list() invokes o2net_stop_listening(). o2net_hb_node_down_cb(). 2. teardown heads for 2. the callback reaches destroy_workqueue(o2net_wq). o2net_disconnect_node() and o2net_set_nn_state(). 3. teardown destroys and NULLs 3. the callback flushes or queues o2net_wq. work through o2net_wq.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90303", "url": "https://ubuntu.com/security/CVE-2026-90303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults When CONFIG_DEBUG_USER=y, and cmdline \"user_debug=31\" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the \"oops\" state, acquiring a lock may risk a deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90307", "url": "https://ubuntu.com/security/CVE-2026-90307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it: BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8) Without KASAN the returned bytes are whatever is next in the slab. One run returned \".strtab\". rsp->data[3] in srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90314", "url": "https://ubuntu.com/security/CVE-2026-90314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression \"table_sz - offset - sizeof(*hdr)\", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90316", "url": "https://ubuntu.com/security/CVE-2026-90316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/omap: dsi: Do not copy isr table To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90318", "url": "https://ubuntu.com/security/CVE-2026-90318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: release buffer head after rebuilding parent fat_scan_logstart() leaves the matching directory entry's buffer head in sinfo.bh for the caller to release, just like fat_scan(). fat_rebuild_parent() uses the directory entry to rebuild the parent inode for the nostale_ro NFS export path, but does not release sinfo.bh after a successful scan. Release it once fat_build_inode() has consumed the directory entry data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90319", "url": "https://ubuntu.com/security/CVE-2026-90319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: clear mport->net when rio_add_net() fails rio_alloc_net() stores the newly allocated rio_net in mport->net before rio_scan_alloc_net() registers the device. If rio_add_net() fails, rio_scan_alloc_net() drops the device reference with put_device(), which releases the rio_net through the device release callback. However, mport->net is left pointing at the freed object. A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rio_net again. Clear mport->net in the rio_add_net() failure path, matching the cleanup done for the destID table allocation failure path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90327", "url": "https://ubuntu.com/security/CVE-2026-90327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: do not write beyond optlen in getsockopt pep_getsockopt() clamps the reported length to the caller's buffer with min_t(), but then stores the value with put_user(val, (int __user *) optval), which always writes sizeof(int) bytes. A getsockopt() call with an optlen smaller than sizeof(int) thus reports the clamped length yet writes a full int, one to three bytes past the user buffer. Write the value with copy_to_user() bounded by len, so at most optlen bytes are copied, matching the length reported back to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90329", "url": "https://ubuntu.com/security/CVE-2026-90329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: synchronize input before cleaning up a failed probe hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90334", "url": "https://ubuntu.com/security/CVE-2026-90334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: clear cdev pointer after cdev_add() failure tty_cdev_add() drops the cdev reference when cdev_add() fails, but leaves driver->cdevs[index] pointing to freed memory. tty_unregister_device() later passes that stale pointer to cdev_del(), causing a use-after-free. Clear the slot after dropping the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90341", "url": "https://ubuntu.com/security/CVE-2026-90341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: coreboot: Validate table bounds The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90348", "url": "https://ubuntu.com/security/CVE-2026-90348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90360", "url": "https://ubuntu.com/security/CVE-2026-90360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: use system_freezable_wq for init complete work schedule_delayed_work() uses system_wq, which is non-freezable, allowing regulator_init_complete_work to run concurrently with system suspend. This work fires ~30s after boot to disable unused regulators via I2C. When it races with PM suspend, the I2C adapter may already be suspended, triggering a -ESHUTDOWN warning in __i2c_transfer(): WARNING: ... at __i2c_transfer+0x36c/0x3c8 Call trace: __i2c_transfer i2c_transfer regmap_i2c_write _regmap_update_bits regulator_disable_regmap _regulator_do_disable regulator_late_cleanup regulator_init_complete_work_function process_one_work Switch to system_freezable_wq so the work is frozen before any device is suspended, eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90361", "url": "https://ubuntu.com/security/CVE-2026-90361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix leak in ath11k_service_ready_ext_event() Currently, during ath11k_service_ready_ext_event() processing, svc_rdy_ext.mac_phy_caps can be allocated during TLV parsing. This is a temporary allocation that is freed on the success path, but not on the error path. If parsing succeeds far enough to allocate mac_phy_caps and then fails on a later TLV, the allocation leaks. So free the allocation on the error path. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90362", "url": "https://ubuntu.com/security/CVE-2026-90362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Drop dev_pm_opp_set_rate(0) dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Drop the explicit call to it. Every call site of ops->link_clk_disable() is followed by pm_runtime_put(), so the power vote will be rescinded if deemed safe. Patchwork: https://patchwork.freedesktop.org/patch/742783/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90372", "url": "https://ubuntu.com/security/CVE-2026-90372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss If a peer's VHT/HE MCS map has no supported spatial stream (all fields 0x3), the loop exits with nss == 0 and the function returned (u8)-1 (255), which was then written into the firmware sta_rec_bf beamforming fields. Clamp the result to 0.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90378", "url": "https://ubuntu.com/security/CVE-2026-90378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt792x: Fix memory leak in SDIO TX path When tx_prepare_skb() returns an error in the SDIO TX path, the skb is not freed, leading to a memory leak. This can occur when zero-length frames (such as WNM NULL frames) are dropped to prevent potential hardware TX hangs. Fix this by properly releasing the skb with ieee80211_tx_status_ext() when tx_prepare_skb() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90382", "url": "https://ubuntu.com/security/CVE-2026-90382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set. Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf (\"mt76x2: remove some harmless WARN_ONs in tx status and rx path\") did for the neighboring rx and tx status paths. Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93261", "url": "https://ubuntu.com/security/CVE-2026-93261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/lockdep: Fix NULL pointer dereference in __lock_set_class() register_lock_class() can return NULL when the lock class pool is exhausted, graph_lock() fails, or key validation fails. However, __lock_set_class() uses the return value directly in pointer arithmetic without a NULL check: class = register_lock_class(lock, subclass, 0); hlock->class_idx = class - lock_classes; If class is NULL, this computes a wild offset that corrupts hlock->class_idx. The subsequent reacquire_held_locks() call will invoke hlock_class() with this corrupted index, leading to a NULL or out-of-bounds pointer dereference. Add the missing NULL check, consistent with how __lock_acquire() already handles this case at the same call site.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93283", "url": "https://ubuntu.com/security/CVE-2026-93283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix device_register() error path When device_register() fails in i3c_master_register_new_i3c_devs(), put_device() is called to drop the reference taken by device_register(). That drops the last reference, so the device's release callback i3c_device_release() runs and frees the i3c_device. Two problems follow from that: i3c_device_release() does WARN_ON(i3cdev->desc), so it warns because desc->dev->desc still points back at the descriptor. Clear it before calling put_device(). After put_device() frees the i3c_device, desc->dev is left pointing at freed memory, so clear desc->dev as well. That prevents, for example, i3c_master_unregister_i3c_devs() seeing desc->dev as non-NULL and dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90386", "url": "https://ubuntu.com/security/CVE-2026-90386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90388", "url": "https://ubuntu.com/security/CVE-2026-90388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Check atomic pool allocation result directly The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90391", "url": "https://ubuntu.com/security/CVE-2026-90391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone dmirror_fault() is called from the dmirror_read() and dmirror_write() retry loops after dmirror_do_read() or dmirror_do_write() finds a missing device page table entry. If the mirrored mm has already exited, mmget_not_zero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress. Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90393", "url": "https://ubuntu.com/security/CVE-2026-90393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF in bpf_netns_link_update_prog In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90394", "url": "https://ubuntu.com/security/CVE-2026-90394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sc2731_charger: cancel work on remove The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released. Set the platform drvdata used by remove, then cancel the work after unregistering the notifier. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90395", "url": "https://ubuntu.com/security/CVE-2026-90395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: isp1704_charger: cancel work on remove The USB notifier and initial VBUS detection can schedule isp->work. The remove path unregisters the notifier and power supply, but does not wait for queued or running work before tearing down the power supply state. Cancel the work after unregistering the notifier. Do this before unregistering the power supply. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93262", "url": "https://ubuntu.com/security/CVE-2026-93262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5-ppl: fix use-after-free in ppl_do_flush() The loop in ppl_do_flush() continues iterating after calling ppl_io_unit_finished(), touching io->pending_flushes and leading to a use-after-free. Add a break statement to stop the loop once io is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-90403", "url": "https://ubuntu.com/security/CVE-2026-90403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix error path in rtl_pci_probe() In the last error path in rtl_pci_probe(), the cleanup functions are skipped due to a wrong goto label. Moreover, the successful call to rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to be reverted. Fix this issue by updating the labels and adding the relevant cleanup functions to the last error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90411", "url": "https://ubuntu.com/security/CVE-2026-90411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request __nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the rsp_iu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmd_iu unmapped and still marked the op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call .exit_request() when .init_request() fails, the cmd_iu mapping is leaked for every op whose rsp_iu mapping fails. Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and returns the error without marking the op idle, so it stays in the FCPOP_STATE_UNINIT state set by the initial memset().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90413", "url": "https://ubuntu.com/security/CVE-2026-90413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject login PDUs declaring more data than was received isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), \tpayload_length = ntoh24(login_req->dlength); \ttmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90414", "url": "https://ubuntu.com/security/CVE-2026-90414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject PDUs declaring more data than was received isert_recv_done() hands each received PDU to the opcode handlers without ever looking at wc->byte_len, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) - out of the fixed-size descriptor: isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len); Because the declared length is never checked against wc->byte_len, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer. Nothing upstream of isert closes this door: - __iscsit_check_dataout_hdr() bounds the inbound payload against conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check. - iscsi_set_connection_parameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsi_check_acceptor_state(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling. - isert never clamps the negotiated value to its own fixed receive descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated. The imm_data_len == data_len path is more than an over-read: it aliases the receive descriptor via sg_set_buf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated. Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN: BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 isert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout() (ib_isert.c:1160), inlined through isert_rx_opcode(). Validate wc->byte_len against the framing in isert_recv_done() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISER_HEADERS_LEN (commit 29e7b925ae6d (\"IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN\")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all. isert reads the data segment from a fixed offset: isert_get_data() returns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum against wc->byte_len bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything furth ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90415", "url": "https://ubuntu.com/security/CVE-2026-90415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: free STAG index when TPT entry write fails write_tpt_entry() allocates a new STAG index with c4iw_get_resource() and bumps stats.stag.cur before programming the entry. When write_adapter_mem() fails, it returns the error without releasing the index or reversing the statistic. No MR is inserted into rhp->mrs, so deregistration never reclaims it, leaking the index until device teardown. Record whether this call allocated the index and, on a failed write, return it to tpt_table and decrement stats.stag.cur. Key the rollback on both the write error and that flag, not the error alone: a non-reset update carries a caller-owned STAG that this call did not allocate and must not free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90416", "url": "https://ubuntu.com/security/CVE-2026-90416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed \"%d\" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as \"-2147483648\\n\" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with \"%u\" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90419", "url": "https://ubuntu.com/security/CVE-2026-90419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent out-of-bounds read in super root block parsing super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90420", "url": "https://ubuntu.com/security/CVE-2026-90420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix infinite loop in nilfs_clean_segments() syzbot reported a hung task in nilfs_transaction_begin(). This occurs because the cleaner ioctl falls into an infinite loop if nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device is remounted as read-only after an I/O error). Currently in nilfs_clean_segments(), if err is non-zero, it logs the error and sleeps but doesn't abort when it encounters a terminal error like -EROFS. This causes the thread to loop forever. Fix this by breaking out of the loop if nilfs_segctor_construct() returns -EROFS. This matches the behaviour in nilfs_segctor_write_out(), which also handles -EROFS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93264", "url": "https://ubuntu.com/security/CVE-2026-93264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Fix PBL chunk length computation On register MR, when creating the PBL, if it's an indirect PBL we create a chunk list to hold the PBL pages pointers. Each chunk is 4KB in size and can hold 510 addresses (EFA_PTRS_PER_CHUNK) and has a 12-byte control buffer at the end of it holding the next chunk's pointer and its length. If the PBL number of pages is a multiple of EFA_PTRS_PER_CHUNK, the calculated last chunk length is wrongly computed as 0, even though that chunk is fully populated with 510 real page pointers. This wrong length is used both to DMA map the chunk and is propagated to the device, causing the device to see the chunk as empty and reject the memory registration. Fix the calculation so it will be performed only if the number of pages isn't a multiple of EFA_PTRS_PER_CHUNK, if it is, its already handled in the above loop correctly. Also prevent out-of-bounds reach in the chunks array in such scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89782", "url": "https://ubuntu.com/security/CVE-2026-89782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject restart table growth beyond U16_MAX entries During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): \trt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90431", "url": "https://ubuntu.com/security/CVE-2026-90431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: Prevent crash handling to race with rproc_del() There's no synchronization between rproc_crash_handler_work() and rproc_del(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues. To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds. In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a \"deleting\" flag is introduced. This is similar to the RPROC_DELETE state that was introduced to ensure that \"start\" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the \"state\" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90434", "url": "https://ubuntu.com/security/CVE-2026-90434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: release zisofs block pointer buffer head zisofs_fill_pages() reads the compressed block pointer table. The error paths release the current buffer_head, the loop also releases the old buffer_head when it advances. However, the success path leaves the last buffer_head referenced. Release it before returning success.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90435", "url": "https://ubuntu.com/security/CVE-2026-90435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix integer overflow of user QP buffer size set_user_buf_size() computes the QP buffer size by left-shifting the user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers. A sufficiently large rq.wqe_cnt causes signed integer overflow, which is undefined behavior, and yields a small or negative buf_size, causing ib_umem_get() to map a buffer smaller than the hardware will actually write into. Replace the shifts and addition with check_shl_overflow() and check_add_overflow(), rejecting invalid user inputs. Moreover, guard the identical shift computing qp->sq.offset in _create_user_qp() before set_user_buf_size() is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92476", "url": "https://ubuntu.com/security/CVE-2026-92476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Initialize completion before requesting IRQ kmb_ocs_aes_probe() requests the device IRQ before initializing irq_completion. Once the handler is registered it can run immediately, and ocs_aes_irq_handler() unconditionally calls complete(). An interrupt in this window would therefore use an uninitialized completion. Initialize the completion before requesting the IRQ, as the sibling OCS HCU and ECC drivers already do.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89785", "url": "https://ubuntu.com/security/CVE-2026-89785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89787", "url": "https://ubuntu.com/security/CVE-2026-89787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check dir entry fits before reading the hash trailer in ext4_search_dir() For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4_DIRENT_HASHES()), at an offset derived from de->name_len. On the sb_no_casefold_compat_fallback() path ext4_match() reads that trailer, but ext4_search_dir()'s by-hand pre-check only tests de->name + de->name_len <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4_DIRENT_HASHES(de) lands past the block end, so ext4_match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object: BUG: KASAN: use-after-free in ext4_match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4_match (fs/ext4/namei.c:1435) ext4_search_dir (fs/ext4/namei.c:1470) __ext4_find_entry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4_lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filename_lookup (fs/namei.c:2842) vfs_statx (fs/stat.c:353) __do_sys_newfstatat (fs/stat.c:538) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4_match(). This is the same bound ext4_check_dir_entry() already enforces via ext4_dir_rec_len(), so no well-formed entry is rejected. The other caller, ext4_find_dest_de(), runs ext4_check_dir_entry() first and is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92494", "url": "https://ubuntu.com/security/CVE-2026-92494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix buffer_head leak in ext4_init_orphan_info ext4_init_orphan_info() reads orphan file blocks with ext4_bread() and stores the returned buffer_head in oi->of_binfo[i].ob_bh. If ext4_bread() succeeds but the orphan block magic or checksum validation fails, the function jumps to out_free. However, the old out_free loop starts releasing buffers from i - 1, so the current buffer_head at index i is skipped. This leaks the buffer_head reference obtained by ext4_bread() on the bad magic and bad checksum error paths. Fix this by tracking the number of successfully read buffer_heads and releasing exactly those buffer_heads on the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92496", "url": "https://ubuntu.com/security/CVE-2026-92496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx() Currently, in ath11k_wmi_tlv_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Add an upfront length check before dereferencing skb->data as a wmi_cmd_hdr. The check is placed before the trace_ath11k_wmi_event() call to preserve the existing trace semantics (tracing the full raw WMI event including the header), unlike the analogous ath12k fix which could use skb_pull_data() directly. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92498", "url": "https://ubuntu.com/security/CVE-2026-92498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: avoid buffer overreads in WMI event handlers The following WMI event handlers currently read from the event buffer without first verifying that the message was large enough to hold the expected event: ath6kl_wmi_scan_complete_rx() ath6kl_wmi_addba_req_event_rx() ath6kl_wmi_delba_req_event_rx() Add length checks to prevent overread.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92501", "url": "https://ubuntu.com/security/CVE-2026-92501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drain in-flight DIO before buffered write fallback generic/746 started failing intermittently on ext3 (no-extent inodes). The test triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO. Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied, post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback) ----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared() iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async) dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0, 8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range() iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages() invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO) This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92504", "url": "https://ubuntu.com/security/CVE-2026-92504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int3400: clean up ODVP on probe failures evaluate_odvp() creates per-ODVP sysfs files before the thermal zone and later probe resources are registered. The current unwind path only calls cleanup_odvp() from the late sysfs failure path, so failures after evaluate_odvp() but before that label, including thermal_tripless_zone_device_register() failures, leave the ODVP files and storage behind. Move the ODVP cleanup to the common ART/TRT unwind path so every failure after evaluate_odvp() releases the ODVP state. Also clear the cached ODVP pointers in cleanup_odvp(), because evaluate_odvp() can already call it for partial setup failures while probe continues.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92508", "url": "https://ubuntu.com/security/CVE-2026-92508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_free_cq() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93268", "url": "https://ubuntu.com/security/CVE-2026-93268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: skip extra isize expansion during mount to prevent deadlock ext4_try_to_expand_extra_isize() is called from __ext4_mark_inode_dirty() while holding an active jbd2 handle. During mount (!SB_ACTIVE), the expand path may move xattrs to external blocks and release ea_inodes via iput(). When !SB_ACTIVE, iput() calls write_inode_now() which acquires s_writepages_rwsem, creating a circular lock dependency: s_writepages_rwsem --> jbd2_handle --> xattr_sem --> s_writepages_rwsem This can be triggered via: ext4_process_orphan() -> ext4_truncate() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() or: ext4_evict_inode() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() Skip expansion when !SB_ACTIVE. This is a minor loss of functionality (extra isize won't grow for these inodes during mount), which e2fsck can resolve later if needed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89786", "url": "https://ubuntu.com/security/CVE-2026-89786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bounds read in ext4_read_inline_dir() ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: \tdir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic \".\" and \"..\" land at their block-dir offsets. A dirent is formed at \"dir_buf + pos - extra_offset\", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92521", "url": "https://ubuntu.com/security/CVE-2026-92521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92522", "url": "https://ubuntu.com/security/CVE-2026-92522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: validate MADT IOAPIC entry bounds The IOAPIC hotplug lookup parses both MADT and _MAT records directly. The MADT walk previously used a subtable's declared length to advance the cursor after only locating a generic header. The _MAT path likewise passed a generic header to the IOAPIC helper. Validate that a current record has a complete generic header, that its declared length is contained in the available record range, and that a typed IOAPIC record contains the full fixed IOAPIC body before reading its fields. Use the same relation for both MADT and _MAT provider paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92524", "url": "https://ubuntu.com/security/CVE-2026-92524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc() When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93037", "url": "https://ubuntu.com/security/CVE-2026-93037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Propagate sdma_txinit_ahg() errors set_txreq_header_ahg() ignores the return value of sdma_txinit_ahg(). If sdma_txinit_ahg() fails, it returns before initializing tx->txreq. However, set_txreq_header_ahg() ignores the error and returns the AHG change count, causing the caller to continue processing the request as though initialization had succeeded. Propagate sdma_txinit_ahg() failures to the caller and abort request processing when initialization fails. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93039", "url": "https://ubuntu.com/security/CVE-2026-93039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: Keep link pointers valid on realloc failure meson_card_reallocate_links() grows the DAI link and private data arrays with two consecutive krealloc() calls and updates the owner pointers only after both calls have succeeded. A successful krealloc() may move the data: it frees the old block and returns a new one. When that happens for the link array and the second krealloc() then fails, card->dai_link still points to the block that krealloc() already freed, and the error path frees the new block too. The probe error path then calls meson_card_clean_references(), which dereferences card->dai_link and kfree()s it again, resulting in a use-after-free and a double free. Commit card->dai_link and card->num_links right after the first krealloc() succeeds, so the pointer always refers to a valid allocation that meson_card_clean_references() can walk and free. krealloc() with __GFP_ZERO zero-initializes the added entries, so walking them on the error path is safe. With both failure paths reduced to a plain return, drop the goto labels and the error message.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93040", "url": "https://ubuntu.com/security/CVE-2026-93040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize channel state checks pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent. For example, pause() can observe EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93041", "url": "https://ubuntu.com/security/CVE-2026-93041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize abort state updates dw_edma_abort_interrupt() drops vc.lock before changing request and status. issue_pending() can acquire the lock in that small window, observe the old busy state, and skip starting queued descriptors. Then the abort handler overwrites the channel status as idle, leaving the new descriptors stranded for good. Keep descriptor completion and the state transition in the same critical section.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93046", "url": "https://ubuntu.com/security/CVE-2026-93046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: software node: Fix software_node_get_reference_args() with index -1 The bounds check for the index passed to software_node_get_reference_args() was failing when passed UINT_MAX, this in turn would lead to an out of bound access in the property array. Fix the bound check to also cover the UINT_MAX case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93048", "url": "https://ubuntu.com/security/CVE-2026-93048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior. Commit 5daa7b21496a (\"mtd: prepare partition add and del functions for ioctl requests\") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e (\"mtd: add a flags for partitions which should just leave smth. after them\") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value. With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers: WARN_ON((!mtd->erasesize || !master->_erase) && \t\t!(mtd->flags & MTD_NO_ERASE)) in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the \"out of reach\" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error. Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93049", "url": "https://ubuntu.com/security/CVE-2026-93049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdswap: Avoid freeing registered blktrans device twice In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice. add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev. The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89777", "url": "https://ubuntu.com/security/CVE-2026-89777", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio_msi_cap_len() lazily allocates the per-device MSI permission table: \tvdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); \tif (!vdev->msi_perm) \t\treturn -ENOMEM; \tret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); \tif (ret) { \t\tkfree(vdev->msi_perm); \t\treturn ret;\t\t/* vdev->msi_perm left dangling */ \t} When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at \"if (vdev->msi_perm) return len;\" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93051", "url": "https://ubuntu.com/security/CVE-2026-93051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ad525x_dpot: use driver core groups for sysfs files ad_dpot_probe() creates per-RDAC sysfs files manually and then optionally creates the command sysfs group. This leaves probe responsible for rolling back partial sysfs state and makes remove responsible for matching every file that probe created. Move the device attributes into driver core dev_groups for the I2C and SPI drivers and use an is_visible() callback to expose only the attributes supported by the probed device. With this shape, the driver core creates the sysfs files only after probe succeeds and removes them before the remove callback frees the driver data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93052", "url": "https://ubuntu.com/security/CVE-2026-93052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: bcm-vk: Use acquire/release for msgq_inited bcm_vk_sync_msgq() fills the message queue information and then sets msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the message queues and their cached queue information. atomic_set()/atomic_read() do not order those accesses. A reader can see msgq_inited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate. Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the gate and does not publish queue state to readers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93053", "url": "https://ubuntu.com/security/CVE-2026-93053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: speakup: keyhelp: guard letter_offsets possible out-of-range indexing help_init() builds letter_offsets[] by using the first byte of each function name as an index via `(start & 31) - 1`. If function_names are overridden from sysfs (root) with a name starting outside [a–z], the index underflows or exceeds the array, leading to OOB write. Function names can be overridden with the following commands as root: modprobe speakup_soft echo \"0 _bad\" > /sys/accessibility/speakup/i18n/function_names # then press Insert+2 on /dev/tty This fix checks the first letter in help_init(), and if it is not in the [a–z] range the function returns an error to the caller. Eventually this error is propagated to drivers/accessibility/speakup/main.c:2217, which causes a bleep sound.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93054", "url": "https://ubuntu.com/security/CVE-2026-93054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same \"device gone\" state as normal uio_unregister_device().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93055", "url": "https://ubuntu.com/security/CVE-2026-93055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: UDF symlink pathComponent header OOB read udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93056", "url": "https://ubuntu.com/security/CVE-2026-93056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: remove broken string configfs attributes The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for the fn_play, fn_cap, and fn_cntl string options. The store function contains an inverted null check on the kstrndup() return value. This means every write attempt returns -ENOMEM on success and dereferences a NULL pointer on allocation failure. The attributes have been broken and unused for many years. Remove the UAC1_STR_ATTRIBUTE macro and the three attributes it generated. The internal defaults (FILE_PCM_PLAYBACK, FILE_PCM_CAPTURE, FILE_CONTROL) set in f_audio_alloc_inst() are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93061", "url": "https://ubuntu.com/security/CVE-2026-93061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Avoid stack over-read in debug output helpers host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93067", "url": "https://ubuntu.com/security/CVE-2026-93067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clamps an AUX read to the payload limit: \tsize_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: \tif (size) \t\tsize = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 (\"drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer\").", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93271", "url": "https://ubuntu.com/security/CVE-2026-93271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate ath11k can receive HT/VHT/HE frames whose reported MCS is above the maximum that can be expressed in the corresponding mac80211 rate space (e.g. an HE frame reported with MCS 12, while HE tops out at MCS 11). The frame itself is valid and decodes correctly, but for such a frame ath11k_dp_rx_h_rate() leaves rx_status->rate_idx set to the out-of-range value and never assigns rx_status->encoding, so it stays RX_ENC_LEGACY from the ath11k_dp_rx_h_ppdu() initialization. Once that frame reaches mac80211 it trips the rate sanity check and the frame is dropped with a splat: ath11k_pci 0000:03:00.0: Received with invalid mcs in HE mode 12 WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:5433 ieee80211_rx_list+0xb0a/0xe90 [mac80211] Dropping the frame would discard otherwise valid data, so instead cap the reported MCS to the maximum the rate space can express and deliver the frame. Set rx_status->encoding before the range check and assign rate_idx from the capped value, so a frame with an out-of-range MCS no longer leaves partial or bogus rate metadata behind. Also downgrade the logging level since they are not treated as invalid frames now. The only loss is that such a frame is reported as the capped MCS in the rx rate statistics. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93095", "url": "https://ubuntu.com/security/CVE-2026-93095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: validate thread record before delete key rebuild hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93098", "url": "https://ubuntu.com/security/CVE-2026-93098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: glink: fix deadlock in endpoint destroy during driver detach During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89778", "url": "https://ubuntu.com/security/CVE-2026-89778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: fix out-of-bounds page array access on empty zisofs block zisofs_uncompress_block()'s empty-block fast path returns pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the decompression path which returns bytes produced relative to poffset. zisofs_fill_pages() uses that return to advance its page cursor, so when the zisofs block size is below PAGE_SIZE and a sub-page block leaves poffset partway into a page, a following empty block over-counts and advances pages[] one element past its end, after which \"if (poffset && *pages)\" reads pages[1] out of bounds. rock.c only rejects a block-size shift > 17, so a crafted \"ZF\" Rock Ridge record can set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a compressed file on such a mounted ISO9660 image. Return the byte count relative to poffset and zero only [poffset, PAGE_SIZE) of the first page, matching the decompression path. The page-aligned case (poffset == 0) is unaffected. BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290) Read of size 8 at addr ffff88800f5eac48 by task exploit/142 zisofs_read_folio (fs/isofs/compress.c:290) read_pages (mm/readahead.c:184) ... filemap_read (mm/filemap.c:2814) vfs_read (fs/read_write.c:574) __x64_sys_pread64 (fs/read_write.c:769) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address is located 0 bytes to the right of the allocated 8-byte region in the kmalloc-8 cache", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93102", "url": "https://ubuntu.com/security/CVE-2026-93102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Free RX data on late probe failure hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning. If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears down the device data without calling hfi1_free_rx(). This leaks netdev_rx and its dummy netdev. Free the RX support after IB unregistration and before postinit_cleanup(), as done on normal device removal.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93103", "url": "https://ubuntu.com/security/CVE-2026-93103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89783", "url": "https://ubuntu.com/security/CVE-2026-89783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use \"sp->len >= XFRM_MAX_DEPTH\", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]'", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93108", "url": "https://ubuntu.com/security/CVE-2026-93108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ipoib: Drain RCU callbacks during module teardown IPoIB reclamation completions can be signaled from inside an RCU callback. Teardown can wake before the callback returns and unload ib_ipoib while its code is still executing. Client registration failure can also remove already-added devices and queue callbacks. Wait after client and workqueue teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93109", "url": "https://ubuntu.com/security/CVE-2026-93109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Drain RCU callbacks during module teardown devx_free_subscription() can remain queued after the last DevX event file drops its module reference or an auxiliary driver detaches its devices. mlx5_ib can then unload before the callback runs. Registration error unwind has the same risk because driver registration can attach existing devices before failing. Wait after all drivers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93110", "url": "https://ubuntu.com/security/CVE-2026-93110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Wait for RCU callbacks before unloading ib_core put_gid_ndev() is queued with call_rcu() and implemented in ib_core. Stopping the workqueues does not drain callbacks already queued, so RCU could invoke it after the module code has been unloaded. synchronize_rcu() does not wait for callbacks. Wait for them after all producers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93114", "url": "https://ubuntu.com/security/CVE-2026-93114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/surface: acpi-notify: Check ACPI companion before use Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 (\"ACPI: driver: Check ACPI_COMPANION() against NULL during probe\") does for the core ACPI platform drivers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93115", "url": "https://ubuntu.com/security/CVE-2026-93115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93120", "url": "https://ubuntu.com/security/CVE-2026-93120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93130", "url": "https://ubuntu.com/security/CVE-2026-93130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix resource leak on module load failure We need to properly clean up the SMBIOS request and the privacy driver when the module load fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93131", "url": "https://ubuntu.com/security/CVE-2026-93131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-privacy: Fix race condition Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93138", "url": "https://ubuntu.com/security/CVE-2026-93138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire(). Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93140", "url": "https://ubuntu.com/security/CVE-2026-93140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 (\"udf: Mark LVID buffer as uptodate before marking it dirty\"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline] vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline] __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93141", "url": "https://ubuntu.com/security/CVE-2026-93141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: r8a66597: avoid double free of ep0_req in probe error path If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL. Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once. Issue found using a prototype static analysis tool and confirmed by code review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93145", "url": "https://ubuntu.com/security/CVE-2026-93145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister() gdsc_unregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pm_genpd_remove() on the individual generic_pm_domain structures registered by gdsc_init(): \tvoid gdsc_unregister(struct gdsc_desc *desc) \t{ \t\tstruct device *dev = desc->dev; \t\tsize_t num = desc->num; \t\tgdsc_pm_subdomain_remove(desc, num); \t\tof_genpd_del_provider(dev->of_node); \t} That leaves dangling entries on the global gpd_list. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdsc_init() will end up trying to re-register a name that is still in the list and pm_genpd_init() returns -EEXIST. While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh of_genpd_get_from_provider() call racing with the teardown could attach to a domain that is mid-removal. Iterate the scs[] array and pm_genpd_remove() each registered domain after the subdomain links are torn down. The regulators stay devm- managed (devm_regulator_get_optional() in gdsc_register()), so the release happens automatically when the underlying device is unbound; just the genpd accounting needs to be undone explicitly.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93278", "url": "https://ubuntu.com/security/CVE-2026-93278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown cvm_oct_rx_shutdown calls free_irq and netif_napi_del without disabling the napi instance first. As the free_irq only waits for completion of hard interrupt handlers, the napi poll function could still be active. If cvm_oct_remove proceeds to free the plat structure (which holds the NAPI instances), the active poll function will access freed memory, resulting in a use-after-free crash.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93279", "url": "https://ubuntu.com/security/CVE-2026-93279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown The TX cleanup tasklet can be scheduled by the watchdog IRQ handler to execute cvm_oct_tx_do_cleanup. There can be a pending tasklet in the queue which might run after the cvm_oct_remove() frees net_device structures, causing a use-after-free in cvm_oct_tx_do_cleanup() as it iterates cvm_oct_device[] which is an array of netdevice pointers. Add tasklet_kill() after free_irq() to ensure the tasklet is no longer scheduled or running before teardown proceeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93280", "url": "https://ubuntu.com/security/CVE-2026-93280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: greybus: audio: bound the topology section sizes against the fetched size gb_audio_gb_get_topology() fetches a topology blob of a module-supplied size, and gbaudio_tplg_parse_data() then walks it by adding the module-supplied size_dais, size_controls and size_widgets fields to form the control, widget and route section offsets. Those le32 sizes are never checked against the fetched blob, so a module reporting a small topology size but large section sizes makes the offsets point past the allocation, and parsing reads out of bounds. Reject a topology whose section sizes do not fit within the fetched size before it is parsed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93151", "url": "https://ubuntu.com/security/CVE-2026-93151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: fix response resource leak on queue teardown When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm \"kworker/2:1H\", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 unreferenced object 0xffff88814bd05e80 (size 64): comm \"kworker/3:1H\", pid 148, jiffies 4295195428 backtrace (crc e35510cb): __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources() that frees up the RDMA read/write context and the request SGLs of such responses.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93158", "url": "https://ubuntu.com/security/CVE-2026-93158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul - stop probe if context pool creation fails sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool. Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93159", "url": "https://ubuntu.com/security/CVE-2026-93159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes. If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated work_data is not usable for producing RNG output and must not remain associated with the hwrng state. Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data. Fix this by freeing the pending work_data. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93160", "url": "https://ubuntu.com/security/CVE-2026-93160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-ecc - reject hardware ECDH without a public key The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm. atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93161", "url": "https://ubuntu.com/security/CVE-2026-93161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - clear AES key schedule from stack qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame. Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93165", "url": "https://ubuntu.com/security/CVE-2026-93165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Fix memory overread in ring handler `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93167", "url": "https://ubuntu.com/security/CVE-2026-93167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: csky: Fix a4/a5 restoration in syscall trace path The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93170", "url": "https://ubuntu.com/security/CVE-2026-93170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93177", "url": "https://ubuntu.com/security/CVE-2026-93177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup vddInd, vddciInd and mvddInd from VBIOS-parsed tables index into vddc, vddci and vddmem lookup tables without bounds checks across nine sites. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93178", "url": "https://ubuntu.com/security/CVE-2026-93178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93274", "url": "https://ubuntu.com/security/CVE-2026-93274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: bcm2835: Don't remove an unregistered GPIO chip If the devm_pinctrl_register() function fails, bcm2835_pinctrl_probe() calls gpiochip_remove() before gpiochip_add_data() has registered the GPIO chip. This means that upon failure the gpio_chip.gpiodev is NULL resulting in a null pointer dereference inside the gpiochip_remove() function. Remove the unnecessary function call to gpiochip_remove(). No GPIO cleanup is required because the GPIO chip has not yet been registered. Without this change there is potential for a kernel panic upon registration failure", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-93183", "url": "https://ubuntu.com/security/CVE-2026-93183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/lima: call drm_mm_init() with a valid allocation range lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2: [ 1.736297] ------------[ cut here ]------------ [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931! [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.750697] Modules linked in: [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree) [ 1.769446] Workqueue: events_unbound deferred_probe_work_func [ 1.775261] PC is at drm_mm_init+0x9c/0xa4 [ 1.779339] LR is at lima_vm_create+0x144/0x17c [ ... ] Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93185", "url": "https://ubuntu.com/security/CVE-2026-93185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rt700-sdw: always drain jack work on remove rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93188", "url": "https://ubuntu.com/security/CVE-2026-93188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: bound device-supplied profile index kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93189", "url": "https://ubuntu.com/security/CVE-2026-93189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path (\"hwmon: prevent packets from going to driver for probe\", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93191", "url": "https://ubuntu.com/security/CVE-2026-93191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix incorrect task context in smack_msg_queue_msgrcv The smack_msg_queue_msgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task. In the msgsnd() syscall path, if a receiver is already waiting, the pipelined_send() optimization is used to push the message directly to the receiver task: ipc/msg.c`pipelined_send(): ` smp_store_release(&msr->r_msg, msg) In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->r_tsk, passed as the 'target' parameter): ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, target := msr->r_tsk,,) However, smack_msg_queue_msgrcv() ignores the 'target' and checks 'current': smack_msg_queue_msgrcv(…) ` smk_curacc_msq(isp, MAY_READWRITE); // current task 'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy. Test: 1) create a sysv message queue with label “foo” 2) echo \"bar foo r\" >/smack/load2 3) msgrcv(,,,0,MSG_NOERROR) in \"bar\"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a \"foo\"-labeled task: \"bar\"-labeled task gets the message. This patch fixes the issue by checking permission on the 'target' task instead of 'current'. (2008-02-04, Casey Schaufler)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2025-40123", "url": "https://ubuntu.com/security/CVE-2025-40123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce expected_attach_type for tailcall compatibility Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-89947", "url": "https://ubuntu.com/security/CVE-2026-89947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: meson: align gxbb_32k_clk_sel number of parents with actual count The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c (\"clk: amlogic: gxbb: drop non existing 32k clock parent\") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80671", "url": "https://ubuntu.com/security/CVE-2026-80671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf sched: Fix register_pid() overflow, strcpy, and BUG_ON register_pid() has several issues when processing untrusted perf.data: 1. Integer overflow: (pid + 1) * sizeof(struct task_desc *) can wrap to a small value on 32-bit systems when pid is large (e.g. 0x40000000), causing realloc to return a tiny buffer followed by out-of-bounds writes in the initialization loop. 2. Heap buffer overflow: strcpy(task->comm, comm) copies the untrusted comm string into a fixed 20-byte COMM_LEN buffer with no length check. 3. BUG_ON on allocation failure: perf.data is untrusted input, so allocation failures should be handled gracefully rather than killing the process. 4. Realloc of sched->tasks assigned directly back, leaking the old pointer on failure; nr_tasks incremented before the realloc, leaving corrupted state on failure. Cap pid at PID_MAX_LIMIT (4194304, matching the kernel's maximum on 64-bit), replace strcpy with strlcpy, guard against NULL comm, replace BUG_ON with NULL returns using safe realloc patterns, and add NULL checks in callers that dereference the result.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-93203", "url": "https://ubuntu.com/security/CVE-2026-93203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: avoid CRC corruption due to parallel claim add batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either * add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone But when the \"new\" claim code was running in parallel to the \"change backbone\" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the \"new\" claim code path: * CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point. * CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc. * CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc The CRC is then wrong for both: * claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs. To avoid this, split the functionality in clear separate parts: * new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back) * update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93204", "url": "https://ubuntu.com/security/CVE-2026-93204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: atomically update mac addresses When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2025-22039", "url": "https://ubuntu.com/security/CVE-2025-22039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix overflow in dacloffset bounds check The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl(). This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer. This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.", "cve_priority": "high", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-21651", "url": "https://ubuntu.com/security/CVE-2025-21651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: don't auto enable misc vector Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below: [ 16.324639] Call trace: [ 16.324641] __queue_delayed_work+0xb8/0xe0 [ 16.324643] mod_delayed_work_on+0x78/0xd0 [ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge] [ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge] [ 16.324666] __handle_irq_event_percpu+0x64/0x1e0 [ 16.324667] handle_irq_event+0x80/0x170 [ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc [ 16.324671] __handle_domain_irq+0x84/0xfc [ 16.324673] gic_handle_irq+0x88/0x2c0 [ 16.324674] el1_irq+0xb8/0x140 [ 16.324677] arch_cpu_idle+0x18/0x40 [ 16.324679] default_idle_call+0x5c/0x1bc [ 16.324682] cpuidle_idle_call+0x18c/0x1c4 [ 16.324684] do_idle+0x174/0x17c [ 16.324685] cpu_startup_entry+0x30/0x6c [ 16.324687] secondary_start_kernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]--- So don't auto enable misc vector when request irq..", "cve_priority": "low", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43088", "url": "https://ubuntu.com/security/CVE-2026-43088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: zero aligned sockaddr tail in PF_KEY exports PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE` Fix those paths by clearing only the aligned sockaddr tail after `pfkey_sockaddr_fill()`.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31420", "url": "https://ubuntu.com/security/CVE-2026-31420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: mrp: reject zero test interval to avoid OOM panic br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock. The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames. Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2025-22103", "url": "https://ubuntu.com/security/CVE-2025-22103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix NULL pointer dereference in l3mdev_l3_rcv When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-21649", "url": "https://ubuntu.com/security/CVE-2025-21649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is sent on HIP08 devices Currently, HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL. But the tx process would still try to set hardware time stamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash. [ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge] [ 128.292938] sp : ffff800059b93140 [ 128.297200] x29: ffff800059b93140 x28: 0000000000003280 [ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080 [ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001 [ 128.315969] x23: 0000000000000000 x22: 0000000000000194 [ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000 [ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000 [ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24 [ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000 [ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368 [ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02 [ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0 [ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000 [ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff [ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294 [ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080 [ 128.390626] Call trace: [ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3] [ 128.405468] xmit_one.constprop.0+0xc4/0x200 [ 128.410600] dev_hard_start_xmit+0x54/0xf0 [ 128.415556] sch_direct_xmit+0xe8/0x634 [ 128.420246] __dev_queue_xmit+0x224/0xc70 [ 128.425101] dev_queue_xmit+0x1c/0x40 [ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch] [ 128.435409] do_output+0x60/0x17c [openvswitch] [ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch] [ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch] [ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch] [ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch] [ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch] [ 128.471460] xmit_one.constprop.0+0xc4/0x200 [ 128.476561] dev_hard_start_xmit+0x54/0xf0 [ 128.481489] __dev_queue_xmit+0x968/0xc70 [ 128.486330] dev_queue_xmit+0x1c/0x40 [ 128.490856] ip_finish_output2+0x250/0x570 [ 128.495810] __ip_finish_output+0x170/0x1e0 [ 128.500832] ip_finish_output+0x3c/0xf0 [ 128.505504] ip_output+0xbc/0x160 [ 128.509654] ip_send_skb+0x58/0xd4 [ 128.513892] udp_send_skb+0x12c/0x354 [ 128.518387] udp_sendmsg+0x7a8/0x9c0 [ 128.522793] inet_sendmsg+0x4c/0x8c [ 128.527116] __sock_sendmsg+0x48/0x80 [ 128.531609] __sys_sendto+0x124/0x164 [ 128.536099] __arm64_sys_sendto+0x30/0x5c [ 128.540935] invoke_syscall+0x50/0x130 [ 128.545508] el0_svc_common.constprop.0+0x10c/0x124 [ 128.551205] do_el0_svc+0x34/0xdc [ 128.555347] el0_svc+0x20/0x30 [ 128.559227] el0_sync_handler+0xb8/0xc0 [ 128.563883] el0_sync+0x160/0x180", "cve_priority": "medium", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2023-52676", "url": "https://ubuntu.com/security/CVE-2023-52676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Guard stack limits against 32bit overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904", "cve_priority": "high", "cve_public_date": "2024-05-17 15:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "low", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-90015", "url": "https://ubuntu.com/security/CVE-2026-90015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89816", "url": "https://ubuntu.com/security/CVE-2026-89816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used Commit 1c6ceeee6ebb (\"drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits\") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93234", "url": "https://ubuntu.com/security/CVE-2026-93234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: validate TV mode names before creating enum property The GUD protocol returns TV mode names as fixed-size GUD_CONNECTOR_TV_MODE_NAME_LEN entries and requires each name to be NUL-terminated. gud_connector_add_tv_mode() currently passes each fixed-size entry directly to drm_mode_create_tv_properties_legacy(), which eventually reaches drm_property_add_enum() and strlen(). If a device returns an entry without a terminating NUL byte, strlen() reads past the end of the slot and can run beyond the allocated buffer, triggering an out-of-bounds read. Validate that each returned TV mode name contains a NUL terminator within its fixed-size slot before passing it to the DRM property code. If a malformed entry is found, reject the device response with -EIO. This fixes the out-of-bounds read without changing the handling of valid devices, and avoids silently truncating malformed protocol data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89817", "url": "https://ubuntu.com/security/CVE-2026-89817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: NUL-terminate TV mode names read from the device gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89821", "url": "https://ubuntu.com/security/CVE-2026-89821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid divide-by-zero in __is_lut_linear() __is_lut_linear() computes the expected value of each entry with \texpected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89823", "url": "https://ubuntu.com/security/CVE-2026-89823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: fix race between partial drm_dev_register() failure and ioctl If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89843", "url": "https://ubuntu.com/security/CVE-2026-89843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89845", "url": "https://ubuntu.com/security/CVE-2026-89845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89846", "url": "https://ubuntu.com/security/CVE-2026-89846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: \tif (IS_FWI2_CAPABLE(ha)) { \t\tsense_data += rsp_info_len; \t\tpar_sense_len -= rsp_info_len; \t} rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): \tif (sense_len > par_sense_len) \t\tsense_len = par_sense_len; \tmemcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89847", "url": "https://ubuntu.com/security/CVE-2026-89847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid double completion in async IOCB timeout qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates \"if (sp->comp) complete(sp->comp)\"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93242", "url": "https://ubuntu.com/security/CVE-2026-93242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb() qla24xx_process_response_queue() advances ring_ptr past the head IOCB before dispatching, so by the time __qla_consume_iocb() runs, ring_ptr already points at the first continuation IOCB. The function however looped purex->entry_count times starting at ring_ptr. As entry_count includes the head, this consumed one entry too many: it stamped RESPONSE_PROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked. Mark the head processed and account for it, then consume only the entry_count - 1 continuation IOCBs, matching __qla_copy_purex_to_buffer().", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89849", "url": "https://ubuntu.com/security/CVE-2026-89849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path qla2x00_status_entry() filters out non-TYPE_SRB entries and the SRB_NVME_CMD, SRB_BIDI_CMD and SRB_TM_CMD types, then falls through to a SCSI fast path that assumes the command is an SRB_SCSI_CMD. The first thing on that path, qla_chk_edif_rx_sa_delete_pending(), and the subsequent handling both evaluate GET_CMD_SP(sp), i.e. sp->u.scmd.cmd. The srb u union overlays the SCSI command pointer with other command layouts (bsg_job, iocb_cmd). If firmware delivers an unexpected STATUS_TYPE IOCB for a non-SCSI handle, sp->u.scmd.cmd can read as a non-NULL garbage pointer, bypassing the NULL checks in qla_chk_edif_rx_sa_delete_pending() and at the cp == NULL test, and leading to a wild pointer dereference. Reject any SRB whose type is not SRB_SCSI_CMD before entering the fast path. The outstanding_cmds slot is left untouched so a genuinely non-SCSI command still completes through its proper handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89850", "url": "https://ubuntu.com/security/CVE-2026-89850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Don't query firmware state while chip is down qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89851", "url": "https://ubuntu.com/security/CVE-2026-89851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace enable parsing in debugfs qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as \"disable\" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89852", "url": "https://ubuntu.com/security/CVE-2026-89852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89853", "url": "https://ubuntu.com/security/CVE-2026-89853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89854", "url": "https://ubuntu.com/security/CVE-2026-89854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix cs84xx use-after-free on host teardown qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89855", "url": "https://ubuntu.com/security/CVE-2026-89855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize flash version read in reset handler The \"update cache versions without reset\" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89856", "url": "https://ubuntu.com/security/CVE-2026-89856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as \"ha->max_req_queues = ha->msix_count - 1\" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent \"ha->max_req_queues--\" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following \"ha->req_q_map[0] = req\" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89858", "url": "https://ubuntu.com/security/CVE-2026-89858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89861", "url": "https://ubuntu.com/security/CVE-2026-89861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89863", "url": "https://ubuntu.com/security/CVE-2026-89863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check qla_chk_edif_rx_sa_delete_pending() obtains the SCSI command via GET_CMD_SP(sp) and immediately dereferences cmd->sc_data_direction. That command pointer can be NULL: the firmware may post a status completion for a command that has already been returned or aborted. The caller qla2x00_status_entry() acknowledges this on the very same status path, re-fetching GET_CMD_SP(sp) and bailing out with the \"Command already returned\" message when it is NULL -- but that check runs only after qla_chk_edif_rx_sa_delete_pending() has already dereferenced the pointer, so a NULL cmd crashes the kernel in interrupt context. Return early when cmd is NULL, before touching cmd->sc_data_direction.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89864", "url": "https://ubuntu.com/security/CVE-2026-89864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: \tstruct qla_i2c_access { \t\tuint16_t device, offset, option, length; \t\tuint8_t buffer[0x40]; \t} __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89865", "url": "https://ubuntu.com/security/CVE-2026-89865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: \tif (len == 1) \t\topt |= BIT_0; \tif (opt & BIT_0) \t\tlen = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89871", "url": "https://ubuntu.com/security/CVE-2026-89871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89872", "url": "https://ubuntu.com/security/CVE-2026-89872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. [Sakari Ailus: Fix subject prefix and coding style a little.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89876", "url": "https://ubuntu.com/security/CVE-2026-89876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tda18250: fix possible integer overflow Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89878", "url": "https://ubuntu.com/security/CVE-2026-89878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: check firmware size before reading trailing marker s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89879", "url": "https://ubuntu.com/security/CVE-2026-89879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: bound JPEG frame size before copying into the buffer s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: \tpayload = le32_to_cpu(pdword[3]); \tif (payload > vc->req_image_size)\t/* payload is checked ... */ \t\treturn -EINVAL; \tvc->pkt_size = payload; \tvc->jpg_size = le32_to_cpu(pdword[4]);\t/* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89880", "url": "https://ubuntu.com/security/CVE-2026-89880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89881", "url": "https://ubuntu.com/security/CVE-2026-89881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89883", "url": "https://ubuntu.com/security/CVE-2026-89883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: sunxi-cir: Unregister rc device on probe failure After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93236", "url": "https://ubuntu.com/security/CVE-2026-93236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common When VIDIOC_TRY_FMT is called with an unsupported pixel format on the OUTPUT queue, vdec_try_fmt_common() falls back to V4L2_PIX_FMT_MPEG2. However, if a distro has locally patched MPEG2 support out (as it has been broken for some time) the platform format table does not contain MPEG2 so find_format() returns NULL and the subsequent dereference of fmt_out->max_width triggers a NULL pointer dereference. Fix this by falling back to the first format in the platform's format array instead of hardcoding V4L2_PIX_FMT_MPEG2. This is always valid since every platform defines at least one format.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89887", "url": "https://ubuntu.com/security/CVE-2026-89887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov7740: fix use-after-destroy in remove The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89888", "url": "https://ubuntu.com/security/CVE-2026-89888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov02a10: fix endpoint parsing use-after-free The ov02a10_check_hwcfg() function calls fwnode_handle_put(ep) immediately after allocating and parsing the endpoint. However, it subsequently calls fwnode_property_read_u32() using the same 'ep' handle, leading to a potential use-after-free. Additionally, reading the optional 'ovti,mipi-clock-voltage' property used to overwrite the 'ret' variable. If the property was missing, 'ret' would become negative, and this failure code would be incorrectly returned at the end of the function, causing probe to fail entirely. Fix the use-after-free by moving fwnode_property_read_u32() before the endpoint is parsed and freed. Avoid the error leak by not assigning the result of fwnode_property_read_u32() to 'ret'.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89890", "url": "https://ubuntu.com/security/CVE-2026-89890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: go7007: defer the ALSA v4l2 put until card release go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89891", "url": "https://ubuntu.com/security/CVE-2026-89891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free of dev_next->devlist on disconnect When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 (\"USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89892", "url": "https://ubuntu.com/security/CVE-2026-89892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: defer audio-only extension registration The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89893", "url": "https://ubuntu.com/security/CVE-2026-89893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: cancel NetUP CI work before teardown netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89894", "url": "https://ubuntu.com/security/CVE-2026-89894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: reject geometry changes while the VBI queue is busy vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: \toffset = lines_completed * (dev->width << 1) + ...; \tif (dma_q->current_field == 2) \t\toffset += dev->width * 2 * dma_q->lines_per_field; \tmemcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89895", "url": "https://ubuntu.com/security/CVE-2026-89895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cobalt: Avoid freeing ALSA private data twice snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89896", "url": "https://ubuntu.com/security/CVE-2026-89896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: fix memory leak in cedrus_init_ctrls() In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89897", "url": "https://ubuntu.com/security/CVE-2026-89897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: Serialize exclusive follower delivery cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89901", "url": "https://ubuntu.com/security/CVE-2026-89901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89923", "url": "https://ubuntu.com/security/CVE-2026-89923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Free guest debug data on vcpu destroy kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89924", "url": "https://ubuntu.com/security/CVE-2026-89924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix old_data leak in guest debug error path __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89925", "url": "https://ubuntu.com/security/CVE-2026-89925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory leak in guest debug handling bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89926", "url": "https://ubuntu.com/security/CVE-2026-89926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix length check __import_wp_info() struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: \twp_info->len = bp_data->len; \t[...] \tif (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) \t\treturn -EINVAL; \twp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89927", "url": "https://ubuntu.com/security/CVE-2026-89927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89930", "url": "https://ubuntu.com/security/CVE-2026-89930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter KVM services local TLB flushes on \"full\" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89932", "url": "https://ubuntu.com/security/CVE-2026-89932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always flush vpid02 on first use Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89936", "url": "https://ubuntu.com/security/CVE-2026-89936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: dac: m62332: Fix regulator reference count imbalance m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89937", "url": "https://ubuntu.com/security/CVE-2026-89937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sgp30: Handle IAQ thread creation failure kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89939", "url": "https://ubuntu.com/security/CVE-2026-89939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89945", "url": "https://ubuntu.com/security/CVE-2026-89945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l34: drain threaded IRQ before runtime suspend cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89946", "url": "https://ubuntu.com/security/CVE-2026-89946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89948", "url": "https://ubuntu.com/security/CVE-2026-89948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89949", "url": "https://ubuntu.com/security/CVE-2026-89949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89951", "url": "https://ubuntu.com/security/CVE-2026-89951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix stale receive device on merged fragments Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89952", "url": "https://ubuntu.com/security/CVE-2026-89952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89953", "url": "https://ubuntu.com/security/CVE-2026-89953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89954", "url": "https://ubuntu.com/security/CVE-2026-89954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: afs: validate v2 image info bounds The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89964", "url": "https://ubuntu.com/security/CVE-2026-89964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: eisa: Fix infinite loop when parsing invalid IRQ value When an invalid value is passed via the \"eisa_irq_edge=\" kernel command line parameter (e.g. \"eisa_irq_edge=16,5\"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89965", "url": "https://ubuntu.com/security/CVE-2026-89965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: reject an arena whose nfree is below the lane count The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89968", "url": "https://ubuntu.com/security/CVE-2026-89968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: reject unsolicited H2CData PDUs nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the \"list_add double add\" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89969", "url": "https://ubuntu.com/security/CVE-2026-89969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as \tqueue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89973", "url": "https://ubuntu.com/security/CVE-2026-89973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: check the data direction of a C2HData PDU nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89979", "url": "https://ubuntu.com/security/CVE-2026-89979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race between non-atomic ops and trigger-start We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89980", "url": "https://ubuntu.com/security/CVE-2026-89980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: harmony: initialize locks before requesting IRQ snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89982", "url": "https://ubuntu.com/security/CVE-2026-89982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89983", "url": "https://ubuntu.com/security/CVE-2026-89983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89984", "url": "https://ubuntu.com/security/CVE-2026-89984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \\ \t./perf bench syscall basic --loop 1000 | \\ \t./perf script -i - --fields brstack|tr ' ' '\\n'| \\ \tgrep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89989", "url": "https://ubuntu.com/security/CVE-2026-89989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89993", "url": "https://ubuntu.com/security/CVE-2026-89993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Initialize IRQ data before requesting IRQs dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89997", "url": "https://ubuntu.com/security/CVE-2026-89997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix resume-vs-remove race If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89999", "url": "https://ubuntu.com/security/CVE-2026-89999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: validate report length in wacom_intuos_pro2_bt_irq wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: \twacom_intuos_pro2_bt_pen(wacom); \tif (type == INTUOSP2_BT || type == INTUOSP2S_BT) { \t\twacom_intuos_pro2_bt_touch(wacom); \t\twacom_intuos_pro2_bt_pad(wacom); \t\twacom_intuos_pro2_bt_battery(wacom); \t} else { \t\twacom_intuos_gen3_bt_pad(wacom); \t\twacom_intuos_gen3_bt_battery(wacom); \t} Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] \t(the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT (\"gen3\"): wacom_intuos_gen3_bt_battery() reads data[45], \tso the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 (\"HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq\") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90000", "url": "https://ubuntu.com/security/CVE-2026-90000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: rmi: fix OOB access with undersized RMI reports The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: \tdata->input_report_size = hid_report_len(input_report); \tdata->output_report_size = hid_report_len(output_report); \talloc_size = data->output_report_size + data->input_report_size; \tdata->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); \tdata->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly \"this probe validated the reports\"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90007", "url": "https://ubuntu.com/security/CVE-2026-90007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Use rollback index when freeing MSI-X vectors pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90011", "url": "https://ubuntu.com/security/CVE-2026-90011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where \tpadding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90017", "url": "https://ubuntu.com/security/CVE-2026-90017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: \tconst u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); \t... \tc = frame_body[0]; \t... \ta = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90018", "url": "https://ubuntu.com/security/CVE-2026-90018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: \tif (attr_ptr + 4 > wps_ie + wps_ielen) \t\tbreak; \tu16 attr_id = get_unaligned_be16(attr_ptr); \tu16 attr_data_len = get_unaligned_be16(attr_ptr + 2); \tu16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: \tmemcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack \"u8 sr\"/\"u8 selected_registrar\" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The \"attr_ptr + 4 > wps_ie + wps_ielen\" header check above was added by commit 1463ca3ec6601 (\"staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()\"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90019", "url": "https://ubuntu.com/security/CVE-2026-90019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: fix null pointer dereference in usb_put_function_instance() usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90020", "url": "https://ubuntu.com/security/CVE-2026-90020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90025", "url": "https://ubuntu.com/security/CVE-2026-90025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix OOB altmode array index The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90031", "url": "https://ubuntu.com/security/CVE-2026-90031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90032", "url": "https://ubuntu.com/security/CVE-2026-90032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: usbtv: keep device alive while ALSA card exists The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90033", "url": "https://ubuntu.com/security/CVE-2026-90033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90034", "url": "https://ubuntu.com/security/CVE-2026-90034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2025-38097", "url": "https://ubuntu.com/security/CVE-2025-38097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: remove encap socket caching to avoid reference leak The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used \"recently\", but it's a lot more complex than just not caching the socket.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2026-89515", "url": "https://ubuntu.com/security/CVE-2026-89515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables() During fuzz testing, the following issue was discovered: BUG: KMSAN: uninit-value in __dma_map_sg_attrs+0x217/0x310 __dma_map_sg_attrs+0x217/0x310 dma_map_sg_attrs+0x4a/0x70 ata_qc_issue+0x9f8/0x1420 __ata_scsi_queuecmd+0x1657/0x1740 ata_scsi_queuecmd+0x79a/0x920 scsi_queue_rq+0x4472/0x4f40 blk_mq_dispatch_rq_list+0x1cca/0x3ee0 __blk_mq_sched_dispatch_requests+0x458/0x630 blk_mq_sched_dispatch_requests+0x15b/0x340 __blk_mq_run_hw_queue+0xe5/0x250 __blk_mq_delay_run_hw_queue+0x138/0x780 blk_mq_run_hw_queue+0x4bb/0x7e0 blk_mq_sched_insert_request+0x2a7/0x4c0 blk_execute_rq+0x497/0x8a0 sg_io+0xbe0/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Uninit was created at: __alloc_pages+0x5c0/0xc80 alloc_pages+0xe0e/0x1050 blk_rq_map_user_iov+0x2b77/0x6100 blk_rq_map_user_io+0x2fa/0x4d0 sg_io+0xad6/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Bytes 14-15 of 16 are uninitialized Memory access of size 16 starts at ffff88800cbdb000 When processing the last unaligned element of the scatterlist, it is supplemented with missing bytes in the amount of pad_len. These bytes remain uninitialized, which leads to a problem. Extend last_sg->length by pad_len first, then use sg_zero_buffer() to zero those pad_len bytes. sg_zero_buffer() uses sg_miter internally, which correctly handles sg entries spanning multiple pages and padding that crosses a page boundary. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80689", "url": "https://ubuntu.com/security/CVE-2026-80689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions mmio_trace_rw() and mmio_trace_mapping() retrieve mmio_trace_array into tr and pass it to __trace_mmiotrace_rw() and __trace_mmiotrace_map(). If these functions are invoked while mmio_trace_array is NULL (e.g. before initialization or after disabled), accessing tr->array_buffer.buffer will result in a NULL pointer dereference crash. Fix this by adding an explicit NULL check for tr at the beginning of __trace_mmiotrace_rw() and __trace_mmiotrace_map().", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80888", "url": "https://ubuntu.com/security/CVE-2026-80888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: drop dma_buf reference on foreign-fd prime import ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-80912", "url": "https://ubuntu.com/security/CVE-2026-80912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: reject an unclaimed class value in security_get_classes() security_get_classes() sizes an array by p_classes.nprim and fills it at value - 1, so a class value the policy never defines leaves a NULL. sel_make_classes() passes every entry to sel_make_dir(), reaching the same d_alloc_name() dereference as the permission array. The class symbol table is allowed to be sparse (policydb_class_isvalid() exists to absorb that), but this getter builds its own array straight from the hash table and has no such predicate. Fail the lookup when a value went unclaimed instead of handing out the NULL. Conforming policies define every class they declare and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-89595", "url": "https://ubuntu.com/security/CVE-2026-89595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix stale object mask after concurrent mark updates When a mark gets a new event bit, fanotify and inotify may avoid recalculating the object mask if the cached aggregate already contains that bit. This is racy with a recalculation triggered by a concurrent update to another mark on the same connector. The concurrent scan can read the mark before the new bit is added, while the updater reads the old aggregate before that scan publishes its result. The updater then skips recalculation and the scan publishes a mask without the bit, leaving the object mask stale after both updates complete. This can be reproduced with two fanotify groups watching the same inode: one thread removes FAN_MODIFY from one existing mark while another thread adds FAN_MODIFY to the other mark. After both fanotify_mark() calls return, writes can fail to produce FAN_MODIFY for the group whose mark now contains the bit. This was reproduced on an unmodified v6.12.95 kernel. The equivalent inotify interleaving loses IN_MODIFY events. For normal fanotify additions, recalculate whenever the raw mark mask changes. The normal mask is not cleared asynchronously, so an unchanged addition cannot introduce missing interest. Always recalculate ignore-mask updates because FS_MODIFY handling may clear the ignore mask without taking mark->lock, making snapshot comparisons unreliable. Always recalculate after updating an existing inotify watch. Its replace path temporarily sets mark->mask to zero, so a concurrent scan can observe zero even when the old and final masks are equal. Assigning the replacement mask directly would avoid the transient zero, but existing-watch updates are infrequent, so unconditional recalculation is simpler.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89603", "url": "https://ubuntu.com/security/CVE-2026-89603", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-74378", "url": "https://ubuntu.com/security/CVE-2026-74378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe get_srq_wqe() reads wqe->dma.num_sge from the shared receive queue buffer, which is mapped into userspace. It validates num_sge against max_sge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify num_sge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe. Read num_sge into a local variable and use it for both the bounds check and the size calculation.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-89488", "url": "https://ubuntu.com/security/CVE-2026-89488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix CT limit teardown use-after-free Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state. An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down. Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists. Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization. The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90049", "url": "https://ubuntu.com/security/CVE-2026-90049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80977", "url": "https://ubuntu.com/security/CVE-2026-80977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't touch shared zerocopy state in skb_tx_error() skb_tx_error() completes the zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone shares, while the caller only owns the reference it is about to drop. Through a clone it tells the producer its pages are free and drops SKBFL_SHARED_FRAG for an skb that is still in flight. Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC: clone_execute() sends a skb_clone() into ovs_dp_process_packet() while do_execute_actions() keeps forwarding the original, and skb_clone() does not privatise the frags here -- skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN. A flow miss on the clone then strips the marker from the packet still being forwarded, and a later local ESP delivery decrypts in place over frags it does not own privately. Skip it for a cloned skb. Nothing is lost: skb_release_data() clears the zerocopy state once the last reference to the shared data goes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80928", "url": "https://ubuntu.com/security/CVE-2026-80928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix cred UAF in smack_file_send_sigiotask() When inspecting the credentials of another task, objective credentials (->real_cred, accessed with __task_cred()) must always be used. Accessing ->cred on a non-current task is forbidden unless that task is being created or destroyed; a task is allowed to change its own ->cred pointer with no synchronization, and changing ->cred should only affect the current syscall. smack_file_send_sigiotask() was accessing both sets of credentials: First tsk->cred, then __task_cred(tsk). Fix it, always access the objective credentials here. I have tested that this bug can lead to a KASAN-reported UAF of struct cred in smack_file_send_sigiotask(), and that this fix prevents the race.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-93222", "url": "https://ubuntu.com/security/CVE-2026-93222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: avoid shared siginfo namespace rewrites send_signal_locked() rewrites sender ids for the target namespace. Group sends reuse the same siginfo, so one recipient can affect the next. Copy the siginfo before changing it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-80930", "url": "https://ubuntu.com/security/CVE-2026-80930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80931", "url": "https://ubuntu.com/security/CVE-2026-80931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: ds28e17: reject an oversize length on an I2C block read w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the device. The downstream slave puts a length byte in buf[0]. The driver then reads that many bytes into buf[1] with w1_f19_i2c_read(). buf[0] is controlled by the device and can be 0 to 255. w1_f19_i2c_read() only rejects a zero count. The caller buffer is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read run past it, up to about 222 bytes out of bounds. The SMBus core does check buf[0] against I2C_SMBUS_BLOCK_MAX. That check runs after master_xfer returns. By then the write is already done. i2c-algo-bit rejects an oversize length before it copies, and returns -EPROTO. Reject a length above I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites, the same way i2c-algo-bit does.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80932", "url": "https://ubuntu.com/security/CVE-2026-80932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: flush works in dependency order virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work. In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it. KASAN reported: BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80938", "url": "https://ubuntu.com/security/CVE-2026-80938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex mt7615_suspend() acquired the mt76 mutex and then called cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the same mutex via mt7615_mutex_acquire() at the top of the worker, so if mac_work is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against. Flush scan_work and mac_work before taking the mutex, matching the suspend paths in mt7921 and mt7925. scan_work only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps mac_work from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80941", "url": "https://ubuntu.com/security/CVE-2026-80941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb() The skb passed to the rtw_hci_tx_write() is expected to be freed when the function fails, but the error path in rtw_txq_push_skb() does not free the skb before returning. This can lead to a memory leak in rtw_txq_push() where a dequeued skb is passed to rtw_txq_push_skb().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80944", "url": "https://ubuntu.com/security/CVE-2026-80944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Detach sync cmd buffer on interrupted wait mwifiex synchronous commands keep the caller-provided data buffer in cmd_node->data_buf. Several callers pass stack-allocated objects there. If wait_event_interruptible_timeout() is interrupted, the caller can return and release that stack object while the firmware command is still the current command. A late firmware response then reaches the normal response handler, which can copy data through cmd_node->data_buf into the stale stack address. This fixes a stack corruption observed during repeated association and disassociation cycles. The panic trace showed the command wait being interrupted immediately before a bad pointer dereference: cmd_wait_q terminated: -512 Unable to handle kernel paging request at virtual address 002c583837384662 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted ... Tainted: [M]=MACHINE_CHECK The fault address decodes as little-endian ASCII: 0x002c583837384662 -> \"bF878X,\\0\" which is a fragment of the VERSION_EXT firmware string exposed as debugfs \"verext\": w8997o-V4, RF878X, FP92, 16.92.21.p153.7 The same runs also showed corrupted control data containing: 0x2400372e333531 -> \"153.7\\0$\" which is the tail of the same VERSION_EXT string. This points at a late VERSION_EXT response writing through a stale stack-backed data_buf after the interrupted wait returned. After cancelling pending commands on an interrupted or timed-out wait, detach the caller-owned data buffer from the still-current command. This preserves the existing command cancellation behaviour while preventing a late response from writing through a pointer whose lifetime ended with the waiting caller. Tested on an i.MX8MP board using an 88W8997.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80949", "url": "https://ubuntu.com/security/CVE-2026-80949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() The memory allocated for buf is not freed in some of the error paths in brcmf_sdio_read_control(). Fix that by adding vfree() calls. [arend: rework as suggested by Johannes]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80951", "url": "https://ubuntu.com/security/CVE-2026-80951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: bound IBI payload to the requested max_payload_len svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into the IBI slot. The loop is bounded by the hardware FIFO size (SVC_I3C_FIFO_SIZE), not by the slot size. slot->data points into the IBI pool, which i3c_generic_ibi_alloc_pool() sizes at max_payload_len per slot. svc_i3c_master_request_ibi() only rejects a max_payload_len larger than SVC_I3C_FIFO_SIZE, so a driver can request a smaller one. mctp-i3c requests 1. Each readsb() then copies the controller RXCOUNT bytes (up to 31) with no check against the slot size. A device that sends more bytes than the slot holds writes past slot->data, an out-of-bounds write into the IBI pool. Bound the loop by dev->ibi->max_payload_len and clamp each read to the space left in the slot, the same way dw-i3c does. A device can still send more than the requested payload. Flush the leftover bytes from the RX FIFO so they do not leak into the next transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80952", "url": "https://ubuntu.com/security/CVE-2026-80952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix info leak and UAF in device unregister path i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During device_unregister(), device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct i3c_device_info, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind. Keep desc valid until device_unregister() has completed. Since device_unregister() drops the device reference and may free the device, take an extra reference with get_device() before unregistering. Clear desc afterwards and release the extra reference with put_device(). This preserves the release-time invariant that desc must be NULL while avoiding both the information leak and a potential use-after-free from writing desc after the device has been released.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80963", "url": "https://ubuntu.com/security/CVE-2026-80963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-stats: fix a crash if allocation of per-cpu data fails If \"dm_kvzalloc(percpu_alloc_size, cpu_to_node(cpu))\" fails, the code jumps to the \"out\" label and calls dm_stat_free. dm_stat_free does \"for_each_possible_cpu(cpu) { dm_kvfree(s->stat_percpu[cpu][0].histogram, s->histogram_alloc_size);\", which crashes with NULL pointer dereference if s->stat_percpu[cpu] is NULL. This commit fixes the bug by testing s->stat_percpu[cpu] for NULL before using it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80964", "url": "https://ubuntu.com/security/CVE-2026-80964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: virmidi: Check card index validity at probe virmidi driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80965", "url": "https://ubuntu.com/security/CVE-2026-80965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: serial-u16550: Check card index validity at probe serial-u16550 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80966", "url": "https://ubuntu.com/security/CVE-2026-80966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: portman2x4: Check card index validity at probe Although portman2x4 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80967", "url": "https://ubuntu.com/security/CVE-2026-80967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcxhr: initialize mutexes before requesting threaded IRQ pcxhr_probe() requests pcxhr_threaded_irq() before initializing mgr->lock, even though the threaded handler takes that mutex. Initialize the manager locks before request_threaded_irq() so an early interrupt cannot run against uninitialized mutex state during probe.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80968", "url": "https://ubuntu.com/security/CVE-2026-80968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mts64: Check card index validity at probe Although mts64 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80969", "url": "https://ubuntu.com/security/CVE-2026-80969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mpu401: Check card index validity at probe mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80971", "url": "https://ubuntu.com/security/CVE-2026-80971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: clear the URB pointers on disconnect bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind: \tusb_kill_urb(bcd2k->midi_out_urb); \tusb_kill_urb(bcd2k->midi_in_urb); \tusb_free_urb(bcd2k->midi_out_urb); \tusb_free_urb(bcd2k->midi_in_urb); The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core: \tbcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE; \t... \tret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC); usb_kill_urb() does not stop a later submission either, so a submit that races the disconnect can requeue the URB after it has been reaped. midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits it from the completion handler. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000] Write of size 4 at addr ffff00001827d388 by task bpoc/168 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 Freed by task 168: usb_free_urb bcd2000_disconnect [snd_bcd2000] BUG: KASAN: slab-use-after-free in usb_submit_urb Read of size 8 at addr ffff00001827d3b8 by task bpoc/168 Clear both pointers after freeing and test them on the paths that can still run. Poison the URBs before freeing them: usb_poison_urb() waits for a running completion handler and rejects any later submission, so after it returns the input path is quiesced and only the rawmidi trigger path can still reach bcd2000_midi_send(). No unpoison is needed; the URBs are freed on the next line. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80972", "url": "https://ubuntu.com/security/CVE-2026-80972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Check card index validity at probe aloop driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80973", "url": "https://ubuntu.com/security/CVE-2026-80973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: bound the MIDI event length from the device usb6fire_comm_receiver_handler() forwards a MIDI event using a length byte the device supplies, with no bound and no check that the transfer delivered that many bytes: \tif (!urb->status) { \t\tif (rt->receiver_buffer[0] == 0x10) /* midi in event */ \t\t\tif (midi_rt) \t\t\t\tmidi_rt->in_received(midi_rt, \t\t\t\t\t\trt->receiver_buffer + 2, \t\t\t\t\t\trt->receiver_buffer[1]); \t} receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the device chooses, so a device that answers with 0x10 and a length of 0xFF makes snd_rawmidi_receive() read 255 bytes starting two bytes into a 64-byte object. The bytes past the buffer are handed to userspace through the rawmidi read path. urb->actual_length is not consulted either, so a short transfer leaves both the type byte and the length byte at their previous values and the handler acts on stale data. The receiver URB is submitted from usb6fire_comm_init() at probe, so the read happens on plug with no user action; forwarding to userspace also needs a MIDI input substream open, since usb6fire_midi_in_received() only calls snd_rawmidi_receive() when rt->in is set. KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device: BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive Read of size 255 at addr ffff000009f64682 by task bash/183 __asan_memcpy snd_rawmidi_receive usb6fire_midi_in_received [snd_usb_6fire] usb6fire_comm_receiver_handler [snd_usb_6fire] Allocated by task 11: usb6fire_comm_init [snd_usb_6fire] usb6fire_chip_probe [snd_usb_6fire] The buggy address is located 2 bytes inside of allocated 64-byte region [ffff000009f64680, ffff000009f646c0) Reject the event when the length exceeds the bytes that follow the header, and require the transfer to have delivered the header plus that many bytes. The receiver URB is submitted with a 64-byte transfer_buffer_length, so a genuine device cannot deliver an event longer than those 62 bytes and nothing valid is dropped. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80976", "url": "https://ubuntu.com/security/CVE-2026-80976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: reset IP6CB after IPv6 decapsulation decap_and_validate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags. End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet. The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports: BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu ip6_protocol_deliver_rcu+0x1118/0x1450 ip6_input_finish+0x11b/0x240 seg6_local_input_core+0xed/0x2e0 lwtunnel_input+0x1e9/0x4e0 ipv6_rthdr_rcv+0x525f/0x6c50 ip6_protocol_deliver_rcu+0xcb7/0x1450 Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field. Use IP6CB(skb)->iif rather than skb->skb_iif because VRF processing can replace skb_iif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKB_L3SLAVE for the same reason.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80978", "url": "https://ubuntu.com/security/CVE-2026-80978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap advertised IP tunnel headroom IP tunnel devices derive their advertised needed_headroom from lower output devices. A stack of user-created devices can make the derived value larger than the 16-bit skb header offsets can represent. Once IP output reserves it, skb head expansion can wrap those offsets. The runtime transmit path already caps a growing needed_headroom at 512. Apply the same cap when tunnel configuration publishes needed_headroom derived from a lower output device. Capping the advertised value is safe: IP tunnel transmit still expands the skb when a packet needs more headroom. A nonsensical stacked configuration can therefore incur an extra reallocation, but it cannot publish an unbounded reservation to upper layers.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80983", "url": "https://ubuntu.com/security/CVE-2026-80983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket refcount leak in smc_switch_conns() smc_switch_conns() takes a reference on the SMC socket before dropping lgr->conns_lock, so the connection stays alive while the CDC slot is fetched: sock_hold(&smc->sk); read_unlock_bh(&lgr->conns_lock); /* pre-fetch buffer outside of send_lock, might sleep */ rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend); if (rc) goto err_out; The err_out label only drops the wr_tx link reference, so this early exit returns without the matching sock_put(). The second error exit is not affected, because sock_put() has already run by then. A leaked sk_refcnt means the smc_sock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down. smc_cdc_get_free_slot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smc_switch_conns() run in the first place. Restructure so there is a single sock_put() covering both outcomes, instead of adding a second one to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80987", "url": "https://ubuntu.com/security/CVE-2026-80987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Reject oversized TX buffers ntb_process_tx() handles an oversized buffer by calling tx_handler() with a NULL data pointer and returning success. ntb_netdev therefore neither frees the skb in its completion callback nor takes its enqueue error path, leaking it. Reject oversized buffers in ntb_transport_tx_enqueue() before acquiring a queue entry and return -EMSGSIZE. The caller retains ownership of the buffer, and the preceding netdev patch frees the skb when enqueue returns this permanent error.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80988", "url": "https://ubuntu.com/security/CVE-2026-80988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Fail TX enqueue when the QP link is down Commit f195a1a6fe41 (\"ntb: Drop packets when qp link is down\") meant to make ntb_transport_tx_enqueue() drop packets submitted while the QP link is down, but it only returns 0 without consuming the packet. Zero means success by this function's contract, so ntb_netdev reports NETDEV_TX_OK and forgets the skb: nothing queued it, nothing frees it, and it leaks, one skb for every transmit racing a link-down. Return -ENOLINK instead, restoring the contract that a non-zero return leaves the buffer owned by the caller. With the preceding patch, ntb_netdev frees the skb on non-retryable enqueue failures and returns NETDEV_TX_OK, so a packet racing with link-down is dropped without leaking or entering a busy retry loop.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80994", "url": "https://ubuntu.com/security/CVE-2026-80994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix flow mask use-after-free on flow deletion The commit in the Fixes tag below made so flow->mask free is scheduled via RCU right after it is removed from the flow table. The pointer stays in the flow structure and it can be accessible while in the same RCU critical section. This is done to avoid requiring ovs_mutex for the ovs_flow_free(). However, while removing the flow during processing of CMD_DEL, we do not take RCU read lock before the removal, and ovs_flow_cmd_fill_info() uses the flow->mask pointer afterwards. The RCU read lock is taken, but it's already late at that point. The comment on that line acknowledges that the lock is cosmetic and doesn't serve a real purpose. This leads to use-after-free if the RCU grace period passes between removal and the filling. It is a short race window, but it is there and can lead to a real crash in case memory allocation for the info takes a bit longer: BUG: KASAN: slab-use-after-free in __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 BUG: KASAN: slab-use-after-free in ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 Read of size 4 at addr ffff88801ee89970 by task ovs_flow_del_ec/9487 Call Trace: __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c:930 ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c:1467 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Allocated by task 9487: mask_alloc net/openvswitch/flow_table.c:967 flow_mask_insert net/openvswitch/flow_table.c:1012 ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c:1084 ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c:1086 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Freed by task 9485: rcu_free_sheaf+0x1e/0x100 mm/slub.c:5978 rcu_do_batch kernel/rcu/tree.c:2645 rcu_core+0x59c/0x10c0 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9a0 kernel/softirq.c:622 ... instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 ovs_flow_tbl_remove() must be called after the ovs_flow_cmd_fill_info() to avoid this race. This also helps with cleaning up the forced cast and the cosmetic RCU read lock. Before the commit in the Fixes tag the order did not matter as long as the flow object itself was not freed. A wider RCU critical section could be another option, but we have a GFP_KERNEL allocation in the way. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-32042.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81000", "url": "https://ubuntu.com/security/CVE-2026-81000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tun: bound receive headroom tun_get_user() uses tun->align both as skb headroom and when choosing how much packet data to keep linear. OVS can propagate an oversized headroom request from another port to TUN or TAP. When align is larger than the usable space in a one-page skb head, SKB_MAX_HEAD(align) underflows and the result becomes negative when stored in good_linear. That value later wraps when assigned to the size_t linear variable, and tun_alloc_skb() can place skb->data outside the allocated head. Bound the headroom stored by TUN to the one-page skb-head budget and the largest non-sentinel 16-bit skb header offset. Leave one linear byte for raw TUN and a complete Ethernet header for TAP, including NET_IP_ALIGN. Also pull the raw-TUN protocol byte and the TAP Ethernet header before accessing them, so these checks remain safe for nonlinear skbs supplied by other allocation paths.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81001", "url": "https://ubuntu.com/security/CVE-2026-81001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: fix use-after-free in sl_sync() slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor. priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop: \t/* Snapshot list, allow later requests */ \tlist_replace_init(&net_todo_list, &list); \t__rtnl_unlock(); \t... \t\tif (dev->priv_destructor) \t\t\tdev->priv_destructor(dev);\t/* slip_devs[i] = NULL */ \t\tif (dev->needs_free_netdev) \t\t\tfree_netdev(dev); \t\t... \t\t/* Free network device */ \t\tkobject_put(&dev->dev.kobj); So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed */ sl = netdev_priv(dev) if (sl->tty || sl->leased) /* use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860 Commit e58c19124189 (\"slip: Fix use-after-free Read in slip_open\") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it. Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: the ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81002", "url": "https://ubuntu.com/security/CVE-2026-81002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xdp: fix zero-copy frame layout xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page and advertises PAGE_SIZE as its frame size. It allows the copied frame to occupy the page tail needed by skb_shared_info and records zero headroom even when metadata separates the frame header from packet data. An AF_XDP zero-copy packet redirected through cpumap can therefore make the skb overlap skb_shared_info or place it beyond the allocated page. Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result. BUG: KASAN: slab-out-of-bounds in skb_gro_receive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skb_gro_receive (net/core/gro.c:174) udp_gro_receive (net/ipv4/udp_offload.c:812) inet_gro_receive (net/ipv4/af_inet.c:1539) dev_gro_receive (net/core/gro.c:515) gro_receive_skb (net/core/gro.c:633) cpu_map_kthread_run (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Kernel panic - not syncing: KASAN: panic_on_warn set ...", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81003", "url": "https://ubuntu.com/security/CVE-2026-81003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: filter frames in afiucv_hs_rcv() by ingress device afiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-byte name fields in the transport header alone. No check is made against the net_device the frame arrived on. This can cause a frame arriving on any netdev to be delivered to an AF_IUCV socket. Three problems follow. First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL. iucv_sock_bind() takes the classic path whenever the requested userid matches iucv_userid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucv_hs_callback_syn() for such a match inherits hs_dev = NULL and transport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable. Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections Third, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() calls sk_alloc(&init_net, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAP_NET_RAW capability valid within that namespace can send a raw ETH_P_AF_IUCV frame on its own lo device and have it matched against init_net sockets. Fix all three by skipping any socket whose hs_dev does not match the ingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hs_dev is always a device in init_net (iucv_sock_bind() scans for_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket. Note that AF_IUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81005", "url": "https://ubuntu.com/security/CVE-2026-81005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: si: Fix NULL pointer dereference after failed registration try_smi_init() allocates new_smi->si_sm and later calls ipmi_register_smi_mod(), which maps to ipmi_add_smi(). During ipmi_add_smi(), the upper IPMI message handler obtains the initial BMC device information through __bmc_get_device_id(). This can fail if the BMC does not return a successful response to the Get Device ID command. When the BMC returns a nonzero completion code, the device-id helper retries the command and eventually returns -EIO if the device ID still cannot be fetched. On this failure path, ipmi_add_smi() logs \"Unable to get the device id\" and goes to out_err_started, where it invokes the lower driver's shutdown callback. try_smi_init() then logs the returned registration failure: ipmi_si IPI0001:00: IPMI message handler: Unable to get the device id: -5 ipmi_si IPI0001:00: Unable to register device: error -5 For ipmi_si, the shutdown callback is shutdown_smi(), which cleans up the SI state machine data, frees smi_info->si_sm, and sets smi_info->si_sm and smi_info->intf to NULL. However, intf->in_shutdown is not set on this failed-registration rollback path. Therefore, the asynchronous redo_bmc_reg work item can still retry BMC device-id probing after the lower driver has already cleared its SI state machine data. In the observed case, that retry path reached start_next_msg(), which passed the NULL smi_info->si_sm pointer to the selected KCS state machine handler: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Workqueue: events redo_bmc_reg [ipmi_msghandler] RIP: start_kcs_transaction+0x2c/0x190 [ipmi_si] Call Trace: start_next_msg+0x50/0x80 [ipmi_si] check_start_timer_thread.part.9+0x3b/0x50 [ipmi_si] sender+0x69/0x80 [ipmi_si] i_ipmi_request+0x2ac/0x9d0 [ipmi_msghandler] __get_device_id.isra.29+0xaa/0x180 [ipmi_msghandler] __bmc_get_device_id+0xef/0x950 [ipmi_msghandler] redo_bmc_reg+0x52/0x60 [ipmi_msghandler] process_one_work+0x1a7/0x360 Set intf->in_shutdown on the out_err_started path before invoking the lower driver's shutdown callback. This prevents later redo_bmc_reg retries from using an interface whose lower driver state has been cleaned up, and applies the same shutdown state to other IPMI interfaces as well.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81007", "url": "https://ubuntu.com/security/CVE-2026-81007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: validate write message length ipmb_write() read message fields before validating the length byte. A zero or short write can read uninitialized stack bytes. A length smaller than the SMBus header underflows the block write length. Require a non-empty buffer and the minimum IPMB request length. Also require the length byte plus payload before parsing the message.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81008", "url": "https://ubuntu.com/security/CVE-2026-81008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: interconnect: Fix use after free in icc_get() and of_icc_get_by_index() In of_icc_get_by_index() and icc_get(), if the dynamic allocation for path->name fails via kasprintf(), the error handling path directly calls kfree(path) to free the path object and returns an error. However, prior to this point, path_find() calls path_init(), which already links the path's requests into the req_list of the respective interconnect nodes via hlist_add_head(). Directly invoking kfree(path) leaves dangling pointers in the hlist. A subsequent call to icc_get() or icc_set_bw() will traverse or modify these corrupted lists, triggering a slab use afterfree. KASAN report showing the vulnerability when reproducing via debugfs: BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0 Fix this by replacing kfree(path) with the proper teardown function, icc_put(path), which safely removes the requests from the req_list using hlist_del() and drops the provider usage references before freeing the memory. Additionally, in icc_get(), ensure that the icc_lock mutex is released prior to calling icc_put(path) to avoid a deadlock, as icc_put() internally acquires the same lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81017", "url": "https://ubuntu.com/security/CVE-2026-81017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Bound the EC-reported sensor number Each EC FIFO event carries an 8-bit sensor number (in->sensor_num). cros_ec_sensorhub_ring_handler() validates the FIFO event count, the per-read count and the ring bound, but not the sensor number, which cros_ec_sensor_ring_process_event() then uses unchecked to index sensorhub->batch_state[] - allocated with only sensorhub->sensor_num entries. A sensor number of sensor_num or larger is an out-of-bounds read and write of batch_state[]. Validate the sensor number in the ring handler, where each event is read from the EC, and drop a malformed event before it is used.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89440", "url": "https://ubuntu.com/security/CVE-2026-89440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: via-sdmmc: stop card-detect handling on probe failure request_irq() registers the SD card-detect interrupt and the probe enables it before mmc_add_host() runs. If mmc_add_host() fails, the error path only unmaps the registers and returns: the interrupt stays registered, so the handler keeps running against the host once it is freed. via_sdc_isr() dereferences sdhost and its MMIO base and schedules carddet_work, which via_sdc_card_detect() also runs against freed memory through its container_of() dereference. Add a probe-error path that disables and frees the interrupt and cancels carddet_work before unmapping. carddet_work can re-enable the device interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it again after cancelling the work. This issue was found by an in-house static analysis tool and confirmed by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89444", "url": "https://ubuntu.com/security/CVE-2026-89444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer set_attribute() populates the security area of the BIOS attribute request buffer with the current admin password via populate_security_buffer(), then dumps the whole request buffer with print_hex_dump_bytes(). This can expose the plaintext admin password in the kernel log. The same issue was fixed for the password attribute path by commit d1a196e0a6dc (\"platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data\"). Remove the remaining dump from the BIOS attribute path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93206", "url": "https://ubuntu.com/security/CVE-2026-93206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/proc: Use file_ns_capable() when checking config space read access proc_bus_pci_read() decides how much of the config space is readable based on capable(CAP_SYS_ADMIN), which checks the credentials of the task calling read(), not the credentials of the process that opened the file. The sysfs equivalent, pci_read_config(), has checked the credentials of the opening process since commit de139a339395 (\"pci: check caps from sysfs file open to read device dependent config space\"), so a privileged process can open the config space file and pass the file descriptor to an unprivileged process (for example, a process running a KVM guest with an assigned device), which can then read the entire config space. The check was subsequently routed through the LSM framework in commit 47970b1b2aa6 (\"pci: use security_capable() when checking capablities during config space read\") and converted to the dedicated helper in commit ab0fa82b2df9 (\"pci-sysfs: use proper file capability helper function\"). Thus, the two interfaces check the same capability against different credentials. Checking the credentials of the task calling read() makes the outcome depend on who reads rather than who opened, so the restriction is bypassed whenever a more privileged process reads through the descriptor. Checking the credentials recorded in file->f_cred settles the decision at open() time and ties it to the file, where it cannot change with the caller. Use file_ns_capable() to check CAP_SYS_ADMIN against the credentials in effect when the file was opened, bringing the procfs interface in line with the sysfs behaviour. As a result, a file descriptor opened by a privileged process and passed to an unprivileged one now allows the entire config space to be read through procfs, matching sysfs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89456", "url": "https://ubuntu.com/security/CVE-2026-89456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Propagate partial completion length across ERP recovery dasd_default_erp_postaction() copies the timing and device state from the finished ERP request back to the original request but drops proc_bytes. A request that was partially completed, an ESE read of a not-yet-allocated track returns fewer bytes than requested, and then recovered through the ERP chain loses its partial-completion length. __dasd_cleanup_cqr() then sees proc_bytes == 0 and completes the whole request instead of requeueing the remainder, silently returning zeroed data for the part that was never read. Carry proc_bytes over to the original request like the other per-request state.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89457", "url": "https://ubuntu.com/security/CVE-2026-89457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Guard sysfs discipline callbacks against unallocated private data Several sysfs show/store handlers call a discipline callback that dereferences device->private, either directly or through the DASD_DEFINE_ATTR() macro. During dasd_generic_set_online() the discipline is assigned before check_device() allocates device->private, so an unprivileged read of one of these world-readable attributes in that window dereferences a NULL pointer and panics. Guard the dereference inside each callback that actually touches device->private.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89458", "url": "https://ubuntu.com/security/CVE-2026-89458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Do not complete a failed ESE read as successful dasd_int_handler() completes an NRF read of an unallocated ESE track by calling ese_read() and unconditionally marking the request DASD_CQR_SUCCESS. dasd_eckd_ese_read() can return an error before it has zeroed the destination buffer: a failed sense-data parse or a current track outside the requested range both return early, leaving the destination pages untouched. The request is still completed successfully, so the block layer is handed stale / uninitialized memory instead of zeros. Check the ese_read() return value and fail the request through the normal error path instead of forcing DASD_CQR_SUCCESS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89461", "url": "https://ubuntu.com/security/CVE-2026-89461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: synchronize work cancellation on suspend max17040_work() requeues itself after every poll. cancel_delayed_work() only cancels a pending instance and does not wait for a callback that is already running. If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns. Use cancel_delayed_work_sync() to ensure polling is quiesced before suspend completes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89463", "url": "https://ubuntu.com/security/CVE-2026-89463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ucs1002: fix use-after-free on remove ucs1002 has no remove callback, so unbind runs entirely through devm. The alert IRQ handler queues the health_poll delayed work, and the work reschedules itself while the chip reports a bad-health condition. devm frees the alert IRQ, which only synchronizes the handler; it does not cancel the delayed work, which can then run after devm frees the driver data and dereference it. Register health_poll with devm_delayed_work_autocancel() before the alert IRQ is requested. devm then frees the IRQ before cancelling the work, so the handler can no longer queue it and the work is cancelled before the driver data is freed. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89464", "url": "https://ubuntu.com/security/CVE-2026-89464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: twl4030_charger: cancel workers via devm bci is devm-allocated. Two workers (bci->work and bci->current_worker) dereference it. twl4030_bci_remove() disables charging and masks interrupts. It cancels neither worker. A worker pending at remove() can run after devm frees bci. The USB transceiver comes from devm_usb_get_phy_by_node(). devm unregisters its notifier only after remove() returns. A cancel_work_sync() in remove() can then race a notifier reschedule. devm_work_autocancel() and devm_delayed_work_autocancel() avoid that. They cancel the workers during devm release, before bci is freed. The current_worker is registered first, since devm will cancel in reverse order and bci->work can reschedule current_worker. [Move comment about order into the commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89469", "url": "https://ubuntu.com/security/CVE-2026-89469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: lp8727: fix use-after-free in lp8727_release_irq() lp8727_isr_func(), the threaded IRQ handler, is the only caller that arms pchg->work via schedule_delayed_work(). lp8727_release_irq() currently cancels the work before freeing the IRQ, so an IRQ delivered in between can re-arm the work through the threaded handler. After .remove returns the devm layer frees pchg while lp8727_delayed_func() may still run and dereference it. Free the IRQ first so the threaded handler is quiesced and can no longer queue work, then cancel the delayed work to drain the final generation. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89470", "url": "https://ubuntu.com/security/CVE-2026-89470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS Currently the cros_usbpd-charger driver probe iterates based on raw charger port count returned by the embedded controller. The only check is against the number of USB PD ports which the embedded controller also defines. A malicious embedded controller could return an inaccurate port count (up to 255) resulting in an out of bounds write and subsequent memory corruption. Update helper functions in cros_usbpd-charger to limit port counts to EC_USB_PD_MAX_PORTS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89471", "url": "https://ubuntu.com/security/CVE-2026-89471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd-charger: bound the EC-reported port count cros_usbpd_charger_probe() reads two port counts from the EC and uses one of them, num_charger_ports, as the loop bound when populating a fixed-size array: \tstruct port_data *ports[EC_USB_PD_MAX_PORTS];\t/* 8 entries */ \t... \tfor (i = 0; i < charger->num_charger_ports; i++) \t\tcharger->ports[charger->num_registered_psy++] = port; Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports (from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The only validation is a sanity check that compares the two EC-reported values against each other: \tif (num_charger_ports < num_usbpd_ports || \t num_charger_ports > num_usbpd_ports + 1) \t\treturn -EPROTO; It never checks either count against EC_USB_PD_MAX_PORTS, the size of the ports[] array. A malfunctioning, malicious or compromised EC that reports num_usbpd_ports == num_charger_ports == N for any N > 8 (for example both 255) passes this check, and the loop then writes N pointers into the 8-entry ports[] array embedded in the devm_kzalloc()'d charger_data, overflowing it by up to 255 - 8 = 247 entries (~1976 bytes): a slab out-of-bounds write. Reject a port count larger than the ports[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89474", "url": "https://ubuntu.com/security/CVE-2026-89474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: drain usb_work before freeing the charger The USB-PHY notifier queues usb_work, whose handler calls power_supply_changed(bq->charger). The reset devm action only unregisters the notifier and was registered before the power supplies, so devm frees bq->charger on unwind before the action runs; a usb_work still queued can then dereference it. Register the reset action after the power supplies, so it unregisters the notifiers and drains usb_work before the supplies are released. Initialize usb_work and obtain the PHY references before registering the notifiers, so the worker cannot run before the supplies exist. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89475", "url": "https://ubuntu.com/security/CVE-2026-89475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq24257: fix use-after-free on remove The STAT-pin interrupt is devm-managed, so it stays armed until the devm cleanup that runs after remove() returns. remove() cancels bq->iilimit_setup_work while the threaded handler can still fire; that handler reschedules the work and dereferences bq, so the work runs against freed memory once devm frees bq. Make the delayed work device-managed with devm_delayed_work_autocancel(), registered before the interrupt request. The devm cleanup then releases the interrupt first, so the handler can no longer reschedule the work, and cancels the work before bq is freed. The explicit cancel_delayed_work_sync() in remove() is no longer needed and is dropped. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89476", "url": "https://ubuntu.com/security/CVE-2026-89476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix stream->outcnt underflow on duplicate RECONF responses A cached RECONF chunk may contain more than one request parameter. A duplicate response can therefore find and process the same ADD_OUT request again while another parameter is still outstanding, rolling back outcnt twice and possibly underflowing it. Track outstanding request types as bits and clear each bit after its first response. Later responses for the same request are then ignored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89477", "url": "https://ubuntu.com/security/CVE-2026-89477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix NULL deref on untransmitted RECONF completion sctp_process_strreset_outreq(), sctp_process_strreset_addstrm_out() and sctp_process_strreset_resp() complete a pending stream reconfiguration request by stopping the reconf timer on the transport it was sent on: \tt = asoc->strreset_chunk->transport; \tif (timer_delete(&t->reconf_timer)) \t\tsctp_transport_put(t); chunk->transport is assigned by __sctp_packet_append_chunk() when the chunk is appended to an outbound packet, and sctp_outq_flush_ctrl() arms the reconf timer at that same point. A request already published in asoc->strreset_chunk but not yet transmitted has neither, so completing it dereferences NULL. Two ways to get there. sctp_send_asconf_del_ip() sets asoc->src_out_of_asoc_ok without sending anything when the address being removed is the association's last one, and sctp_outq_flush_ctrl() then leaves every non-ASCONF control chunk queued; as only sctp_process_asconf_ack() clears that flag, it persists. An unprivileged process that removes such an address and then asks for a stream reset panics the kernel from softirq. A peer needs neither ASCONF nor local help: sctp_cmd_interpreter() uncorks the outqueue only once the whole packet has been processed, so a reply built while walking a RECONF chunk stays untransmitted for the rest of that walk, and one RECONF chunk carrying [Incoming SSN Reset Request, Outgoing SSN Reset Request, Response] -- or two RECONF chunks in one packet -- reaches the same dereference. KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef] RIP: 0010:timer_delete+0x67/0x110 Call Trace: sctp_process_strreset_addstrm_out (net/sctp/stream.c:832) sctp_sf_do_reconf (net/sctp/sm_statefuns.c:4212) sctp_do_sm (net/sctp/sm_sideeffect.c:1172) sctp_assoc_bh_rcv (net/sctp/associola.c:1044) sctp_rcv (net/sctp/input.c:243) ip_local_deliver (net/ipv4/ip_input.c:262) process_backlog (net/core/dev.c:6680) A response can only acknowledge a request that was actually sent, so do not match asoc->strreset_chunk while chunk->transport is NULL. Guarding the lookup covers all three completion sites.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89478", "url": "https://ubuntu.com/security/CVE-2026-89478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: drop a chunk if its transport was removed sctp_rcv() resolves the transport once per packet and leaves it in chunk->transport. The lookup reference, or the one sctp_add_backlog() takes if the socket is owned by userspace, keeps it around until the chunk has been processed. An authenticated ASCONF DEL-IP can remove it in the meantime. sctp_assoc_rm_peer() takes the transport out of the association and calls sctp_transport_free(), which tags it dead and drops the reference the association held. There is a window on both paths: the packet can sit on the socket backlog, and on the direct path the lookup completes before bh_lock_sock(). The DATA chunk in that packet puts the removed transport back into asoc->peer.last_data_from. Once the packet is done that reference goes away and the transport is freed by RCU, so the next delayed SACK carries the pointer into the SACK chunk and sctp_outq_select_transport() reads the freed transport's state. Drop the chunk in sctp_inq_push(), next to the existing rcvr->dead check. Both paths reach it with the association's socket lock held. The peer retransmits it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89479", "url": "https://ubuntu.com/security/CVE-2026-89479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stop processing a packet once its association is deleted sctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference. A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(), so the association and its transports are freed. The endpoint loop has no counterpart to the asoc->base.dead check in sctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed transport and is then passed to sctp_do_sm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context. The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctp_inq_free() releases the chunk on the association receive path. sctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89480", "url": "https://ubuntu.com/security/CVE-2026-89480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: reject a read that transferred too few bytes nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above. A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target. Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89482", "url": "https://ubuntu.com/security/CVE-2026-89482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone Commit 25e5cb780e62 (\"nvme-tcp: fix possible crash in write_zeroes processing\") established that blk_rq_payload_bytes() must not be read without first checking blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight, because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now tests the same two.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89483", "url": "https://ubuntu.com/security/CVE-2026-89483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: zero the discard fallback page nvme_setup_discard() always maps sizeof(struct nvme_dsm_range) * NVME_DSM_MAX_RANGES = 4096 bytes as the DSM payload however many ranges the command declares, because some devices ignore the 'Number of Ranges' field - the Fixes: commit records two that read past the declared ranges. A single-range discard fills only the first 16 bytes. Normally the buffer comes from kzalloc() and the other 4080 bytes are zero. When that allocation fails the code falls back to the per-controller ctrl->discard_page, which nvme_init_ctrl() obtains with alloc_page(GFP_KERNEL) and nothing ever zeroes, so those 4080 bytes are whatever the page last held and are handed to the controller. Reaching it requires the kzalloc(GFP_ATOMIC | __GFP_NOWARN) to fail, that is memory pressure; it is not remotely triggerable. Failing the allocation under KMSAN reproduces it, with the leaked tail full of vmemmap struct page pointers. The extent in the report is a partial transfer of the payload, not the whole 4096 bytes; the 16-byte boundary in it is the one declared range: [ 11.991601] BUG: KMSAN: uninit-value in dma_map_phys+0x14c8/0x1900 [ 11.991969] dma_map_phys+0x14c8/0x1900 [ 11.992220] dma_map_page_attrs+0xcf/0x130 [ 11.992485] e1000_xmit_frame+0x4099/0x6d10 [ 11.992768] dev_hard_start_xmit+0x22f/0xa80 [ 11.993068] sch_direct_xmit+0x35c/0xcb0 [ 11.993315] __dev_queue_xmit+0x1ee5/0x5eb0 [ 11.993608] ip_finish_output2+0x1903/0x1c30 [ 11.993881] ip_finish_output+0x288/0x870 [ 11.994125] ip_output+0x15e/0x400 [ 11.994365] __ip_queue_xmit+0x1e85/0x1fb0 [ 11.994639] ip_queue_xmit+0x60/0x80 [ 11.994899] __tcp_transmit_skb+0x4e71/0x5fa0 [ 11.995210] tcp_write_xmit+0x3a36/0x9160 [ 11.995533] __tcp_push_pending_frames+0xc5/0x3c0 [ 11.995854] tcp_push+0x7dc/0x840 [ 11.996076] tcp_sendmsg_locked+0x766c/0x8400 [ 11.996371] tcp_sendmsg+0x4b/0x90 [ 11.996572] inet_sendmsg+0x134/0x2a0 [ 11.996823] __sock_sendmsg+0x265/0x360 [ 11.997076] sock_sendmsg+0x100/0x1e0 [ 11.997293] nvme_tcp_try_send+0x196f/0x6370 [ 11.997605] nvme_tcp_queue_rq+0x1d54/0x20b0 [ 11.997882] blk_mq_dispatch_rq_list+0x5ee/0x2e50 [ 11.998175] __blk_mq_sched_dispatch_requests+0x16dc/0x24a0 [ 11.998539] blk_mq_sched_dispatch_requests+0x11b/0x2c0 [ 11.998865] blk_mq_run_work_fn+0x13b/0x280 [ 11.999146] process_scheduled_works+0x966/0x1ad0 [ 11.999465] worker_thread+0xe44/0x1480 [ 11.999709] kthread+0x53b/0x600 [ 11.999927] ret_from_fork+0x29f/0x7c0 [ 12.000191] ret_from_fork_asm+0x1a/0x30 [ 12.000460] [ 12.000558] Uninit was created at: [ 12.000788] __alloc_frozen_pages_noprof+0x8bf/0xd30 [ 12.001096] alloc_pages_mpol+0x1d0/0x5f0 [ 12.001326] alloc_pages_noprof+0x102/0x290 [ 12.001627] nvme_init_ctrl+0x5a3/0x9f0 [ 12.001891] nvme_tcp_create_ctrl+0xd75/0x19b0 [ 12.002170] nvmf_dev_write+0x4c68/0x4fd0 [ 12.002426] vfs_write+0x587/0x1a10 [ 12.002636] __x64_sys_write+0x207/0x4f0 [ 12.002874] x64_sys_call+0x2ff0/0x3ea0 [ 12.003123] do_syscall_64+0x147/0x3b0 [ 12.003400] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 12.003680] [ 12.003777] Bytes 16-2843 of 2844 are uninitialized [ 12.004068] Memory access of size 2844 starts at ffff888109f82000 [ 12.004412] [ 12.004530] CPU: 0 UID: 0 PID: 101 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMECTL-gf5098b6bae76 #1 PREEMPT(lazy) [ 12.005127] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 12.005762] Workqueue: kblockd blk_mq_run_work_fn [ 12.006073] ===================================================== Allocate the page with __GFP_ZERO. The single allocation site covers every use of it: bytes no discard has written stay zero, and bytes one did write hold that controller's own range list, which it has already been sent.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89485", "url": "https://ubuntu.com/security/CVE-2026-89485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: pin next file across nlm_inspect_file lock-drop nlm_traverse_files() pins the current file with f_count++ across a mutex_unlock for nlm_inspect_file(), but nothing pins the saved next pointer. A concurrent nlm_release_file() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step. Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock. Always call nlm_file_release() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlm_file_inuse(), which does a live walk of the inode lock list, rather than the cached f_locks field, so skipped files that never ran nlm_inspect_file() are evaluated correctly. Because every file in a hash bucket is now pinned and released, files skipped by the is_failover_file predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89487", "url": "https://ubuntu.com/security/CVE-2026-89487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: only skb_tx_error() a packet we are about to drop queue_userspace_packet() borrows the packet skb -- it only copies it into a private netlink message (user_skb) and does not own it; on return do_execute_actions() keeps forwarding it through the flow's remaining actions. Its error path nevertheless calls skb_tx_error(skb), which via skb_zcopy_clear() does skb_shinfo(skb)->flags &= ~SKBFL_ALL_ZEROCOPY, stripping SKBFL_SHARED_FRAG from that live skb (skb_tx_error()'s kerneldoc says \"skb must be freed afterwards\"). For a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG is what makes esp_input() skb_cow_data() before in-place AEAD; once it is stripped a later local ESP-in-UDP delivery decrypts in place over pages the sender does not own -- an unprivileged page-cache write (the \"Fragnesia\" primitive). do_execute_actions() ignores output_userspace()'s return value, so any action after a failed USERSPACE upcall inherits the stripped skb. Move the skb_tx_error() to the flow-miss drop path - the \"default\" branch of ovs_dp_process_packet()'s switch(error), before kfree_skb(). The call has been here since commit 36d5fe6a0007 (\"core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors\") but was harmless until esp_input() began relying on SKBFL_SHARED_FRAG to gate in-place decrypt; only then did stripping it on a still-forwarded skb become a page-cache write primitive.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89489", "url": "https://ubuntu.com/security/CVE-2026-89489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openrisc: fix arbitrary kernel memory access via or1k_atomic syscall sys_or1k_atomic() (syscall 244 in the \"or1k\" ABI) takes two user pointers, v1 and v2, and swaps the words they point to in hand-written assembly. l.lwz r29,0(r4) l.lwz r27,0(r5) l.sw 0(r4),r27 l.sw 0(r5),r29 The pointers are not checked with access_ok(). The four memory accesses also have no exception table entries. A caller passes a kernel address as either pointer, and the syscall reads from and writes to it directly. This gives an unprivileged process a kernel read/write primitive. It overwrites kernel data such as the sys_call_table, gaining code execution in kernel context. Check both pointers before entering the critical section. Add fixups for the four memory accesses so faults on valid but unmapped user addresses return -EFAULT. [shorne@gmail.com: fix comment style]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89490", "url": "https://ubuntu.com/security/CVE-2026-89490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix readdir position truncation on 32-bit kernels In ocfs2_dir_foreach_blk_el(), the directory cookie position is rebuilt with \tctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset; `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask \t~(sb->s_blocksize - 1) is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB block size). In the AND expression with the 64-bit `ctx->pos`, that unsigned operand is zero-extended to 64 bits per the usual arithmetic conversions, yielding 0x00000000fffff000. The high 32 bits of `ctx->pos` are silently cleared, even though directory size is allowed to exceed 4 GiB. When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position is reset back into the first 4 GiB block, making the re-validation path re-enumerate already-returned dirents indefinitely. This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken for all non-inline directories, so a directory large enough to cross 4 GiB reaches it. This is the same class of bug that commit 3dce5bb82c97 (\"exfat: Fix bitwise operation having different size\") fixed in exfat, and the fix mirrors the equivalent ext4 fix in this series. Cast the operand to loff_t so the mask is 64-bit before the AND: \tctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89491", "url": "https://ubuntu.com/security/CVE-2026-89491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cluster: don't sleep while holding o2hb_live_lock in o2hb_region_pin() Patch series \"ocfs2: cluster: o2hb_region_pin() fixes\", v2. This series fixes three related issues in o2hb_region_pin(), all are from the original implementation in commit: 58a3158a5d17 (\"ocfs2/cluster: Pin/unpin o2hb regions\"): 1) It is called with o2hb_live_lock (a spinlock) held, but the underlying configfs_depend_item() sleeps (takes inode rwsem and pins the filesystem). This triggers BUG under CONFIG_DEBUG_ATOMIC_SLEEP. 2) When called from the configfs drop_item callback, it creates a lock order inversion: parent inode_lock -> configfs root inode_lock, which can deadlock against subsystem unregistration paths taking root -> parent. 3) If pinning fails partway through o2hb_region_inc_user(), the o2hb_dependent_users counter is leaked and partially-pinned regions are never released, leaving heartbeat regions unprotected on subsequent mounts. Patch 1 reworks o2hb_region_pin() to drop o2hb_live_lock across each sleeping configfs_depend_item() call, using a config_item reference to keep the region alive while unlocked. Patch 2 adds a from_callback parameter to select configfs_depend_item_unlocked() when called from configfs context, avoiding the inode_lock nesting. Patch 3 fixes the error path in o2hb_region_inc_user() to unpin and decrement the counter on failure. This patch (of 3): o2hb_region_pin() is always called with the o2hb_live_lock spinlock held (from o2hb_region_inc_user() and o2hb_heartbeat_group_drop_item()), but it calls o2nm_depend_item() -> configfs_depend_item(), which sleeps: it pins the configfs filesystem and takes the configfs root inode rwsem. Under CONFIG_DEBUG_ATOMIC_SLEEP this triggers: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c in_atomic(): 1, ... name: mount.ocfs2 down_write configfs_depend_item o2hb_region_pin o2hb_region_inc_user o2hb_register_callback dlm_register_domain_handlers ... ocfs2_dlm_init ocfs2_mount_volume ocfs2_fill_super Rework o2hb_region_pin() to pin one region at a time with the lock dropped across the sleeping call: under o2hb_live_lock find the next eligible region and take a config_item reference to keep it alive, drop the lock, call o2nm_depend_item(), then retake the lock and record the pin. The config_item_put() is done with the lock released as well, since o2hb_region_release() also acquires o2hb_live_lock and can sleep. The region list may change while unlocked, so the scan restarts from the top after each pin. Local heartbeat still pins only the matching region; global heartbeat pins all eligible regions. The unpin path is unaffected: configfs_undepend_item() only takes a spinlock and does not sleep.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89493", "url": "https://ubuntu.com/security/CVE-2026-89493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate rl_used against rl_count in refcount block validator ocfs2_find_refcount_rec_in_rl() walks the on-disk refcount record array with: \tfor (; i < le16_to_cpu(rb->rf_records.rl_used); i++) { \t\trec = &rb->rf_records.rl_recs[i]; \t\t... rl_recs[] lives in a single metadata block (4096 bytes on the common configuration), so its real capacity is fixed by ocfs2_refcount_recs_per_rb(sb) (247 records for a 4K block with the 16-byte ocfs2_refcount_rec). rl_used and rl_count are both read directly off disk by ocfs2_validate_refcount_block() and are never checked against that capacity, nor against each other, before any refcount/reflink/CoW operation walks the array. A crafted (or corrupted) refcount block with rl_used == 0xffff makes the loop above walk far past the end of the block, dereferencing rl_recs[i] for i up to 65534. The resulting index is then handed to the sibling ocfs2_insert_refcount_rec(), whose insert-shift does: \tif (index < le16_to_cpu(rf_list->rl_used)) \t\tmemmove(&rf_list->rl_recs[index + 1], \t\t\t&rf_list->rl_recs[index], \t\t\t(le16_to_cpu(rf_list->rl_used) - index) * \t\t\t sizeof(struct ocfs2_refcount_rec)); i.e. a memmove() of up to (0xffff - index) * 16 bytes (~1 MiB) from an offset already past the block. This is reachable from an ordinary reflink (FICLONE) against a crafted/corrupted ocfs2 image: attaching an extent whose cpos sorts past every real record in the leaf forces the lookup to run off the end instead of returning early on a match. The attacker model is local: CAP_SYS_ADMIN mounting a crafted or corrupted ocfs2 image, or a raw write to the block device backing an already-mounted ocfs2 filesystem. ocfs2_validate_refcount_block() already validates the block's ECC, signature, rf_blkno and rf_fs_generation, but never rl_count/rl_used against the block's actual on-disk capacity. This is the same class of gap that ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) already closes for the sibling extent-list header, which checks both the record capacity and the \"used\" bound before any code walks h_list.l_recs[]: \tif (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) { \t\trc = ocfs2_error(...); \t\tgoto bail; \t} \tif (le16_to_cpu(eb->h_list.l_next_free_rec) > \t le16_to_cpu(eb->h_list.l_count)) { \t\trc = ocfs2_error(...); \t\tgoto bail; \t} Add the equivalent pair of checks to ocfs2_validate_refcount_block(): reject a refcount block whose rl_count does not match the fixed per-block capacity returned by ocfs2_refcount_recs_per_rb(), and reject rl_used > rl_count. Both checks are skipped when OCFS2_REFCOUNT_TREE_FL is set, because in that case the same union bytes hold an ocfs2_extent_list (rf_list), not the refcount record list (rf_records) -- that layout is already validated separately by ocfs2_validate_extent_block() when the referenced extent block is read. This mirrors the existing \"!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)\" guard used elsewhere in this file (e.g. ocfs2_get_refcount_rec()) to decide whether rf_records or rf_list is the live member of the union. With this in place, a forged rl_used/rl_count is caught at block validation time (ocfs2_error()), consistent with every other corruption check in this function, instead of driving an out-of-bounds read in ocfs2_find_refcount_rec_in_rl() and a subsequent out-of-bounds memmove() in ocfs2_insert_refcount_rec(). Verified against a crafted image on a v6.19 KASAN (KASAN_GENERIC) build: replaying the same reflink (FICLONE) reliably hit a KASAN report in __ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() before this patch, and triggers no report once ocfs2_validate_refcount_block() rejects the forged rl_used/rl_count.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89494", "url": "https://ubuntu.com/security/CVE-2026-89494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate lengths in dlm_mig_lockres_handler A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres->ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain. Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres->lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len <= DLM_LOCKID_NAME_MAX, num_locks <= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89495", "url": "https://ubuntu.com/security/CVE-2026-89495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: bound namelen in dlm_migrate_request_handler Patch series \"ocfs2/dlm: bound peer-controlled lengths in the o2dlm\". The o2dlm receive handlers trust u8 length and count fields from the wire without bounding them, so a node in a DLM domain can corrupt or panic any other node with a malformed message. Three defects: - dlm_migrate_request_handler() passes migrate->namelen unchecked to dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an o2dlm_mle slab object: a heap out-of-bounds write of up to ~215 attacker-controlled bytes. - dlm_mig_lockres_handler() passes mres->lockname_len unchecked to dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname slab object: a heap out-of-bounds write of up to ~223 bytes. - the same handler trusts mres->num_locks without checking that the message is large enough to hold that many entries, so dlm_process_recovery_data() walks mres->ml[] past the kmalloc(data_len) copy and trips a BUG_ON (an out-of-bounds read ending in a panic). The other o2dlm receive handlers already reject an oversized name; the migration and recovery handlers have omitted it since the DLM was added (see the Fixes tags). Patch 1 bounds namelen; patch 2 validates lockname_len, num_locks, and the payload size. Conforming recovery and migration traffic is unaffected. o2net authenticates peers only by the DLM domain key, so any node that has joined the domain -- including a compromised or malicious member -- can send these messages. There is no local trigger; the attacker must already be a member of the cluster. Each sink was confirmed under KASAN with an out-of-tree module mirroring it exactly -- a kmem_cache/kmalloc of the real destination size, then the same unclamped memcpy/loop: slab-out-of-bounds Write for the two writes, Read for the recovery walk, and a panic. A userspace AddressSanitizer build faults identically under -m32 and -m64. Scrubbed logs are available on request. I reported this privately to security@kernel.org and the ocfs2 maintainers on 2026-06-20; with no response after the standard embargo period I am posting the fix publicly. I have no embargo requirement. This patch (of 2): A node receiving a DLM_MIGRATE_REQUEST message trusts the peer-supplied name length (migrate->namelen) without bounding it. dlm_init_mle() then copies that many bytes into the fixed DLM_LOCKID_NAME_MAX-byte mname[] array of an o2dlm_mle slab object, so a malformed message from a cluster peer overflows the slab object by up to ~215 bytes: a heap out-of-bounds write of attacker-controlled data, reachable by any node in the domain. Reject an oversized name, the way dlm_master_request_handler() and the other o2dlm receive handlers already do; the migration handler omits the check entirely. Conforming messages are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89496", "url": "https://ubuntu.com/security/CVE-2026-89496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: always run deallocs on copy-on-write completion Local fuzzing of 6.12.94 has found the following memory leak caused by doing 'copy_file_range()' within the same filesystem: unreferenced object 0xffff88812192c980 (size 32): comm \"syz.0.49\", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................ c0 c5 92 21 81 88 ff ff 00 02 00 00 00 06 00 00 ...!............ backtrace (crc 7068d63f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] ocfs2_find_per_slot_free_list fs/ocfs2/alloc.c:6618 [inline] ocfs2_cache_block_dealloc+0x155/0x4b0 fs/ocfs2/alloc.c:6786 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:944 [inline] direct_splice_actor+0x232/0x480 fs/splice.c:1167 splice_direct_to_actor+0x4b4/0xb60 fs/splice.c:1111 do_splice_direct_actor fs/splice.c:1210 [inline] do_splice_direct+0x10f/0x1c0 fs/splice.c:1236 do_sendfile+0x430/0xbf0 fs/read_write.c:1388 unreferenced object 0xffff88812192c5c0 (size 32): comm \"syz.0.49\", pid 12095, jiffies 4294964143 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 29 70 00 00 00 00 00 00 19 00 00 00 00 00 00 00 )p.............. backtrace (crc afec850f): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ocfs2_cache_block_dealloc+0x25c/0x4b0 fs/ocfs2/alloc.c:6793 ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline] ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613 ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline] __ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985 ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237 ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825 ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138 ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098 ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline] ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline] ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349 ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline] ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470 ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline] ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451 iter_file_splice_write+0x890/0xf60 fs/splice.c:743 do_splice_from fs/splice.c:9 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89497", "url": "https://ubuntu.com/security/CVE-2026-89497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: skip leading spaces before parsing client debug masks orangefs_prepare_cdm_array() sizes each client debug keyword buffer with strcspn(cds_head, \" \"), but then parses the keyword with %s. The %s conversion skips leading whitespace, while strcspn() does not. If a client debug entry starts with a space, the allocation can be sized for an empty keyword while sscanf() copies the following non-empty token. This can write past the end of the allocated keyword buffer. Skip leading spaces before computing the keyword length so the allocation matches the string parsed by sscanf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89498", "url": "https://ubuntu.com/security/CVE-2026-89498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix double-free of trailer_buf on readdir copy failure On a readdir downcall, orangefs_devreq_write_iter() frees op->downcall.trailer_buf with vfree() when copy_from_iter_full() fails, but does not clear the pointer before goto Efault. The waiter in do_readdir() is then woken with a negative status and frees the same pointer again on its r < 0 path, causing a deterministic double-free. A client holding /dev/pvfs2-req triggers it by sending a readdir downcall whose declared trailer_size exceeds the bytes it supplies. Clear the pointer after freeing so the readdir-side vfree() becomes a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89504", "url": "https://ubuntu.com/security/CVE-2026-89504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: as3722_get_regulator_dt_data: fix premature of_node_put leaving dangling of_node pointer In as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a reference on np, which is then assigned to pdev->dev.of_node. The function immediately calls of_node_put(np), releasing the reference and leaving pdev->dev.of_node as a dangling pointer. Remove the of_node_put(np) call to let the device hold the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89508", "url": "https://ubuntu.com/security/CVE-2026-89508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Lock the handler in ucma_set_ib_path() ucma_set_ib_path() calls ucma_event_handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference: \tmutex_lock(&ctx->file->mut);\t\t\t/* file A */ \tlist_add_tail(&uevent->list, &ctx->file->event_list);\t/* file B */ \tmutex_unlock(&ctx->file->mut);\t\t\t/* file B */ \twake_up_interruptible(&ctx->file->poll_wait);\t/* file B */ A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION caller sleeps in mutex_lock(), so the list_add_tail() lands on file B's event_list while only file A's mutex is held, racing every other user of that list: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0 Read of size 8 at addr ffff888153c6a418 by task poc_corr/486 Call Trace: __list_add_valid_or_report+0x1aa/0x1c0 ucma_event_handler+0x1be/0xc00 ucma_set_ib_path+0x45e/0x710 ucma_set_option+0x32e/0x590 ucma_write+0x1f9/0x330 Allocated by task 505: ucma_write_cm_event+0x1a1/0x660 Freed by task 505: kfree+0x1da/0x4c0 ucma_get_event+0x5d5/0x7e0 The freed object is a ucma_event that another thread dequeued from file B's list under file B's mutex. File A's mut is left held on top of that, wedging its next writer in uninterruptible sleep. This path needs a bound and address-resolved cm_id, so it requires an RDMA device to be present. Take the handler lock around the call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89510", "url": "https://ubuntu.com/security/CVE-2026-89510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Cancel reg_work before freeing device on remove c4iw_uld_state_change() queues reg_work to register the RDMA device. c4iw_remove() can free ctx->dev while this work is pending or running, leaving c4iw_register_device() accessing the freed device. Cancel reg_work before removing the device. The registration work can tear down ctx->dev when registration fails, so do not unregister or deallocate it again in that case. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89511", "url": "https://ubuntu.com/security/CVE-2026-89511", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: Fix NULL pointer dereference in TPA fragment processing Under memory pressure, the qede driver encounters NULL pointer dereferences when processing TPA continuation fragments. Commit 8a8633978b84 (\"qede: Add build_skb() support.\") accidentally dropped the assignment of tpa_info->buffer.data in qede_tpa_start(). When memory pressure causes an SKB allocation failure in qede_tpa_start(), the driver sets tpa_start_fail = true and attempts to recycle the physical page later in qede_tpa_end() via qede_reuse_page(). However, because buffer.data was left uninitialized (NULL), qede_reuse_page() pushes a \"ghost\" BD (valid DMA mapping but NULL data pointer) back into the active Rx ring. The next time the hardware uses this ring slot, it passes a NULL page to qede_fill_frag_skb(), causing a kernel panic. Example crash from production system: BUG: unable to handle kernel NULL pointer dereference at 0x8 RIP: qede_fill_frag_skb+0x96/0x430 [qede] Call Trace: qede_rx_int+0xb06/0x1de0 qede_poll+0x2f4/0x6c0 __napi_poll+0x2d/0x130 Fix the root cause by restoring the tpa_info->buffer.data assignment in qede_tpa_start(), ensuring valid pages are correctly tracked and recycled. Additionally, update the stale comment for struct qede_agg_info::buffer to reflect its current usage.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89512", "url": "https://ubuntu.com/security/CVE-2026-89512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: scp: Fix device reference leak on failed lookup Make sure to drop the reference taken to the SCP device when attempting to look up its driver data before the driver has been bound. Note that holding a reference to a device does not prevent its driver data from going away.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89524", "url": "https://ubuntu.com/security/CVE-2026-89524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: clamp assoc request/response lengths before subtracting IE offsets ath6kl_cfg80211_connect_event() subtracts fixed IE offsets from assoc_req_len (-= 4) and assoc_resp_len (-= 6), both u8, with no lower bound. The aggregate check recently added to ath6kl_wmi_connect_event_rx() bounds the declared lengths from above (their sum must fit the received event), but an assoc request/response shorter than its fixed offset still underflows here: the u8 wraps to ~250, and cfg80211_connect_result() / cfg80211_roamed() then treat that wrapped value as the IE length and copy that many bytes out of the small assoc_info buffer to user space via nl80211, disclosing adjacent slab memory. Clamp both lengths to their offsets before subtracting. Found by 0sec (https://0sec.ai) using automated source analysis; the missing lower bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89525", "url": "https://ubuntu.com/security/CVE-2026-89525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: reject VAT indexes equal to the entry count UDF 1.50 virtual partition mapping uses the VAT as an array of physical block mappings. s_num_entries stores the number of entries in that array, not the highest valid index. The valid VAT indexes are therefore below s_num_entries. udf_get_pblock_virt15() currently rejects only indexes greater than s_num_entries. A crafted image can request index s_num_entries, pass the bounds check, and make the kernel read one entry past the allocated VAT table. Change the check to reject block >= s_num_entries, so the count is handled as an exclusive upper bound. A crafted UDF image reproduced this on origin/master commit 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53 with a KASAN slab-out-of-bounds report in udf_get_pblock_virt15(). Trail of Bits has a reproducer that triggers kernel panic demonstrating the bug, and can share it if needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89532", "url": "https://ubuntu.com/security/CVE-2026-89532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix pcl_for_each_segment for empty chunks When a parsed chunk list contains a chunk whose ch_segcount is zero, pcl_for_each_segment computes its inclusive upper bound as &chunk->ch_segments[ch_segcount - 1]. ch_segcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the ch_segments flex array. The loop body then walks unrelated memory at sizeof(struct svc_rdma_segment) stride until it faults. A zero-segcount chunk is reachable from the wire: xdr_check_write_chunk() only rejects segcount values greater than rc_maxpages, and pcl_alloc_write() links a freshly allocated chunk onto rc_write_pcl/rc_reply_pcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves ch_segcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svc_rdma_get_inv_rkey() iterates all four PCLs with pcl_for_each_segment and dereferences segment->rs_handle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault. xdr_check_write_list / xdr_check_reply_chunk pcl_alloc_write() chunk = pcl_alloc_chunk(...) /* ch_segcount = 0 */ list_add_tail(&chunk->ch_list, &pcl->cl_chunks) /* fill loop iterates zero times for wire segcount 0 */ svc_rdma_get_inv_rkey() pcl_for_each_chunk(rc_write_pcl) pcl_for_each_segment(segment, chunk) pos <= &ch_segments[0u - 1u] /* 0xFFFFFFFF */ segment->rs_handle /* OOB read -> GPF */ Fix by switching the macro to a half-open upper bound that uses ch_segcount directly. For ch_segcount == 0 the loop start equals the loop end and the body is skipped; for ch_segcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and net/sunrpc/xprtrdma/svc_rdma_rw.c remain correct under the new bound, so no caller changes are needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89533", "url": "https://ubuntu.com/security/CVE-2026-89533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix offset arithmetic in read_chunk_range svc_rdma_read_chunk_range() walks a Read chunk's segment list to build a sub-range starting at byte offset and spanning length bytes for a Position-Zero or Call chunk. Two arithmetic defects in the per-segment loop produce wrong DMA lengths and a u32 underflow: pcl_for_each_segment(segment, chunk) { if (offset > segment->rs_length) { offset -= segment->rs_length; continue; } dummy.rs_handle = segment->rs_handle; dummy.rs_length = min_t(u32, length, segment->rs_length) - offset; dummy.rs_offset = segment->rs_offset + offset; First, the skip predicate uses '>' instead of '>='. When offset equals the segment's full rs_length, the segment is fully consumed and should be skipped, but the loop falls through into the body. The resulting dummy.rs_length is min_t(u32, length, rs_length) - rs_length, which underflows to a near-UINT_MAX u32 when length is smaller than rs_length, or is zero otherwise. Second, the length formula subtracts offset from the min_t() result rather than from segment->rs_length before the cap. For offset > 0 the segment's residual is rs_length - offset, not rs_length, so the cap must be applied to the residual. With the current bracketing, whenever length is smaller than rs_length - offset the per-segment length becomes length - offset instead of length, silently dropping offset bytes from the rebuilt chunk. Combined with the boundary case above it also enables the u32 underflow path, which propagates a huge nr_bvec into svc_rdma_build_read_segment() and a multi-MiB kmalloc_array_node() in svc_rdma_get_rw_ctxt(). Additionally, svc_rdma_read_call_chunk() can invoke this function with length == 0 when the last Read chunk ends exactly at the end of the Call chunk. With the corrected >= predicate, every segment is skipped and the function returns the initial -EINVAL, rejecting a valid request. Return success immediately when length is zero. Also break out of the loop once length is fully consumed to avoid passing zero-length segments to svc_rdma_build_read_segment(). Fix by using '>=' so a fully-consumed segment is skipped, by moving '- offset' inside min_t() so the cap is applied to the segment's residual length, by returning success for zero-length requests, and by stopping iteration when the requested range has been consumed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89538", "url": "https://ubuntu.com/security/CVE-2026-89538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field gss_krb5_unwrap_v2() sets buf->len to a logical length, which can be much smaller than head[0].iov_len (the allocated receive-page capacity). It then calls xdr_buf_trim() with a trim length derived from the 16-bit \"extra count\" (ec) field in the Kerberos v2 token header. The ec field is authenticated by the post-decrypt memcmp() against the encrypted header copy, so a randomly-mutated value is rejected. However, any peer holding a valid GSS context can legitimately encrypt a token whose ec exceeds the plaintext length. Per RFC 4121, such a token is structurally malformed. Although xdr_buf_trim() now clamps the buf->len subtraction to avoid unsigned underflow, the buffer is still left in a semantically invalid state (zero length, inconsistent iov lengths) when ec is oversized. Reject these tokens before calling xdr_buf_trim(), giving callers a well-defined GSS_S_DEFECTIVE_TOKEN error and keeping the xdr_buf internally consistent. The wrapped blob begins at a nonzero offset -- both callers pass len as offset + opaque_len -- so buf->len still counts the offset bytes that precede the blob. Compare the trim length against the remaining wrapped segment, buf->len - offset, rather than the whole buffer; comparing against buf->len alone leaves an offset-wide window in which an oversized ec passes the test and xdr_buf_trim() cuts into the bytes ahead of the blob.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89540", "url": "https://ubuntu.com/security/CVE-2026-89540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: init gssp_lock before publishing proc entry create_use_gss_proxy_proc_entry() publishes /proc/net/rpc/use-gss-proxy via proc_create_data() before init_gssp_clnt() runs mutex_init() on sn->gssp_lock. Once the dentry is linked under proc_subdir_lock it is immediately reachable from userspace, so a write that lands in the window drives set_gssp_clnt() into mutex_lock() on a zero-initialized struct mutex. create_use_gss_proxy_proc_entry(net) proc_create_data(\"use-gss-proxy\", ...) /* dentry live */ init_gssp_clnt(sn) mutex_init(&sn->gssp_lock) /* too late */ write_gssp() set_gssp_clnt(net) mutex_lock(&sn->gssp_lock) /* uninitialized */ gssp_rpc_create(...) sn->gssp_clnt = clnt mutex_unlock(&sn->gssp_lock) The window spans only the two statements between proc_create_data() returning and init_gssp_clnt(), so a writer reaches it only if the registering thread is preempted there while another task is already opening the freshly published file. register_pernet_subsys() runs in preemptible context under pernet_ops_rwsem, so that preemption is possible, and the window widens on auth_rpcgss module load, when the proc entry is created for every live net namespace whose tasks are already running. A writer that wins the race locks a zero-filled struct mutex. On CONFIG_DEBUG_MUTEXES the missing magic value trips a \"lock used without init\" splat; on a production kernel the fast path acquires the lock via CMPXCHG(owner, 0, current). In the latter case a second writer that arrives before init_gssp_clnt() re-zeroes owner can enter set_gssp_clnt() concurrently, shut down the first writer's clnt while it is still in use, and leak the loser's clnt. Fix by initializing sn->gssp_lock in sunrpc_init_net() so its lifetime matches the sunrpc_net it lives in. sn->gssp_clnt is already NULL from the kzalloc that backs net_generic storage, so the lazy helper is no longer needed; drop init_gssp_clnt(), its prototype, and the call from create_use_gss_proxy_proc_entry(). sunrpc.ko is a build-time dependency of auth_rpcgss.ko, so sunrpc_init_net() has always run on every netns before any auth_gss pernet init can publish the proc entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89541", "url": "https://ubuntu.com/security/CVE-2026-89541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_unwrap_resp_priv length checks gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 (\"SUNRPC: svcauth_gss: enforce krb5 token minimum length\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89542", "url": "https://ubuntu.com/security/CVE-2026-89542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_krb5_unwrap_v2 against short tokens gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and ptr+6 before validating that the token is at least GSS_KRB5_TOK_HDR_LEN (16) bytes long, and its rotate_left() helper passes buf->len - base to xdr_buf_subsegment() without verifying that base <= buf->len. When a caller hands in a sub-16-byte token, or a token whose declared len leaves base past the end of the buffer, three distinct failures follow: gss_krb5_unwrap_v2(offset, len, buf) ptr = buf->head[0].iov_base + offset ec = *(ptr + 4) /* OOB read on short head */ rrc = *(ptr + 6) /* OOB read on short head */ rotate_left(offset + 16, buf, rrc) xdr_buf_subsegment(buf, &subbuf, base, buf->len - base) /* u32 wrap when base > len */ _rotate_left(&subbuf, shift) shift %= buf->len /* divide-by-zero when base == len */ After decryption, the cleanup arithmetic has the same shape: movelen = min_t(unsigned int, buf->head[0].iov_len, len); movelen -= offset + GSS_KRB5_TOK_HDR_LEN + headskip; BUG_ON(offset + GSS_KRB5_TOK_HDR_LEN + headskip + movelen > buf->head[0].iov_len); The BUG_ON re-adds the value just subtracted, so it reduces to min(A, B) > A and is permanently false; it cannot catch the unsigned underflow of movelen, which then drives a ~UINT_MAX-byte memmove(). Add four defense-in-depth guards inside the unwrap core so it is safe regardless of what its callers validate: - reject tokens with len - offset < GSS_KRB5_TOK_HDR_LEN before touching ptr+4/ptr+6; - bail from rotate_left() when buf->len <= base, covering both the underflow and zero-length cases; - return early from _rotate_left() when buf->len is zero, so the shift %= buf->len modulo cannot fault; - replace the dead BUG_ON with a live check that returns GSS_S_DEFECTIVE_TOKEN before the movelen subtraction.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89548", "url": "https://ubuntu.com/security/CVE-2026-89548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: always drain cache_cleaner before destroying a cache_detail sunrpc_destroy_cache_detail() only cancels the global cache_cleaner delayed_work when cache_list is empty. During per-netns teardown cache_list is never empty because init_net's caches remain registered, so the cancel never fires. After unlink, the caller proceeds to cache_destroy_net() which kfrees the cache_detail while cache_clean() may still hold a dangling pointer to it. The result is a use-after-free: cache_dequeue() takes cd->queue_lock on freed memory, and cache_put() dereferences cd->cache_put as a function pointer from freed slab. Drop the list_empty guard so that cancel_delayed_work_sync() always runs, ensuring any in-flight cache_clean() completes before the cache_detail is freed. Re-arm the cleaner afterwards if other caches are still registered.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89549", "url": "https://ubuntu.com/security/CVE-2026-89549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: route to a populated pool in svc_pool_for_cpu() svc_set_num_threads() spreads the requested threads evenly across the service's pools (base = nrservs / sv_nrpools). When a service runs fewer threads than it has pools -- e.g. an nfsd configured with fewer threads than the host has NUMA nodes while running in \"pernode\" or \"percpu\" mode -- the trailing pools are left with no threads at all. svc_xprt_enqueue() selects a pool from the CPU servicing the transport, queues the transport on that pool's sp_xprts, and only wakes a thread from the same pool. Each thread services exclusively its own pool, so a transport that lands on a threadless pool is enqueued on sp_xprts and never picked up: the connection hangs indefinitely. Have svc_pool_for_cpu() skip pools that currently have no threads, falling back to the next populated pool. This trades NUMA locality for a guarantee that the work is actually serviced. sp_nrthreads is only updated under the service mutex; the lockless read here is a best-effort routing hint, so annotate it with data_race().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89551", "url": "https://ubuntu.com/security/CVE-2026-89551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow xdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by walking the tail, pages, and head iovecs. Each per-section step uses min_t() so it never removes more bytes than that section holds, but the final accounting at the fix_len label subtracts the total bytes actually consumed from buf->len without any clamp: fix_len: buf->len -= (len - trim); When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches xdr_buf_trim() in exactly that state: buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip; buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip); xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip); buf->len is a small wire-derived value while the iov_lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder. Fix by clamping the decrement so buf->len bottoms out at zero: buf->len -= min_t(unsigned int, buf->len, len - trim); On the normal path where the iov_lens sum to buf->len, (len - trim) is always <= buf->len and the result is identical to before. No callers change behavior outside the underflow case.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89554", "url": "https://ubuntu.com/security/CVE-2026-89554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection. Restore subflow_req->local_id from the cookie entry, as done for the other fields.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89555", "url": "https://ubuntu.com/security/CVE-2026-89555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: reload header after pskb_may_pull() mpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop when an MPLS route has multiple nexthops. While walking the MPLS label stack, the hash routine caches hdr for the current label. After finding the bottom-of-stack label, it calls pskb_may_pull() before reading the inner IP header. If an skb is constructed with the inner IP header in nonlinear data and insufficient tailroom in the linear head, pskb_may_pull() calls pskb_expand_head() to replace the skb head and free the old one. This leaves hdr pointing to freed memory. The IPv6 path can invalidate hdr again when it performs a second pull for the larger header. The issue was found through static analysis. A reproducer sending a legal Geneve packet through a bareudp/MPLS multipath setup triggered the same KASAN report in 2 of 2 unpatched runs: BUG: KASAN: slab-use-after-free in mpls_select_multipath Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23 Call Trace: mpls_select_multipath mpls_forward __netif_receive_skb_list_core netif_receive_skb_list_internal napi_complete_done gro_cell_poll __napi_poll net_rx_action Freed by task 23: kfree pskb_expand_head __pskb_pull_tail mpls_select_multipath Reload hdr from the current skb head after each successful pull before deriving the inner IPv4 or IPv6 header pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89557", "url": "https://ubuntu.com/security/CVE-2026-89557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: do overflow check for sb->bblog_shift in super_1_load() In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 } bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c. Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller. This may avoid unnecessary check, make the badblocks API code more simple and elegant.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89559", "url": "https://ubuntu.com/security/CVE-2026-89559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Prevent integer overflow in __nd_label_validate() The on-media namespace index field nslot is a u32 read from the DIMM label storage area. __nd_label_validate() bounds it against the config area size, but sizeof_namespace_label() returns unsigned, so the product nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before the comparison. A crafted nslot passes the bound and is then used as the loop trip count in nd_label_data_init(), whose memset() walks off the end of the config_size buffer: an out-of-bounds write. The field is not trusted -- it comes from the medium, or from userspace via ND_CMD_SET_CONFIG_DATA. Evaluate the product in 64-bit so the bound check is exact; conforming labels are unaffected. The check was safe when introduced by commit 4a826c83db4e (\"libnvdimm: namespace indices: read and validate\"): it multiplied by sizeof(struct nd_namespace_label), a size_t, so on a 64-bit build the product did not wrap. Commit 564e871aa66f (\"libnvdimm, label: add v1.2 nvdimm label definitions\") narrowed it to 32 bits when the label size became a runtime value read via sizeof_namespace_label().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93226", "url": "https://ubuntu.com/security/CVE-2026-93226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU iterator to dump route exceptions rt6_nh_dump_exceptions() uses hlist_for_each_entry() to iterate over RCU-protected exception lists. The caller holds rcu_read_lock(), but does not hold rt6_exception_lock, so rt6_insert_exception() can concurrently add an entry with hlist_add_head_rcu(). KCSAN reports this race (irrelevant details omitted): ================================================================== BUG: KCSAN: data-race in rt6_insert_exception / rt6_nh_dump_exceptions write (marked) to 0xffff8a7c44c59620 of 8 bytes by interrupt on cpu 5: rt6_insert_exception+0x3bb/0x760 __ip6_rt_update_pmtu+0x4fe/0x750 ip6_sk_update_pmtu+0x19a/0x3b0 udpv6_err+0x3ff/0x800 icmpv6_notify+0x1e1/0x440 icmpv6_rcv+0x8c0/0xab0 ip6_protocol_deliver_rcu+0x616/0x840 ip6_input_finish+0xb9/0x160 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff8a7c44c59620 of 8 bytes by task 549 on cpu 14: rt6_nh_dump_exceptions+0xb3/0x260 rt6_dump_route+0x53e/0x5f0 fib6_dump_node+0x6d/0xf0 fib6_walk_continue+0x290/0x2d0 fib6_dump_table+0x28d/0x360 inet6_dump_fib+0x37d/0x620 rtnl_dumpit+0x7b/0xd0 netlink_dump+0x3ae/0x7e0 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f 4 locks held by dumper/549: ... #1: (rcu_read_lock){....}-{1:3}, at: inet6_dump_fib+0x88/0x620 #2: (&tb->tb6_lock){+.-.}-{3:3}, at: fib6_dump_table+0x1e9/0x360 #3: (rcu_read_lock){....}-{1:3}, at: rt6_dump_route+0x483/0x5f0 value changed: 0xffff8a7c44e05700 -> 0xffff8a7c45d60100 Reported by Kernel Concurrency Sanitizer on: CPU: 14 UID: 0 PID: 549 Comm: dumper Not tainted 7.2.0-rc7-virtme #38 PREEMPT(lazy) ... Use hlist_for_each_entry_rcu() to safely iterate over the exception list.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89562", "url": "https://ubuntu.com/security/CVE-2026-89562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: fix hardware header length for NBMA tunnels ip6gre_tnl_link_config_route() accumulates the lower device's hardware header length into dev->hard_header_len whenever header_ops is set. This is incorrect for both users of header_ops. ip6gretap and ip6erspan have a fixed Ethernet hardware header length. For an NBMA ip6gre tunnel, ip6gre_header() creates only the GRE header, the optional FOU or GUE header, and the outer IPv6 header. The lower device header is headroom needed later, not part of the tunnel device's hardware header. Keep the lower device header in needed_headroom. Set hard_header_len to the tunnel header length only for ARPHRD_IP6GRE devices with header_ops, and leave the fixed Ethernet header length unchanged for tap and erspan devices.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89563", "url": "https://ubuntu.com/security/CVE-2026-89563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit() ip6_tnl_xmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skb_realloc_headroom(), copies skb->sk ownership, consumes the original skb, and then continues processing with the replacement skb kept only in its local variable. That is safe only if the helper cannot fail afterwards. But this helper still has post-reallocation error exits. collect_md tunnels reject non-NONE encap after the replacement, and ip6_tnl_encap() can also fail later. In those cases the helper returns an error to its callers while the caller still only has the original skb pointer. Both ip6_tnl_start_xmit() and the IPv6 GRE paths free the caller skb on error, so they can end up freeing an skb that ip6_tnl_xmit() already consumed. Use skb_cow_head() instead. It provides the required headroom and writability without privately replacing the caller-owned skb, so later error returns cannot leave callers with a stale pointer. The Ethernet users, ip6gretap and ip6erspan, clear IFF_TX_SKB_SHARING and already call skb_cow_head() before entering ip6_tnl_xmit(). They do not rely on the removed skb_shared() reallocation. This also makes the IPv6 tunnel path consistent with ip_tunnel_xmit().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89569", "url": "https://ubuntu.com/security/CVE-2026-89569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: serialize security confirmation handling rfcomm_security_cfm() looks up a session on session_list and then walks its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown uses rfcomm_mutex, krfcommd can close and free the same session and DLCs concurrently: hci_rx_work krfcommd ----------- --------- rfcomm_session_get() rfcomm_lock() rfcomm_session_close() rfcomm_dlc_unlink() rfcomm_session_del() kfree(s) rfcomm_unlock() walk s->dlcs The callback can then read a freed session list head and touch freed DLCs while updating their flags or timers. Serialize the session lookup and DLC traversal in rfcomm_security_cfm() with rfcomm_mutex. This matches the existing RFCOMM session lifetime rules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink() from tearing the objects down while the callback is using them. KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440 Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89 Workqueue: hci0 hci_rx_work Call Trace: rfcomm_security_cfm+0x41c/0x440 hci_encrypt_cfm+0x139/0x590 hci_encrypt_change_evt+0x37b/0xc40 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 69: rfcomm_session_add+0x9e/0x2f0 rfcomm_run+0x44b/0x41e0 Freed by task 69: kfree+0x131/0x3c0 rfcomm_session_del+0x188/0x220 rfcomm_run+0x1985/0x41e0", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89573", "url": "https://ubuntu.com/security/CVE-2026-89573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm array: reject an array block whose value size is not the caller's array_block_check() can only compare the header against itself, so a block with value_size 4 and max_entries 1018 is internally consistent and passes. dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and the roots for both live in the superblock. Point the mappings root at a hint block and __load_mappings() walks it through an info whose value size is 8, so element_at() strides 8 bytes over 4-byte entries and reaches offset 8160 of a 4096-byte block. get_ablock() and __shadow_ablock() are the two places that hold the block and the caller at once. Reject there when the two value sizes disagree. Arrays only ever read their own blocks, so this fires on crafted metadata only.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89575", "url": "https://ubuntu.com/security/CVE-2026-89575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm raid1: reserve space for NUL-terminator in build_constructor_string() Reserve space for the termination NUL after the maximum 20 decimal digits of a long long value to avoid buffer overflow in sprintf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89576", "url": "https://ubuntu.com/security/CVE-2026-89576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-era: fix shadowed superblock leak on take-snap failure metadata_take_snap() bumps the live superblock refcount and then dm_tm_shadow_block() allocates a new block for the metadata snapshot. If the subsequent dm_sm_inc_block() of writeset_tree_root or era_array_root fails, the function only unlocks the clone and returns. The newly allocated shadow block is never returned to the metadata space map, so each failed take-snap permanently leaks one metadata block. Free the clone with dm_sm_dec_block() on those error paths, matching the final step of metadata_drop_snap().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89582", "url": "https://ubuntu.com/security/CVE-2026-89582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix double free in bnx2x_init_firmware() error path bnx2x_init_firmware() frees bp->init_ops, bp->init_data and bp->init_ops_offsets in its error path without setting them to NULL. The cleanup function bnx2x_release_firmware() frees the same three pointers unconditionally, so if init_firmware fails and release_firmware is later called (e.g. from __bnx2x_remove or through the function state machine), all three are freed a second time. Set each pointer to NULL after kfree() in the error path so that the subsequent kfree(NULL) in bnx2x_release_firmware() is a safe no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89585", "url": "https://ubuntu.com/security/CVE-2026-89585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: auxdisplay: charlcd: cancel backlight work on registration failure With CONFIG_CHARLCD_BL_FLASH, charlcd_init() schedules bl_work before charlcd_register() calls misc_register(). If registration fails, the caller frees the charlcd object while delayed work still contains its address. Add charlcd_deinit() to cancel the delayed work and turn the backlight off. Use it for both registration rollback and normal unregistration.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89586", "url": "https://ubuntu.com/security/CVE-2026-89586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes ata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the UNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command. The TRIM descriptor is built by ata_format_dsm_trim_descr() into the 2048-byte ata_scsi_rbuf staging buffer, and the number of bytes copied is compared against the logical sector size by the caller: \tsize = ata_format_dsm_trim_descr(scmd, trmax, block, n_block); \tif (size != len)\t\t/* len == sdp->sector_size */ \t\tgoto invalid_param_len; ata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE (2048). On a device whose logical sector size exceeds that (e.g. a 4Kn device, where sector_size == 4096) the function can never return more than 2048, while the caller expects it to return sector_size. The comparison therefore always fails, so every TRIM is rejected with \"Parameter list length error\" and WARN_ON() splats on each attempt. TRIM / discard is thus completely broken on such devices. The descriptor was incorrectly sized from the logical sector size. A DSM TRIM payload is a list of 512-byte pages, each holding up to ATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical sector size. The Block Limits VPD page already advertises a single such page as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical blocks), so the block layer never sends a request that needs more than one page. Emit exactly one 512-byte page, independent of the logical sector size, and transfer only that page (COUNT == 1). For a 512-byte-sector device this is unchanged; devices with larger logical sectors now work instead of failing every TRIM.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89594", "url": "https://ubuntu.com/security/CVE-2026-89594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device The OMAP SSI driver uses a synthetic HSI controller device allocated via hsi_alloc_controller(), which does not go through the normal OF/platform device initialization path. As a result, the embedded struct device does not have a DMA mask initialized by default. After recent DMA API hardening changes, dma_map_sg() and related helpers now require a valid dma_mask to be present, otherwise the driver may crash or trigger warnings when attempting DMA mapping operations. Fix this by explicitly initializing the DMA mask for the SSI controller device and setting a 32-bit DMA mask, which matches the hardware capabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89596", "url": "https://ubuntu.com/security/CVE-2026-89596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix off-by-one when saving/restoring non-PCI config space nv_suspend() and nv_resume() walk the non-PCI configuration space with \tfor (i = 0; i <= np->register_size/sizeof(u32); i++) which runs one iteration too many. saved_config_space is declared as \tu32 saved_config_space[NV_PCI_REGSZ_MAX/4]; and NV_PCI_REGSZ_VER3 is equal to NV_PCI_REGSZ_MAX (0x604), so on a VER3 device register_size/sizeof(u32) is exactly the array length and the last iteration addresses one element past the end. The element it lands on is np->name_rx[0..3]: saved_config_space[] is followed immediately by char name_rx[IFNAMSIZ + 3], and char needs no padding. Nothing observable is corrupted by that, because nv_request_irq() rewrites name_rx with sprintf() before it is ever passed to request_irq(). The bug is the out-of-bounds access itself, which UBSAN reports and which CONFIG_UBSAN_TRAP=y turns into a trap that aborts the running kernel code, plus an MMIO read and, on resume, an MMIO writel() to base + 0x604, one dword past the range the driver mapped: \tnp->base = ioremap(addr, np->register_size); VER1 and VER2 devices stay inside the array, but they too get the stray read and the stray write one dword past their own window. Caught by UBSAN on an Apple Macmini3,1 (MCP79) during a deep S3 cycle. The splat below is trimmed: the build path in the file name, the CPU and taint lines, the Workqueue line, the \"?\" hint frames, and the frames below device_suspend are all cut. The kernel was tainted, with an out-of-tree nouveau and CPU_OUT_OF_SPEC; forcedeth itself was the stock module. UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c:6225:25 index 385 is out of range for type 'u32 [385]' Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... Both loops are hit. UBSAN reports each source location only once per module load (__ubsan_handle_out_of_bounds() calls suppress_report(), which does test_and_set_bit(REPORTED_BIT, ...) on the struct source_location), so the two splats land in the first S3 cycle after the module is loaded and later cycles are silent even though the access still runs off the end every time. In that first cycle line 6225 is reported from pci_pm_suspend and line 6240 from pci_pm_resume. The same off-by-one was fixed in nv_get_regs() by commit ba9aa134287f (\"forcedeth: fix buffer overflow\") in 2012; these two loops were missed. The suspend and resume side was reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix, but the patch was attached rather than sent inline and the thread ended there. Use < instead of <=, which saves and restores exactly register_size bytes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89597", "url": "https://ubuntu.com/security/CVE-2026-89597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: unregister connector callback on init failure uvesafb_init() registers the v86d connector callback before registering the platform driver. If platform_driver_register() fails, the function returns the error directly and leaves the connector callback registered. The later platform-device failure path already unregisters the callback. Add the same cleanup before the final return when platform-driver registration fails. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89599", "url": "https://ubuntu.com/security/CVE-2026-89599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: panel-dsi-cm: initialize lock before registering display dsicm_probe() registers the display before initializing ddata->lock. Once omapdss_register_display() publishes the display, another consumer can reach a dsicm callback that takes this mutex while it is still uninitialized. Initialize the mutex before registering the display so the published callbacks always see a valid lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89605", "url": "https://ubuntu.com/security/CVE-2026-89605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: release message context on send failure ecryptfs_send_message_locked() moves a message context from the free list to the allocated list before sending the request to the userspace daemon. If ecryptfs_send_miscdev() fails, the context is left on the allocated list and cannot be reused. Move it back to the free list on failure and clear the caller's pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89606", "url": "https://ubuntu.com/security/CVE-2026-89606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject too-small tag 70 packets ecryptfs_parse_tag_70_packet() subtracts fixed metadata fields from the parsed packet body size to derive the encrypted filename size. A malformed packet with a body smaller than those fixed fields can underflow that size calculation. Reject tag 70 packets before the subtraction unless the body contains the signature, cipher code, and at least one byte of encrypted filename data.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89607", "url": "https://ubuntu.com/security/CVE-2026-89607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key() sets decrypted_key_size = encrypted_key_size and performs two out-of-bounds writes: 1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into decrypted_key[64] via scatterlist, overflowing into the parent ecryptfs_auth_tok struct. 2. memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes into crypt_stat->key[64], corrupting root_iv, keysig_list, and mutexes in ecryptfs_crypt_stat. Only AES-192 (cipher code 0x08) enables this because it sets crypt_stat->key_size = 24 independently of encrypted_key_size, allowing crypto_skcipher_setkey() to succeed while encrypted_key_size exceeds ECRYPTFS_MAX_KEY_BYTES. The PKI decryption path (parse_tag_65_packet) already validates decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path omits this check. Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also protects the 512-byte encrypted_key[] buffer, so the former 512-byte check is removed as redundant. [tyhicks: Adjust the code comment to refer to macros representing the buffer sizes rather than mentioning the buffer size values since they may change in the future]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89608", "url": "https://ubuntu.com/security/CVE-2026-89608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: pass packet set buffer size to parser ecryptfs_parse_packet_set() receives a pointer into the file header, but it calculates the remaining packet buffer size from PAGE_SIZE - 8. For version 1 headers the packet set starts later in the header, so this can overstate the available buffer. Pass the actual packet set buffer length from the caller and calculate per-packet limits from the remaining bytes in that buffer. Recompute the remaining length after consuming a tag 3 packet before parsing the following tag 11 packet.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89609", "url": "https://ubuntu.com/security/CVE-2026-89609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: hold msg ctx list lock when cleaning daemon queue ecryptfs_exorcise_daemon() drops queued messages from a dying daemon without holding ecryptfs_msg_ctx_lists_mux, but ecryptfs_msg_ctx_alloc_to_free() requires that lock. Take the list lock while moving the queued contexts back to the free list to avoid racing with other global msg ctx list users.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89615", "url": "https://ubuntu.com/security/CVE-2026-89615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound page_lcns[] index by the log record The copy_lcns loop and the redo shorten loop index page_lcns[] at j + i, where i runs up to the log record's lcns_follow. That count is checked only against the record's own length, not the target entry, so check_dp_table() (which validates the entry's lcns_follow) does not cover it: the copy_lcns entry may even be freshly allocated after that check, and find_dp() bounds j but not i. A crafted record thus overflows page_lcns[] of an otherwise valid entry. Add dp_range_ok() and reject, before each loop, any record whose run does not fit the entry. These are the only two page_lcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded. [almaz.alexandrovich@paragon-software.com: original patch contained changes to the problem already handled, applied partly]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89616", "url": "https://ubuntu.com/security/CVE-2026-89616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame() ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target pages and then trusts decompress_lznt()'s return value: unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem, frame_size); if ((ssize_t)unc_size < 0) err = unc_size; else if (!unc_size || unc_size > frame_size) err = -EINVAL; decompress_lznt() stops as soon as the compressed stream is exhausted (e.g. a zero chunk header) and returns the number of bytes it actually wrote, which may be far less than frame_size. The bytes between unc_size and frame_size are never written. The only memset() that follows zeroes the region beyond i_valid; when the frame lies entirely within the file's valid size that memset() does not run, so the gap retains whatever was in the just-vmapped pages. All pages are then marked uptodate and returned to userspace, disclosing uninitialized (recently-freed) kernel page memory. A crafted compressed file whose stream decompresses to only a few bytes leaks the remainder of every frame on a plain read(2), which is enough to recover kernel pointers and defeat KASLR. Zero the [unc_size, frame_size) tail immediately after a successful LZNT decompress so the remainder reads back as zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89617", "url": "https://ubuntu.com/security/CVE-2026-89617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate dirty page table on log replay Each DIR_PAGE_ENTRY ends in a page_lcns[] array whose length is the on-disk lcns_follow field. check_rstbl() validates the table bookkeeping but never checks that this array fits in the entry, so a crafted lcns_follow lets the v0->v1 conversion memmove and later replay passes run off the entry. Add check_dp_table() to reject, right after check_rstbl(), any entry larger than its size claims via struct_size() (the same expression used to allocate these entries, so the check is overflow-safe by construction). All consumers can then trust lcns_follow as the real capacity. This covers every page_lcns[] access whose index is bounded by the entry itself (the conversion memmove, the HotFix store via find_dp(), and the self-bounded scan loops). Accesses whose index comes from the log record need a separate bound and are handled in a follow-up patch.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89621", "url": "https://ubuntu.com/security/CVE-2026-89621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: mcp2221: validate report size in mcp2221_raw_event() mcp2221_raw_event() never validates the size of incoming HID reports. In the MCP2221_I2C_GET_DATA path it trusts the device-supplied data[3] as the copy length without checking that 4 + data[3] bytes actually exist in the received report. A malicious or misbehaving USB device can send a short report with a large data[3], causing the memcpy to read past the valid report data in the HID transfer buffer and leak uninitialized kernel memory back to userspace through the I2C/SMBus read path. Add a minimum size check at entry and validate that the source range fits within the received report before the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89626", "url": "https://ubuntu.com/security/CVE-2026-89626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix field sysfs group cleanup on failure hid_sensor_custom_add_attributes() creates one sysfs group for each custom sensor field. If sysfs_create_group() fails after some groups have already been created, the function returns the error without removing the previously created groups. Add a local unwind path to remove the groups that were already created. With enable_sensor exposed only after the field attributes are ready, this path can free sensor_inst->fields without leaving enable_sensor able to access pointers into that array.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89627", "url": "https://ubuntu.com/security/CVE-2026-89627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: free buffered reports when destroying device roccat_report_event() duplicates each report with kmemdup() and stores the allocation in a circular-buffer slot. The allocation is released only when that slot is reused. The device destruction paths free struct roccat_device without releasing reports still stored in cbuf[]. This makes those allocations unreachable and leaks up to ROCCAT_CBUF_SIZE report buffers per device. Add a small destructor that frees every buffered report before freeing the device, and use it in both paths that can destroy a registered device.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89628", "url": "https://ubuntu.com/security/CVE-2026-89628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: picolcd: clamp eeprom debugfs read to bytes actually received picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte supplied by the device in its REPORT_EE_DATA reply -- clamped only to the caller's read() count: \tret = resp->raw_data[2]; \tif (ret > s) \t\tret = s; \tif (copy_to_user(u, resp->raw_data+3, ret)) It never checks resp->raw_size, the number of bytes picolcd_raw_event() actually copied into the 64-byte raw_data[] of the kmalloc'd struct picolcd_pending. A device (or a spoofed picoLCD) returning a length byte of 0xff, read with a count >= 255, makes copy_to_user() read past raw_data[] into adjacent slab memory and return it to userspace through the debugfs \"eeprom\" file: \tBUG: KASAN: slab-out-of-bounds in _copy_to_user \tRead of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd] The debug-dump path in the same file already validates the device length byte against the received size before trusting it; this read does not. The file is created S_IRUSR (root-only) and a crafted device is needed, so it is neither unprivileged- nor remotely-triggerable. Clamp the copy length to resp->raw_size - 3 (the payload actually received, minus the 3-byte header), floored at 0 for short replies.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89643", "url": "https://ubuntu.com/security/CVE-2026-89643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: avoid dropping live tree ref on fsnotify rule autoremove audit_del_rule() is used for both netlink deletion templates and internal fsnotify autoremove. The former passes a parsed template which owns a temporary tree reference; the latter passes the installed entry itself. The unconditional audit_put_tree() at the end of audit_del_rule() assumes the template case. For mixed AUDIT_DIR plus AUDIT_EXE rules, an fsnotify autoremove event therefore drops the installed rule's live tree reference. Repeating this across rules sharing the same tree can free the tree while another rule still references it, and a later autoremove dereferences the freed pathname while comparing rules. Move the temporary-tree put to audit_rule_change(), the caller that owns deletion templates. Keep it in the AUDIT_DEL_RULE cleanup so both successful deletion and -ENOENT still release the parser-owned tree. [PM: dropped unnecessary comment for line length reasons]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89649", "url": "https://ubuntu.com/security/CVE-2026-89649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound xattr value length in __build_xattrs() __build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare \"p += len\" and no ceph_decode_need() check that \"len\" bytes remain in the blob. For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob. The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space. Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89650", "url": "https://ubuntu.com/security/CVE-2026-89650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound num_export_targets array for mds info v2/v3 ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from each per-mds info record and advances the decode cursor by num_export_targets * sizeof(u32) without first checking that many bytes remain. The only upper-bound check that catches a runaway cursor (*p > info_end) is gated on info_v >= 4, because info_end is left NULL for info_v 2 and 3. When the monitor sends an MDS map whose per-mds info version is 2 or 3 with an oversized num_export_targets, the cursor moves past the message front buffer and the later export-targets loop calls the unchecked ceph_decode_32() on out-of-bounds memory. A kernel client processes CEPH_MSG_MDS_MAP from its monitor session (net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an on-path attacker on an unsigned/unencrypted messenger session, can therefore drive an out-of-bounds read in the client kernel; on x86_64 with KASAN it is reported as a slab-out-of-bounds read in ceph_mdsmap_decode(). The decoded values land in the internal info->export_targets[] array, so the consequence is a kernel out-of-bounds read, not an information leak to the attacker. Impact: a malicious or compromised Ceph monitor sending an MDS map with a per-mds info version of 2 or 3 and an oversized num_export_targets field triggers an out-of-bounds read in the CephFS client kernel. Add a ceph_decode_need() for the export-targets array before advancing the cursor, so the bound is enforced for every info_v >= 2, not only info_v >= 4. This mirrors the count-then-need idiom already used for m_data_pg_pools later in the same function. Compute the export-targets byte count with size_mul() and reuse that checked length when advancing the cursor, so the attacker-controlled num_export_targets multiplication fails closed on overflow rather than relying on the later kcalloc() guard.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89653", "url": "https://ubuntu.com/security/CVE-2026-89653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode MDSMap export_targets entries are monitor controlled. check_new_map() uses each entry as a bit number in a fixed stack bitmap, so a rank outside the protocol namespace can make set_bit() write past the end of the array. Reject ranks outside CEPH_MAX_MDS while decoding the map. Do not validate against possible_max_rank here because maps may legitimately reference ranks beyond a temporarily reduced max_mds.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89655", "url": "https://ubuntu.com/security/CVE-2026-89655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock list_for_each_entry() iterates ci->i_cap_flush_list but drops i_ceph_lock to send cap messages. During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid <= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock. When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next on freed memory. The race timeline: __kick_flushing_caps() handle_cap_flush_ack() ----------------------- ----------------------- holds i_ceph_lock <--- iterates to cf (tid=10) prepares FLUSH message drops i_ceph_lock <--- __send_cap() ── FLUSH(tid=10) \t MDS sends FLUSH_ACK(tid=10) ---> acquires i_ceph_lock cf->tid(10) <= flush_tid(10), detaches cf from i_cap_flush_list drops i_ceph_lock ceph_free_cap_flush(cf) <- frees it! acquires i_ceph_lock <--- for-loop advances: cf = list_next_entry(cf, i_list) -- UAF on freed cf->i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS may respond with FLUSH_ACK quickly enough that handle_cap_flush_ack() frees cf before __kick_flushing_caps can finish the iteration. Fix by converting to a manual while loop: save the next pointer under i_ceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89656", "url": "https://ubuntu.com/security/CVE-2026-89656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject buckets with mismatched CRUSH ids crush_decode() stores bucket data by array slot, and the mapper later derives the per-bucket workspace index from the decoded bucket id. A malformed map can therefore make one bucket reuse another bucket's workspace by encoding an id different from -1 - slot. For uniform buckets, the second replica selection expands the source bucket's permutation into that aliased workspace buffer. If the source bucket is larger than the aliased bucket, the write runs past the smaller permutation array and can escape the kvmalloc'd CRUSH workspace. KASAN reports a slab OOB write of 4 bytes in bucket_perm_choose(). Reject buckets whose encoded id does not match their array slot. Valid CRUSH maps already use the canonical negative id corresponding to the bucket slot, so this restores the invariant expected by work->work[-1 - in->id] without changing valid map behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89662", "url": "https://ubuntu.com/security/CVE-2026-89662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent lock owner use-after-free during client teardown __destroy_client() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on cl_ownerstr_hashtbl. client_has_state() does not count a bare owner, so DESTROY_CLIENTID can reach __destroy_client() with such owners present. __destroy_client() then walks the table, calling remove_blocked_locks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flc_owner. The per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently of client state. The two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks(). nfsd4_release_lockowner() holds a reference across the same call; __destroy_client() does not. Hold cl_lock across the walk, taking a reference and unhashing each owner, then drop it before remove_blocked_locks() and nfs4_put_stateowner(), which take blocked_locks_lock and cl_lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89663", "url": "https://ubuntu.com/security/CVE-2026-89663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: revoke copy-notify stateids before dropping their reference Copy-notify stateids live in the s2s_cp_stateids IDR and on their parent stid's sc_cp_list, pinned by a single membership reference. _free_cpntf_state_locked() only unlinks an entry once its refcount reaches zero, so any revoke path that runs while a concurrent find_cpntf_state()/manage_cpntf_state() holder has elevated cs_count drops the reference without unlinking, leaving the entry discoverable with its membership reference already consumed. A second revoke or a laundromat tick then frees it while the reader still holds the pointer -- a KASAN-detectable use-after-free at the reader's nfs4_put_cpntf_state(). This affected all three revoke paths: - The parent-stid drain (nfs4_free_cpntf_statelist()) repeatedly called _free_cpntf_state_locked() on the first list entry; a holder that had bumped cs_count made it return early, so the next iteration re-decremented and burned the holder's reference. - OFFLOAD_CANCEL (manage_cpntf_state()) and laundromat expiry likewise used _free_cpntf_state_locked() and could drop 2->1 without unlinking. Add revoke_cpntf_state_locked(), which unhashes the entry from the IDR and sc_cp_list first (deferring the final free to any holder), and use it from all three revoke paths. The drain now walks with list_for_each_entry_safe() and revokes each entry unconditionally, so it terminates in one pass per entry regardless of cs_count. The unhash is gated on !list_empty(&cps->cp_list); the idr_remove() gate matters because idr_alloc_cyclic() may have recycled the so_id by then. Keep _free_cpntf_state_locked() for the reference-holder put path only, where a concurrent revoke may already have unlinked the entry (its list_del_init() then a no-op).", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89665", "url": "https://ubuntu.com/security/CVE-2026-89665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE The NFSv2 sattr decoder converts the wire useconds to nanoseconds in svcxdr_decode_sattr(): \tiap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC; tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds value such as 4294968 wraps to tv_nsec == 704. The corruption therefore happens during decode, before any proc function can inspect the value, and a later range check on tv_nsec would see an in-range result and accept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply. NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return for a malformed time argument, and the check cannot move to the proc function the way the v3/v4 nsec range checks do. Guard the raw useconds before the multiplication and reject values greater than 1000000. useconds == 1000000 is kept: it is the Sun convention for \"set to the current server time\", and the in-tree Linux NFSv2 client emits it in both the atime and the mtime field for a plain touch / utimes(file, NULL) (see encode_sattr() and xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000 would turn that common operation into a hard decode failure for both SETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap on ILP32, so the Sun convention value passes through safely. Only genuinely out-of-range values (> 1000000) are rejected. The atime and mtime guards are therefore symmetric. The decoder only applied the Sun convention in the mtime block, which clears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a client puts 1000000 in the atime field but not in the mtime field, the atime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET set, so the bogus value reached the filesystem. Apply the convention in the atime block as well, clearing ATTR_ATIME_SET so the server uses its current time and ignores the value. Only ATTR_ATIME_SET is cleared there. The mtime block keeps its existing behavior, where 1000000 means \"set both atime and mtime to now\". [ cel: various tweaks, addenda, and clean-ups ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89669", "url": "https://ubuntu.com/security/CVE-2026-89669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: initialize copy-notify stateid before publishing it nfsd4_copy_notify() finished initializing the cpntf state after nfs4_alloc_init_cpntf_state() had already linked it into the s2s_cp_stateids IDR and the parent's sc_cp_list, with cs_count == 1 (the membership reference) and none held for the caller. A racing OFFLOAD_CANCEL (crafted cl_id == nn->s2s_cp_cl_id plus the guessable so_id) could reach manage_cpntf_state() and free the entry, turning the caller's subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid writes into use-after-free. The owning clientid was also only recorded after publication, so it could not gate an ownership check in that window. Record cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state() before nfs4_init_cp_state() publishes the entry, and return it with an extra reference. The caller reads the stateid under that reference and drops it with nfs4_put_cpntf_state(); on a late error the laundromat reaps the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89673", "url": "https://ubuntu.com/security/CVE-2026-89673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo nfsd4_ff_encode_getdeviceinfo() computes the da_addr_body reservation as 16 + netid_len + addr_len, but the subsequent xdr_encode_opaque() calls emit 8 + round_up(netid_len, 4) + round_up(addr_len, 4) bytes. The mismatch means the declared da_addr_body length exceeds the actual encoded data by 2-8 bytes on every flexfile GETDEVICEINFO reply, leaking stale reply-page content to the client and mis-aligning the subsequent version list decode. Use xdr_align_size() for each string length to match what xdr_encode_opaque() actually writes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89674", "url": "https://ubuntu.com/security/CVE-2026-89674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client: - fh_len doesn't account for XDR padding on the file handle data - uid and gid lengths use \"8 + len\" but xdr_encode_opaque() actually writes \"4 + xdr_align_size(len)\" bytes - ds_len omits the flags and stats_collect_hint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client. Fix this by breaking out every encoded field explicitly in the ds_len calculation, using xdr_align_size() for all variable-length opaque fields, and correcting the header constants.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89684", "url": "https://ubuntu.com/security/CVE-2026-89684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix cpntf publish race in nfs4_init_cp_state nfs4_alloc_init_cpntf_state() published the new cpntf entry into the s2s_cp_stateids IDR (with cs_type set) in one s2s_cp_lock section, then took the lock again to list_add() it onto p_stid->sc_cp_list. In the gap the entry is reachable by so_id but cp_list is still {NULL,NULL} from kzalloc. A racing OFFLOAD_CANCEL (so_id is echoed to the client as cnr_stateid, so any NFSv4.2 client can drive it) reaches manage_cpntf_state() -> _free_cpntf_state_locked() and does list_del() on the zeroed list_head, oopsing the server. Fold the cs_type assignment and the list_add() into the same critical section as idr_alloc_cyclic(), so a concurrent lookup either misses the entry or sees a fully linked cp_list. INIT_LIST_HEAD() the entry after allocation and switch _free_cpntf_state_locked() to list_del_init() so a stale unlink is a no-op. nfs4_init_copy_state() passes NULL p_stid and skips the list_add, preserving NFS4_COPY_STID semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89694", "url": "https://ubuntu.com/security/CVE-2026-89694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: check client ownership when cancelling a copy-notify stateid On the OFFLOAD_CANCEL path (clp != NULL), manage_cpntf_state() freed the target cpntf state without checking ownership. The lookup key st->si_opaque.so_id is allocated cyclically (guessable) and the embedded clientid is the fixed per-net nn->s2s_cp_cl_id, so any authenticated NFSv4.2 client could cancel and free another client's copy-notify stateid. Compare the creating clientid recorded in state->cp_p_clid against the requesting client's cl_clientid and return nfserr_bad_stateid on a mismatch instead of freeing the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89696", "url": "https://ubuntu.com/security/CVE-2026-89696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref When CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return success with fh_dentry and fh_export both NULL if fh_verify() returns nfserr_stale and putfh->no_verify is true. The NFSD4_FH_FOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserr_nofilehandle check -- it does not prevent subsequent ops from running with a NULL fh_dentry. A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes check_if_stalefh_allowed() to set no_verify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fh_want_write() which dereferences fh_export->ex_path.mnt without calling fh_verify() first, causing a NULL pointer dereference in the nfsd kthread. Fix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set and fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow) and ops with ALLOWED_WITHOUT_FH (which don't need a resolved filehandle) may proceed. All other ops receive nfserr_stale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERR_STALE returned at that point.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89697", "url": "https://ubuntu.com/security/CVE-2026-89697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: add fh_want_write() for early-verified SETATTR in nfsd_proc_setattr() The BOTH_TIME_SET branch calls fh_verify() early so setattr_prepare() can inspect the dentry. This causes nfsd_setattr() to skip fh_want_write(), so notify_change() runs without a mount write reference. Add the missing fh_want_write() call after the early fh_verify().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89699", "url": "https://ubuntu.com/security/CVE-2026-89699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: validate symlink target length in NFSv4 CREATE nfsd4_decode_create() accepts an unbounded cr_datalen from the wire for NF4LNK symlink targets, allowing a client to force a kmalloc of up to the maximum RPC payload size (several MiB) per COMPOUND op that persists until compound teardown. The VFS rejects oversized targets with ENAMETOOLONG, but the allocation has already occurred. Reject cr_datalen == 0 early with nfserr_inval and cr_datalen greater than NFS4_MAXPATHLEN (PATH_MAX) with nfserr_nametoolong to bound the allocation.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89704", "url": "https://ubuntu.com/security/CVE-2026-89704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: sample writeback error cursor before async COPY loop _nfsd_copy_file_range() samples dst->f_wb_err into \"since\" after the copy loop, then uses it to detect writeback errors via filemap_check_wb_err() once vfs_fsync_range() returns. Because the nfsd_file cache reuses a single struct file across requests targeting the same inode, a concurrent COMMIT or stable WRITE on dst advances dst->f_wb_err to the current mapping->wb_err via file_check_and_advance_wb_err() during its own vfs_fsync_range(). If that advancement lands between the writeback error appearing in mapping->wb_err and the COPY worker sampling \"since\", the worker captures the already-advanced cursor, errseq_check() sees cur == since and returns zero, and NFSD4_COPY_F_COMMITTED is set even though writeback failed. CB_OFFLOAD then encodes wr_stable_how = FILE_SYNC4, the client treats the copied data as durable, and the failure becomes silent data loss. Sample since once at the start of the function. The cursor then reflects state in effect before this COPY issues any writes, and filemap_check_wb_err() detects any error that occurs during the copy regardless of which thread first observes it. This matches the pattern used by nfsd_vfs_write() and nfsd4_clone_file_range().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89706", "url": "https://ubuntu.com/security/CVE-2026-89706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: Reset write verifier when async COPY writeback fails Async COPY captures nn->writeverf at request time and reports it to the client via CB_OFFLOAD after the worker kthread completes. When the post-copy vfs_fsync_range() or filemap_check_wb_err() in _nfsd_copy_file_range() reports an error, the worker correctly leaves NFSD4_COPY_F_COMMITTED clear so that CB_OFFLOAD encodes wr_stable_how as NFS_UNSTABLE, but the server's write verifier is not rotated. A client that receives NFS_UNSTABLE in CB_OFFLOAD follows up with COMMIT to make the copied data durable. With the verifier unchanged, COMMIT returns the same value the client just received via CB_OFFLOAD, and the client concludes the copy is durable -- silently dropping the data whose writeback in fact failed. This violates the UNSTABLE+COMMIT durability contract (RFC 7862 section 15.1, RFC 8881 section 18.32) and matches the bug just fixed in nfsd_vfs_write() and nfsd_commit(). Rotate nn->writeverf at the writeback-failure site. The async COPY worker has no svc_rqst, so commit_reset_write_verifier() is not available here; calling nfsd_reset_write_verifier() directly mirrors the trace-less reset already used by nfsd_file_check_write_error() for the same purpose. Filter out -EAGAIN and -ESTALE, matching commit_reset_write_verifier(), since neither indicates a durable-storage failure.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89710", "url": "https://ubuntu.com/security/CVE-2026-89710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget path When the server returns a new layout stateid while a valid one is still held, pnfs_layout_process() calls pnfs_mark_matching_lsegs_return() on the on-stack free_me list and jumps to out_forget. Segments whose reference count drops to zero are unlinked from lo->plh_segs and moved to free_me by mark_lseg_invalid(); for an idle cached segment the layout header holds the only reference, so this happens on the first decrement. out_forget never drains free_me -- only the success path calls pnfs_free_lseg_list(). Commit 814b84971388 (\"pNFS/NFSv4: Fix a layout segment leak in pnfs_layout_process()\") added the drain; commit 08bd8dbe8882 (\"pNFS/NFSv4: Try to return invalid layout in pnfs_layout_process()\") removed it while switching the destination to lo->plh_return_segs, which is drained elsewhere. Commit fb700ef02676 (\"NFSv4.1: Simplify layout return in pnfs_layout_process()\") switched the destination back to free_me without restoring the drain. Restore the pnfs_free_lseg_list() call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89711", "url": "https://ubuntu.com/security/CVE-2026-89711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check The header for commit e75b23f9e323 (\"nfsd: check d_can_lookup in fh_verify of directories\") details the assumption that justified adding the WARN_ON_ONCE to nfsd_mode_check(), that assumption is invalid (in the case of NFS reexport). When NFSD exports an NFS filesystem it is very possible for nfsd_mode_check() to encounter a @dentry that doesn't have i_op->lookup (see nfs_fhget()'s NFS_ATTR_FATTR_MOUNTPOINT and NFS_ATTR_FATTR_V4_REFERRAL handling, and d_flags_for_inode()). So remove nfsd_mode_check()'s WARN_ON_ONCE(). The nfserr_notdir return on that branch must stay. It guards the subsequent lookup_one_unlocked() -> __lookup_slow() path, which calls inode->i_op->lookup() with no NULL check, so returning nfserr_notdir is what keeps a client LOOKUP into such a @dentry from dereferencing a NULL method pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89712", "url": "https://ubuntu.com/security/CVE-2026-89712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock nfsd4_ssc_expire_umount() walks nn->nfsd_ssc_mount_list with list_for_each_entry_safe(ni, tmp, ...). For each expired entry it sets nsui_busy = true, drops nfsd_ssc_lock to run mntput() on the source vfsmount, then reacquires the lock to list_del + kfree the entry and continue iterating via the macro's saved tmp pointer. The nsui_busy flag protects the current ni from concurrent nfsd4_ssc_setup_dul() finders during the lock-drop window, but it does not pin tmp. Another nfsd RPC thread that fails its source- server mount and reaches nfsd4_ssc_cancel_dul() will, during that same window, take nfsd_ssc_lock, list_del + kfree its own ssc_umount item, and release the lock. If that item is the saved tmp of the expire walk, the next iteration dereferences a freed nfsd4_ssc_umount_item. Restart the walk from the head after the mntput() unlock window so no saved next pointer survives the lock-drop. The list is bounded by the number of active inter-server source mounts (typically small) and the expire delayed-work runs periodically rather than per-IO, so the restart is cheap.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89720", "url": "https://ubuntu.com/security/CVE-2026-89720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: fix out-of-bounds read in signature length check ubifs_sb_verify_signature() bounds the on-disk ubifs_sig_node->len field before handing the signature payload to verify_pkcs7_signature(), but the check has the wrong sign: \tif (le32_to_cpu(signode->len) > snod->len + sizeof(struct ubifs_sig_node)) The signature bytes start sizeof(struct ubifs_sig_node) (UBIFS_SIG_NODE_SZ, 64 bytes) into the node, so the payload is at most \tsnod->len - sizeof(struct ubifs_sig_node) bytes long. Adding the header size instead of subtracting it accepts a declared length up to 2 * UBIFS_SIG_NODE_SZ larger than the node actually holds -- past the end of c->sbuf, which is vmalloc(c->leb_size). verify_pkcs7_signature() -> pkcs7_parse_message() -> asn1_ber_decoder() is then handed that inflated length and reads beyond the allocation while walking the DER headers. The node length comes straight from the mounted image, so a crafted signed UBIFS image reaches this via ubifs_read_superblock() before the signature is cryptographically checked. snod->len is guaranteed to be >= UBIFS_SIG_NODE_SZ by the node scanner (c->ranges[UBIFS_SIG_NODE].min_len == UBIFS_SIG_NODE_SZ), so the corrected subtraction cannot underflow. Legitimately signed images are unaffected: a correct superblock never declares a signature longer than the node it is embedded in.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93213", "url": "https://ubuntu.com/security/CVE-2026-93213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: of: fix out-of-bounds read in of_alias_scan() stem parser The stem parser tests isdigit(*(end - 1)) before checking end > start and so reads one byte before the property name when the name is empty or all digits. Check the bound first.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89723", "url": "https://ubuntu.com/security/CVE-2026-89723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after truncation Shuangpeng Bai reported that KASAN detected a slab-out-of-bounds error in nilfs_direct_propagate() during testing. Analysis revealed that after truncating a file, a node block immediately below the B-tree root was not deleted. Instead, it remained in the B-tree node cache in a dirty state. The log writer subsequently detected this block and incorrectly invoked nilfs_direct_propagate() on it, which is designed to handle only data blocks in direct mapping. B-tree nodes in the cache are managed by virtual block numbers, and their logical keys typically exceed the range expected by direct mapping. Consequently, processing such a node as a direct mapping entry triggers a slab-out-of-bounds access. The root cause is that when a B-tree mapping collapses into a direct mapping during truncation, an intermediate node block pointed to by the root node is left behind as garbage instead of being explicitly deleted. This resolves the issue by adding a nilfs_btree_discard() operation to delete the remaining intermediate node block during the conversion. A 'deform' flag is added to the bop_delete interface to explicitly signal that the deletion is part of a mapping transformation. This allows the B-tree mapping implementation to perform the necessary cleanup and discarding of the residual node structure that would be otherwise be left orphaned after the transition.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89724", "url": "https://ubuntu.com/security/CVE-2026-89724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vicodec: fix out-of-bounds write in FWHT encoder vidioc_s_fmt_vid_out() sizes the encoder CAPTURE buffer from the compressed descriptor pixfmt_fwht, whose sizeimage_mult is 3: coded_w * coded_h * 3 + sizeof(struct fwht_cframe_hdr). fwht_encode_frame() encodes one plane per component, and an incompressible plane takes the FWHT_FRAME_UNENCODED path in encode_plane(), copying the plane verbatim. For a 4-component pixel format all four planes are full resolution (width_div == height_div == 1), so a frame that forces every plane through the unencoded fallback writes sizeof(struct fwht_cframe_hdr) + 4 * coded_w * coded_h bytes, overrunning the plane by coded_w * coded_h, which can result in corruption of adjacent kernel heap memory. Bump pixfmt_fwht.sizeimage_mult from 3 to 4, matching the largest components_num among the supported raw formats, so the capture buffer is always large enough for the unencoded fallback.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89725", "url": "https://ubuntu.com/security/CVE-2026-89725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: stm32: prevent out-of-bounds write on RX overflow stm32_rx_done() appends each received CEC byte to rx_msg.msg[] using rx_msg.len as the write index, incrementing it on every RXBR (receive-byte-ready) interrupt without checking it against the buffer size: \tcec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF; rx_msg.msg[] is a fixed CEC_MAX_MSG_SIZE (16) byte array in struct cec_msg, and rx_msg.len is only reset on RXACKE/RXOVR or after a completed message (RXEND). The number of bytes received before RXEND is decided by the remote CEC device (it sets EOM), not by the driver. A peer that keeps sending bytes without ending the message drives RXBR repeatedly, pushing rx_msg.len past 16 and writing peer-controlled bytes out of bounds into the surrounding memory. This is reachable in normal operation once the driver has probed and receiving is enabled, from the IRQ thread, without any local privilege. The length check in the CEC core runs on the consumer side, after the byte has been stored, so it does not prevent the overflow. Bound the index in the driver before the store, as the other platform CEC drivers already do (e.g. tegra_cec), dropping the excess bytes of an overlong frame. Found by static analysis tool CodeQL.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89726", "url": "https://ubuntu.com/security/CVE-2026-89726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen() Patch series \"lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()\", v2. This series fixes an off-by-one out-of-bounds read in ucs2_strnlen(). The first patch is the real fix, the second patch comes as a bonus and fixes the code indentation. This patch (of 2): ucs2_strnlen() checks the current character before checking whether the caller-provided maximum length has been reached. If the input is not NUL-terminated within that bound, the loop can read one ucs2_char_t past the limit. Test the length before dereferencing to prevent an off-by-one out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89729", "url": "https://ubuntu.com/security/CVE-2026-89729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature sensor_hub_get_feature() clamps its return value to the caller's buffer size, but the copy loop still copies field->report_size / 8 bytes for each report value. A malicious HID descriptor can advertise a large feature field size while an IIO caller supplies a small stack buffer, such as a single s32, causing an out-of-bounds write. HID core stores parsed report values in __s32 slots and clamps extracted values to 32 bits. Reject feature fields that require more than one slot per value, guard the total byte count calculation, and clamp each per-value copy to the remaining caller buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89730", "url": "https://ubuntu.com/security/CVE-2026-89730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write The trailing byte path in altera_cvp_send_block() dereferences a u32 pointer even when only 1-3 bytes remain in the input buffer. If the buffer ends at a page or scatterlist boundary, this can read past the valid image data and fault. Copy the remaining bytes into a zero-initialized u32 before writing the final word so only valid bytes are read from the input buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89732", "url": "https://ubuntu.com/security/CVE-2026-89732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Prevent deadlock during ep0 read loop Currently, ffs_ep0_read() holds ffs->mutex when it prepares to go to sleep waiting for an event. When no setup events are pending, it calls wait_event_interruptible_exclusive_locked_irq() with the mutex still held. The wait macro deliberately drops the waitqueue spinlock before sleeping but does not drop the mutex. If a userspace daemon is polling ep0 via read() and the gadget is asynchronously torn down via configfs (e.g., echo \"\" > UDC), a deadlock can occur: 1. The configfs teardown calls functionfs_unbind(), which queues a FUNCTIONFS_UNBIND event. 2. The daemon wakes up, consumes the event, and drops the mutex. 3. However, if the daemon loops and immediately issues another read() before exiting, it reacquires ffs->mutex and again goes into an interruptible sleep. 4. Meanwhile, functionfs_unbind() continues execution and attempts to acquire ffs->mutex to tear down ep0req. 5. The kernel deadlocks because the configfs thread is stuck in an uninterruptible sleep waiting for the mutex, while the userspace daemon is in an interruptible sleep holding the mutex forever because no more events will arrive. To fix this, we drop both the waitqueue spinlock and ffs->mutex before going to sleep, and use wait_event_interruptible_exclusive() instead. Upon waking up, we jump back to the `retry` label to safely reacquire the mutex and re-evaluate the state machine. By not sleeping with ffs->mutex held, we natively decouple gadget teardowns (which require the mutex) from userspace polling.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89733", "url": "https://ubuntu.com/security/CVE-2026-89733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and uvc_function_unbind() In uvc_function_bind() error path, we use usb_ep_free_request which uses uvc->control_req but does not set it to NULL afterwards. Thus, uvc->control_req is a dangling pointer causing a UAF. Also we do not set the uvc->control_buf pointer to NULL after freeing it, which is another dangling pointer. Fix it by setting uvc->control_req to NULL after we run usb_ep_free_request() and uvc->control_buf to NULL after kfree. Do the same for uvc_function_unbind().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93214", "url": "https://ubuntu.com/security/CVE-2026-93214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: fix deadlock in usbg_make_tpg() usbg_make_tpg() held dep_lock while calling configfs_depend_item_unlocked(), which acquires the configfs root inode lock when operating across subsystems. This creates a circular lock dependency with configfs_rmdir(): dep_lock -> configfs root inode lock -> su_mutex -> dep_lock In usbg_make_tpg(), dep_lock only serialized the read of opts->ready, which is a monotonic flag that transitions from false to true exactly once (in tcm_set_name()) and never reverts. Remove dep_lock from usbg_make_tpg() entirely and use READ_ONCE/WRITE_ONCE to access opts->ready locklessly instead.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89736", "url": "https://ubuntu.com/security/CVE-2026-89736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: Fix use-after-free on sound card disconnect g_audio_cleanup() invokes snd_card_free_when_closed() to initiate sound card teardown and immediately frees the underlying struct snd_uac_chip context. However, snd_card_free_when_closed() returns asynchronously while ALSA control elements (kctls) remain open in userspace. When userspace control applications access or close these open file descriptors, kctl callbacks attempt to dereference kctl->private_data pointing to &uac->c_prm or &uac->p_prm within the freed uac structure, resulting in a use-after-free (UAF) memory corruption. Fix this issue by deferring the destruction of struct snd_uac_chip until all references to the ALSA sound card are released. Register a custom card->private_free callback (u_audio_card_free) during g_audio_setup() that frees uac and its associated playback/capture request and ring buffers only when the sound card reference count drops to zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89741", "url": "https://ubuntu.com/security/CVE-2026-89741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"media: v4l2-dev: fix error handling in __video_register_device()\" This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a. The intentions of that patch were good, but it doesn't work. The idea is that if device_register fails, you have to do a put_device to let the ref counter release resources. However, the V4L2 API says that if video_register_device() fails, then you have to call video_device_release(), which kfree()s the video_device struct. But the put_device() will already have freed the struct, so you end up in a double-free scenario. There is not really a good way of fixing this without breaking video_register_device() into two parts, one that initializes everything, and one that does the actual device_register, and then converting all V4L2 drivers to this new model. That is a massive job, and it is very unlikely that device_register will fail. So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89742", "url": "https://ubuntu.com/security/CVE-2026-89742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: mport_cdev: fix use-after-free in dma_req_free() dma_req_free() acquires buf_mutex through req->map, drops the mapping reference with kref_put(), and then dereferences req->map again to unlock the mutex. If kref_put() drops the last reference, mport_release_mapping() frees the mapping, and the subsequent mutex_unlock() dereferences a freed object. This is a use-after-free. Fix this by caching map and md before kref_put(), clearing req->map while holding buf_mutex, and using the cached md for mutex unlocking. The bug is reachable from userspace via the RapidIO mport character device interface.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89749", "url": "https://ubuntu.com/security/CVE-2026-89749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix crash passing ERR_PTR to kthread_stop() event_test_stuff() calls kthread_run() and unconditionally passes the returned task_struct pointer to kthread_stop(). kthread_run() returns an error pointer such as ERR_PTR(-ENOMEM) when kthread creation fails, for example under memory pressure during the boot-time event self-test. kthread_stop() then dereferences the invalid pointer, crashing the kernel. Check the result of kthread_run() before passing it to kthread_stop(). Use WARN_ON() so that a failure to create the self-test thread does not go unnoticed, matching the ring-buffer self-test fix in commit 91542863abad (\"ring-buffer: Fix crash passing ERR_PTR to kthread_stop()\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89752", "url": "https://ubuntu.com/security/CVE-2026-89752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: memcg: stop reclaim when a limit update is superseded kernfs serializes file operations only per open file, so separate open files can update the same memory.high or memory.max file concurrently. Both handlers store the new limit before synchronous reclaim, but continue to use the writer's local target in the reclaim loop. If another writer raises or removes the limit, the first writer can continue reclaiming toward a stale target. For memory.max, this can leave the writer looping indefinitely once reclaim retries are exhausted. The OOM path sees sufficient margin under the current limit and returns true without killing, while the writer still compares usage against its stale target and records another OOM event. Check the current limit at the start of each reclaim iteration and stop if it no longer matches the writer's target. Reproducer: Populate a cgroup with anonymous memory and disable swapping. Lower memory.max from one open file, then restore it to \"max\" through another open file after the new limit becomes visible. Without the patch, the first writer remains blocked and repeatedly increments the OOM event counter. With the patch, it returns normally. This was not motivated by a reported production workload. We found it through automated randomized testing for our cgroup observability work and reduced it to the reproducer above.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89753", "url": "https://ubuntu.com/security/CVE-2026-89753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: \t0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 \ttask:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89765", "url": "https://ubuntu.com/security/CVE-2026-89765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers/itimer: Zero-init old itimerval before copy to userspace On native sparc64, struct __kernel_old_timeval contains a four-byte hole after tv_usec because tv_sec is 64-bit while __kernel_suseconds_t is 32-bit. put_itimerval() fills only the named fields in a stack-allocated __kernel_old_itimerval and copies the entire object to userspace, so getitimer() can expose the two padding holes. Zero-initialize the aggregate before assigning the fields so implicit padding is deterministic before it crosses the user/kernel boundary.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-93219", "url": "https://ubuntu.com/security/CVE-2026-93219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/timer-sun4i: Advertise a real minimum delta sun4i_clkevt_next_event() compensates for the timer stop/start synchronization delay by programming evt - TIMER_SYNC_TICKS into the hardware interval register. The clockevent device currently advertises TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed to call set_next_event() with evt == TIMER_SYNC_TICKS. That programs a zero-tick interval. With oneshot/highres/nohz timer operation this can leave the next event stuck, which was observed as a boot hang on Allwinner D1 after the clockevents core started reusing forced minimum-delta events. Advertise one extra tick instead, so the smallest event accepted by the core still programs at least one hardware tick after the synchronization compensation.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-23191", "url": "https://ubuntu.com/security/CVE-2026-23191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix racy access at PCM trigger The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers. For addressing the UAF, this patch changes two things: - It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.", "cve_priority": "high", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-80824", "url": "https://ubuntu.com/security/CVE-2026-80824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbfs: fix use-after-free of usb_device in usbdev_release() usbdev_release() drops its reference to the struct usb_device before draining the list of completed async URBs, but that drain path reads back through the same object: free_async() calls dec_usb_memory_use_count() for any URB whose buffer came from the usbfs mmap() region, and its first statement is bus_to_hcd(ps->dev->bus). After a disconnect the usbfs reference can be the last one, in which case usb_put_dev() frees the device and the subsequent loop reads offset 80 of freed memory and uses the result as a struct usb_hcd *, which hcd_buffer_free_pages() then dereferences. This is reachable by an unprivileged process that has read/write access to a /dev/bus/usb node: mmap() the fd, submit one URB with a buffer inside the mapping, wait for the device to be unplugged, then munmap() and close(). It reproduces on every attempt rather than being a race, because a live MAP_SHARED vma holds a reference on the struct file, so usbdev_release() cannot run until the last vma is gone and the freeing branch of dec_usb_memory_use_count() is always taken. BUG: KASAN: slab-use-after-free in dec_usb_memory_use_count+0x3ae/0x410 Read of size 8 at addr ffff8880122ee050 by task poc/769 CPU: 1 UID: 1000 PID: 769 Comm: poc Tainted: G B 6.12.94 #3 Call Trace: dec_usb_memory_use_count+0x3ae/0x410 free_async+0x2aa/0x4f0 usbdev_release+0x375/0x460 __fput+0x3ea/0xb50 __x64_sys_close+0x86/0x100 Allocated by task 11: usb_alloc_dev+0x55/0xd90 hub_event+0x2524/0x43d0 Freed by task 769: kfree+0x121/0x360 device_release+0xd2/0x280 usb_put_dev+0x23/0x30 usbdev_release+0x2d8/0x460 Release the device reference after the drain loop instead. Nothing between the two points requires it to have been dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80826", "url": "https://ubuntu.com/security/CVE-2026-80826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: c67x00: fix use-after-free in c67x00_add_iso_urb() When TD creation fails for the last packet of an isochronous URB, c67x00_add_iso_urb() gives the URB back before updating the endpoint scheduling state. c67x00_giveback_urb() frees the URB private data, and the completion callback may release the final URB reference. The following accesses to urbp->ep_data, urb->interval, and urbp->cnt can therefore use freed memory. Update next_frame and cnt before giving back the failed final packet, making the giveback the last operation that uses the URB and its private data.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80827", "url": "https://ubuntu.com/security/CVE-2026-80827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: option: fix slab OOB read in interrupt URB callback The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. [ johan: use dev_err(); split signals declaration and initialisation ]", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80828", "url": "https://ubuntu.com/security/CVE-2026-80828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Complete cleanup after system-resume errors A failed system resume can leave the card unusable until reboot. usb_audio_resume() jumps to err_out when snd_usb_pcm_resume() or snd_usb_mixer_resume() fails. The error path skips the out: block, which restores D0 and decrements chip->num_suspended_intf. The card stays in SNDRV_CTL_POWER_D3hot, so later control access blocks in snd_power_ref_and_wait(). USB core logs an interface resume callback error. It does not retry that callback, so a later callback cannot complete the skipped cleanup. usb_audio_suspend() increments num_suspended_intf before returning success. A system-resume callback must consume the system-suspend count even if a component resume fails. Otherwise, the stranded count skews later suspend and resume cycles. Do not apply this cleanup to runtime-resume errors. Runtime PM can retry -EAGAIN or -EBUSY without another suspend callback. The count must continue to describe that suspended interface. Other runtime-resume errors latch runtime_error in the PM core and do not cause an immediate callback retry. Both parts of the system-resume error path are longstanding. Commit 88a8516a2128a (\"ALSA: usbaudio: implement USB autosuspend\") introduced err_out past the D0 restore. Commit 862b2509d157c (\"ALSA: usb-audio: Fix inconsistent card PM state after resume\") later moved num_suspended_intf-- into the out: block. The error path now skips both operations. No third-party code is needed to reach the error path. snd_usb_mixer_resume() ends in snd_usb_mixer_activate(), which returns the result of usb_submit_urb() for devices that have a mixer status URB. Its mixer->private_resume hook can also fail through scarlett2_init_notify(). snd_usb_pcm_resume() issues a SET_CUR request to a UAC3 power domain. It can return -EPIPE or -EIO when the device stalls the request. Route a component error through out: only when system_suspend is nonzero. Continue to return runtime-resume errors through err_out. Later component resume stages remain skipped. The original error still reaches USB core. A later transfer can fail if the device did not recover. I reproduced the system-resume failure on an Audient iD14 MkI with an out-of-tree diagnostic mixer resume hook. An injected -EIO on the unpatched core left control readers in uninterruptible sleep in snd_power_ref_and_wait() until a reboot. With this patch, the same failure restored control access. A second system suspend and resume also succeeded after I disabled fault injection.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80829", "url": "https://ubuntu.com/security/CVE-2026-80829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output() snd_usbmidi_novation_output() lays out a two-byte header at transfer_buffer[0..1] and passes &transfer_buffer[2] together with a length of ep->max_transfer - 2 to snd_rawmidi_transmit(): \tcount = snd_rawmidi_transmit(ep->ports[0].substream, \t\t\t\t &transfer_buffer[2], \t\t\t\t ep->max_transfer - 2); ep->max_transfer comes from the output endpoint's wMaxPacketSize via usb_maxpacket(). A malformed or malicious device can advertise a bulk OUT endpoint with a wMaxPacketSize of 1 - the USB core only clamps this value downwards - so ep->max_transfer becomes 1 and the count argument becomes -1. snd_rawmidi_transmit() passes the negative count on to __snd_rawmidi_transmit_peek(), where \"if (count1 > count) count1 = count\" leaves count1 negative; get_aligned_size() keeps it negative for a byte-stream substream, so the following memcpy(buffer, ..., count1) runs with a (size_t)-1 length and writes far past the transfer buffer, which was allocated with usb_alloc_coherent(ep->max_transfer). This is the same class of bug that was fixed for snd_usbmidi_akai_output() in commit 0970274613fb (\"ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()\"); the novation output routine was left unguarded. Bail out when the endpoint cannot hold the two-byte header plus at least one payload byte.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80830", "url": "https://ubuntu.com/security/CVE-2026-80830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: Add lock to usb_wakeup_notification() Add a spin lock to usb_wakeup notification to prevent a race condition with dereferencing freed memory. This could be hit by the xHCI driver as it calls this function from an IRQ and could race with the hub_disconnect() function, which properly grabs this lock to protect the state of the device.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80921", "url": "https://ubuntu.com/security/CVE-2026-80921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: zero stale crypto bits When shadowing crypto access bits from a format0 apcb (crycb 0 or 1), the bits 64..255 are unchanged from whatever is in the vsie page in the crycb and thus in the apcb. This gives a nested guest potential access to a device no longer available. Zero out the remaining bits.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80831", "url": "https://ubuntu.com/security/CVE-2026-80831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: mxs-dcp - fix source scatterlist length access mxs_dcp_aes_block_crypt() uses sg_dma_len() without mapping the source scatterlist with dma_map_sg() first. Therefore, sg_dma_len() is invalid and could return zero or a stale DMA length, causing encryption and decryption to process the wrong number of bytes when CONFIG_NEED_SG_DMA_LENGTH=y. Use the original scatterlist length instead.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80832", "url": "https://ubuntu.com/security/CVE-2026-80832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qce - fix CCM AAD buffer underallocation The AAD buffer allocated in qce_aead_ccm_prepare_buf_assoclen() can be smaller than the length later programmed into the DMA scatterlist. The allocation size is currently calculated as: ALIGN(assoclen, 16) + MAX_CCM_ADATA_HEADER_LEN while the DMA length is set to: ALIGN(assoclen + adata_header_len, 16) Since ALIGN() does not distribute over addition, the allocation can be smaller than the DMA length. For example, when assoclen = 32 and adata_header_len = 2: allocation = ALIGN(32, 16) + 6 = 38 DMA length = ALIGN(32 + 2, 16) = 48 As a result, the QCE hardware can read beyond the allocated buffer while computing the CBC-MAC over the associated data. The extra bytes are folded into the authentication tag, resulting in an incorrect tag and causing CCM self-test failures such as: alg: aead: ccm-aes-qce encryption test failed (wrong result) on test vector 8 Fix the allocation by adding the maximum possible AAD header length before alignment: ALIGN(assoclen + MAX_CCM_ADATA_HEADER_LEN, 16) This guarantees that the allocated buffer is large enough for the fully padded AAD data for all supported header sizes.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80840", "url": "https://ubuntu.com/security/CVE-2026-80840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: seg6: clear IPv4 control block on IPIP decapsulation End.DX4 and End.DT4 decapsulate an IPv4 packet through decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), which normally clears IPCB before IPv4 interprets skb->cb. The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts. The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40. Both tcp_v4_save_options() and __ip_options_echo() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls __ip_options_echo(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte option-data area. Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced: BUG: KASAN: slab-out-of-bounds in __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm. Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80842", "url": "https://ubuntu.com/security/CVE-2026-80842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: fix use-after-free of a master VLAN's multicast context br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so once it is cleared under the lock no reader can arm the context again. For a master VLAN the handshake never runs. __vlan_del() clears BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so br_multicast_toggle_one_vlan(masterv, false) returns early on !br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is never taken. br_vlan_put_master() then drains the context in br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a reader still inside rcu_read_lock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no br_vlan_is_brentry() test and flips the flag under br->multicast_lock, so it is not affected. The reader is the bridge transmit path. For a master VLAN br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after br_multicast_ctx_deinit() has already stopped them. BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 Allocated by task 610: br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 Only test br_vlan_is_brentry() when enabling, like the br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before br_multicast_ctx_deinit() drains the context.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80843", "url": "https://ubuntu.com/security/CVE-2026-80843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix xfrm_state_construct() auth-trunc leak attach_auth_trunc() can allocate x->aalg while leaving x->props.aalgo at zero when the selected auth algorithm has no sadb_alg_id. One real case is cmac(aes). xfrm_state_construct() then treats !x->props.aalgo as \"no auth algorithm attached yet\" and calls attach_auth(). That overwrites x->aalg and loses the first allocation. Any later failure or teardown only frees the replacement pointer. Check whether x->aalg is already attached instead of inferring that state from x->props.aalgo.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80844", "url": "https://ubuntu.com/security/CVE-2026-80844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah6: validate routing header segments_left AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6_rearrange_rthdr() assumes that segments_left is not larger than the number of addresses described by the routing header's hdrlen field. That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segments_left value. With segments_left equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access. Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80846", "url": "https://ubuntu.com/security/CVE-2026-80846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: drop ESP-in-TCP packets with no ingress device ESP-in-TCP receives records through the TCP strparser. handle_esp() restores skb->dev from the saved skb_iif before passing the packet into the XFRM input path. Queued TCP data can be processed after the original ingress device has been removed, for example during veth or net namespace teardown. In that case dev_get_by_index_rcu() returns NULL. The XFRM IPv4 and IPv6 input paths both expect skb->dev to be valid while building the route lookup, so queued ESP-in-TCP data can dereference a NULL device. Drop the packet if the saved ingress device can no longer be resolved. Such a packet can no longer be routed through the normal XFRM receive path, and this preserves the existing behaviour for packets whose ingress device still exists.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80848", "url": "https://ubuntu.com/security/CVE-2026-80848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: fix UAF during close ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80854", "url": "https://ubuntu.com/security/CVE-2026-80854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: keep port count until LUN teardown completes tcm_usbg_drop_nexus() permits session removal once tpg_port_count reaches zero. However, usbg_port_unlink() currently decrements that count from the fabric_pre_unlink() callback, before core_dev_del_lun() waits for active se_lun references to drain. If removal of the last LUN races a nexus removal, the latter can observe a zero port count and call target_remove_session(). This frees sess_cmd_map while an in-flight struct usbg_cmd, including its work item, can still be accessed. Overlapping the last-LUN unlink with nexus removal reproduces this lifetime violation as a DEBUG_OBJECTS \"free active\" warning for usbg_cmd_work, followed by a target-core BUG/Oops. The generic target-core unlink path has no callback after core_dev_del_lun() completes. Add an optional fabric_post_unlink() callback and use it for the f_tcm port count. The count now remains nonzero until core_dev_del_lun() has finished draining active LUN references, preventing nexus removal from freeing the session during command completion.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80855", "url": "https://ubuntu.com/security/CVE-2026-80855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on open O_TRUNC DAX failure fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open(\"file\", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80856", "url": "https://ubuntu.com/security/CVE-2026-80856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on setattr writeback failure fuse_do_setattr() takes filemap_invalidate_lock() for a DAX truncate (fault_blocked = true) and releases it at the out:/error: labels. But when a writeback flush is also needed, a write_inode_now() failure returns directly and leaks the lock, so any later fault or truncate on the file stalls on the stale rwsem. For example, truncate(2) on a setuid file reaches fuse_do_setattr() with both ATTR_SIZE and ATTR_MODE set: truncate(2) └─ do_truncate() ├─ dentry_needs_remove_privs() # S_ISUID └─ notify_change() # KILL_SUID -> ATTR_MODE └─ fuse_setattr() # no killpriv: │ # ia_valid |= ATTR_MODE └─ fuse_do_setattr() ├─ filemap_invalidate_lock() # IS_DAX && is_truncate └─ write_inode_now() # is_wb && ATTR_MODE └─ if (err) # e.g. daemon -> -EIO return err # <- lock leaked Fix this by adding an unlock label that releases the lock before returning the error, and use it for the fuse_dax_break_layouts() failure path as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80923", "url": "https://ubuntu.com/security/CVE-2026-80923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: dbgtty: Fix unregister on tty_register_driver() failure If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80768", "url": "https://ubuntu.com/security/CVE-2026-80768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: ft260: fix stack-use-after-return write in I2C read race ft260_i2c_read() points dev->read_buf at a caller-supplied buffer (often an on-stack variable), arms a completion and waits up to five seconds for the device to return the data. The HID input callback ft260_raw_event() runs in the input/IRQ path, independent of the dev->lock mutex held by the read path, and copies the device-supplied payload into dev->read_buf after a plain NULL check. These two paths share read_buf, read_idx and read_len with no serialization. If the device delays its response until the read times out, ft260_i2c_read() resets the controller, clears read_buf and returns, unwinding the stack frame the buffer lived in. A response that arrives at that moment lets ft260_raw_event() pass the NULL check and then memcpy() the device-controlled payload into the now-freed stack location, a bounded but attacker-influenced stack-use-after-return write triggerable by malicious or malfunctioning hardware. Add a dedicated spinlock that serializes every access to read_buf, read_idx and read_len. ft260_raw_event() now holds it across the NULL check, the memcpy and the index update, while the read path takes it when arming and when clearing the buffer, so the teardown can no longer slip between the check and the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80766", "url": "https://ubuntu.com/security/CVE-2026-80766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: fix use-after-free of inrange_timer on remove uclogic_remove() cancels the pen in-range timer and then stops the device: \ttimer_delete_sync(&drvdata->inrange_timer); \thid_hw_stop(hdev); timer_delete_sync() only guarantees the timer is idle at that instant. uclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop() stops the transport several lines later, and every report with pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer: \tmod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); A report landing between the timer_delete_sync() call and the transport teardown in hid_hw_stop() re-arms inrange_timer after it was cancelled. uclogic_remove() then returns and the devm drvdata is freed, while hid_hw_stop() has already freed the input device drvdata->pen_input points at, so when the timer fires ~100 ms later uclogic_inrange_timeout() dereferences freed memory -- a use-after-free in timer-softirq context. Swapping the two calls is not a fix: stopping the device first frees drvdata->pen_input via hidinput_disconnect() while the timer may still be pending, so a timer already armed before removal fires on the freed input device in the window before timer_delete_sync() runs. Use timer_shutdown_sync() before hid_hw_stop() instead. It cancels the timer, waits for a running callback while pen_input is still valid, and prevents any further re-arming -- a later mod_timer() from an in-flight report is silently ignored -- so the timer is provably dead before hid_hw_stop() frees the inputs. This is the ordering the timer core documents for this \"timer re-armed from another path\" teardown case.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80789", "url": "https://ubuntu.com/security/CVE-2026-80789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: bound SGL data length before allocating command buffers nvmet_tcp_map_data() reads the host-controlled 32-bit sgl->length and, for the in-capsule offset descriptor (type 0x01), checks it against port->inline_data_size before use. Any other SGL descriptor type -- including the non-inline transport SGL data-block descriptor (type (NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, the type a real host uses for out-of-capsule writes) skips that check entirely and falls straight through to: \tcmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt); with len taken directly from the wire, unbounded up to 4 GiB. nvmet_req_init() only parses the command and never inspects sgl->length, and nvmet_check_transfer_len() -- the only other place transfer_len is validated -- runs later, from req->execute(), after the allocation has already happened. For a write command the target responds with an R2T and parks the command waiting for the host to send the data; if the host (or an unauthenticated peer that simply never follows up) never does, the sgl_alloc() buffer stays resident for the life of the command. NVMe/TCP has no mandatory authentication in the default configuration, so any peer able to reach the target portal and complete a Fabrics connect can drive this with a single crafted command, repeatable across queues and connections for amplification. This is unbounded kernel memory allocation triggered by a remote, effectively unauthenticated peer. Validate len against the same NVMET_TCP_MAXH2CDATA ceiling this file already uses to bound per-PDU H2C data, for every SGL descriptor type, before doing any allocation. This closes the gap for the non-inline descriptor while leaving the existing, tighter inline_data_size check in place for the in-capsule case. Runtime-verified on a v6.19 KASAN stand: with this bound in place, a crafted write command carrying an oversized non-inline SGL length is rejected before sgl_alloc() runs, where the same request previously drove an unbounded ~256 MiB kernel allocation (up to 4 GiB) that stayed resident pending an R2T the host never satisfies.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80783", "url": "https://ubuntu.com/security/CVE-2026-80783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event() magicmouse_raw_event() handles DOUBLE_REPORT_ID (0xf7) packets, which pack two touch reports into one, by splitting the packet and calling itself on each half. The only guard against runaway recursion is a \"size < 1\" check, which stops zero-sized calls but does not bound the recursion depth. A malicious HID device that matches this driver can send a report starting with DOUBLE_REPORT_ID and filled with the sequence [0xf7, 0x00]. Each level consumes two bytes and recurses on the remainder, so an incoming report of up to HID_MAX_BUFFER_SIZE (16 KiB) drives roughly 8000 nested calls. That easily exhausts the 16 KiB kernel stack, leading to a stack overflow: a panic with CONFIG_VMAP_STACK, or memory corruption without it. A double report only ever wraps two normal reports; it is never legitimately nested. Refuse to re-enter the DOUBLE_REPORT_ID case from a recursive call so the recursion depth is bounded to two, while all valid packets keep being parsed exactly as before.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80796", "url": "https://ubuntu.com/security/CVE-2026-80796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: add data_len bound checks to activation parameter extractors nci_extract_activation_params_iso_dep() and nci_extract_activation_params_nfc_dep() read an inner length byte from the NCI RF_INTF_ACTIVATED_NTF payload and use it to memcpy() into fixed kernel buffers, but neither function receives the caller-validated activation_params_len. A crafted NCI notification with activation_params_len=1 and an inner length byte of up to 20 (NFC-A) or 50 (NFC-B) causes memcpy() to read that many bytes past the one valid byte in the activation params region -- a slab out-of-bounds read of kernel memory adjacent to the NCI skb. The sibling nci_extract_rf_params_*() family was given equivalent protection by commit 571dcbeb8e63 (\"net: nfc: nci: Fix parameter validation for packet data\"), but the two activation parameter extractors were not updated at that time. Add a data_len parameter to both functions, guard against an empty region before consuming the inner length byte, decrement the remaining count after consuming it, and clamp the copy length to what is actually available. Update both call sites to pass ntf.activation_params_len, which is already validated against the skb at ntf.c:801.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80807", "url": "https://ubuntu.com/security/CVE-2026-80807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid block index in GC ioctl Syzbot reported list corruption caused by a double list_add_tail() call on bh->b_assoc_buffers within nilfs_lookup_dirty_data_buffers(). Analysis revealed that the root cause was the insertion of a page/folio with a page index of ULONG_MAX into the page cache via the GC ioctl. filemap_get_folios_tag(), called by nilfs_lookup_dirty_data_buffers(), repeatedly detects a dirty folio with a page index of ULONG_MAX due to index wrap-around, leading to duplicate processing of dirty buffers. As a preparatory step, the GC ioctl loads the page/folio of the block to be moved during GC and inserts it into the page cache based on information in the nilfs_vdesc structure passed as an argument. Normally, this does not cause issues because the user-space GC library configures the nilfs_vdesc structure properly. However, since there is no range check on the parameters determining the page index, a request with artificially crafted parameters -- such as those generated by Syzbot -- can result in a page/folio being inserted with a page index of ULONG_MAX, triggering the above problem. This resolves the issue by checking the ranges of 'vd_offset' and 'vd_vblocknr' in the nilfs_vdesc structure that determine the page index, thereby preventing the invalid page/folio insertions.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80916", "url": "https://ubuntu.com/security/CVE-2026-80916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcov: fix data corruption and race conditions on PREEMPT_RT syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area. On PREEMPT_RT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state. Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites. Note that while the temporary storage is now on a per-thread basis, the per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that kcov_remote_start() and kcov_remote_stop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state. It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when __init function of built-in module runs. But this patch also fixes crashing the kernel when vmalloc_node() in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in (1) doing vmalloc() in kcov_remote_start() despite !in_task() context (2) out-of-array-bounds access if (1) succeeded but kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE (3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes problems.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-43437", "url": "https://ubuntu.com/security/CVE-2026-43437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain() In the drain loop, the local variable 'runtime' is reassigned to a linked stream's runtime (runtime = s->runtime at line 2157). After releasing the stream lock at line 2169, the code accesses runtime->no_period_wakeup, runtime->rate, and runtime->buffer_size (lines 2170-2178) — all referencing the linked stream's runtime without any lock or refcount protecting its lifetime. A concurrent close() on the linked stream's fd triggers snd_pcm_release_substream() → snd_pcm_drop() → pcm_release_private() → snd_pcm_unlink() → snd_pcm_detach_substream() → kfree(runtime). No synchronization prevents kfree(runtime) from completing while the drain path dereferences the stale pointer. Fix by caching the needed runtime fields (no_period_wakeup, rate, buffer_size) into local variables while still holding the stream lock, and using the cached values after the lock is released.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-53089", "url": "https://ubuntu.com/security/CVE-2026-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in offloaded map/prog info fill When querying info for an offloaded BPF map or program, bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns() obtain the network namespace with get_net(dev_net(offmap->netdev)). However, the associated netdev's netns may be racing with teardown during netns destruction. If the netns refcount has already reached 0, get_net() performs a refcount_t increment on 0, triggering: refcount_t: addition on 0; use-after-free. Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains valid, they cannot prevent the netns refcount from reaching zero. Fix this by using maybe_get_net() instead of get_net(). maybe_get_net() uses refcount_inc_not_zero() and returns NULL if the refcount is already zero, which causes ns_get_path_cb() to fail and the caller to return -ENOENT -- the correct behavior when the netns is being destroyed.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2025-40102", "url": "https://ubuntu.com/security/CVE-2025-40102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000) Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-39925", "url": "https://ubuntu.com/security/CVE-2025-39925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: j1939: implement NETDEV_UNREGISTER notification handler syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 (\"can: j1939: move j1939_priv_put() into sk_destruct callback\") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on \"struct j1939_priv\" held by j1939_sk_bind() call prevents \"struct net_device\" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. [mkl: remove space in front of label]", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2024-58095", "url": "https://ubuntu.com/security/CVE-2024-58095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before txBeginAnon() call Added a read-only check before calling `txBeginAnon` in `extAlloc` and `extRecord`. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes. Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-58094", "url": "https://ubuntu.com/security/CVE-2024-58094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before truncation in jfs_truncate_nolock() Added a check for \"read-only\" mode in the `jfs_truncate_nolock` function to avoid errors related to writing to a read-only filesystem. Call stack: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) If the `isReadOnly(ip)` condition is triggered in `jfs_truncate_nolock`, the function execution will stop, and no further data modification will occur. Instead, the `xtTruncate` function will be called with the \"COMMIT_WMAP\" flag, preventing modifications in \"read-only\" mode.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-46754", "url": "https://ubuntu.com/security/CVE-2024-46754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Remove tst_run from lwt_seg6local_prog_ops. The syzbot reported that the lwt_seg6 related BPF ops can be invoked via bpf_test_run() without without entering input_action_end_bpf() first. Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a (\"ipv6: sr: Add seg6local action End.BPF\"). The reason is that the per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self test case but each BPF function expects it. Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.", "cve_priority": "low", "cve_public_date": "2024-09-18 08:15:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-80806", "url": "https://ubuntu.com/security/CVE-2026-80806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't enable DAX on new encrypted files Currently, when a new encrypted regular file is created, the call to ext4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made before EXT4_INODE_ENCRYPT is set. As a result, it can set S_DAX if the filesystem is mounted with \"-o dax=always\". EXT4_INODE_ENCRYPT then actually gets set a bit later in __ext4_new_inode(), when it calls fscrypt_set_context() which calls ext4_set_context(). ext4_set_context() sets EXT4_INODE_ENCRYPT and calls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too. This was intended to clear S_DAX as well. However, this was broken by commit 043546e46dc7 (\"fs/ext4: Only change S_DAX on inode load\"). This causes data written to the file to bypass encryption, also causing xfstests failures such as generic/548 (when \"-o dax=always\" is used). Fix this by simplifying the flow by making __ext4_new_inode() set EXT4_INODE_ENCRYPT earlier. This makes it take effect in ext4_set_inode_flags(inode, init=true), making S_DAX never be set. Similarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first place on new encrypted inodes. Then it doesn't need to be cleared. As a result of these simplifications, ext4_set_context() no longer needs to change inode flags or state when 'handle != NULL'. Remove that too.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80863", "url": "https://ubuntu.com/security/CVE-2026-80863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix OOB in free_rd_atomic_resources() free_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic. Updating max_dest_rd_atomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] BUG: KASAN: slab-out-of-bounds in rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 Write of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063 CPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xf7/0x600 mm/kasan/report.c:482 kasan_report+0xe4/0x120 mm/kasan/report.c:595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fefc75a70cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fefc8495018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd RDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007 RBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0 Allocated by task 11063: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5296 [inline] __kmalloc_noprof+0x32a/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:155 [inline] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_ma ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80590", "url": "https://ubuntu.com/security/CVE-2026-80590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 (\"net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list\") and by commit 9e4b7a99a03a (\"net: gso: fix panic on frag_list with mixed head alloc types\") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 (\"tun: Allow GSO using virtio_net_hdr\"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80765", "url": "https://ubuntu.com/security/CVE-2026-80765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: validate initial device info bounds The Hyper-V synthetic HID host supplies SYNTH_HID_INITIAL_DEVICE_INFO messages that contain a HID descriptor followed by the report descriptor bytes. mousevsc_on_receive_device_info() trusts bLength and wDescriptorLength without checking that the received packet contains both byte ranges. A malformed host or backend message can therefore make the guest read past the received VMBus packet while copying the report descriptor. Pass the received initial-device-info size into the parser and reject descriptor lengths that exceed the packet. Impact: A malicious Hyper-V host or backend can crash a guest by sending a short initial device-info message with an oversized HID report descriptor length.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80767", "url": "https://ubuntu.com/security/CVE-2026-80767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix use-after-free in enable_sensor enable_sensor_store() can call set_power_report_state(), which dereferences sensor_inst->power_state and sensor_inst->report_state. These pointers refer to entries in sensor_inst->fields. Create the field attributes before exposing the enable_sensor sysfs attribute, so enable_sensor cannot be accessed before the state it depends on has been initialized. On remove, delete enable_sensor before freeing the field attributes, so a concurrent sysfs write cannot dereference freed memory through power_state or report_state.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80918", "url": "https://ubuntu.com/security/CVE-2026-80918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix number/pointer type confusion on long items When fetch_item() is called by hid_scan_report() on an item with HID_ITEM_TAG_LONG, it stores a pointer to the item data in item->data.longdata instead of storing a value directly in item->data.{u8/u16/u32}. When item_udata() or item_sdata() encounters such an item, it incorrectly assumes that the item is in short format, and therefore returns the lower part of a kernel pointer reinterpreted as a number. When a HID device is connected whose descriptor contains a HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this causes the lower half of a kernel pointer to be printed into dmesg as a number, like this: hid (null): invalid report_size 107953555 To fix it, let item_udata() and item_sdata() verify that the item is in short format. Note that this bug only affects hid_scan_report(), while the main parsing pass hid_parse_collections() will always bail out when encountering a long item. Sidenote: There are currently no users of data.longdata; maybe we should just remove any parsing of long-format descriptors as a follow-up.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80889", "url": "https://ubuntu.com/security/CVE-2026-80889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix timer drain order, wakeup handling and tx_gen ordering This patch is a follow-up to commit cf070fe33bfb (\"can: isotp: serialize TX state transitions under so->rx_lock\") which addresses following sashiko-bot findings: - isotp_sendmsg(): drain so->txfrtimer first so a stale callback can't re-arm echotimer after the claim - isotp_release(): wake so->wait after forcing ISOTP_SHUTDOWN so a sleeping sendmsg() claim isn't stranded - isotp_sendmsg(): have both wait_event_interruptible() calls in isotp_sendmsg() also wake on ISOTP_SHUTDOWN and do not return claim to IDLE to avoid corrupting a concurrent isotp_release() process. - isotp_sendmsg(): handle potential claim of a new transfer when the wait_event_interruptible() call returns in CAN_ISOTP_WAIT_TX_DONE mode. Don't touch timers and states of the new transfer if a new thread incremented so->tx_gen before getting the lock at err_event_drop. - isotp_sendmsg(): handle a stuck can_send() and omit timer and state changes if a new transfer was claimed. wait_tx_done() returns the error recorded in so->tx_result[], tagged with the caller's own generation. - isotp_tx_timeout(): on a claimed timeout, record the ECOMM error for the timed-out transfer's own generation in so->tx_result[]; sk->sk_err is raised unconditionally, same as every other error path here. - isotp_tx_gen_done()/isotp_tx_timeout(): always read tx.state (acquire) before tx_gen - the reverse order let a weakly ordered CPU pair a fresh tx.state with a stale tx_gen/tx_result slot. - isotp_sendmsg(): wait_tx_done: drain sk_err via sock_error() once we have read the result from so->tx_result[], so an already-reported error doesn't stay latched for a later poll()/SO_ERROR. Also align the remaining lock-free so->tx.state/rx.state/cfecho accesses and use skb->hash as unique loopback echo frame indicator.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-46170", "url": "https://ubuntu.com/security/CVE-2026-46170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: free sk if last When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on \"itself\".", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46158", "url": "https://ubuntu.com/security/CVE-2026-46158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: always decrease sk refcount When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as \"unlikely\".", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-80555", "url": "https://ubuntu.com/security/CVE-2026-80555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Free all memory if cp_init() fails The routine cp_free() is called to unpin/free any memory once an I/O is completed successfully, or if cp_prefetch() fails. But if cp_init() fails, and cp->initialized is not enabled, the same routine cannot be used to free all the memory. An attempt to address this exists in ccwchain_handle_ccw(), where a single call to ccwchain_free() is made for the currently-processed CCW segment. But this will leak other segments (created as a result of a Transfer in Channel) that had been allocated as part of the same channel program. Address this by performing the cleanup outside of the recursive ccwchain_handle_ccw()/ccwchain_loop_tic() logic.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2025-68794", "url": "https://ubuntu.com/security/CVE-2025-68794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: adjust read range correctly for non-block-aligned positions iomap_adjust_read_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio. Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-80781", "url": "https://ubuntu.com/security/CVE-2026-80781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix OOB read of field->usage in hid_set_field() hid_set_field() hands field->usage + offset to hid_dump_input() before the guard that bounds offset: \thid_dump_input(field->report->device, field->usage + offset, value); \tif (offset >= field->report_count) { \t\thid_err(...); \t\treturn -1; \t} Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is allocated inline with the hid_field in hid_register_field() and holds field->maxusage entries, so an offset past it reads off the end of the kvzalloc()ed allocation and into a neighbouring object. Had the guard run first, offset < report_count <= maxusage would already have confined the pointer to the array. A caller supplies such an offset today. picolcd_fb_send_tile() validates only report->maxfield before issuing hid_set_field(report->field[0], 11 + i, ...) for i = 0..31, so its offsets are fixed at 11..42 and are never checked against the bound field. When the device registers that field with fewer usages, the framebuffer deferred-io work drives the read on every tile. KASAN reports a 4-byte slab-out-of-bounds read in hid_dump_input() below hid_set_field(), and the same boot logs \"offset (1) exceeds report_count (1)\" from the guard that runs only afterwards. Move the hid_dump_input() call below the guard. Because field->maxusage >= field->report_count, the guard then establishes that field->usage + offset lies inside the array before it is dereferenced, for every caller and without changing behaviour on the valid path. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80782", "url": "https://ubuntu.com/security/CVE-2026-80782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: do not keep a stale msc->input if no input is claimed magicmouse_input_mapping() caches the first hid_input's input_dev in msc->input while the report descriptor is parsed, and the rest of the driver treats a non-NULL msc->input as proof that an input device was registered. That does not hold on the hid-input error path. If hidinput_connect() fails -- for instance because input_register_device() returns an error -- it unwinds through hidinput_disconnect(), which frees every input_dev it created, including the one cached in msc->input. The failure does not abort the probe. hid_connect() only skips the claim: \tif ((connect_mask & HID_CONNECT_HIDINPUT) && !hidinput_connect(hdev, \t\t\t\tconnect_mask & HID_CONNECT_HIDINPUT_FORCE)) \t\thdev->claimed |= HID_CLAIMED_INPUT; and the \"device has no listeners\" bailout below it does not fire for this driver, which sets ->raw_event; on the USB Magic Mouse 2 / Magic Trackpad 2 paths hidraw and hiddev are claimed as well. hid_hw_start() therefore returns 0 and magicmouse_probe() continues with msc->input pointing at freed memory. Being non-NULL, it passes the \"input not registered\" check in probe and the NULL checks in ->raw_event and ->event, so the next input report dereferences freed memory. Clear msc->input when the HID core did not claim an input device, so the existing NULL checks cover this case as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-80583", "url": "https://ubuntu.com/security/CVE-2026-80583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses The \"DEC0 MODE\" to \"DEC7 MODE\" controls are enumerated, but tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 (\"ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type\") and commit 0ea5eff7c606 (\"ASoC: codecs: va-macro: fix accessing array out of bounds for enum type\"), but tx-macro was missed. On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value sanity check catches the 4 bytes written past the enumerated item and every read of these controls fails with -EINVAL: snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80587", "url": "https://ubuntu.com/security/CVE-2026-80587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid combining some incoming suboptions Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80547", "url": "https://ubuntu.com/security/CVE-2026-80547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Implement a crw lock Unlike the channel_program struct, which covers synchronous I/O submissions and asynchronous interrupts, the CRW region relies exclusively on asynchronous events coming from hardware. Implement a lock to manage the list of those payloads, to ensure they are read cohesively.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80548", "url": "https://ubuntu.com/security/CVE-2026-80548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Selectively expand io_mutex The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80552", "url": "https://ubuntu.com/security/CVE-2026-80552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure index for read/write regions are within range The introduction of the capability chain rightly clamped the region indexes to the range of the capabilities itself, but neglected to do so for the existing read/write regions which should also be enforced.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80788", "url": "https://ubuntu.com/security/CVE-2026-80788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations When fuzzing the nvme target code, I tripped a kernel warning in nvmet_tcp_map_data() because the length passed into the allocator is controlled by the remote initiator. A remote initiator that sends a command with an SGL claiming a huge number, can create a scatterlist and iovec allocation of over 1 million entries, which causes the backing kmalloc call to exceed MAX_PAGE_ORDER and then the page allocator will trip on a WARN_ON_ONCE_GFP() message: WARNING: mm/page_alloc.c:5280 __alloc_frozen_pages_noprof Workqueue: nvmet_tcp_wq nvmet_tcp_io_work ... sgl_alloc_order nvmet_tcp_map_data nvmet_tcp_try_recv_pdu As it's never good to trip a kernel warning remotely due to many systems having panic-on-warn enabled, let's silence it by just add GFP_NOWARN to the allocation flags.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80790", "url": "https://ubuntu.com/security/CVE-2026-80790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: fix invalid free in LS IOD error path nvmet_fc_alloc_ls_iodlist() advances iod while initializing the LS IOD array. If an rqstbuf allocation or response buffer DMA mapping fails, the unwind loop decrements iod past the start of the array. The final kfree(iod) therefore frees an address before the allocated object. This can be reproduced with nvme-fcloop and failslab by setting fail-nth to 6 before creating a target port. KASAN reports: BUG: KASAN: invalid-free in nvmet_fc_register_targetport Free of addr ffff88816cf8ff48 by task nvmet_fail_nth/9552 Free the original allocation base stored in tgtport->iod instead. With this fix applied, the same sysfs write with fail-nth=6 returns -ENOMEM without any KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80792", "url": "https://ubuntu.com/security/CVE-2026-80792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix use-after-free in ip6_finish_output2() ip6_finish_output2() caches a pointer to the IPv6 destination address (daddr) before invoking lwtunnel_xmit(). The LWT-BPF transmit path or other encapsulation operations within lwtunnel_xmit() can reallocate the skb head, freeing the memory that daddr points to. When lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, the function continues to use the stale daddr pointer to compute the nexthop and to look up or create the neighbour entry. This results in a use-after-free read, which can leak sensitive kernel data, pollute the neighbour table with arbitrary values, misdirect traffic, or crash the system. Fix this by re-fetching the IPv6 header and the destination address pointer after lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, ensuring that the subsequent nexthop computation and neighbour lookup operate on valid memory.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80793", "url": "https://ubuntu.com/security/CVE-2026-80793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: reject undersized MTUs in ip_do_fragment() ip_do_fragment() subtracts the IPv4 header length from the effective MTU and passes the resulting payload MTU to ip_frag_next(). If the effective MTU is smaller than hlen + 8, ip_frag_next() rounds the fragment payload length down to zero. The fragmentation state then never makes forward progress: state->left, state->ptr and state->offset stay unchanged while ip_do_fragment() keeps allocating and transmitting header-only fragments until the softlockup detector fires. This is reproducible with a route installed using \"mtu lock 20\", but it is also reproducible without route MTU lock, for example by forwarding a packet to a device whose MTU is 20. Fix it in ip_do_fragment() by rejecting mtu < hlen + 8 with -EMSGSIZE, matching the existing IPv6 fragmentation check.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80557", "url": "https://ubuntu.com/security/CVE-2026-80557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix OOB read in decode_watchers() via missing bounds check ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80794", "url": "https://ubuntu.com/security/CVE-2026-80794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix uninit-value in the RF discover/activated NTF handlers nci_rf_discover_ntf_packet() and nci_rf_intf_activated_ntf_packet() each parse a notification into an on-stack struct (nci_rf_discover_ntf / nci_rf_intf_activated_ntf) that is not initialised. The RF technology-specific parameters are only extracted when rf_tech_specific_params_len is non-zero, so a notification that reports a zero length leaves the rf_tech_specific_params union uninitialised - and both handlers then pass it to nci_add_new_protocol(), which reads it: - discover: nci_add_new_target() -> nci_add_new_protocol(); - activated: nci_target_auto_activated() -> nci_add_new_protocol(). nci_add_new_protocol() uses nfca_poll->nfcid1_len as both a branch condition and a memcpy() length and copies nfcid1/sens_res/sel_res into ndev->targets, which is later exposed to user space via NFC_CMD_GET_TARGET. BUG: KMSAN: uninit-value in nci_add_new_protocol+0x624/0x6c0 nci_add_new_protocol+0x624/0x6c0 nci_ntf_packet+0x25b2/0x3c30 nci_rx_work+0x318/0x5d0 process_scheduled_works+0x84b/0x17a0 worker_thread+0xc10/0x11b0 kthread+0x376/0x500 Local variable ntf.i created at: nci_ntf_packet+0xbc2/0x3c30 Zero-initialise both on-stack notifications so the union reads back as zero when no technology-specific parameters are present.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80795", "url": "https://ubuntu.com/security/CVE-2026-80795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix out-of-bounds write in nci_target_auto_activated() nci_target_auto_activated() appends a target to the fixed-size array ndev->targets[NCI_MAX_DISCOVERED_TARGETS] and increments ndev->n_targets without first checking the array is full; unlike its sibling nci_add_new_target(), which bails out when n_targets already equals NCI_MAX_DISCOVERED_TARGETS. ndev->n_targets is only cleared by nci_clear_target_list(), so an NFCC that repeatedly re-runs discovery (RF_DISCOVER_RSP, which re-enters NCI_DISCOVERY without clearing the target list) and reports an auto-activated target (RF_INTF_ACTIVATED_NTF) drives n_targets past the limit. The append then writes a struct nfc_target past the end of the array (a slab out-of-bounds write), and nfc_targets_found() goes on to walk the array with the inflated count: BUG: KASAN: slab-out-of-bounds in nci_add_new_protocol+0x94/0x2ac [nci] Write of size 2 at addr ffff0000c7299a18 by task kworker/u8:0/12 Workqueue: nfc0_nci_rx_wq nci_rx_work [nci] Call trace: nci_add_new_protocol+0x94/0x2ac [nci] nci_ntf_packet+0xddc/0x11a0 [nci] nci_rx_work+0x15c/0x1e0 [nci] process_one_work+0x2dc/0x500 worker_thread+0x240/0x460 kthread+0x1c0/0x1d0 ret_from_fork+0x10/0x20 The buggy address belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1024 bytes to the right of allocated 1560-byte region [ffff0000c7299000, ffff0000c7299618) Guard nci_target_auto_activated() with the same check used by nci_add_new_target().", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80823", "url": "https://ubuntu.com/security/CVE-2026-80823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: validate ATR_REQ length against the received frame st21nfca_tm_recv_atr_req() checks that the received ATR_REQ frame is at least ST21NFCA_ATR_REQ_MIN_SIZE and that the self-declared atr_req->length is at least sizeof(struct st21nfca_atr_req), but never checks that atr_req->length does not exceed the actual received length (skb->len). st21nfca_tm_send_atr_res() then trusts the declared length: \tgb_len = atr_req->length - sizeof(struct st21nfca_atr_req); \t... \tmemcpy(atr_res->gbi, atr_req->gbi, gb_len); so an RF peer that sends a short frame but sets atr_req->length larger than the frame makes gb_len exceed the general bytes actually present, and the memcpy reads out of bounds past the received skb. Those bytes are placed in the ATR_RES and sent back to the peer (kernel-memory disclosure to a proximity attacker); a larger declared length is an out-of-bounds read (DoS). Reject frames whose declared length exceeds the received length. The adjacent nfc_tm_activated() path in the same function already derives its general-bytes length from skb->len rather than the declared field. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80797", "url": "https://ubuntu.com/security/CVE-2026-80797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: purge fragmented skbs during cleanup pn53x_common_clean() purges resp_q before freeing the common PN533 state, but it leaves fragment_skb untouched. The fragmentation helpers queue transmit fragments there while sending large initiator or target-mode frames, and those skbs remain owned by the driver until they are sent or discarded. If the device is removed while fragments are still queued, the common cleanup path frees the PN533 state without releasing the queued fragment skbs, leaking them. Purge fragment_skb during cleanup alongside resp_q.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80798", "url": "https://ubuntu.com/security/CVE-2026-80798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: reject PDUs shorter than the LLCP header Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes before parsing it. nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/ nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a CONNECT or CC PDU then computes \ttlv_array_len = skb->len - LLCP_HEADER_SIZE; as a size_t and hands it to the TLV walk. When the frame is shorter than the header the subtraction wraps to a huge value and the walk runs far past the buffer, an out-of-bounds read. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Guard the common receive choke point __nfc_llcp_recv(), shared by both the target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so a short skb is dropped before the rx_work worker parses it. Use pskb_may_pull() rather than a skb->len test so the two header bytes are guaranteed to sit in the skb linear area even for a non-linear skb, matching how the sibling NCI and HCI receive paths validate their headers. Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on linux-next. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80799", "url": "https://ubuntu.com/security/CVE-2026-80799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain three related bugs in their TLV parsing loops: 1. 'offset' is declared u8 but tlv_array_len is u16. When TLV data advances offset past 255 it silently wraps to zero, causing infinite loops or double-processing of buffer data. 2. Before reading tlv[0] (type) and tlv[1] (length) there is no check that offset+2 <= tlv_array_len. A truncated TLV causes an OOB read of one byte past the buffer end. 3. After reading the length field, the value bytes are accessed without checking offset+2+length <= tlv_array_len. A crafted length=0xFF on a short buffer causes up to 255 bytes of OOB read past the buffer end. Both functions are reachable without authentication via nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes directly into nfc_llcp_parse_gb_tlv() with no additional validation. Fix all three issues by widening offset from u8 to u16 and adding bounds checks for both the TLV header and value field before each access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80800", "url": "https://ubuntu.com/security/CVE-2026-80800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound the connect_sn TLV walk to the skb Commit 27256cdb290e (\"nfc: llcp: bound SNL TLV parsing to the skb and add length checks\") fixed the unbounded TLV walk in nfc_llcp_recv_snl(), and commit d8bd2dedbde5 (\"nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers\") subsequently bounded nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv(). One sibling parser sharing the same pattern remains unbounded: nfc_llcp_connect_sn(). nfc_llcp_connect_sn() walks a TLV list, reading a two-byte header (type, length) followed by length bytes of value, without checking that the two header bytes or the declared length stay within the buffer. It returns a pointer to a service name of up to 255 bytes that may point past the end of the skb; it is subsequently consumed by memcmp() in nfc_llcp_sock_from_sn(). In addition tlv_array_len was computed as \"skb->len - LLCP_HEADER_SIZE\" in size_t, so a CONNECT/CC frame shorter than the LLCP header underflows to a huge length and the walk runs far past the buffer. nfc_llcp_connect_sn() is reachable from nfc_llcp_recv_connect() and nfc_llcp_recv_cc(), i.e. from received CONNECT and CC PDUs. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP, and the nfc_llcp_rx_skb() dispatcher applies no minimum-length guard. Walk the TLV list by pointer, bounded by skb_tail_pointer(skb), and validate each declared length before use, matching the approach already used for nfc_llcp_recv_snl(). Starting the walk at &skb->data[LLCP_HEADER_SIZE] against the tail pointer also removes the size_t underflow for short frames. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80801", "url": "https://ubuntu.com/security/CVE-2026-80801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: microread: validate target discovery payload lengths microread_target_discovered() parses target discovery payloads from skb->data according to the HCI gate. The fixed field offsets and UID copies were checked only against the destination nfc_target buffers, not against the actual skb length. Validate that each gate-specific payload contains the fixed fields and UID bytes before reading or copying them.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80802", "url": "https://ubuntu.com/security/CVE-2026-80802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: bound the device-reported read length and fix an skb leak fdp_nci_i2c_read() takes the next packet length from two device-supplied bytes and never validates it. The value is a u16 used as the i2c_master_recv() count into a 261-byte on-stack buffer: a malicious, counterfeit or malfunctioning controller (or an i2c bus interposer) can drive it far past the buffer for a stack out-of-bounds write that clobbers the canary and return address, or below the minimum frame size (directly, or by truncating the computed sum) so the header/LRC strip and the next length read run past a short receive. Reject a length outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD], as a corrupted packet already is, and force resynchronization. The same loop allocates one data skb per iteration and assumes a length packet followed by a data packet; a device that sends two data packets in one call leaks the first skb when the second allocation overwrites it. Free a previously allocated skb before allocating the next.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80803", "url": "https://ubuntu.com/security/CVE-2026-80803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: digital: clamp SENSF_RES length to the destination buffer digital_in_recv_sensf_res() memcpy()s resp->len bytes from a remote NFC-F device response into the NFC_SENSF_RES_MAXSIZE-byte target.sensf_res field without an upper-bound check. A nearby malicious NFC-F device can send an oversized SENSF_RES response to overflow the stack-local struct nfc_target. Clamp resp->len to NFC_SENSF_RES_MAXSIZE before the copy. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80536", "url": "https://ubuntu.com/security/CVE-2026-80536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: bounds-check buffer log item's dirty bitmap xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: \tmemcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), \t\titem->ri_buf[i].iov_base, \t\tnbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80553", "url": "https://ubuntu.com/security/CVE-2026-80553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Cancel existing workqueues The initialization of the io_work and crw_work workqueues begs the question of whether they should be un-initialized. Add the corresponding cleanup tags in _release_dev to ensure work isn't dispatched after the private struct is free'd.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74662", "url": "https://ubuntu.com/security/CVE-2026-74662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: publish queues before arming timer inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74666", "url": "https://ubuntu.com/security/CVE-2026-74666", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: synchronize pressure clearing with ring reconfiguration packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74663", "url": "https://ubuntu.com/security/CVE-2026-74663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: reject overly deep qdisc hierarchies Deep qdisc hierarchies can lead to excessive recursion in qdisc tree walkers and exhaust the kernel stack. The existing loop check does not cover the create-and-graft path, so a hierarchy can still be extended by creating a new child qdisc below an already deep parent. Store the hierarchy depth in struct Qdisc and update it when qdiscs are grafted. Reject new child qdiscs once the parent is already at the maximum allowed depth.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74668", "url": "https://ubuntu.com/security/CVE-2026-74668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in TX_RING send path tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative. Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb(). The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74582", "url": "https://ubuntu.com/security/CVE-2026-74582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in non-ring send paths packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-80737", "url": "https://ubuntu.com/security/CVE-2026-80737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: synchronize DMA teardown dmaengine_terminate_all() does not wait for a running callback, so the TX callback can still touch the TX buffer after it is freed. The RX poll timer reads the RX buffers without the port lock. Switch to dmaengine_terminate_sync() and delete the RX timer before freeing the buffers.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74626", "url": "https://ubuntu.com/security/CVE-2026-74626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_netdev: Preserve RX queue depth on allocation failure ntb_netdev_rx_handler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception. A retry path could refill the queue later, but ntb_netdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74637", "url": "https://ubuntu.com/security/CVE-2026-74637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix group leader use-after-free after sibling detach perf_group_detach() handles leader and sibling detach differently. When the group leader is detached, all siblings are promoted to singleton events and their group_leader pointer is reset to themselves. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. That is harmless when the sibling is being closed and freed immediately, as in the DETACH_DEAD path. It is not safe when the sibling is detached but kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the sibling is removed from the context, while its file descriptor can still keep it alive. A typical failing sequence is: - A group contains leader L and sibling S. - CPU hot-unplug detaches S with DETACH_GROUP, removing it from L->sibling_list but leaving S->group_leader == L. - L is later closed and freed. - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and dereferences the freed leader. This was reproduced by running the perf event fuzzer, CPU hotplug, and a stress workload concurrently: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT pc : perf_ioctl+0x34c/0xc68 x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908) Call trace: perf_ioctl+0x34c/0xc68 (P) __arm64_sys_ioctl+0xa0/0xf4 invoke_syscall+0x58/0xe4 el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x40/0xc0 el0t_64_sync_handler+0x68/0xdc el0t_64_sync+0x1c4/0x1c8 The fault happened in perf_ioctl(), where perf_event_for_each() follows the stale group_leader pointer and perf_event_for_each_child() then dereferences the freed leader's context. Fix the use-after-free by promoting the detached sibling to a singleton. Also fix __event_disable() cgroup accounting and event state change.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74647", "url": "https://ubuntu.com/security/CVE-2026-74647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Remove buffer from list prior to unmap operation fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74632", "url": "https://ubuntu.com/security/CVE-2026-74632", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix huge_zero_pfn race Patch series \"mm/huge_memory: fix huge_zero_pfn race\", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80562", "url": "https://ubuntu.com/security/CVE-2026-80562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: ml-ioh: use raw_spinlock_t for the register lock ioh_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irq_set_type callback additionally emits a dev_warn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same fix as commit a02b8950d619 (\"gpio: pch: use raw_spinlock_t for the register lock\"); this driver shares the same structure as gpio-pch.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80805", "url": "https://ubuntu.com/security/CVE-2026-80805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: validate attr entry pointer before field access xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen, valuelen) before checking if the entry pointer itself is within bounds. If nameidx is crafted to point near the end of the buffer, these field accesses can read out-of-bounds before the bounds check at name_end > buf_end is performed. Add explicit bounds checks for entry pointers before accessing their fields. Use offsetof() to check that the start of the flexible array member (nameval/name) is within bounds, which ensures all preceding fields are safe to access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80808", "url": "https://ubuntu.com/security/CVE-2026-80808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: stop retrying saturated xattr cache entries ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked. Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop. Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition. Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80809", "url": "https://ubuntu.com/security/CVE-2026-80809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix missing metadata reservation for large xattrs [BUG] lsetxattr() panics the kernel when setting a large xattr value on a fragmented filesystem where the file already has an external xattr block. [CAUSE] ocfs2_calc_xattr_set_need() never reserves metadata blocks for a new xattr value's extent tree when the file already has an external xattr block. The not_found path leaves meta_add at zero, so meta_ac is NULL when ocfs2_xattr_extend_allocation() runs. A new value root has room for a single extent record. On a fragmented filesystem, the allocator cannot satisfy the xattr value in one contiguous run, so each non-contiguous run requires its own extent record. When the value root's extent list is full and meta_ac is NULL, ocfs2_add_clusters_in_btree() returns RESTART_META, and ocfs2_xattr_extend_allocation() hits BUG_ON(why == RESTART_META). [FIX] The case where no xattr block exists yet already calls ocfs2_extend_meta_needed(&def_xv.xv.xr_list) to reserve value tree metadata. Add the same reservation to the case where an xattr block already exists, making the two cases consistent. Replace the BUG_ON with a -ENOSPC return so that if RESTART_META is returned despite the reservation, the error propagates to userspace instead of panicking the kernel.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80812", "url": "https://ubuntu.com/security/CVE-2026-80812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dummy: Check card index validity at probe snd_dummy_probe() blindly trusts that the given devptr->id value is within the proper card index range. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80814", "url": "https://ubuntu.com/security/CVE-2026-80814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rndis_host: add overflow check in rndis_rx_fixup() Add an overflow check to ensure that data_offset + data_len + 8 does not wrap, which would enable an OOB read of the USB data buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80819", "url": "https://ubuntu.com/security/CVE-2026-80819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept rfcomm_sock_recvmsg() completes a deferred setup by calling rfcomm_dlc_accept() without holding any RFCOMM lock: \tif (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { \t\trfcomm_dlc_accept(d); \t\treturn 0; \t} and rfcomm_dlc_accept() dereferences the session on its first line: \tstruct sock *sk = d->session->sock->sk; Every other path that touches d->session runs under rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). rfcomm_connect_ind() is even documented as \"called under rfcomm_lock()\". This call site is the only one that skips it. The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against teardown, since __rfcomm_dlc_close() returns early when it wins the test_and_clear. But rfcomm_recv_disc() forces the state first: \td->state = BT_CLOSED; \t__rfcomm_dlc_close(d, err); and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2. With the state already BT_CLOSED that switch does not match, the bit is never consulted, and __rfcomm_dlc_close() falls through to rfcomm_dlc_unlink(), which sets d->session = NULL. So a remote DISC on a deferred dlc clears the session while leaving RFCOMM_DEFER_SETUP set. The next recvmsg() then passes the test_and_clear and dereferences a NULL session. No timing window is needed: once the DISC has been processed, the dereference is unconditional. Give rfcomm_dlc_accept() the same shape as rfcomm_dlc_open() and rfcomm_dlc_close(): an exported wrapper that takes rfcomm_mutex and re-checks the session, around a __rfcomm_dlc_accept() that the two in-core callers, which already hold the mutex, keep using. Reproduced on a KASAN + PROVE_LOCKING kernel with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session, opens a dlc on a channel bound with BT_DEFER_SETUP, and sends DISC after the socket is accepted. recv() on the accepted socket then hits: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10 is the offset of sock in struct rfcomm_session. With this patch the same run completes with recv() returning 0 and no report, and lockdep stays quiet, confirming rfcomm_mutex is still taken before lock_sock on this path as it is on the thread side.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80917", "url": "https://ubuntu.com/security/CVE-2026-80917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems On 32-bit systems the config space is too large to ioremap in one go, so pci_ecam_create() maps each bus segment separately and relies on the ->add_bus callback (pci_ecam_add_bus) to populate the per-bus mapping in cfg->winp[]. pci_ecam_map_bus() then uses that mapping as the base for every config access. The generic ECAM ops (pci_generic_ecam_ops) already provide the ->add_bus and ->remove_bus callbacks, but the CAM (legacy) ops in pci-host-generic.c do not. As a result, on a 32-bit host using \"pci-host-cam-generic\" the per-bus mapping is never set up and the first config read dereferences a NULL base, crashing during bus enumeration: Unable to handle kernel NULL pointer dereference at virtual address 00000800 Oops [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 6.9.7+ #43 Hardware name: Digilent Nexys-Video-A7 RV32 (DT) epc : pci_generic_config_read+0x40/0xb0 ra : pci_generic_config_read+0x2c/0xb0 [] pci_generic_config_read+0x40/0xb0 [] pci_bus_read_config_dword+0x50/0xb0 [] pci_bus_generic_read_dev_vendor_id+0x3c/0x1ec [] pci_scan_single_device+0xa4/0x11c [] pci_scan_slot+0x9c/0x23c [] pci_scan_child_bus_extend+0x58/0x2f4 [] pci_scan_root_bus_bridge+0x64/0xe8 [] pci_host_probe+0x20/0xc8 [] pci_host_common_probe+0x144/0x1e4 Fix this by giving the CAM ops the same ->add_bus/->remove_bus callbacks. Since pci_ecam_add_bus() and pci_ecam_remove_bus() are static to ecam.c, move the CAM ops definition there as pci_generic_cam_ops (mirroring pci_generic_ecam_ops) and export it for pci-host-generic.c to reference. [mani: removed timestamp from log]", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1111.116 -proposed tracker (LP: #2170108)", "", " [ Ubuntu: 5.15.0-202.212 ]", "", " * jammy/linux: 5.15.0-202.212 -proposed tracker (LP: #2170970)", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603)", " - bus: fsl-mc: wait for the MC firmware to complete its boot", " - ALSA: usb-audio: Propagate write errors in generic mixer put callbacks", " - ima: return error early if file xattr cannot be changed", " - tee: optee: Allow MT_NORMAL_TAGGED shared memory", " - PCI: Stop setting cached power state to 'unknown' on unbind", " - hfsplus: fix issue of direct writes beyond end-of-file", " - wifi: mac80211: always allow transmitting null-data on TXQs", " - kcsan: Silence -Wmaybe-uninitialized when calling __kcsan_check_access()", " - bridge: Do not suppress ARP probes and DAD NS unconditionally", " - soundwire: validate DT compatible before parsing it", " - media: rc: mceusb: Add support for 04eb:e033", " - s390/cio: Purge based on the cdev's online status", " - thunderbolt: Keep the domain reference while processing hotplug", " - net: dsa: mv88e6xxx: fix number of g1 interrupts for 6320 family", " - net: dsa: mv88e6xxx: define .pot_clear() for 6321", " - net: dsa: mv88e6xxx: enable .rmu_disable() for 6320 family", " - media: em28xx-video: fix missing res_free() on init_usb_xfer failure", " - clk: renesas: cpg-mssr: Add number of clock cells check", " - ASoC: ti: omap3pandora: update board check to use DT compatible", " - mmc: core: Add validation for host-provided max_segs", " - drm/amd/display: Fix CRC open failure during active rendering", " - hfsplus: rework hfsplus_readdir() logic", " - drm/gud: Add RCade Display Adapter VID/PID pair", " - integrity: Check for NULL returned by asymmetric_key_public_key", " - scsi: pm8001: Reject firmware update in fatal error state", " - scsi: pm8001: Reject non-fatal dump when controller is crashed", " - crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y", " - crypto: atmel-ecc - add support for atecc608b", " - media: imon: Add iMON VFD HID OEM v1.2 key mappings", " - RDMA/mlx5: Use QP port when decoding responder CQEs", " - mailbox: Make mbox_send_message() return error code when tx fails", " - ALSA: usx2y: Drain pending US-428 pipe-4 output commands", " - 9p: invalidate readdir buffer on seek", " - arm64/daifflags: Make local_daif_*() helpers __always_inline", " - firmware: arm_scmi: Validate SENSOR_UPDATE payload size", " - firmware: arm_scmi: Validate BASE_ERROR_EVENT payload size", " - bitfield: wire __bf_shf to __builtin_ctzll", " - net: usb: qmi_wwan: add MeiG SRM813Q", " - net: bridge: remove stale rcu_barrier() in br_multicast_dev_del()", " - net/sched: sch_drr: make cl->quantum lockless", " - befs: handle set_blocksize failures", " - minix: handle set_blocksize failures", " - isofs: handle set_blocksize failures", " - usb: host: add ARCH_AIROHA in XHCI MTK dependency", " - char/nvram: Remove redundant nvram_mutex", " - netlabel: fix IPv6 unlabeled address add error handling", " - rds: annotate data-race around rs_seen_congestion", " - s390/zcore: Removed unused variables", " - clk: socfpga: agilex: implement l3_main_free_clk", " - drm/panel: simple: Add AM-1280800W8TZQW-T00H", " - mips: cps: Assemble jr.hb with an R2 ISA level", " - iio: adc: qcom-spmi-iadc: balance enable_irq_wake() on driver unbind", " - irqchip/gic-v4: Don't advertise VLPIs if no ITS is probed", " - ALSA: usb-audio: Add quirk for Novation Mininova", " - drm/amd/pm/si: Fix updating clock limits from power states", " - ACPICA: Improve argument parsing in acpi_ps_get_next_simple_arg()", " - hfs: rework hfsplus_readdir() logic", " - host1x: bus: Fix missing ops null check in error teardown", " - scripts: modpost: detect and report truncated buf_printf() output", " - ASoC: Intel: catpt: Complete coredump handling", " - soundwire: only handle alert events when the peripheral is attached", " - mmc: davinci: fix mmc_add_host order in probe", " - mmc: renesas_sdhi: Add OF entry for RZ/G2N SoC", " - mmc: renesas_sdhi: Add OF entry for RZ/G2E SoC", " - iio: accel: mma8452: switch to non-devm request_threaded_irq()", " - libbpf: Also reset {insn,data}_cur on realloc failure", " - net: ibm: emac: Reserve VLAN header in MJS limit", " - ASoC: codecs: pcm3168a: Drop CONFIG_PM-conditional preproc directive", " - ACPI: PCI: Clear _DEP dependencies after PCI root bridge attach", " - iommu/rockchip: disable fetch dte time limit", " - ASoC: codecs: rk3328: Use managed GPIO and clock helpers", " - ALSA: seq: oss: Reject reads that cannot fit the next event", " - dpaa2-switch: fix the error path in dpaa2_switch_rx()", " - clk: keystone: don't cache clock rate", " - ALSA: hda/realtek: Add quirk for ASUS VivoBook X509DAP", " - ipmi: si: Use platform_get_irq_optional() to retrieve interrupt", " - wifi: nl80211: Increase ie_len size to prevent truncated IEs in new peer", " notifications", " - RDMA/mlx5: Fix state and counter desync on loopback enable failure", " - net: cpsw_new: unregister devlink on port registration failure", " - xprtrdma: Add request-pool slack for delayed recycling", " - configfs_depend_prep(): pass configfs_dirent instead of dentry", " - platform/x86: dell-laptop: add Inspiron N5110 to touchpad LED quirk", " table", " - wifi: mt76: transform aspm_conf for pci_disable_link_state", " - btrfs: protect sb_write_pointer() with invalidate lock", " - hwmon: (adt7462) Add of_match_table to support devicetree", " - ata: libata-pmp: add JMicron JMS562 quirk", " - platform/x86: intel-hid: Add HP ProBook x360 440 G1 to", " button_array_table", " - sctp: Unwind address notifier registration on failure", " - PCI: Avoid SBR for Qualcomm WCN6855/WCN7850 WiFi, SDX62/SDX65 modems", " - dmaengine: dw-axi-dmac: fix PM for system sleep and channel alloc", " - hwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i", " - ASoC: rockchip: rockchip_pdm: Reorder clock enable sequence", " - ASoC: rockchip: spdif: Restore regcache cache-only mode on sync failure", " - sparc64: uprobes: add missing break", " - ptp: ocp: add shutdown callback", " - vsock: use sk_acceptq_is_full() helper in all transports", " - e1000e: limit endianness conversion to boundary words", " - net/sched: act_csum: don't mangle UDP tunnel GSO packets", " - i3c: mipi-i3c-hci: Tolerate i3c_master_add_i3c_dev_locked() failures in", " DAA", " - sparc: Disable compat support with LLD", " - fuse: set ff->flock only on success", " - scsi: bfa: Reduce kernel stack usage in", " bfa_fcs_lport_fdmi_build_portattr_block()", " - gpio: pisosr: Read \"ngpios\" as u32", " - ALSA: hda/conexant: Add pin config quirk for Lenovo IdeaPad Slim 5", " 16AKP10", " - leds: uleds: Return -EFAULT on copy_to_user() failure", " - leds: pca9532: Don't stop blinking for non-zero brightness", " - mfd: rsmu: Add 8a34002 support", " - ALSA: usb-audio: Add quirk for YAMAHA CDS3000", " - md/raid5: account discard IO", " - md/raid5: let stripe batch bm_seq comparison wrap-safe", " - rtc: aspeed: add AST2700 compatible", " - ksmbd: use connection ClientGUID for lease lookup", " - ksmbd: treat unnamed DATA stream as base file", " - ksmbd: apply create security descriptor first", " - ksmbd: break RH leases before delete-on-close", " - PCI/sysfs: Use kstrtobool() to parse the ROM attribute input", " - rtc: bq32000: add delay between RTC reads", " - fbdev: pm2fb: unwind WC setup on probe failure", " - drm/arm/malidp: use clk_bulk API in runtime PM resume and suspend", " - netfilter: nf_conntrack_expect: zero at allocation time", " - drm/arm/komeda: fix error handling for clk_prepare_enable() and callers", " - ksmbd: fix n.data memory leak in ksmbd_vfs_set_dos_attrib_xattr", " - xen/front-pgdir-shbuf: free grant reference head on errors", " - freevxfs: don't BUG() on unknown typed-extent type", " - xen/gntalloc: validate grant count before allocation", " - ksmbd: fix credit charge calculation for SMB2 QUERY_INFO", " - wifi: ralink: RT2X00: init EEPROM properly", " - wifi: mac80211: validate deauth frame length before reason access", " - wifi: libertas: reject short monitor TX frames", " - ksmbd: find bound sessions during reauthentication", " - ksmbd: mark invalid session responses as signed", " - ksmbd: validate SID namespace before mapping IDs", " - gpio: dwapb: Mask interrupts at hardware initialization", " - netfilter: ipset: mark the rcu locked areas properly", " - btrfs: only account delalloc bytes for regular file inodes in", " btrfs_getattr()", " - wifi: iwlwifi: mvm: fix sched scan IE sizing", " - arm64: fixmap: Allow 256K early_ioremap() at any offset", " - arm64: kprobes: Allow reentering kprobes while single-stepping", " - drm/amd/pm/si: Don't schedule thermal work when queue isn't initialized", " - ALSA: usb-audio: Add FIXED_RATE quirk for JBL Quantum650 Wireless", " - wifi: mwifiex: replace one-element arrays with flexible array members", " - regulator: core: clamp voltage constraints before applying apply_uV", " - wifi: mac80211_hwsim: reject undersized HWSIM_ATTR_TX_INFO", " - drm/gma500: return errors from Oaktrail HDMI I2C reads", " - phonet: check register_netdevice_notifier() error in", " phonet_device_init()", " - ALSA: hda/realtek: Add mute LED quirk for HP Laptop 14s-dr1xxx", " - ice: pass the return value of skb_checksum_help()", " - powerpc/pseries: Ensure vpa,slb_shadow & dtl are unregistered during", " crash", " - ALSA: usb-audio: Add quirk for Corsair Virtuoso (later revision)", " - ASoC: rt5645: Perform the initial jack detect at probe", " - clk: at91: pmc: #undef field_{get,prep}() before definition", " - Revert \"Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU\"", " - Revert \"Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU\"", " - ARM: 9484/1: enable interrupts when unhandled user faults are triggered", " - EDAC/igen6: Fix interleave boundary condition", " - EDAC/igen6: Fix channel selection hash", " - EDAC/igen6: Fix channel address decode for non-hash mode", " - drm/virtio: Fix a NULL vs ERR_PTR() bug in", " virtio_gpu_user_framebuffer_create()", " - selftests/cgroup: Fix cg_run_in_subcgroups ignoring arg parameter", " - net/sched: act_api: budget all shared attributes in notify skbs", " - net/sched: act_api: size the RTM_GETACTION reply from the actions", " - smb: client: transport: Fix debug printing in __release_mid()", " - net: amd-xgbe: discard rx packets with bad FCS", " - OPP: of: Fix potential multiplication overflow when calculating freq", " - Bluetooth: L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM", " - Bluetooth: hci_mrvl: Fix wrong return value check of", " wait_on_bit_timeout()", " - ASoC: ab8500: Reset the audio block before configuring it", " - ASoC: ab8500: Repair the DAPM capture graph", " - ASoC: ab8500: Update to modern clocking terminology", " - ASoC: ab8500: Correct digital interface format setup", " - ASoC: ab8500: Validate and program TDM slots correctly", " - tty: make tty_ldisc_ops::hangup return void", " - ppp: ppp_async: simplify tty disc_data access", " - ASoC: amd: renoir: fix disable_pdm_interrupts() to clear mask bits", " - btrfs: consolidate device_list_mutex in prepare_sprout to its parent", " - scsi: mpt3sas: Use irq_set_affinity_and_hint()", " - perf/core: Skip empty AUX records with only format flags", " - locking/lockdep: Introduce lock_sync()", " - locking/lockdep: Improve the deadlock scenario print for sync and read", " lock", " - lockdep: Add lock_set_cmp_fn() annotation", " - locking/lockdep: Invalidate stale class_cache entries for zapped classes", " - ASoC: ux500: Fix MSP stream lifecycle handling", " - ASoC: ux500: remove platform_data support", " - ASoC: ux500: Propagate MSP setup errors", " - ASoC: ux500: Correct MSP frame and bit clock setup", " - ASoC: ux500: Validate MSP DAI configuration", " - ASoC: ux500: remove stedma40 references", " - ASoC: ux500: Request the MSP MMIO resource", " - ASoC: ux500: Program the MSP FIFO watermarks", " - net/rds: use clear_bit_unlock() in release_refill()", " - net/rds: tcp: don't force RDS_CONN_RESETTING over a concurrent shutdown", " - net: stmmac: reconfigure RX packet parser table in stmmac_hw_setup()", " after reset", " - bonding: use skb_cow_head() in bond_do_alb_xmit() and rlb_arp_xmit()", " - powerpc/kexec_file: Use inclusive range checks in add_usable_mem()", " - net/mlx5e: Fix setting RS FEC after remapping", " - net/mlx5e: Fix ETS zero BW reporting when one TC holds 100%", " - net_sched: sch_fq_pie: implement lockless fq_pie_dump()", " - net/sched: pie: clamp psched_mtu in pie_drop_early", " - ASoC: bcm: bcm63xx: Publish the OF module aliases", " - ASoC: Intel: SST: Publish the PCI module aliases", " - netfilter: ip6_tables: set F_PROTO when proto value is nonzero", " - ASoC: mt6351: Publish the OF module alias", " - virtio-console: call scheduler when we free unused buffs", " - vdpa_sim_blk: use dev_dbg() to print errors", " - vdpa_sim_blk: make vdpasim_blk_check_range usable by other requests", " - virtio-pci: return IRQ_HANDLED after non-zero ISR", " - net: ipv6: Clamp to IP6_MAX_MTU in ip6_dst_mtu_maybe_forward", " - net: ethernet: cortina: Finish RX updates before NAPI completion", " - net: ethernet: cortina: No mapping is a dropped rx", " - net: ethernet: cortina: Count RX drops once per frame", " - net: ethernet: cortina: Count RX descriptors for freeq refill", " - watchdog: fix hrtimer start when pretimeout is zero", " - hwmon: (gpio-fan) take fan_data->lock in gpio_fan_shutdown()", " - hwmon: (aspeed-pwm-tacho) Propagate reset deassert errors", " - net: stmmac: optimize locking around PTP clock reads", " - net: sun4i-emac: fix missing of_node_put() for phy_node", " - octeontx2-af: fix PF/CGX debugfs PCI bus lookup", " - net/rds: Pass a pointer to virt_to_page()", " - scsi: target: iscsi: Handle abort for WRITE_PENDING cmds", " - Revert \"scsi: smartpqi: Fix AIO retry marker cleared by SCSI core", " between dispatches.\"", " - Revert \"scsi: smartpqi: Fix BUILD_BUG_ON() statements\"", " - Revert \"scsi: core: Register sysfs attributes earlier\"", " - Revert \"scsi: smartpqi: Capture controller reason codes\"", " - ALSA: ctxfi: Fix CA20K2 S/PDIF passthrough", " - dm/amdgpu: fix malformed link_settings debugfs output", " - watchdog: sunxi_wdt: preserve boot-enabled watchdog", " - tunnels: Drop stale dst when building an ICMP error for PMTUD", " - exec: do_close_on_exec() before taking exec_update_lock", " - net: hso: fix TIOCMIWAIT race", " - netfilter: report NLM_F_DUMP_FILTERED when all is filtered out", " - KVM: PPC: Book3S HV: Set irqfd->producer only on success", " - s390/qeth: allow bridgeport queries despite OS_MISMATCH", " - hwmon: (applesmc) fix key backlight workqueue leak on register failure", " - hwmon: (pmbus) Clear generic status alarms with CLEAR_FAULTS", " - media: hevc: add bounded tile-count helpers", " - media: v4l2-h264: Fix memcmp() size in B1 reference list comparison", " - mptcp: options: handle MPC data + csum reqd + no csum", " - Revert \"perf tests: Fix flakiness in BPF counters test on hybrid", " systems\"", " - [Config] remove CRYPTO_DEV_SUN8I_CE_PRNG", " - [Config] remove CRYPTO_DEV_SUN8I_SS_PRNG", " - netfilter: nft_set_pipapo_avx2: add missing vzeroupper", " - ARM: fix hash_name() fault", " - ARM: fix branch predictor hardening", " - ARM: ensure interrupts are enabled in __do_user_fault()", " - Bluetooth: L2CAP: Fix deadlock", " - Revert \"alpha: don't leak hardware-fabricated FP exception bits to user", " space\"", " - Revert \"alpha: fix ieee_swcr_to_fpcr setting FPCR_DNOD unconditionally\"", " - selftests/landlock: Add tests for whiteout object creation", " - sunvdc: fix -EIO issue due to lack of retries", " - Revert \"perf cs-etm: Avoid truncating AUX buffer sizes to int\"", " - Revert \"perf cs-etm: Flush thread stacks after decoder reset\"", " - media: video-i2c: fix buffer queue ordering", " - ipv6: Select best matching nexthop object in fib6_table_lookup()", " - ipv6: Honor oif when choosing nexthop for locally generated traffic", " - xfrm: propagate extack to all netlink doit handlers", " - xfrm: add extack to verify_sec_ctx_len", " - xfrm: add extack support to verify_newsa_info", " - xfrm: add extack to verify_one_alg, verify_auth_trunc, verify_aead", " - xfrm: avoid RCU warnings around the per-netns netlink socket", " - xfrm: fix compat ALLOCSPI request use-after-free", " - xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for", " xfrm_trans_reinject()", " - ARM: socfpga: select the PL310 erratum 753970 workaround", " - RDMA/siw: Introduce siw_cep_set_free_and_put", " - RDMA/siw: Cleanup siw_accept", " - RDMA/siw: Clear association under lock if siw_qp_modify fails in", " siw_accept", " - firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS", " - clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate", " - IB/iser: Align coding style across driver", " - IB/iser: Remove iser_reg_data_sg helper function", " - IB/iser: Use iser_fr_desc as registration context", " - IB/iser: reject a remote invalidation of an unregistered direction", " - scsi: target: iscsi: Rename iscsi_cmd to iscsit_cmd", " - IB/isert: wait for deferred control PDU completions before releasing the", " connection", " - RDMA/mad: Fix receive buffer leak when PKey enforcement fails", " - RDMA/irdma: Enforce local fence for IB_WR_REG_MR", " - RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted", " - dmaengine: sprd: Fix runtime PM reference leak in probe", " - wifi: virt_wifi: free skb when disconnected", " - wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path", " - wifi: libipw: reject too-short beacon and probe responses", " - wifi: libipw: reject too-short association responses", " - IB/IPoIB: Avoid restoring OPER_UP after multicast flush", " - wifi: cfg80211: check IP header size in cfg80211_classify8021d()", " - soundwire: cadence_master: wait and cancel cdns->work before clock stop", " - MIPS: Octeon: apply USB FDT fixups also when USB is modular", " - dma-coherent: Warn if OF reserved memory is beyond current coherent DMA", " mask", " - dma-coherent: report a failed reserved memory assignment", " - dmaengine: Fix device kref underflow in dma_chan_put()", " - dmaengine: fix use-after-free in dma_chan_put() and", " dma_release_channel()", " - dmaengine: wait for RCU readers before releasing dma_device", " - wifi: cfg80211: only group hidden BSSes with beacon entries", " - wifi: cfg80211: don't filter by BSS type when removing stale entries", " - wifi: mac80211: suppress chanctx warning for debugfs reset", " - wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown", " - wifi: mac80211: don't RCU-dereference the mesh CSA settings we just set", " - wifi: mac80211: don't access the TSF of a down interface", " - dmaengine: xilinx_dma: Fix hardware buffer descriptor reuse order", " - dmaengine: xilinx_dma: Fix hardware buffer descriptor chain after cyclic", " DMA", " - RDMA/siw: Bound fragmented header copies by the remaining length", " - netfilter: nft_nat: fully initialise new_addr in netmap setup", " - netfilter: flowtable: hold reference on ct until flow is released", " - drm: Fix drm_pending_vblank_event leak in error path for out_fence_ptr", " - keys: fix lost wakeup when reaping a dead key type", " - ALSA: pcm: set timer->private_data before registering the PCM timer", " - Input: trackpoint - fix the inertia attribute name in the ABI document", " - wifi: virt_wifi: don't transfer operstate before register", " - ALSA: hda: trace PCM open only after assigning a stream", " - btrfs: tree-checker: print dev extent offset in error message", " - drm/msm/dsi: correct byte intf clock rate for 14nm DSI PHY", " - drm/msm/dsi: round the byte clock rate after reparenting to the PHY PLL", " - seg6: set IPSKB_L3SLAVE from IP6SKB_L3SLAVE on IPIP decapsulation", " - net: fddi: skfp: fix NULL deref when setting the MAC address while down", " - wifi: brcmfmac: fix lost 802.1x TX completion wakeup", " - tcp: Don't call skb_clone_and_charge_r() for close()d listener in", " tcp_v6_do_rcv().", " - tcp: do not let tcp_rmem be set below 4096", " - dmaengine: mmp_pdma: fix wrong sg length in mmp_pdma_prep_slave_sg()", " - Bluetooth: btmtksdio: Fix PM runtime reference leak in shutdown", " - Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup", " - pppoatm: ensure a writable skb header and linear data", " - drop_monitor: synchronize tracepoint unregistration on error path", " - drop_monitor: fix out-of-bounds write in reset_per_cpu_data()", " - KVM: PPC: Book3S HV: fix secure device page leak on uv_page_in() failure", " - powerpc/iommu: Fix the overflow validation in iommu_tce_check_ioba", " - ASoC: ux500: Parenthesize MSP_{RX,TX}_CLKPOL_BIT() arguments", " - ASoC: hdmi-codec: Report a change when the channel status moves", " - net: netsec: fix device_node reference leak on phy_np", " - net: lock the socket in sock_gettstamp()", " - net: ethernet: cortina: Ack RX overrun interrupt correctly", " - net: mvpp2: prevent buffer overflow in page_pool allocation", " - Input: eeti_ts - publish the OF module alias", " - Input: xpad - add support for Victrix Pro BFG Controller", " - Input: xpad - add support for Azeron devices", " - Input: xpad - fix PDP Marvel Xbox 360 controller", " - ata: libahci: clear PxCLBU and PxFBU for AHCI_HFLAG_32BIT_ONLY", " - rds: ib: use rds_conn_drop() on protocol version mismatch", " - tcp: exclude old ACKs from tcp fast path", " - RDMA/ucma: Serialize join and leave on copy_to_user failure", " - RDMA/core: fix refcount bug in iwpm_get_nlmsg_request()", " - openvswitch: avoid reallocating confirmed conntrack labels", " - net: xfrm: reject unrepresentable espintcp transport headers", " - kselftest/arm64: Fix size of thread_data values for pthread_join()", " - arm64: percpu: Fix this_cpu_write() casting", " - arm64: percpu: Fix this_cpu_and() mask generation", " - Bluetooth: btusb: fix NXP IW610 composite device handling", " - dmaengine: sun6i: fix non-atomic read of DMA position registers", " - dmaengine: sun6i: fix undefined behaviour in sun6i_dma_tx_status", " - dmaengine: ti: k3-udma-glue: fix NULL dereference in", " k3_udma_glue_release_rx_chn()", " - ipv6: xfrm: use full sockets in local error paths", " - net: wwan: mhi_wwan_mbim: guard against a cyclic NDP chain", " - net: wwan: mhi_wwan_mbim: check skb_copy_bits() return value", " - net/sched: hhf: cap hh_flows_limit at change time", " - net/packet: clear RX owner on VNET header error", " - net/packet: avoid truncating TPACKET_V3 private size", " - keys: translate request_key_auth pid for the reading procfs instance", " - KEYS: trusted: Fix tpm2_load_cmd() boundary check", " - i2c: at91: release DMA channels on remove and probe error", " - i2c: imx: release DMA channels on probe error", " - IB/mlx4: Fix use-after-free on pkey sysfs registration failure", " - selinux: always fill AVC decision in avc_has_perm_noaudit()", " - mmc: core: Fix OF node reference leak on card add failure", " - mmc: mxcmmc: cancel data work and watchdog on remove", " - mmc: rtsx_pci_sdmmc: ignore broken write-protect on ThinkPad X260", " - mmc: sdhci-of-aspeed: Remove children before releasing SDC resources", " - mmc: sdio_uart: fix xmit_fifo leak when the port table is full", " - mmc: sh_mmcif: initialize IRQ-thread mutex before requesting interrupt", " - mmc: spi: reset bytes_xfered before retrying CRC failures", " - mmc: sdhci_am654: Reset command and data lines on failed tuning", " - Input: atkbd - skip deactivate for Xiaomi Redmi Book Pro 16 2026", " - Input: evdev - zero absinfo before partial copy in EVIOCSABS", " - Input: i8042 - add quirk for Acer Aspire Go 15 AG15-42P", " - Input: rmi_smbus - fix out-of-bounds read in rmi_smb_write_block()", " - Input: soc_button_array - fix MS Surface Pro 11 probe failure", " - Input: soc_button_array - check btns_desc->package.count", " - Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722)", " - Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound", " - Input: zero ff_effect before compat copy in input_ff_effect_from_user", " - hwmon: (pmbus/core) increase number of phases and add new mask", " - hwmon: (pmbus/tps53679) Fix TPS53676 phase page decoding", " - hwmon: (pmbus/tps53679) Select page 0 for single-page TPS53676", " - hwmon: (w83791d) remove fan/pwm 4-5 sysfs group on remove", " - hwmon: (w83793) release probe data through kref", " - watchdog: digicolor: Avoid division by zero", " - watchdog: msc313e: Fix premature reset during timeout update", " - watchdog: sp5100_tco: Fix pci_dev reference leak in sp5100_tco_init()", " - wifi: brcmsmac: fix UAF in brcms_free_timer()", " - wifi: iwlegacy: fix broadcast stations deallocation", " - wifi: libertas_tf: fix UAF in lbtf_free_adapter()", " - wifi: rsi: fix heap OOB write on key removal", " - wifi: wlcore: release runtime PM ref on regdomain config failure", " - wifi: wilc1000: fix out-of-bounds read in P2P public action frames", " - wifi: wilc1000: fix RX buffer OOB-write in wilc_wlan_handle_isr_ext()", " - wifi: p54: validate curve data length in the calibration curve", " converters", " - wifi: p54: require a full exp_if record in PDR_INTERFACE_LIST", " - wifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length", " - wifi: mwifiex: validate scan response extents", " - wifi: mwifiex: validate action frame fixed fields", " - wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver", " - drm/gud: fix out-of-bounds write in gud_plane_atomic_check()", " - drm/msm/adreno: fix autosuspend cleanup during teardown", " - drm/msm/hdmi_phy: fix runtime PM cleanup on probe failure", " - HID: logitech-hidpp: fix race condition when accessing stale stack", " pointer", " - spi: spi-zynqmp-gqspi: stop the controller on shutdown", " - spi: zynqmp-gqspi: Use devm_spi_alloc_host()", " - erofs: fix atomic context detection when !CONFIG_DEBUG_LOCK_ALLOC", " - HID: hyperv: streamline driver probe to avoid devres issues", " - bpf: Fix bpf_skb_change_tail wrt csum partial skbs", " - bpf: Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL", " - bpf: support access variable length array of integer type", " - bpf: Fix divide-by-zero in btf_struct_walk()", " - HID: elecom: fix bus type for M-XGL20DLBK", " - bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch()", " - bpf: Fix out-of-bounds read of rtt_min in sock_ops", " - HID: amd_sfh: Move common macros and structures", " - HID: amd_sfh: Validate PCI BAR size before mapping", " - squashfs: Add dictionary size range check to prevent shift-out-of-bounds", " - Bluetooth: SMP: reject Security Request over BR/EDR", " - Documentation: s390: correct spelling", " - docs: s390/pci: Improve and update PCI documentation", " - s390/pci/docs: Fix sriov_numvfs attribute name", " - s390/cio: Fix cio_update_schib() to not cache invalid schib", " - s390/cio: Check pmcw.dnv before pmcw.ena in I/O entry points", " - xsk: Use a 32-bit compare in xsk_map_gen_lookup", " - libbpf: Fix an error in 64bit relocation value computation", " - bpf: Restrict CO-RE poisoning to relocatable instructions", " - netfilter: flowtable: allow unidirectional rules", " - netfilter: flowtable: publish HW_DEAD after worker is done", " - netfilter: nfnetlink_queue: nfqnl_instance GFP_ATOMIC ->", " GFP_KERNEL_ACCOUNT allocation", " - netfilter: nfnetlink_queue: hold nfnl mutex in event notifier", " - netfilter: nft_synproxy: use the family-aware checksum helper", " - ipvs: revalidate ihl before icmp_send", " - ocfs2: make ocfs2_calc_xattr_init() return void", " - drm/nouveau/clk: fix list cursor use after loop in", " nvkm_clk_ustate_update", " - drm/nouveau/clk: don't clobber reclock status when restoring volt/fan", " - net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure", " - net: gue: reject invalid REMCSUM offsets", " - ip6_gre: Call ip6erspan_tunnel_unlink_md() in ip6erspan_changelink().", " - sctp: avoid livelock while updating retransmit path", " - net: usb: catc: bound the RX packet length in catc_rx_done()", " - net/sched: sch_hfsc: bound the classify inner-filter walk with a drift", " budget", " - drm/virtio: fix object leak when drm_gem_handle_create() fails", " - drm/virtio: fix object leak in virtio_gpu_resource_create_ioctl()", " - drm/virtio: fix object leaks in virtio_gpu_resource_create_blob_ioctl()", " - drm/virtio: release the GEM object on virtio_gpu_vram_create() errors", " - Bluetooth: bnep: fix out-of-bounds reads on short RX/TX frames and", " control fallthrough", " - Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame()", " - net: usb: sr9700: include receive overhead in the length check", " - tg3: clean up PHYLIB resources on probe failure", " - s390/debug: Do not register views for failed static debug areas", " - s390/debug: Fix NULL pointer dereference in debug_info_copy()", " - net: ethernet: ti: netcp: fix pm_runtime usage counter leak on error", " - bpf: Fix bpf_sock context code generation", " - bpf, sockmap: Reject max_entries > INT_MAX in sock_map_alloc", " - sctp: hold asoc or transport before mod_timer() in timer handlers", " - net: stmmac: selftests: Support running selftests on DSA conduits", " - net: stmmac: selftests: Check the dev->features for S-TAG offload", " testing", " - net: stmmac: selftests: Capture all packets for vlan checks", " - net: stmmac: Remove some unnecessary void pointers", " - net: stmmac: dwmac4: Use the correct bufzise when the len is exactly 8K", " - nfc: nfcmrvl: validate helper command length before pull", " - nfc: st21nfca: remove redundant assignment to variable i", " - nfc: st21nfca: validate received frame size", " - nfc: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm()", " - selftests: nci: Correct pthread_create return value check", " - nfc: llcp: Fix race condition in accept_queue lifecycle", " - selftests: nci: Fix uninitialized family ID on missing attribute", " - selftests/nci: Fix out-of-bounds store on thread join", " - nfc: virtual_ncidev: Add missing ioctl compat handler", " - nfc: llcp: fix sdreq TLV list leak on parse/alloc/send failure", " - nfc: st21nfca: validate ISO15693 inventory length", " - nfc: llcp: fix -ENOMEM on connect with zero-length service name", " - nfc: llcp: fix WKS SAP hijacking via prefix match in nfc_llcp_wks_sap()", " - nfc: llcp: fix slab-out-of-bounds reads when logging service names", " - nfc: pn533: fix OOB read in pn533_acr122_is_rx_frame_valid()", " - veth: manage XDP program pointers during channel resize", " - net: skbuff: fix pull-bound underflow in skb_checksum_setup_ipv6()", " - vrf: Stop corrupting skb->csum when capturing CHECKSUM_COMPLETE packets", " - net: bcmgenet: validate Ethernet address in bcmgenet_set_mac_addr", " - ip_gre: Reject enabling collect metadata through changelink", " - net: xps: reject an out of range traffic class", " - tcp: fix use-after-free of retransmit_skb_hint in tcp_send_synack()", " - net/smc: fix UAF on lgr list traversal in smcr_port_err()", " - tipc: Fix a data race on mon->peer_cnt in mon_timeout()", " - llc: fix skb UAF and leaks on llc_mac_hdr_init() failure", " - bridge: check llc_mac_hdr_init() return value in br_send_bpdu()", " - net/sched: sch_teql: fix shadowed err in __teql_resolve()", " - vlan: ensure sufficient headroom in vlan_dev_hard_header()", " - autofs: fix sbi->pipe file reference leak in autofs_kill_sb()", " - rculist: add list_splice_rcu() for private lists", " - KVM: x86/mmu: Use a bool for direct", " - KVM: x86/mmu: Stop passing \"direct\" to mmu_alloc_root()", " - KVM: MMU: update comment on the number of page role combinations", " - KVM: X86: Remove useless code to set role.gpte_is_8_bytes when", " role.direct", " - KVM: X86: Calculate quadrant when !role.gpte_is_8_bytes", " - KVM: X86: Rename gpte_is_8_bytes to has_4_byte_gpte and invert the", " direction", " - KVM: x86/mmu: Derive shadow MMU page role from parent", " - KVM: x86/mmu: Always pass 0 for @quadrant when gptes are 8 bytes", " - SAUCE: Revert \"KVM: x86: Fix shadow paging use-after-free due to", " unexpected role\"", " - KVM: x86/mmu: pull call to drop_large_spte() into __link_shadow_page()", " - KVM: x86: Fix shadow paging use-after-free due to unexpected role", " - x86/PCI: Disable enhanced atomics on AMD NBIO 7.7 and 7.11", " - tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers", " underflow", " - sctp: discard the rest of the packet on a stale-cookie error", " - af_packet: fix integer overflow in prb_calc_retire_blk_tmo()", " - fou: reject omitted FOU_ATTR_IPPROTO on FOU_ENCAP_DIRECT", " - workqueue: Fix NULL current_pwq deref in flush dependency check", " - writeback: report a Tasks-RCU quiescent state per cgwb drain pass", " - fsl/fman: Fix clk reference leak in read_dts_node()", " - ipv6: do not let ipv6_find_hdr() return an offset past the packet end", " - ipv6: sr: enforce exact attribute length for SEG6_ATTR_DST", " - gpio: arizona: Fix runtime PM leak in arizona_gpio_direction_out()", " - gpio: zynq: fix runtime PM leak on request error path", " - llc: reserve device headroom for allocated frames", " - rds: ib: Clear the sg list when mapping an MR fails", " - drm/nouveau: fix autosuspend cleanup during teardown", " - drm/nouveau: Fix bridge reference leak in nv1a_ram_new()", " - drm/nouveau: fix double-free in nvif_vmm_dtor", " - drm/nouveau: Fix gem reference leak in validate_init()", " - drm/nouveau: don't bump pin count on failed re-pin in", " nouveau_bo_pin_locked()", " - HID: alps: fix use-after-free on input2 registration failure", " - HID: quirks: add ALWAYS_POLL quirk for SDINNOVATION gaming keyboard", " - HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()", " - net/mlx5: Fix rev_entry reference leak in", " mlx5_tc_ct_shared_counter_get()", " - net/sched: reject IDR error pointers when deleting actions", " - net: arp: terminate device name before lookup", " - net: atl1: fix soft lockup on out-of-range cmb_tpd_next_to_clean read", " - net: hisilicon: hns_dsaf_mac: fix mdio device leak in", " hns_mac_register_phy()", " - net: openvswitch: conntrack: avoid modifying shared unconfirmed ct entry", " - net: atl1c: fix soft lockup on out-of-range tpd_cons read", " - net: atl1e: fix soft lockup on out-of-range hw_next_to_clean read", " - net: usb: cdc_mbim: add MeiG Smart SRM821 to ZLP whitelist", " - netfilter: ip6t_rpfilter: reject routes without inet6_dev", " - netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds read", " - nfc: fix use-after-free in nfc_get_local_general_bytes", " - nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc()", " - nfc: port100: reject frames whose declared length exceeds the received", " data", " - scsi: libiscsi_tcp: Check the data direction of a Data-In PDU", " - pinctrl: single: free the IRQ on domain creation failure", " - s390/cio: Fix NULL pointer dereference in ccw_device_get_util_str()", " - Bluetooth: hci_sock: validate event length before filtering", " - Bluetooth: hci_sock: reject out-of-range OCF values", " - Bluetooth: L2CAP: validate frame length before control and FCS access", " - Bluetooth: RFCOMM: fix NULL dereference of dlc->session in", " RFCOMM_CONNINFO", " - xfs: fix blockgc group quota scanning when usrquota isn't enforced", " - net: tls: fix silent data drop under pipe back-pressure", " - file: add fput() cleanup helper", " - eventpoll: use hlist_is_singular_node() in __ep_remove()", " - eventpoll: split __ep_remove()", " - eventpoll: kill __ep_remove()", " - eventpoll: drop vestigial __ prefix from ep_remove_{file,epi}()", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: move epi_fget() up", " - perf test: Change all remaining #!/bin/sh to #!/bin/bash", " - tools/thermal/tmon: Fix compilation warning for wrong format", " - lan78xx: Enable 125 MHz CLK configuration for LAN7801 if NO EEPROM is", " detected", " - lan78xx: Enable Auto Speed and Auto Duplex configuration for LAN7801 if", " NO EEPROM is detected", " - Linux 5.15.222", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2025-68190", " - drm/amdgpu/atom: Check kcalloc() for WS buffer in", " amdgpu_atom_execute_table_locked()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-46242", " - eventpoll: fix ep_remove struct eventpoll / struct file UAF", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2025-38349", " - eventpoll: don't decrement ep refcount while still holding the ep mutex", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2025-37964 -- to the 6.1, 6.6 and 6.12 trees ended up with two", " - x86/mm: Fix check/use ordering in switch_mm_irqs_off()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-80726", " - KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow", " page", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-46113", " - KVM: x86: Fix shadow paging use-after-free due to unexpected GFN", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-52988", " - netfilter: nf_tables: join hook list via splice_list_rcu() in commit", " phase", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2023-53231", " - erofs: Fix detection of atomic context", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2023-53707", " - drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2024-49568", " - net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal", " msg", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-89560", " - landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2024-41062", " - bluetooth/l2cap: sync sock recv cb and release", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2022-50406", " - iomap: iomap: fix memory corruption when recording errors during", " writeback", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97523", " - mptcp: close race between scheduler and state change", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97524", " - mptcp: avoid unneeded actions on subflow reset", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-80833", " - crypto: sun8i-ss - Remove crypto_rng interface", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-80834", " - crypto: sun8i-ce - Remove crypto_rng interface", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-74496", " - fou: Fix use-after-free in fou_create()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93286", " - net: appletalk: fix NULL pointer dereference in aarp_send_ddp()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93287", " - i2c: smbus: reject oversized block transfers in the common path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97931", " - ALSA: us122l: Prevent write upgrades for read mappings", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97568", " - mptcp: syncookies: remember the request backup flag", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97572", " - bnxt_en: Propagate RX ring init failures in bnxt_init_nic()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97573", " - bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97576", " - media: v4l2-ctrls: validate HEVC tile counts", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97582", " - hwmon: (gpio-fan) Fix use-after-free in alarm work", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97592", " - s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm", " algorithm", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97596", " - ipvs: reject invalid states in connection template sync records", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97598", " - ipv4: fib: bound automatic table ID allocation", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97601", " - ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97604", " - fbdev: vfb: defer cleanup until the last reference", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97608", " - netfilter: nf_log: unregister loggers before per-net teardown", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97611", " - net: openvswitch: fix use-after-free of the flow table mask array", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97612", " - net: mpls: clear inner_protocol when the last label is popped", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97899", " - drm/i915: Fix memory leak in query_perf_config_list()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97904", " - cpufreq: initialize policy rwsem before sysfs publication", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97905", " - cpufreq: zero-initialize policy cpumask before sysfs publication", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97909", " - ASoC: sti: initialize IRQ lock before requesting IRQ", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97910", " - ASoC: sprd: validate compress buffer sizes against fixed allocations", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97923", " - tracing: Free histogram the var ref when its initialization fails", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97926", " - ufs: validate cylinder group metadata before caching it", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97927", " - ufs: create the root dentry after loading cylinder metadata", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97930", " - ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97940", " - ipv6: fix fib6 walker UAF on seq stop", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97948", " - powerpc/eeh: Fix recursive locking on devices without EEH sensitive", " driver", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-74743", " - macvlan: inherit needed_headroom and needed_tailroom from lowerdev", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-89792", " - ksmbd: prevent out-of-bounds reads in share config responses", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97951", " - scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97952", " - sunvdc: unmap LDC cookies when the descriptor send fails", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97954", " - net/rds: fix tcp stream corruption with large pages", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97957", " - net: hinic: fix mailbox segment buffer overflow", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97958", " - net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain().", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97959", " - net/sched: cls_route: free emptied bucket on filter move", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97963", " - net: stmmac: initialize ptp_lock at probe time", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97964", " - ppp_synctty: ensure a writeable skb header", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97969", " - watchdog: msc313e: Fix clock leak and spurious timer in settimeout()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97970", " - watchdog: msc313e: Avoid division by zero", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97981", " - net: ethernet: cortina: Count dropped frames as NAPI work", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97982", " - net: ethernet: cortina: Fix budget accounting", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97991", " - vdpa_sim_blk: reject out-of-range sector starts", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97993", " - vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97995", " - virtio_console: do not free control-out buffers on remove", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97998", " - netfilter: nfnetlink_log: cope with concurrent instance destruction", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98006", " - ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98009", " - net/sched: ets: clamp quantum in parse and fallback paths", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98010", " - net/sched: drr: clamp quantum in change class", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98011", " - net/sched: hhf: clamp quantum in change and init paths", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98012", " - net/sched: sfq: clamp quantum in change path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98013", " - net/sched: fq_pie: clamp quantum in change path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98014", " - net/mlx5: E-Switch, prevent mc_list repopulation during vport disable", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98015", " - net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98016", " - net/mlx5e: Fix use-after-free race in sample_restore_put()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98022", " - net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98023", " - vxlan: reject dynamic fdb entries that reference a nexthop id", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98025", " - net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent", " partial_data heap overflow", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98027", " - net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer", " size", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98030", " - net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98031", " - nexthop: Initialize extack in remove_nh_grp_entry()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98063", " - bpf: Fix NULL-ptr-deref in btf_var_show()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98064", " - bpf: Fix NULL-ptr-deref when showing a void BTF type", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98066", " - ALSA: caiaq: Fix potential double-free at error path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98068", " - net/rds: don't let rds_conn_shutdown() consume a concurrent drop", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98069", " - net/rds: acquire the fastpath locks in rds_conn_shutdown()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98070", " - net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98071", " - net/rds: clear cp_flags bits individually in rds_conn_path_reset()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98072", " - net/rds: use wq_has_sleeper() in release_in_xmit()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98074", " - bonding: do not clear curr_active_slave prematurely when releasing all", " slaves", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98075", " - bpf: reject BPF_PSEUDO_FUNC reference to the main program", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98076", " - tracing/probes: Fix use-after-free on field name/type of events with", " multiple probes", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98077", " - netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98078", " - ipvs: fix reversed sequence option serialization", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98080", " - btrfs: do not force reloc root creation during qgroup_account_snapshot()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98088", " - scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in", " _base_assign_reply_queues()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98090", " - btrfs: restore active device pointers after failed sprout", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98091", " - btrfs: detach failed sprout device from transaction update list", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98094", " - staging: fbtft: make dirty_lock IRQ-safe", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98095", " - af_packet: Don't cast tpacket_hdr.tp_len to int in", " tpacket_parse_header().", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98096", " - ipv6: sr: restore network header before routing and forwarding", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98098", " - tipc: fix NULL deref in tipc_named_node_up() on empty publication list", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98108", " - Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98113", " - ksmbd: rate limit unmapped SID errors", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98116", " - ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98121", " - watchdog: msc313e: Fix NULL pointer dereference in PM callbacks", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98123", " - sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98130", " - sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98154", " - nvme-rdma: fix -EIO cleanup order in queue_rq", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98157", " - EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-89796", " - mm/damon/core: avoid infinite kdamond_merge_regions() internal loop", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-98158", " - ppp_async: drop the errored frame instead of resetting its headroom", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93288", " - netfilter: nfnetlink_log: wait for rcu grace period before freeing", " pernet state", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93782", " - vhost-scsi: flush backend after device ioctls", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93783", " - Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93784", " - wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93785", " - cifs: validate idmap key payload length", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93789", " - wifi: iwlwifi: bound aligned TLV advance in FW parser", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93795", " - blk-cgroup: fix leaks and online flag on radix_tree_insert failure", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93797", " - wifi: iwlwifi: mvm: fix an off-by-1 boundary check", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93798", " - btrfs: fix reloc root cleanup in merge_reloc_roots()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93800", " - btrfs: fix use-after-free on reloc root after error in", " insert_dirty_subvol()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93802", " - wifi: rsi: validate beacon length before fixed buffer copy", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93803", " - wifi: libipw: fix key index receive bound checks", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93805", " - wifi: cfg80211: validate rx/tx MLME callback frame lengths before access", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93807", " - wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93808", " - ALSA: usb-audio: caiaq: validate EP1 reply lengths", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93811", " - ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93812", " - ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93813", " - btrfs: tree-checker: validate INODE_REF's namelen", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93815", " - net: au1000: move free_irq out of the close-time spinlocked section", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93816", " - f2fs: validate inline dentry name lengths before conversion", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93819", " - PCI: mediatek: Protect root bus removal with rescan lock", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93820", " - PCI: rockchip: Protect root bus removal with rescan lock", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93821", " - PCI: altera: Protect root bus removal with rescan lock", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93822", " - PCI: iproc: Protect root bus removal with rescan lock", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93825", " - spi: Add NULL check for spi_get_device_id() in", " spi_get_device_match_data()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-93830", " - net: stmmac: xgmac2: disable RBUE in default RX interrupt mask", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97407", " - ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in", " set_fmt", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97408", " - Bluetooth: L2CAP: validate connectionless PSM length", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97411", " - net: ibm: emac: mal: fix potential system hang in mal_remove()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97413", " - RDMA/rtrs-srv: Fix integer underflow in process_read and process_write", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97416", " - btrfs: balance: fix potential bg lookup failure in", " btrfs_may_alloc_data_chunk()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97417", " - netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97418", " - ALSA: es18xx: check control allocation before private data setup", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97419", " - hsr: broadcast netlink notifications in the device's net namespace", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97420", " - bpf: NUL-terminate replaced sysctl value", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97421", " - RDMA/umem: Be careful about boundary conditions in", " ib_umem_find_best_pgsz()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97430", " - xhci: Prevent queuing new commands if xhci is inaccessible", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97434", " - dpaa2-switch: fix handling of NAPI on the remove path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97435", " - net: dsa: sja1105: flower: reject cross-chip redirect", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97436", " - dpaa2-switch: rework FDB management on the bridge leave path", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97437", " - ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97438", " - fs/ntfs3: validate index entry key bounds", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97439", " - fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97440", " - net: qrtr: fix node refcount leak on ctrl packet alloc failure", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97441", " - ata: ahci: fail probe if BAR too small for claimed ports", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97443", " - perf/ftrace: Fix WARNING in __unregister_ftrace_function", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97444", " - ACPICA: add boundary checks in two places", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97445", " - ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97446", " - ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97448", " - ACPICA: Add validation for node in acpi_ns_build_normalized_path()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97449", " - ACPICA: Add package limit checks in parser functions", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97450", " - ACPICA: validate handler object type in two places", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97451", " - ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op)", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97452", " - ACPICA: Prevent adding invalid references", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97453", " - ACPICA: validate byte_count in acpi_ps_get_next_package_length()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97454", " - ACPICA: add boundary checks in acpi_ps_get_next_field()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97455", " - ACPICA: Fix use-after-free in acpi_ds_terminate_control_method()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97456", " - ACPICA: Fix condition check in acpi_ps_parse_loop()", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97472", " - ipv6: addrconf: fix temp address generation after prefix deprecation", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97475", " - thermal/drivers/tegra/soctherma: Switch to devm cooling device", " registration", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97476", " - rds: filter RDS_INFO_* getsockopt by caller's netns", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97481", " - serial: 8250: fix possible ISR soft lockup", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97482", " - usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET", " log", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97483", " - usb: core: hcd: fix possible deadlock in rh control transfers", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97484", " - usbip: vhci_hcd: fix NULL deref in status_show_vhci", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97485", " - omfs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97486", " - hpfs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97487", " - jfs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97488", " - qnx4: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97489", " - bfs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97490", " - affs: handle set_blocksize failures", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97491", " - net/rds: Don't sleep inside rds_ib_conn_path_shutdown", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97492", " - wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not", " needed", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97502", " - mmc: davinci: avoid NULL deref of host->data in IRQ handler", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97506", " - crypto: ixp4xx - fix buffer chain unwind on allocation failure", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97507", " - media: dm1105: fix missing error check for dma_alloc_coherent", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97508", " - thunderbolt: Set tb->root_switch to NULL when domain is stopped", " * Jammy update: v5.15.222 upstream stable release (LP: #2169603) //", " CVE-2026-97510", " - thunderbolt: Release request if tb_cfg_request() fails in", " __tb_xdomain_response()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726)", " - alpha: fix ieee_swcr_to_fpcr setting FPCR_DNOD unconditionally", " - alpha: don't leak hardware-fabricated FP exception bits to user space", " - include/linux/list.h: mark list_add and __list_add as __always_inline", " - tools/compiler: match glibc 2.42 definition of __attribute_const__", " - x86/insn-eval: Move assign_register() out of KVM as insn_assign_reg()", " - powerpc/powermac: fix OF node refcount", " - staging: greybus: hid: fix SET_REPORT return value", " - usb: dwc2: gadget: Exit partial power down state when changing USB pull-", " up", " - USB: phy: fsl-usb: fix missing static keywords", " - usb: gadget: snps_udc_plat: clean up PHY on probe deferral", " - NFSD: Encode only the status in NFS-ACL v2 GETACL error replies", " - NFSD: Fix off-by-one in DRC bucket pruning limit", " - nfsd: return NFS4ERR_NOTSUPP for unsupported netloc4 types", " - nfsd: add filehandle match check to nfsd4_delegreturn()", " - nfsd: fix version mismatch loops in nfsd_acl_init_request()", " - nfsd: reject reclaim LOCK after RECLAIM_COMPLETE", " - eCryptfs: bound the packet-length peek to the user buffer", " - ecryptfs: fix tag 11 packet exact-fit size check", " - ecryptfs: show filename encryption options", " - fat: restore original value when fat_ent_write failed", " - fbdev: pvr2fb: correct user pointer annotation and sentinel initializer", " - fpga: stratix10-soc: Fix SVC mailbox handling during reconfiguration", " - alpha/PCI: Fix I/O port accessor argument order in pci_legacy_write()", " - alpha: marvel: Fix irq_set_status_flags to use correct IRQ number", " - alpha: marvel: Fix lock ordering in init_io7_irqs()", " - Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU", " - Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU", " - cpufreq: schedutil: Fix rate limit overflow", " - Bluetooth: hci_bcm: fix usage_count leak when autosuspend_delay is", " negative", " - Bluetooth: hci_uart: Fix false success return in hci_uart_setup()", " - Bluetooth: hci_event: clear HCI_LE_ADV only on a created connection", " - Bluetooth: hci_h5: fix usage_count leak when autosuspend_delay is", " negative", " - Bluetooth: hci_intel: fix usage_count leak when autosuspend_delay is", " negative", " - SUNRPC: Guard svcauth_gss_release() dispatch on rq_auth_stat", " - staging: media: tegra-video: vi: fix probe failure on skipped last port", " - rpmsg: glink: smem: order FIFO read after availability check", " - regulator: max8998_pmic_dt_parse_pdata: of_node_put on reg_np after", " ownership transferred to rdata", " - ocfs2: cluster: avoid lock order inversion in o2hb_region_pin() from", " drop_item", " - ocfs2: cluster: fix o2hb_dependent_users leak on pin failure", " - hwmon: (max6621) fix negative temperature offset and crit readings", " - hwmon: (max6621) fix temperature clamp range", " - nvme: nvme-fc: Fix nvme_fc_create_hw_io_queues() queue deletion in error", " path", " - sctp: distinguish sequence zero from wildcard in reconf lookup", " - PCI: Fix 32-bit config write in Intel PCH Root Port MPC ACS quirk", " - PCI: meson: Fix GPIO state while requesting PERST#", " - PCI/sysfs: Avoid spurious runtime PM wakeup on config space accesses", " - PCI/proc: Avoid spurious runtime PM wakeup on config space accesses", " - iommu/vt-d: Fix no_iommu to disable platform opt-in", " - net: usb: qmi_wwan: add Telit Cinterion FE990D50 composition", " - net: openvswitch: fix nf_connlabels leak in ovs_ct_init", " - NTB: ntb_transport: Recycle TX entries before client callbacks", " - net: ntb_netdev: Avoid double-accounting netif_rx() drops", " - net: ntb_netdev: Count packets dropped on RX refill failure", " - PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip", " - arch_numa: avoid false positive fortify warning in", " setup_node_to_cpumask_map()", " - dm-switch: use WRITE_ONCE() in switch_region_table_write()", " - wifi: rtl818x: initialize eeprom_93cx6 struct to zero", " - taskstats: fix cpumask parsing cutting off the last character", " - timer: Keep debugobjects state consistent in migrate_timer_list()", " - udf: Fix i_lenExtents truncation on 32-bit kernels", " - platform/chrome: sensorhub: Fix dropped timestamp events and log spam", " - net: openvswitch: fix kernel-doc warnings in internal headers", " - selinux: avoid implicit conversions in services code", " - ALSA: seq: Fix port lock leak in deliver_to_subscribers()", " - net: ntb_netdev: Fix TX busy and drop handling", " - tracing/mmiotrace: Remove reference to unused per CPU data pointer", " - clk: qcom: gcc-mdm9607: Increase delay for USB PHY reset", " - usb: f_mass_storage: Bump local buffer size in fsg_common_create_luns()", " - thermal/drivers/imx: Disable clock on runtime resume failure", " - thermal/drivers/qoriq: Disable clock on resume failure", " - dmaengine: dw-edma: Complete descriptors before pausing", " - block: flag zoned disks with GENHD_FL_NO_PART", " - ata: ahci: work around lost interrupts on Marvell 88SE61xx", " - Input: aiptek - validate raw macro indices before updating state", " - Input: aiptek - switch to using dev_groups for driver-specific", " attributes", " - Revert \"irqchip/mbigen: Fix mbigen node address layout\"", " - parisc: Fix alignment of asm statements in head.S", " - batman-adv: bla: prevent CRC corruptions after claim flush", " - clk: qcom: gcc-msm8916: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: qcom: gcc-msm8939: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: qcom: gcc-mdm9607: Drop incorrect apss_tcu_clk_src", " - clk: qcom: gcc-mdm9607: Drop incorrect system_noc_bfdcd_clk_src", " - clk: qcom: gcc-mdm9607: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: qcom: gcc-mdm9607: Fix halt_reg for gcc_apss_axi_clk", " - clk: qcom: gcc-mdm9607: Drop incorrect BIMC PLL and related clocks", " - i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure", " - ASoC: fsl: mpc5200-i2s: Free DMA resources on probe failure", " - AsoC: intel: sst: fix PCI device reference leak on probe failure", " - ASoC: samsung: aries_audio_probe: double of_node_put due to direct", " assignment without of_node_get", " - iio: gyro: mpu3050: fix sign of raw angular velocity readings", " - iio: light: cm32181: return zero after writing calibscale", " - iio: light: gp2ap002: Disable regulators on resume failure", " - iio: srf04: fix pm_runtime handling on probe error path", " - iio: temperature: hid-sensor-temperature: switch to non-devm", " iio_device_register()", " - KVM: s390: Zero initialize irq in reinject_machine_check", " - KVM: s390: Restore sigset on error path", " - media: cec: meson: ao-cec-g12a: name the CEC core regmap to avoid", " debugfs clash", " - media: v4l2-ctrls: Allow unknown HDR10 white point and luminance", " - media: venus: fix payload size returned by parse_caps() and", " parse_alloc_mode()", " - media: venus: fix payload size calculation in parse_raw_formats()", " - media: vimc: fix pixel format lookup in enum_framesizes", " - scsi: qla2xxx: Fix Name Server logout detection on FWI2 adapters", " - scsi: qla2xxx: Check entry_status in qla24xx_modify_vp_config()", " - scsi: qla2xxx: Drop vport reference under lock in report ID acquisition", " - scsi: qla2xxx: Use coherent DMA buffer for D_Port diagnostics", " - f2fs: return symlink writeback errors", " - f2fs: reject overlapping move range after len expansion", " - f2fs: return writeback error from collapse range", " - f2fs: fix i_size when pinned fallocate partially fails", " - drm/bridge: dw-hdmi: fix i2c adapter leak on probe failure", " - drm/sun4i: fix refcount leak in sun4i_backend_init_sat()", " - drm/hibmc: Fix list of formats on the primary plane", " - drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value", " - drm/amdgpu: use AMDGPU_GPU_PAGE_SHIFT instead of PAGE_SHIFT", " - drm/nouveau: Use write-combined maps for coherent", " - mm/damon/core-kunit: check region count before testing in split_at()", " - mm/damon/vaddr: drop last same folio access check optimization", " - mm/damon/vaddr-kunit: check region count in three_regions test", " - mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of()", " - firmware: stratix10-svc: Add mutex in stratix10 memory management", " - drm/bridge: cdns-mhdp8546: Return an error pointer on allocation failure", " - Smack: fix W=1 build warnings", " - smack: simplify write handlers of sysfs entries", " - smack: deduplicate smackfs/{direct,mapped} file_operations", " - smack: restrict smackfs/{direct,mapped} values to 0-255", " - soc: samsung: exynos-pmu: fix of_node refcount leak in", " exynos_get_pmu_regmap()", " - media: cec-pin: Fix event FIFO ordering", " - clk: moxart: remove unused variables, fix refcount leak", " - clk: hisilicon: reset: Use devm_kzalloc to initialize", " hisi_reset_controller", " - ARM: imx: fix device_node refcount leak in imx_src_init()", " - ARM: imx: fix device_node refcount leaks in imx7_src_init()", " - clk: imx: scu: drop redundant init.ops variable assignment", " - perf/x86/intel/uncore: Keep PCI PMUs working when MMIO/MSR setup fails", " - media: keymaps: Remove obsolete RC_MAP_RC5_TV keymap define", " - media: keymaps: Remove obsolete RC_MAP_HAUPPAUGE_NEW keymap define", " - perf tests stat_bpf_counters: Fix usage of '==' to address shellcheck", " warning", " - perf test: raise limit to 20 percent for perf_stat_--bpf-counters_test", " - perf test bpf-counters: Add test for BPF event modifier", " - perf test stat_bpf_counter.sh: Stabilize the test results", " - perf test: Use sqrtloop workload to test bperf event", " - perf test: Fix perf stat --bpf-counters on hybrid machines", " - perf tests: Fix flakiness in BPF counters test on hybrid systems", " - bpftool: Update btf_dump__new() and perf_buffer__new_raw() calls", " - bpftool: Use libbpf_get_error() to check error", " - bpftool: Fix pretty print dump for maps without BTF loaded", " - tools/bpf/bpftool: Reset vmlinux BTF after map commands", " - bpftool: remove duplicate free_btf_vmlinux() definition", " - dmaengine: mediatek: mtk-uart-apdma: Return -ENOMEM on memory allocation", " failure", " - dmaengine: hisilicon: Return -ENOMEM on dynamic memory allocation in", " probe", " - soundwire: qcom: Fix port exhaustion check in stream_alloc_ports", " - iio: orientation: hid-sensor-rotation: Avoid race between callback setup", " and device exposure", " - selftests/rseq: Replace glibc-specific __GNUC_PREREQ with portable check", " - crypto: atmel-ecc - replace min_t with min", " - crypto: atmel-ecc - clean up and improve ECDH comments", " - crypto: sa2ul - Use the defined variable to clean code", " - nvmet-rdma: avoid circular locking dependency on install_queue()", " - nvmet-rdma: use sbitmap to replace rsp free list", " - nvmet-rdma: factor out response resource cleanup", " - bus: ti-sysc: Fix /chosen node reference leak", " - PM: sleep: Fix off-by-one in wakelocks number limit check", " - staging: greybus: audio: correct sscanf() return value check", " - staging: sm750fb: gate dualview dataflow using g_dualview", " - staging: fbtft: Use sysfs_emit_at() to print to sysfs file", " - netdev: reshuffle netif_napi_add() APIs to allow dropping weight", " - staging: switch to netif_napi_add_weight()", " - staging: octeon: fix free_irq dev_id mismatch in cvm_oct_rx_shutdown", " - staging: octeon: ethernet-mem: replace pr_warn with dev_warn in free", " functions", " - staging: octeon: replace pr_warn with dev_warn in fill and rx paths", " - staging: rtl8723bs: fix mismatched free of HalData in", " rtw_sdio_if1_init()", " - ALSA: via82xx: Remove unreachable branch in snd_via686_pcm_pointer()", " - selftests/bpf: Fix memory leak in msg_alloc_iov error path", " - selftests/bpf: Fix memory leak in msg_alloc_iov", " - irqchip/gic-v3-its: Fix memleak in its_probe_one()", " - selftests: timers: leap-a-day: Fix -w option and update usage comment", " - clocksource: Unregister subsystem on device registration failure", " - y2038: uapi: Use 64-bit __kernel_old_timespec::tv_nsec on x32", " - timekeeping: Account for monotonicity adjustment in ntp_error", " - clk: qcom: gdsc: propagate gdsc_check_status() errors from", " gdsc_poll_status", " - clk: qcom: gdsc: propagate gdsc_enable() failure for ALWAYS_ON domains", " - clk: qcom: gdsc: enable optional power domain support", " - clk: qcom: gdsc: Release pm subdomains in reverse add order", " - clk: qcom: gdsc: Capture pm_genpd_add_subdomain result code", " - efi: fix stale reference to efi_recover_from_page_fault()", " - iommu/mediatek-v1: Fix off-by-one in MT2701_LARB_NR_MAX", " - iommu/msm: Return -ENOMEM on memory allocation failure in probe", " - iommu/amd: Prevent SB IOAPIC from overriding IVRS validation errors", " - iommu/amd: Add support for Hygon family 18h model 4h IOAPIC", " - iommu/amd: Fix false positive in SB IOAPIC IVRS validation", " - leds: pca9532: Fix inverted GPIO output polarity", " - hwspinlock: propagate errno when registering single lock", " - usb: mtu3: allow system suspend during active gadget connection", " - usb: renesas_usbhs: Fix power-off ordering on unbind", " - drm/panel: samsung-s6d16d0: Power off on prepare failure", " - iio: accel: dmard09: Implement IIO_CHAN_INFO_SCALE", " - RDMA/core: Avoid flush_workqueue(system_unbound_wq) usage", " - RDMA/mlx4: Avoid flush_scheduled_work() usage", " - RDMA/mlx: Calling qp event handler in workqueue context", " - hwrng: ks-sa - access private data via struct hwrng", " - hwrng: ks-sa - Fix runtime PM cleanup on registration failure", " - ALSA: hpi: Check transport errors during HPI6000 adapter initialization", " - pmdomain: bcm: bcm2835: handle genpd provider registration errors", " - misc: rtsx_usb: avoid USB I/O in runtime autosuspend", " - RDMA/hfi1: Remove redundant PCI device ID validation", " - RDMA/hfi1: Create workqueues before device initialization", " - RDMA/hfi1: Stop flushing the global IB workqueue", " - RDMA/hfi1: Initialize debugfs after probe completes", " - fs/isofs: replace kmap() with kmap_local_page()", " - rpmsg: glink: Remove the rpmsg dev in close_ack", " - rpmsg: glink: remove duplicate code for rpmsg device remove", " - libnvdimm/labels: Bound the on-media label size before the shift", " - cpufreq: spear: Fix an IS_ERR() vs NULL bug in spear1340_set_cpu_rate()", " - irqdomain: Introduce irq_domain_free()", " - irqdomain: Introduce irq_domain_instantiate()", " - irqdomain: Handle additional domain flags in irq_domain_instantiate()", " - genirq/generic_chip: Introduce irq_domain_{alloc,remove}_generic_chips()", " - cpufreq: intel_pstate: Fix setting minimum P-state at init time", " - cpufreq: schedutil: Fix self-contradictory comment in", " sugov_iowait_apply()", " - remoteproc: qcom: Fix glink->node reference leak in", " qcom_add_glink_subdev", " - arm64: dts: qcom: sm8250: Use QMP property to control load state", " - arm64: dts: qcom: sm8250: remove mmcx regulator", " - arm64: dts: qcom: sm8250: Add camcc DT node", " - gpu: host1x: Fix offset calculation in trace_write_gather", " - crypto: sl3516 - drop invalid sg_dma_len checks before DMA mapping", " - ACPI: move from strlcpy() with unused retval to strscpy()", " - ACPI: processor: idle: Expand _LPI package sanity checks", " - tty: hvc: restrict HVC_DCC to ARMv6+ and ARM64", " - accessibility: speakup: Fix incorrect string length computation in", " report_char_chartab_status()", " - misc: rtsx: add missing write register handling", " - misc: ad525x_dpot: Make ad_dpot_remove() return void", " - ppdev: prevent overflow when setting port timeout", " - char: xilinx_hwicap: unregister class on init errors", " - perf ui hists: Fix uninitialized stack memory free on pstack allocation", " failure", " - driver core: soc: remove layering violation for the soc_bus", " - driver core: soc: Unregister bus on early device registration failure", " - dmaengine: dw-edma: Clear stale requests on termination", " - arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for", " PCIe", " - RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters", " - RDMA/srpt: Pass the mapped task attribute to target_init_cmd()", " - RDMA/nldev: Split nldev_stat_set_mode_doit out of nldev_stat_set_doit", " - RDMA/restrack: Fix typos in the comments", " - RDMA/core: Add driver APIs pre_destroy_cq() and post_destroy_cq()", " - iommu/arm-smmu: Add missing pm_runtime_disable() in", " qcom_iommu_device_probe", " - iommu/qcom: Remove sysfs device on probe failure path", " - iommu/qcom: Fix inverted fault report check in qcom_iommu_fault()", " - thermal: int340x_thermal: Consolidate priv->data_vault checks", " - wifi: ath11k: Correctly copy the hint BSSID in WMI scan request", " - ath11k: add trace log support", " - ARM: dts: allwinner: a10: Fix PMU interrupt", " - perf cs-etm: Flush thread stacks after decoder reset", " - perf cs-etm: Avoid truncating AUX buffer sizes to int", " - leds: pca9532: Fix phantom device registration on missing hardware", " - drm/tve200: add OF module alias for autoloading", " - netfilter: nf_nat_sip: rewind offset when NAT shrinks the packet", " - arm64: dts: rockchip: Add gru-scarlet-dumo board", " - arm64: dts: rockchip: Fix PCI node addresses on rk3399-gru", " - arm64: dts: rockchip: Fix Gru WLAN sideband interrupt", " - ARM: lpc32xx: only run SoC init on LPC32xx hardware", " - power: supply: sbs-battery: Use a per-device serial number buffer", " - crypto: keembay - publish OF module alias for OCS AES/SM4", " - w1: ds2482: Fix signedness bug in ds2482_w1_triplet()", " - remoteproc: Use unbounded workqueue for recovery work", " - remoteproc: core: Attach rproc asynchronously in rproc_add() path via", " schedule_work()", " - staging: rtl8723bs: use kfree_sensitive() for key material", " - arm64: dts: allwinner: sun50i-a64-pinephone: Fix mpu6050 mount matrix", " - clk: tegra: tegra124-emc: put EMC node on register failure", " - clk: palmas: Manage external-control prepare with devm", " - clk/x86: pmc_atom: add kasprintf return value check", " - scsi: core: Register sysfs attributes earlier", " - scsi: smartpqi: Fix AIO retry marker cleared by SCSI core between", " dispatches.", " - RDMA/mlx5: Send cong param changes to the resolved port mdev", " - bus: mhi: host: Flush the posted write after writing to", " MHI_SOC_RESET_REQ_OFFSET", " - selftests/zram: fix kernel_gte() for POSIX sh", " - power: supply: sc2731_charger: Convert to platform remove callback", " returning void", " - clk: qcom: Return expected ENOMEM error on dynamic allocation failure", " - misc: vmc_vmci: Fix potential memory leak in vmci_event_subscribe()", " - fanotify: report full event length for FIONREAD", " - wifi: mt76: mt7915: use little-endian for bss_info_ra wire fields", " - perf: arm_spe: Make wakeup range check overflow safe", " - perf machine: Guard against NULL strlist in machines__findnew()", " - perf machine: Use snprintf() for guestmount path construction", " - perf machine: Check snprintf truncation in machines__findnew()", " - perf machine: Don't abort guest map creation on first inaccessible dir", " - perf machine: Reset errno before strtol in guest kernel map creation", " - perf machine: Free scandir entries in guest kernel map creation", " - perf machine: Check snprintf truncation for guest kallsyms path", " - iommu/arm-smmu-v3: Convert to use atomic poll timeout", " - wifi: mac80211: send TWT teardown to peer after setup TX failure", " - wifi: zd1211rw: reject secondary interfaces to prevent conflicts", " - wifi: mac80211: skip unused probe response countdown offsets", " - firmware: google: Add bounds checks in coreboot_table_populate()", " - powerpc/smp: add NULL guard for cause_ipi in smp_muxed_ipi_message_pass", " - MIPS: ptrace: Fix syscall skipping via PTRACE_SYSCALL", " - serial: amba-pl011: unprepare console clock on unregister", " - HID: split apart hid_device_probe to make logic more apparent", " - HID: ensure timely release of driver-allocated resources", " - HID: i2c-hid: Switch i2c_hid_parse() to goto style error handling", " - HID: i2c-hid: Fix \"(null)\" output when reading report descriptor fails", " - HID: lg4ff: validate report length before fixed offsets", " - perf thread-stack: Fix heap buffer overflow on branch stack wrap copy", " - perf auxtrace: Fix queue grow overflow and old array leak", " - perf intel-pt: Fix off-by-one in auxtrace_info minimum size check", " - perf intel-bts: Fix off-by-one in auxtrace_info minimum size check", " - iio: light: tsl2772: fix ALS calibscale readback", " - iio: light: isl29028: return zero in write_raw() on success", " - iio: light: tsl2583: return zero in write_raw() on success", " - block/blk-stat: drain per-cpu callback stats over possible CPUs", " - block/blk-iocost: collect per-cpu latency stats over possible CPUs", " - block/kyber-iosched: flush per-cpu latency buckets over possible CPUs", " - lib/string: fix memchr_inv() for large ranges", " - pps: don't try to wait for negative timeouts in PPS_FETCH", " - pps: clients: gpio: Bypass edge's direction check when not needed", " - pps: pps-gpio: split IRQ handler into hardirq timestamper + threaded", " handler", " - pps-gpio: remove dead capture_clear code", " - PCI/sysfs: Add static PCI resource attribute macros", " - remoteproc: Move resource table data structure to its own header", " - remoteproc: use rsc_table_for_each_entry() in rproc_handle_resources()", " - scripts/tags.sh: improve compiled sources generation", " - scripts/tags.sh: Prevent binary files appearing in cscope.files", " - ocfs2: use bitmap API in fill_node_map", " - drm/sun4i: vi scaler: Fix coefficient selection", " - of: property: add missing kerneldoc for of_graph_get_endpoint_count()", " - of: property: use unsigned int return on of_graph_get_endpoint_count()", " - bitfield: Add less-checking __FIELD_{GET,PREP}()", " - bitfield: Add non-constant field_{prep,get}() helpers", " - drm/sun4i: tcon: Drop remote endpoint reference", " - drm/sun4i: dw-hdmi: Drop TCON TOP port reference", " - drm/sun4i: hdmi-phy: Fix H6 8-bit MPLL config at 594 MHz", " - RDMA/siw: Introduce siw_free_cm_id", " - mfd: rave-sp: validate received frame payload lengths", " - mfd: iqs62x: Reject zero-length firmware records", " - drm/amdgpu/gfx6: Fixup emit_cntxcntl()", " - ext4: fix spurious message about orphan cleanup on RO fs", " - phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table", " - perf trace-event: Fix buffer overflow in read_string()", " - drm/amdgpu/gfx6: Fixup emitting SWITCH_BUFFER packets", " - firmware_loader: Check fw_state_is_done in loading_store", " - pinctrl: rockchip: Reset the pin count when recalculating SoC data", " - soc: fsl: qe: check platform_driver_register() in qe_ic_of_init()", " - coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()", " - coresight: etm4x: Cleanup TRCIDR2 register accesses", " - coresight: etm4x: Cleanup TRCIDR3 register accesses", " - coresight: etm4x: Cleanup TRCIDR4 register accesses", " - coresight: etm4x: Cleanup TRCIDR5 register accesses", " - coresight: Change syncfreq to be a u8", " - regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handling", " - sched/fair: Check CPU capacity before comparing group types during load", " balance", " - Bluetooth: btusb: Fix BD_ADDR byte order in btusb_set_bdaddr_wcn6855()", " - perf trace-event: Fix integer truncation in do_read() and skip()", " - scsi: sd: Fix sd_done() sense handling condition", " - iio: light: gp2ap002: re-enable irq if runtime suspend fails", " - flow_offload: rename offload functions with offload instead of flow", " - arm64: dts: turris-mox: fix usb3 phys", " - ARM: dts: helios4: add vcc-supply to EEPROM", " - ARM: dts: helios4: add vcc-supply to GPIO expander", " - ARM: dts: helios4: add SATA regulator supplies", " - perf stat: Clear screen only if output file is a tty", " - perf stat: Fix evsel_list leak in cmd_stat", " - perf synthetic-events: Fix uninitialized pthread_join", " - perf synthetic-events: Fix divide by zero in", " perf_event__synthesize_threads", " - iommu/vt-d: Fix UCTP context table slot when copying root entries", " - m68k: Fix backtraces for non-running tasks", " - powerpc/configs: enable CONFIG_RAS to fix EDAC support", " - spi: sprd-adi: Fix probe succeeding without registering the controller", " - nfc: digital: Do not dump a NULL response in command completion", " - dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal", " - ASoC: pxa: Use devm_clk_get_optional() for extclk clock", " - ASoC: fsl-asoc-card: defer probe when the CPU DAI device is not ready", " - ubi: Fix repeated words in comments", " - ubi: fastmap: Use the bitmap API to allocate bitmaps", " - ubi: fastmap: Fix missed ec updating after erasing old fastmap data", " block", " - ubi: fastmap: erase_block: Get erase counter from wl_entry rather than", " flash", " - ubi: fastmap: Allocate memory with GFP_NOFS in ubi_update_fastmap", " - ubi: Replace erase_block() with sync_erase()", " - UBI: Preserve torture flag when rescheduling failed erasures", " - UBI: fastmap: Pass to_be_tortured when reusing old fastmap PEBs", " - ubi: fastmap: Add fastmap control support for 'UBI_IOCATT' ioctl", " - ubi: fastmap: Add fastmap control support for module parameter", " - ubi: Simplify bool conversion", " - ubi: fastmap: Wait until there are enough free PEBs before filling pools", " - ubi: fastmap: Fix lapsed wear leveling for first 64 PEBs", " - ubi: fastmap: Add module parameter to control reserving filling pool", " PEBs", " - UBI: fix two issues in the ubi.mtd MODULE_PARM_DESC", " - selfetests/bpf: Update vmtest.sh defaults", " - selfetests/bpf: Adapt vmtest.sh to s390 libbpf CI changes", " - bpf/docs: Update list of architectures supported.", " - selftests/bpf: Fix vmtest.sh getopts optstring", " - selftests/bpf: Limit URLS parsing logic to actual scope in vmtest", " - selftests/bpf: Support local rootfs image for vmtest", " - selftests/bpf: Add description for running vmtest on RV64", " - selftests/bpf: vmtest.sh: Preserve command quoting when running in the", " VM", " - spi: img-spfi: don't disable runtime PM on DMA deferred probe", " - power: supply: bd99954: Drop bad register fields", " - power: supply: bq27xxx: bq27520g4: fix REG_TTES address", " - power: supply: bq27xxx: bq28z610: fix invalid AverageEnergy address", " - power: supply: bq27xxx: bq27z561: fix invalid AverageEnergy address", " - xenbus: Unregister reboot notifier on init failure", " - clocksource/drivers/clps711x: Do not unmap clocksource MMIO", " - clocksource/drivers/armada: Unwind timer clock on init failure", " - x86/pkeys: Fix pkey_alloc() return value when pkeys are not supported", " - bpftool: Fix double close in map dump", " - tracing: Remove \"__attribute__()\" from the type field of event format", " - tracing: Have trace_event_update_all() only handle module that is", " loading", " - bpf: Fix pending_pos walk on 32-bit ring position wrap", " - crypto: hisilicon/sec2 - fix CCM algorithm long packet failure", " - perf dso: Guard close() against invalid fd in", " dso__decompress_kmodule_path()", " - perf dso: Guard against cache underflow on short reads in", " dso_cache__memcpy()", " - mailbox: rockchip: disable pclk on probe failure and unbind", " - hwmon: (emc1403) Add support for EMC1442", " - smb/server: preserve error status in smb2_handle_negotiate()", " - nfs: replace atomic bitops sequence with clear_and_wake_up_bit helper", " - nfs: refactor pNFS functions using clear_and_wake_up_bit", " - pppox: drain queued packets on channel handoff", " - hsr: Use a single struct for self_node.", " - net: hsr: Use full string description when opening HSR network device", " - net: bridge: vlan: fix inverted default vlan notification", " - ALSA: hda: Fix connection list comparison in proc output", " - 8139cp: fix Rx and Tx not being disabled in cp_suspend", " - platform/x86: dell-wmi-sysman: Fix instance ID bounds", " - vsock: use sock_error() to consume sk_err after a failed connect", " - bonding: initialize err for empty target lists", " - i3c: mipi-i3c-hci: Fix DAT/DCT entry sizes", " - i3c: mipi-i3c-hci: Fix number of DAT/DCT entries for HCI versions < 1.1", " - i3c: mipi-i3c-hci: Quieten initialization messages", " - i3c: mipi-i3c-hci: Switch PIO data allocation to devm_kzalloc()", " - i3c: mipi-i3c-hci: Refactor PIO register initialization", " - i3c: mipi-i3c-hci: Fix missing STAT_IBI_STATUS_THLD in PIO mode", " - virtio_balloon: disable indirect descriptors", " - prctl: fix PR_SET_MM_AUXV losing the forced AT_NULL terminator", " - ALSA: control: Use automatic cleanup of kfree()", " - RDMA/ucma: Allow path records to exactly fit the output buffer", " - net: thunderbolt: Count delivered packets in rx_packets and rx_bytes", " - forcedeth: stop the tx_timeout register dump past the requested window", " - net: ipa: report when the driver has been removed", " - net: ipa: Convert to platform remove callback returning void", " - net: ipa: balance runtime PM reference on remove error", " - nfs: move the nfs4_data_server_cache into struct nfs_net", " - scsi: qla2xxx: Fix an loop timeout test", " - Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX", " - octeontx2-af: Fix TL3/TL2 link config ENA clearing", " - cifs: fix clearing stats for fastest execution of each smb2 command", " - net: ip6_gre: Remove the unused function ip6gre_tnl_addr_conflict()", " - net_sched: sch_fq: struct sched_data reorg", " - net_sched: sch_fq: change how @inactive is tracked", " - net_sched: export pfifo_fast prio2band[]", " - net/sched: sch_codel: clamp default mtu to avoid disabling CoDel", " - tpm: st33zp24: Validate locality read result", " - apparmor: Replace sprintf/strcpy with scnprintf/strscpy in", " aa_policy_init", " - net: ethernet: sun4i-emac: Fix IRQ error handling", " - net: stmmac: selftests: Pass the IP proto mask in the TC selftest", " - netfilter: xt_cgroup: Make it independent from net_cls", " - netfilter: xt_HL: add pr_fmt and checkentry validation", " - netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited()", " - selftests: arm64: add hugetlb mte tests", " - selftests/arm64: Print missing MTE TAP headers", " - selftests/arm64: Treat KSM merge_across_nodes as optional", " - net: stmmac: selftests: Check multiple MMC counters", " - net: stmmac: dwmac1000: Account for the primary MAC address for UC", " filtering", " - net: stmmac: dwmac4: Account for the primary MAC address for UC", " filtering", " - net: stmmac: dwxgmac: Account for the primary MAC address for UC", " filtering", " - net: stmmac: selftests: Account for the UC filter list for filtering", " tests", " - nvme: target: rdma: fix ndev refcount leak on queue connect", " - clk: qcom: Drop mmcx gdsc supply for dispcc and videocc", " - RDMA/nldev: Check stat attribute before accessing it", " - HID: fix an error code in hid_check_device_match()", " - ALSA: control: Fix unannotated kfree() cleanup", " - Bluetooth: L2CAP: Fix send LE flow credits in ACL link", " - kselftest/arm64: mte: Skip the hugetlb tests if MTE not supported on", " such mappings", " - kselftest/arm64: mte: Use the correct naming for tag check modes in", " check_hugetlb_options.c", " - nvmet-rdma: fix queue leak when connect backlog is exceeded", " - clk: qcom: gdsc: Bump parent usage count when GDSC is found enabled", " - Linux 5.15.221", " - SAUCE: Revert \"bpftool: Update btf_dump__new() and", " perf_buffer__new_raw() calls\"", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90053", " - net/sched: sch_htb: limit htb_classify inner-class filter hops", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90054", " - tcp: fix corruption of urgent data on multi-segment retransmit", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90055", " - usb: atm: usbatm: fix invalid ci_range initialization", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90056", " - net: fec: only stop PTP if it was initialized", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90058", " - net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90062", " - netfilter: nf_tables: move hardware offload step after building the", " chain blob", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90063", " - virtio-net: Ensure that TCP packets don't overflow gso_segs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90067", " - libceph: validate banner payload length", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90068", " - ASoC: dapm: Fix off-by-one check on the second enum channel", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93245", " - apparmor: policy_int make sure list heads are initialized before fail", " path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90070", " - tpm: st33zp24: Return zero on status read failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90071", " - net/sched: sch_teql: restore skb->dev on the slave failure path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90072", " - net/sched: sfq: clamp quantum to avoid signed overflow soft lockup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90073", " - net/sched: hhf: clamp quantum before hhf_change() to avoid overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90074", " - net/sched: fq_pie: clamp default quantum to avoid signed overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90075", " - net/sched: fq_codel: clamp default quantum and mtu", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90078", " - net/sched: act_skbmod: fix length calculations and avoid invalid header", " warnings", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90081", " - net/rds: use wq_has_sleeper() in rds_cong_map_updated()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89780", " - net: qualcomm: rmnet: restore skb->dev on deaggregated frames", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89789", " - gtp: add synchronize_net() in gtp_newlink() error path to prevent use-", " after-free", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90088", " - Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite", " loop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90102", " - NFSv4/pnfs: key the data server cache on the NFS version", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90103", " - NFSv4.2: fix LAYOUTSTATS send buffer exhaustion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90107", " - net/smc: free pending qentry in smc_llc_flow_stop() before memset", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90114", " - net: bridge: Reject descending VLAN tunnel ranges", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90126", " - rtc: pcf8563: fix clock provider leak on unbind", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90128", " - vdpa/mlx5: fix wrong list iterated in add_direct_chain error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89779", " - fs/ntfs3: validate ef->size covers the record's name and value", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89781", " - fs/ntfs3: fix out-of-bounds read in read_log_rec_buf()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90140", " - cuse: wait for pending RCU callbacks on module exit", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90141", " - ipvs: fix integer overflow in ftp helper port/address parsing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90143", " - net: kcm: Hold RCU read lock while running BPF parser", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90151", " - NFSv4: remove callback IDR entry on client allocation failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90157", " - bpf: Reject negative optlen in cgroup getsockopt hook", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90160", " - lwt_bpf: Restore reserved headroom after xmit program", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90198", " - ALSA: core: Fix use-after-free in snd_card_do_free()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90202", " - scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90203", " - Squashfs: check block offset is not negative", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93252", " - ocfs2: fix circular locking dependency in ocfs2_init_acl()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90209", " - s390/debug: Fix deadlock during unregister", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90214", " - ASoC: xilinx: formatter_pcm: fix stream_data leak on open error", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90216", " - ubi: Fix rollback for explicit UBI device numbers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90218", " - RDMA/cma: Fix WARNING in res_to_rt", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90219", " - RDMA/cxgb4: Free debugfs on registration failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90221", " - nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90222", " - nfc: pn533: hold a reference to the request skb during send_frame", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90223", " - nfc: llcp: bound SNL TLV parsing to the skb and add length checks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90224", " - nfc: nci: fix double completion race in nci_data_exchange_complete", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90225", " - nfc: llcp: read llcp_sock->local under the socket lock in getsockopt", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90226", " - nfc: llcp: avoid userspace overflow on invalid optlen", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90228", " - nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89784", " - SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90245", " - fbdev: kyro: Validate overlay viewport coordinates", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90248", " - net/sched: cls_api: fix teardown of an adopted proto on insert-race loss", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90249", " - iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90251", " - Bluetooth: MSFT: validate evt_prefix_len against the response length", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90257", " - Bluetooth: virtio_bt: avoid OOB read of build info string", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90274", " - coresight: etm4x: fix underflow for usage of (nrseqstate - 1)", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90281", " - phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime", " suspend", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90283", " - hugetlbfs: release subpool on fill_super failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90284", " - firmware_loader: do not queue completed sysfs fallback requests", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90285", " - scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90286", " - drm/amdgpu/gfx6: Use PFP on the compute queues too", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90290", " - arm64: hibernate: Restore DAIF state on error", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93256", " - arm64: hibernate: mask DAIF before restoring hibernated kernel", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90292", " - RDMA/siw: Fix use-after-free in siw_accept()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90293", " - IB/isert: post the full-feature receive buffers after session", " registration", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90294", " - IB/isert: delay the final Login Response until the session is registered", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90295", " - cpufreq: imx6q: fix out-of-bounds write when probed more than once", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90296", " - cpufreq: imx6q: fix devres accumulation across driver rebind", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90297", " - drm/sun4i: crtc: Propagate layer initialization error", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90298", " - drm/sun4i: tcon: Drop TCON TOP device reference", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90302", " - ocfs2: synchronize heartbeat callbacks with o2net teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90303", " - ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user", " faults", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90307", " - RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90314", " - remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90316", " - drm/omap: dsi: Do not copy isr table", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90318", " - fat: release buffer head after rebuilding parent", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90319", " - rapidio: clear mport->net when rio_add_net() fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90327", " - phonet: pep: do not write beyond optlen in getsockopt", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90329", " - HID: synchronize input before cleaning up a failed probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90334", " - tty: clear cdev pointer after cdev_add() failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90341", " - firmware: coreboot: Validate table bounds", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90348", " - wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90360", " - regulator: core: use system_freezable_wq for init complete work", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90361", " - wifi: ath11k: fix leak in ath11k_service_ready_ext_event()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90362", " - drm/msm/dsi: Drop dev_pm_opp_set_rate(0)", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90372", " - wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90378", " - wifi: mt76: mt792x: Fix memory leak in SDIO TX path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90382", " - wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93261", " - locking/lockdep: Fix NULL pointer dereference in __lock_set_class()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93283", " - i3c: master: Fix device_register() error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90386", " - i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90388", " - iommu/dma: Check atomic pool allocation result directly", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90391", " - lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90393", " - bpf: Fix potential UAF in bpf_netns_link_update_prog", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90394", " - power: supply: sc2731_charger: cancel work on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90395", " - power: supply: isp1704_charger: cancel work on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93262", " - md/raid5-ppl: fix use-after-free in ppl_do_flush()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90403", " - wifi: rtlwifi: pci: fix error path in rtl_pci_probe()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90411", " - nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90413", " - IB/isert: reject login PDUs declaring more data than was received", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90414", " - IB/isert: reject PDUs declaring more data than was received", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90415", " - RDMA/cxgb4: free STAG index when TPT entry write fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90416", " - RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90419", " - nilfs2: prevent out-of-bounds read in super root block parsing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90420", " - nilfs2: fix infinite loop in nilfs_clean_segments()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93264", " - RDMA/efa: Fix PBL chunk length computation", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89782", " - fs/ntfs3: reject restart table growth beyond U16_MAX entries", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90431", " - remoteproc: Prevent crash handling to race with rproc_del()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90434", " - isofs: release zisofs block pointer buffer head", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90435", " - RDMA/mlx5: Fix integer overflow of user QP buffer size", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92476", " - crypto: keembay - Initialize completion before requesting IRQ", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89785", " - fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89787", " - ext4: check dir entry fits before reading the hash trailer in", " ext4_search_dir()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92494", " - ext4: fix buffer_head leak in ext4_init_orphan_info", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92496", " - wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92498", " - wifi: ath6kl: avoid buffer overreads in WMI event handlers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92501", " - ext4: drain in-flight DIO before buffered write fallback", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92504", " - thermal: intel: int3400: clean up ODVP on probe failures", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92508", " - RDMA/core: Fix potential use after free in ib_free_cq()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93268", " - ext4: skip extra isize expansion during mount to prevent deadlock", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89786", " - ext4: fix out-of-bounds read in ext4_read_inline_dir()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92521", " - ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92522", " - ACPI: processor: validate MADT IOAPIC entry bounds", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-92524", " - irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93037", " - RDMA/hfi1: Propagate sdma_txinit_ahg() errors", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93039", " - ASoC: meson: Keep link pointers valid on realloc failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93040", " - dmaengine: dw-edma: Serialize channel state checks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93041", " - dmaengine: dw-edma: Serialize abort state updates", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93046", " - software node: Fix software_node_get_reference_args() with index -1", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93048", " - mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93049", " - mtd: mtdswap: Avoid freeing registered blktrans device twice", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89777", " - vfio/pci: clear vdev->msi_perm after freeing it on init failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93051", " - misc: ad525x_dpot: use driver core groups for sysfs files", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93052", " - misc: bcm-vk: Use acquire/release for msgq_inited", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93053", " - speakup: keyhelp: guard letter_offsets possible out-of-range indexing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93054", " - uio: Fix stale info pointer in failed registration path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93055", " - UDF symlink pathComponent header OOB read", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93056", " - usb: gadget: f_uac1_legacy: remove broken string configfs attributes", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93061", " - gpu: host1x: Avoid stack over-read in debug output helpers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93067", " - drm/bridge: tc358767: clamp the reported AUX read size to the request", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93271", " - wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93095", " - hfsplus: validate thread record before delete key rebuild", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93098", " - rpmsg: glink: fix deadlock in endpoint destroy during driver detach", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89778", " - isofs: fix out-of-bounds page array access on empty zisofs block", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93102", " - RDMA/hfi1: Free RX data on late probe failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93103", " - RDMA/hfi1: Preserve unit 0 on allocation failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89783", " - xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is", " full", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93108", " - RDMA/ipoib: Drain RCU callbacks during module teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93109", " - RDMA/mlx5: Drain RCU callbacks during module teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93110", " - RDMA/core: Wait for RCU callbacks before unloading ib_core", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93114", " - platform/surface: acpi-notify: Check ACPI companion before use", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93115", " - platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93120", " - usb: gadget: configfs: fix out-of-bounds read of qw_sign", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93130", " - platform/x86: dell-wmi-base: Fix resource leak on module load failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93131", " - platform/x86: dell-privacy: Fix race condition", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93138", " - bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93140", " - udf: Mark LVID buffer as uptodate before marking it dirty", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93141", " - usb: gadget: r8a66597: avoid double free of ep0_req in probe error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93145", " - clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93278", " - staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93279", " - staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93280", " - greybus: audio: bound the topology section sizes against the fetched", " size", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93151", " - nvmet-rdma: fix response resource leak on queue teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93158", " - crypto: sa2ul - stop probe if context pool creation fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93159", " - crypto: atmel-sha204a - fix heap info leak on I2C transfer failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93160", " - crypto: atmel-ecc - reject hardware ECDH without a public key", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93161", " - crypto: qat - clear AES key schedule from stack", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93165", " - platform/chrome: sensorhub: Fix memory overread in ring handler", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93167", " - csky: Fix a4/a5 restoration in syscall trace path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93170", " - dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and", " MCDMA interrupt handlers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93177", " - drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93178", " - drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93274", " - pinctrl: bcm2835: Don't remove an unregistered GPIO chip", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93183", " - drm/lima: call drm_mm_init() with a valid allocation range", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93185", " - ASoC: rt700-sdw: always drain jack work on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93188", " - HID: roccat: bound device-supplied profile index", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93189", " - HID: core: quiesce input in hid_hw_stop() to prevent use-after-free", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93191", " - smack: fix incorrect task context in smack_msg_queue_msgrcv", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-40123", " - bpf: Enforce expected_attach_type for tailcall compatibility", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89947", " - clk: meson: align gxbb_32k_clk_sel number of parents with actual count", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80671", " - perf sched: Fix register_pid() overflow, strcpy, and BUG_ON", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93203", " - batman-adv: bla: avoid CRC corruption due to parallel claim add", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93204", " - batman-adv: dat: atomically update mac addresses", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-52944", " - ksmbd: fix FSCTL permission bypass by adding a permission check for", " FSCTL_SET_SPARSE", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-22039", " - ksmbd: fix overflow in dacloffset bounds check", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-21651", " - net: hns3: don't auto enable misc vector", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-53078", " - bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-43088", " - net: af_key: zero aligned sockaddr tail in PF_KEY exports", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-31420", " - bridge: mrp: reject zero test interval to avoid OOM panic", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-22103", " - net: fix NULL pointer dereference in l3mdev_l3_rcv", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-21649", " - net: hns3: fix kernel crash when 1588 is sent on HIP08 devices", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2023-52676", " - bpf: Guard stack limits against 32bit overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2024-50017", " - x86/mm/ident_map: Use gbpages only where full GB page should be mapped.", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-74268", " - tcp: clear sock_ops cb flags before force-closing a child socket", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90015", " - xhci: fix lost bounce buffers on TDs spanning several ring segments", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89816", " - drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93234", " - drm/gud: validate TV mode names before creating enum property", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89817", " - drm/gud: NUL-terminate TV mode names read from the device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89821", " - drm/amd/display: avoid divide-by-zero in __is_lut_linear()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89823", " - drm: fix race between partial drm_dev_register() failure and ioctl", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89843", " - scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89845", " - scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89846", " - scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89847", " - scsi: qla2xxx: Avoid double completion in async IOCB timeout", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93242", " - scsi: qla2xxx: Fix response queue over-consumption in", " __qla_consume_iocb()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89849", " - scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89850", " - scsi: qla2xxx: Don't query firmware state while chip is down", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89851", " - scsi: qla2xxx: Fix FCE trace enable parsing in debugfs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89852", " - scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89853", " - scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89854", " - scsi: qla2xxx: Fix cs84xx use-after-free on host teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89855", " - scsi: qla2xxx: Serialize flash version read in reset handler", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89856", " - scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89858", " - scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89861", " - scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89863", " - scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89864", " - scsi: qla2xxx: Bound i2c->length in I2C bsg handlers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89865", " - scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89871", " - media: video-i2c: fix kthread error pointer left in kthread_vid_cap on", " failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89872", " - media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89876", " - media: tda18250: fix possible integer overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89878", " - media: s2255: check firmware size before reading trailing marker", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89879", " - media: s2255: bound JPEG frame size before copying into the buffer", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89880", " - media: rtl2832_sdr: release URBs and stream buffers on start_streaming()", " failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89881", " - media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix", " DMA leak", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89883", " - media: rc: sunxi-cir: Unregister rc device on probe failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93236", " - media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89887", " - media: i2c: ov7740: fix use-after-destroy in remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89888", " - media: i2c: ov02a10: fix endpoint parsing use-after-free", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89890", " - media: go7007: defer the ALSA v4l2 put until card release", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89891", " - media: em28xx: fix use-after-free of dev_next->devlist on disconnect", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89892", " - media: em28xx: defer audio-only extension registration", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89893", " - media: cx23885: cancel NetUP CI work before teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89894", " - media: cx231xx: reject geometry changes while the VBI queue is busy", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89895", " - media: cobalt: Avoid freeing ALSA private data twice", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89896", " - media: cedrus: fix memory leak in cedrus_init_ctrls()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89897", " - media: cec: Serialize exclusive follower delivery", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89901", " - media: airspy: use vb2_video_unregister_device() on disconnect to fix", " NULL deref", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89923", " - KVM: s390: Free guest debug data on vcpu destroy", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89924", " - KVM: s390: Fix old_data leak in guest debug error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89925", " - KVM: s390: Fix memory leak in guest debug handling", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89926", " - KVM: s390: Fix length check __import_wp_info()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89927", " - KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89930", " - KVM: nVMX: Service local TLB flushes on failed nested VM-Enter", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89932", " - KVM: nVMX: Always flush vpid02 on first use", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89936", " - iio: dac: m62332: Fix regulator reference count imbalance", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89937", " - iio: chemical: sgp30: Handle IAQ thread creation failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89939", " - iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89945", " - ASoC: cs35l34: drain threaded IRQ before runtime suspend", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89946", " - ASoC: cs35l33: drain threaded IRQ before runtime suspend", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89948", " - batman-adv: bla: fix freeing of claims on meshif deletion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89949", " - batman-adv: dat: avoid unaligned fault in IP extraction", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89951", " - batman-adv: fix stale receive device on merged fragments", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89952", " - mtd: rawnand: validate ONFI extended parameter page sections", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89953", " - mtd: mtdoops: free page bitmap when the backing MTD is removed", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89954", " - mtd: afs: validate v2 image info bounds", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89964", " - parisc: eisa: Fix infinite loop when parsing invalid IRQ value", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89965", " - nvdimm/btt: reject an arena whose nfree is below the lane count", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89968", " - nvmet-tcp: reject unsolicited H2CData PDUs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89969", " - nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89973", " - nvme-tcp: check the data direction of a C2HData PDU", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89979", " - ALSA: pcm: Fix race between non-atomic ops and trigger-start", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89980", " - ALSA: harmony: initialize locks before requesting IRQ", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89982", " - i2c: mux: Fix channel node leak on adapter add failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89983", " - i2c: core: fix debugfs UAF on adapter removal", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89984", " - perf/x86/intel: Fix kernel address leakages in LBR stack", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89989", " - ima: Check for ERR_PTR from dentry_path() in validate_hash_algo()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89993", " - dmaengine: dw-edma: Initialize IRQ data before requesting IRQs", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89997", " - dm: fix resume-vs-remove race", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89999", " - HID: wacom: validate report length in wacom_intuos_pro2_bt_irq", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90000", " - HID: rmi: fix OOB access with undersized RMI reports", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90007", " - scsi: pm8001: Use rollback index when freeing MSI-X vectors", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90011", " - scsi: target: iscsi: Reserve a terminator byte for the login payload", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90017", " - staging: rtl8723bs: fix OOB read in rtw_action_frame_parse()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90018", " - staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90019", " - usb: gadget: fix null pointer dereference in usb_put_function_instance()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90020", " - USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90025", " - usb: typec: ucsi: displayport: Fix OOB altmode array index", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90031", " - usb-storage: ene_ub6250: fix race between scan work and probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90032", " - media: usbtv: keep device alive while ALSA card exists", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90033", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90034", " - usb: image: mdc800: change kmalloc() to kzalloc()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2025-38097", " - espintcp: remove encap socket caching to avoid reference leak", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89515", " - scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80689", " - tracing/mmiotrace: Add NULL check for mmio_trace_array in logging", " functions", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80888", " - drm/vmwgfx: drop dma_buf reference on foreign-fd prime import", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80912", " - selinux: reject an unclaimed class value in security_get_classes()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89595", " - fsnotify: Fix stale object mask after concurrent mark updates", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89603", " - entry: Fix seccomp bypass after ptrace with TSYNC", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-74378", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89488", " - openvswitch: Fix CT limit teardown use-after-free", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-90049", " - net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80977", " - net: skbuff: don't touch shared zerocopy state in skb_tx_error()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80928", " - smack: fix cred UAF in smack_file_send_sigiotask()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93222", " - signal: avoid shared siginfo namespace rewrites", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80930", " - tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80931", " - w1: ds28e17: reject an oversize length on an I2C block read", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80932", " - vsock/virtio: flush works in dependency order", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80938", " - wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80941", " - wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80944", " - wifi: mwifiex: Detach sync cmd buffer on interrupted wait", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80949", " - wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80951", " - i3c: master: svc: bound IBI payload to the requested max_payload_len", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80952", " - i3c: master: Fix info leak and UAF in device unregister path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80963", " - dm-stats: fix a crash if allocation of per-cpu data fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80964", " - ALSA: virmidi: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80965", " - ALSA: serial-u16550: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80966", " - ALSA: portman2x4: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80967", " - ALSA: pcxhr: initialize mutexes before requesting threaded IRQ", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80968", " - ALSA: mts64: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80969", " - ALSA: mpu401: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80971", " - ALSA: bcd2000: clear the URB pointers on disconnect", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80972", " - ALSA: aloop: Check card index validity at probe", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80973", " - ALSA: 6fire: bound the MIDI event length from the device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80976", " - seg6: reset IP6CB after IPv6 decapsulation", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80978", " - net: cap advertised IP tunnel headroom", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80983", " - net/smc: fix socket refcount leak in smc_switch_conns()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80987", " - NTB: ntb_transport: Reject oversized TX buffers", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80988", " - NTB: ntb_transport: Fail TX enqueue when the QP link is down", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-80994", " - net: openvswitch: fix flow mask use-after-free on flow deletion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81000", " - net: tun: bound receive headroom", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81001", " - slip: fix use-after-free in sl_sync()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81002", " - xdp: fix zero-copy frame layout", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81003", " - net/iucv: filter frames in afiucv_hs_rcv() by ingress device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81005", " - ipmi: si: Fix NULL pointer dereference after failed registration", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81007", " - ipmi: ipmb: validate write message length", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81008", " - interconnect: Fix use after free in icc_get() and of_icc_get_by_index()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-81017", " - platform/chrome: sensorhub: Bound the EC-reported sensor number", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89440", " - mmc: via-sdmmc: stop card-detect handling on probe failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89444", " - platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93206", " - PCI/proc: Use file_ns_capable() when checking config space read access", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89456", " - s390/dasd: Propagate partial completion length across ERP recovery", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89457", " - s390/dasd: Guard sysfs discipline callbacks against unallocated private", " data", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89458", " - s390/dasd: Do not complete a failed ESE read as successful", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89461", " - power: supply: max17040: synchronize work cancellation on suspend", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89463", " - power: supply: ucs1002: fix use-after-free on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89464", " - power: supply: twl4030_charger: cancel workers via devm", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89469", " - power: supply: lp8727: fix use-after-free in lp8727_release_irq()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89470", " - power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89471", " - power: supply: cros_usbpd-charger: bound the EC-reported port count", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89474", " - power: supply: bq256xx: drain usb_work before freeing the charger", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89475", " - power: supply: bq24257: fix use-after-free on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89476", " - sctp: fix stream->outcnt underflow on duplicate RECONF responses", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89477", " - sctp: fix NULL deref on untransmitted RECONF completion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89478", " - sctp: drop a chunk if its transport was removed", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89479", " - sctp: stop processing a packet once its association is deleted", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89480", " - nvme-tcp: reject a read that transferred too few bytes", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89482", " - nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89483", " - nvme: zero the discard fallback page", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89485", " - lockd: pin next file across nlm_inspect_file lock-drop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89487", " - openvswitch: only skb_tx_error() a packet we are about to drop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89489", " - openrisc: fix arbitrary kernel memory access via or1k_atomic syscall", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89490", " - ocfs2: fix readdir position truncation on 32-bit kernels", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89491", " - ocfs2: cluster: don't sleep while holding o2hb_live_lock in", " o2hb_region_pin()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89493", " - ocfs2: validate rl_used against rl_count in refcount block validator", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89494", " - ocfs2: validate lengths in dlm_mig_lockres_handler", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89495", " - ocfs2: bound namelen in dlm_migrate_request_handler", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89496", " - ocfs2: always run deallocs on copy-on-write completion", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89497", " - orangefs: skip leading spaces before parsing client debug masks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89498", " - orangefs: fix double-free of trailer_buf on readdir copy failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89504", " - regulator: as3722_get_regulator_dt_data: fix premature of_node_put", " leaving dangling of_node pointer", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89508", " - RDMA/ucma: Lock the handler in ucma_set_ib_path()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89510", " - RDMA/cxgb4: Cancel reg_work before freeing device on remove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89511", " - qede: Fix NULL pointer dereference in TPA fragment processing", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89512", " - remoteproc: scp: Fix device reference leak on failed lookup", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89524", " - wifi: ath6kl: clamp assoc request/response lengths before subtracting IE", " offsets", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89525", " - udf: reject VAT indexes equal to the entry count", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89532", " - svcrdma: Fix pcl_for_each_segment for empty chunks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89533", " - svcrdma: Fix offset arithmetic in read_chunk_range", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89538", " - SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89540", " - sunrpc: init gssp_lock before publishing proc entry", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89541", " - SUNRPC: harden gss_unwrap_resp_priv length checks", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89542", " - SUNRPC: harden gss_krb5_unwrap_v2 against short tokens", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89548", " - SUNRPC: always drain cache_cleaner before destroying a cache_detail", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89549", " - sunrpc: route to a populated pool in svc_pool_for_cpu()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89551", " - SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89554", " - mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89555", " - mpls: reload header after pskb_may_pull()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89557", " - md: do overflow check for sb->bblog_shift in super_1_load()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89559", " - libnvdimm/labels: Prevent integer overflow in __nd_label_validate()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93226", " - ipv6: use RCU iterator to dump route exceptions", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89562", " - ip6_gre: fix hardware header length for NBMA tunnels", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89563", " - ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89569", " - Bluetooth: RFCOMM: serialize security confirmation handling", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89573", " - dm array: reject an array block whose value size is not the caller's", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89575", " - dm raid1: reserve space for NUL-terminator in build_constructor_string()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89576", " - dm-era: fix shadowed superblock leak on take-snap failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89582", " - bnx2x: fix double free in bnx2x_init_firmware() error path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89585", " - auxdisplay: charlcd: cancel backlight work on registration failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89586", " - ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89594", " - hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89596", " - forcedeth: fix off-by-one when saving/restoring non-PCI config space", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89597", " - fbdev: uvesafb: unregister connector callback on init failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89599", " - fbdev: omapfb: panel-dsi-cm: initialize lock before registering display", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89605", " - ecryptfs: release message context on send failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89606", " - ecryptfs: reject too-small tag 70 packets", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89607", " - ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89608", " - ecryptfs: pass packet set buffer size to parser", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89609", " - ecryptfs: hold msg ctx list lock when cleaning daemon queue", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89615", " - fs/ntfs3: bound page_lcns[] index by the log record", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89616", " - fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89617", " - fs/ntfs3: validate dirty page table on log replay", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89621", " - HID: mcp2221: validate report size in mcp2221_raw_event()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89626", " - HID: sensor: custom: Fix field sysfs group cleanup on failure", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89627", " - HID: roccat: free buffered reports when destroying device", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89628", " - HID: picolcd: clamp eeprom debugfs read to bytes actually received", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89643", " - audit: avoid dropping live tree ref on fsnotify rule autoremove", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89649", " - ceph: bound xattr value length in __build_xattrs()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89650", " - ceph: bound num_export_targets array for mds info v2/v3", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89653", " - ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89655", " - ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89656", " - libceph: reject buckets with mismatched CRUSH ids", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89662", " - NFSD: Prevent lock owner use-after-free during client teardown", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89663", " - nfsd: revoke copy-notify stateids before dropping their reference", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89665", " - nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89669", " - nfsd: initialize copy-notify stateid before publishing it", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89673", " - nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89674", " - nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89684", " - nfsd: fix cpntf publish race in nfs4_init_cp_state", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89694", " - nfsd: check client ownership when cancelling a copy-notify stateid", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89696", " - nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89697", " - nfsd: add fh_want_write() for early-verified SETATTR in", " nfsd_proc_setattr()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89699", " - nfsd: validate symlink target length in NFSv4 CREATE", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89704", " - nfsd: sample writeback error cursor before async COPY loop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89706", " - nfsd: Reset write verifier when async COPY writeback fails", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89710", " - NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget", " path", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89711", " - NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89712", " - NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89720", " - ubifs: fix out-of-bounds read in signature length check", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93213", " - of: fix out-of-bounds read in of_alias_scan() stem parser", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89723", " - nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after", " truncation", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89724", " - media: vicodec: fix out-of-bounds write in FWHT encoder", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89725", " - media: cec: stm32: prevent out-of-bounds write on RX overflow", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89726", " - lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89729", " - HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89730", " - fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89732", " - usb: gadget: f_fs: Prevent deadlock during ep0 read loop", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89733", " - usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and", " uvc_function_unbind()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93214", " - usb: gadget: f_tcm: fix deadlock in usbg_make_tpg()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89736", " - usb: gadget: u_audio: Fix use-after-free on sound card disconnect", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89741", " - Revert \"media: v4l2-dev: fix error handling in", " __video_register_device()\"", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89742", " - rapidio: mport_cdev: fix use-after-free in dma_req_free()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89749", " - tracing: Fix crash passing ERR_PTR to kthread_stop()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89752", " - mm: memcg: stop reclaim when a limit update is superseded", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89753", " - mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec()", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-89765", " - timers/itimer: Zero-init old itimerval before copy to userspace", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-93219", " - clocksource/drivers/timer-sun4i: Advertise a real minimum delta", " * Jammy update: v5.15.221 upstream stable release (LP: #2168726) //", " CVE-2026-23191", " - ALSA: aloop: Fix racy access at PCM trigger", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586)", " - io_uring/io-wq: fix worker accounting when canceling creation callbacks", " - can: j1939: add missing calls in NETDEV_UNREGISTER notification handler", " - can: j1939: make j1939_sk_bind() fail if device is no longer registered", " - Revert \"PM: sleep: Use complete() in device_pm_sleep_init()\"", " - smc: Use __sk_dst_get() and dst_dev_rcu() in smc_vlan_by_tcpsk().", " - selinux: switch two allocations to use kzalloc_objs()", " - ALSA: pcm: fix wait_time calculations", " - ASoC: tegra: Fix Master Volume Control", " - ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked", " streams", " - kcov: replace local_irq_save() with a local_lock_t", " - ext4: propagate errors from fast commit range replay", " - nilfs2: correct return value kernel-doc descriptions for ioctl functions", " - nvme: rename CDR/MORE/DNR to NVME_STATUS_*", " - HID: ft260: fix i2c probing for hwmon devices", " - HID: ft260: improve i2c write performance", " - HID: ft260: improve i2c large reads performance", " - HID: ft260: skip unexpected HID input reports", " - HID: ft260: wake up device from power saving mode", " - HID: ft260: missed NACK from busy device", " - HID: ft260: validate i2c input report length", " - HID: input: read battery capacity from its actual report offset", " - fpga: dfl: fme: add error handling", " - accessibility: speakup: unregister tty ldisc on later init failures", " - xhci: dbgtty: Fix unregister on tty_alloc_driver() failure", " - usb: usbtest: disable dynamic ID support", " - mm/swap: reject swapon() on filesystem-level encrypted files", " - crypto: atmel-tdes - use scatterlist length before DMA mapping", " - crypto: qce - Remove unsafe/deprecated algorithms", " - usb: core: Strengthen error handling in hub_hub_status()", " - USB: serial: spcp8x5: drop broken carrier detect support", " - Linux 5.15.220", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80824", " - usb: usbfs: fix use-after-free of usb_device in usbdev_release()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80826", " - USB: c67x00: fix use-after-free in c67x00_add_iso_urb()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80827", " - USB: serial: option: fix slab OOB read in interrupt URB callback", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80828", " - ALSA: usb-audio: Complete cleanup after system-resume errors", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80829", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80830", " - usb: core: Add lock to usb_wakeup_notification()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80921", " - KVM: s390: vsie: zero stale crypto bits", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80831", " - crypto: mxs-dcp - fix source scatterlist length access", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80832", " - crypto: qce - fix CCM AAD buffer underallocation", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80840", " - ipv6: seg6: clear IPv4 control block on IPIP decapsulation", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80842", " - net: bridge: mcast: fix use-after-free of a master VLAN's multicast", " context", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80843", " - xfrm: fix xfrm_state_construct() auth-trunc leak", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80844", " - xfrm: ah6: validate routing header segments_left", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80846", " - xfrm: drop ESP-in-TCP packets with no ingress device", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80848", " - xfrm: espintcp: fix UAF during close", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80854", " - usb: gadget: f_tcm: keep port count until LUN teardown completes", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80855", " - fuse: fix invalidate lock leak on open O_TRUNC DAX failure", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80856", " - fuse: fix invalidate lock leak on setattr writeback failure", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80923", " - xhci: dbgtty: Fix unregister on tty_register_driver() failure", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80768", " - HID: ft260: fix stack-use-after-return write in I2C read race", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80766", " - HID: uclogic: fix use-after-free of inrange_timer on remove", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80789", " - nvmet-tcp: bound SGL data length before allocating command buffers", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80783", " - HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80796", " - nfc: nci: add data_len bound checks to activation parameter extractors", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80807", " - nilfs2: reject invalid block index in GC ioctl", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80916", " - kcov: fix data corruption and race conditions on PREEMPT_RT", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-72323", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-43437", " - ALSA: pcm: fix use-after-free on linked stream runtime in", " snd_pcm_drain()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-53089", " - bpf: Fix use-after-free in offloaded map/prog info fill", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2025-40102", " - KVM: arm64: Prevent access to vCPU events before init", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2025-39925", " - can: j1939: implement NETDEV_UNREGISTER notification handler", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2024-58095", " - jfs: add check read-only before txBeginAnon() call", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2024-58094", " - jfs: add check read-only before truncation in jfs_truncate_nolock()", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2024-46754", " - bpf: Remove tst_run from lwt_seg6local_prog_ops.", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-68476", " - ipvs: reload ip header after head reallocation", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80806", " - ext4: don't enable DAX on new encrypted files", " * Jammy update: v5.15.220 upstream stable release (LP: #2168586) //", " CVE-2026-80863", " - RDMA/rxe: Fix OOB in free_rd_atomic_resources()", " * Jammy update: v5.15.219 upstream stable release (LP: #2168549)", " - Linux 5.15.219", " * Jammy update: v5.15.219 upstream stable release (LP: #2168549) //", " CVE-2026-80590", " - inet: frags: strip GSO state from fragments before reassembly", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525)", " - null_blk: fix UBSAN shift-out-of-bounds when zone_size is 0 or overflows", " - ext4: clear error before retrying inode xattr space fallback", " - misc: fastrpc: separate fastrpc device from channel context", " - misc: fastrpc: Rework fastrpc_req_munmap", " - perf/core: Fix child_total_time_enabled accounting bug at task exit", " - perf: Fix cgroup state vs ERROR", " - perf: Fix dangling cgroup pointer in cpuctx", " - nfc: nci: free destination parameters when closing a connection", " - drm/amdgpu: check ASPM on the dGPU host link", " - KVM: x86/mmu: Retry page fault if root is invalidated by memslot update", " - KVM: x86/mmu: Directly \"destroy\" PTE list when recycling rmaps", " - KVM: x86/mmu: Rename pte_list_{destroy,remove}() to show they zap SPTEs", " - KVM: x86/mmu: Document the \"rules\" for using host_pfn_mapping_level()", " - KVM: Rename mmu_notifier_* to mmu_invalidate_*", " - KVM: x86/mmu: Split out TDP MMU page fault handling", " - KVM: x86/mmu: Rename __direct_map() to direct_map()", " - HID: magicmouse: Prevent out-of-bounds (OOB) read during", " DOUBLE_REPORT_ID", " - KVM: x86: Retry page fault if MMU reload is pending and root has no sp", " - Input: atkbd - skip deactivate for HONOR FMB-P's internal keyboard", " - Input: atkbd - skip deactivate for HONOR ZQC-P", " - mptcp: pm: ADD_ADDR rtx: allow ID 0", " - mptcp: pm: fix data race in add_addr timer callback", " - can: use skb hash instead of private variable in headroom", " - Revert \"ALSA: aoa: Use guard() for mutex locks\"", " - Linux 5.15.218", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80765", " - HID: hyperv: validate initial device info bounds", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80767", " - HID: sensor: custom: Fix use-after-free in enable_sensor", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80918", " - HID: core: fix number/pointer type confusion on long items", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80889", " - can: isotp: fix timer drain order, wakeup handling and tx_gen ordering", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-46170", " - mptcp: pm: ADD_ADDR rtx: free sk if last", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-46158", " - mptcp: pm: ADD_ADDR rtx: always decrease sk refcount", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80555", " - s390/vfio_ccw: Free all memory if cp_init() fails", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2025-68794", " - iomap: adjust read range correctly for non-block-aligned positions", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-64581", " - xfrm: fix sk_dst_cache double-free in xfrm_user_policy()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80781", " - HID: core: fix OOB read of field->usage in hid_set_field()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80782", " - HID: magicmouse: do not keep a stale msc->input if no input is claimed", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80583", " - ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80587", " - mptcp: avoid combining some incoming suboptions", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80547", " - s390/vfio_ccw: Implement a crw lock", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80548", " - s390/vfio_ccw: Selectively expand io_mutex", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80552", " - s390/vfio_ccw: Ensure index for read/write regions are within range", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80788", " - nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80790", " - nvmet-fc: fix invalid free in LS IOD error path", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80792", " - ipv6: fix use-after-free in ip6_finish_output2()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80793", " - ipv4: reject undersized MTUs in ip_do_fragment()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80557", " - libceph: fix OOB read in decode_watchers() via missing bounds check", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80794", " - nfc: nci: fix uninit-value in the RF discover/activated NTF handlers", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80795", " - nfc: nci: fix out-of-bounds write in nci_target_auto_activated()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80823", " - nfc: st21nfca: validate ATR_REQ length against the received frame", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80797", " - nfc: pn533: purge fragmented skbs during cleanup", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80798", " - nfc: llcp: reject PDUs shorter than the LLCP header", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80799", " - nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80800", " - nfc: llcp: bound the connect_sn TLV walk to the skb", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80801", " - nfc: microread: validate target discovery payload lengths", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80802", " - nfc: fdp: bound the device-reported read length and fix an skb leak", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80803", " - nfc: digital: clamp SENSF_RES length to the destination buffer", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80536", " - xfs: bounds-check buffer log item's dirty bitmap", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80553", " - s390/vfio_ccw: Cancel existing workqueues", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74662", " - inet: frags: publish queues before arming timer", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74666", " - packet: synchronize pressure clearing with ring reconfiguration", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74663", " - net/sched: reject overly deep qdisc hierarchies", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74668", " - packet: use consistent hard_header_len in TX_RING send path", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74582", " - packet: use consistent hard_header_len in non-ring send paths", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80737", " - serial: amba-pl011: synchronize DMA teardown", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74626", " - NTB: ntb_netdev: Preserve RX queue depth on allocation failure", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74637", " - perf/core: Fix group leader use-after-free after sibling detach", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74647", " - misc: fastrpc: Remove buffer from list prior to unmap operation", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-74632", " - mm/huge_memory: fix huge_zero_pfn race", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80562", " - gpio: ml-ioh: use raw_spinlock_t for the register lock", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80805", " - xfs: validate attr entry pointer before field access", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80808", " - ext4: stop retrying saturated xattr cache entries", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80809", " - ocfs2: fix missing metadata reservation for large xattrs", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80812", " - ALSA: dummy: Check card index validity at probe", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80814", " - rndis_host: add overflow check in rndis_rx_fixup()", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80819", " - Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept", " * Jammy update: v5.15.218 upstream stable release (LP: #2168525) //", " CVE-2026-80917", " - PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems", " * Jammy update: v5.15.217 upstream stable release (LP: #2168510)", " - f2fs: fix UAF issue in f2fs_merge_page_bio()", " - media: mediatek: vcodec: Fix a resource leak related to the scp device", " in FW initialization", " - fscrypt: use the mount idmap for the owner check in", " fscrypt_ioctl_set_policy()", " - ipvs: separate destination availability state", " - selinux: require every boolean value to be defined", " - selinux: reject a class permission count below its inherited common", " - selinux: do not cancel a policy conversion that never started", " - mptcp: options: reset DSS fields in case of unexpected size", " - s390/qeth: validate user buffer length in SNMP and ARP query ioctls", " - ASoC: cs4265: sort the register default table", " - ASoC: codecs: lpass-wsa-macro: Fix enum kcontrol accesses", " - powerpc/pseries: pci - logic bug", " - Input: synaptics-rmi4 - fix F55 transmitter electrode count typo", " - Input: focaltech - fix array out-of-bounds in", " focaltech_process_rel_packet", " - Input: psxpad-spi - set driver data before use", " - Input: atkbd - skip deactivate for Xiaomi Book Pro 14's internal", " keyboard", " - Input: iforce - validate input packet lengths", " - powerpc/pseries: lparcfg - fix kbuf[] underflow", " - Input: synaptics-rmi4 - zero report size on F54 work error", " - Input: synaptics-rmi4 - bound the F54 report size to the allocated", " buffer", " - Input: synaptics-rmi4 - block s_input when F54 queue is busy", " - Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue", " - crypto: qce - fix error path in devm_qce_register_algs", " - libceph: fix multiple unsafe decodes in decode_locker()", " - ftrace: Fix off-by-one fentry site disable in ftrace_free_mem()", " - openrisc: signal: do not restore privileged SR bits on sigreturn", " - Input: sur40 - fix input device registration ordering", " - Input: sur40 - fix V4L error path cleanup", " - libceph: Avoid using invalid osd indices from primary_temp", " - ceph: fix MDS random selection readiness predicate", " - libceph: tolerate addrvecs with multiple entries of the same type", " - mmc: omap_hsmmc: fix busy_timeout overflow in ns conversion on 32-bit", " - mmc: sdhci: unmap the bounce buffer before device release", " - mmc: sdhci: make tuning_err a signed int", " - drm/radeon: fix autosuspend cleanup during teardown", " - s390/vfio_ccw: Fix out of bounds check on CCW array", " - drm/amdgpu: Reject UVD message with invalid number of h265 refs", " - drm/amdgpu: validate GEM_CREATE domain combinations", " - drm/amdgpu: Reject UVD message with dimensions above 4096", " - drm/amdgpu: Implement insert_end for VCE 3", " - drm/amdgpu: Fix UVD decode image min size calculation", " - xfs: fix ilock leak on error in xfs_dq_get_next_id", " - xfs: check v5 superblock features early", " - net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot", " - mm: do file ownership checks with the proper mount idmap", " - iommu/amd: Don't split flush for amd_iommu_domain_flush_all()", " - bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is", " uninitialized", " - udmabuf: Do not create malformed scatterlists", " - dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning", " - fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region()", " - Input: mms114 - fix touch indexing for MMS134S and MMS136", " - i2c: davinci: Unregister cpufreq notifier on probe failure", " - Input: mms114 - reject an oversized device packet size", " - ALSA: hda: conexant: Remove mic bias threshold override", " - VFS/audit: introduce kern_path_parent() for audit", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - audit: fix recursive locking deadlock in audit_dupe_exe()", " - ALSA: hda: Fix cached processing coefficient verbs", " - serial: max310x: replace bare use of 'unsigned' with 'unsigned int'", " (checkpatch)", " - serial: max310x: implement gpio_chip::get_direction()", " - rxrpc: serialize kernel accept preallocation with socket teardown", " - fbcon: Rename struct fbcon_ops to struct fbcon_par", " - fbcon: Use correct type for vc_resize() return value", " - tipc: restrict socket queue dumps in enqueue tracepoints", " - mlxsw: spectrum: On port enslavement to a LAG, join upper's bridges", " - mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()", " - vduse: Use fixed 4KB bounce pages for non-4KB page size", " - vduse: remove unused vaddr parameter of vduse_domain_free_coherent", " - vduse: take out allocations from vduse_dev_alloc_coherent", " - VDUSE: avoid leaking information to userspace", " - octeontx2-af: Fix APR entry mapping based on APR_LMT_CFG", " - octeontx2: Annotate mmio regions as __iomem", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - tcp: convert to dev_net_rcu()", " - net: dst: annotate data-races around dst->input", " - net: dst: annotate data-races around dst->output", " - net: dst: add four helpers to annotate data-races around dst->dev", " - ipv4: adopt dst_dev, skb_dst_dev and skb_dst_dev_net[_rcu]", " - netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst", " - ASoC: mediatek: mt8192-afe-pcm: Convert to devm_pm_runtime_enable()", " - ASoC: mediatek: mt8192-afe-pcm: Simplify with dev_err_probe()", " - ASoC: mediatek: Use common mtk_afe_pcm_platform with common probe cb", " - ASoC: mediatek: mt8192-afe-pcm: Simplify probe() with local dev variable", " - ASoC: mediatek: mt8192: Check runtime resume during probe", " - netfilter: nft_set_pipapo: use GFP_KERNEL for insertions", " - netfilter: nft_set_pipapo: move prove_locking helper around", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", " - netfilter: nft_set_pipapo: make pipapo_clone helper return NULL", " - netfilter: nft_set_pipapo: prepare walk function for on-demand clone", " - netfilter: nft_set_pipapo: merge deactivate helper into caller", " - netfilter: nft_set_pipapo: prepare pipapo_get helper for on-demand clone", " - netfilter: nft_set_pipapo: move cloning of match info to insert/removal", " path", " - netfilter: nft_set_pipapo: don't leak bad clone into future transaction", " - remoteproc: qcom: replace kstrdup with kstrndup", " - remoteproc: qcom: fix sparse warnings", " - remoteproc: qcom: pas: Adjust the phys addr wrt the mem region", " - remoteproc: qcom: Fix leak when custom dump_segments addition fails", " - lsm: use default hook return value in call_int_hook()", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - fs/ntfs3: Make ntfs_update_mftmirr return void", " - fs/ntfs3: Undo critial modificatins to keep directory consistency", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - net: thunderbolt: Fix frags[] overflow by bounding frame_count", " - mtd: spi-nor: Fix spi_nor_try_unlock_all()", " - mtd: spi-nor: swp: Improve locking user experience", " - dmaengine: dw-edma: Remove unused irq field in struct dw_edma_chip", " - dmaengine: dw-edma: Detach the private data and chip info structures", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - taskstats: fill_stats_for_tgid: use for_each_thread()", " - taskstats: retain dead thread stats in TGID queries", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - ksmbd: fix integer overflow in set_file_allocation_info()", " - i2c: imx: separate atomic, dma and non-dma use case", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", " - can/esd_usb2: Rename esd_usb2.c to esd_usb.c", " - [Config] Set CONFIG_CAN_ESD_USB=m", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - thunderbolt: Remove usage of the deprecated ida_simple_xx() API", " - thunderbolt: Update property.c function documentation", " - thunderbolt: Keep XDomain reference during the lifetime of a service", " - thunderbolt: Remove service debugfs entries during unregister", " - thunderbolt: Remove XDomain from the bus without holding tb->lock", " - thunderbolt: Prevent XDomain delayed work use-after-free on disconnect", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - ovl: use linked upper dentry in copy-up tmpfile", " - scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: make error counter atomic", " - firmware_loader: introduce __free() cleanup hanler", " - Input: ims-pcu - fix firmware leak in async update", " - mmc: vub300: fix use-after-free on disconnect", " - mmc: vub300: rename probe error labels", " - mmc: vub300: fix use-after-free on probe failure", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", " - net: Add helper function to parse netlink msg of ip_tunnel_encap", " - net: ipip: require CAP_NET_ADMIN in the device netns for changelink", " - net: ixp4xx_hss: fix duplicate HDLC netdev allocation", " - net/sched: act_ct: preserve tc_skb_cb across defragmentation", " - net: mana: Validate the packet length reported by the NIC", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", " - treewide: rename pinctrl_gpio_direction_output_new()", " - gpio: tegra: do not call pinctrl for GPIO direction", " - net/sched: taprio: avoid calling child->ops->dequeue(child) twice", " - net/sched: sch_taprio: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - bootconfig: do not put quotes on cmdline items unless necessary", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - espintcp: use sk_msg_free_partial to fix partial send", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - octeontx2-pf: fix SQB pointer leak on init failure", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", " - usb: gadget: f_tcm: synchronize delayed set_alt with teardown", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", " - dma-buf/drivers: make reserving a shared slot mandatory v4", " - drm/virtio: use uninterruptible resv lock for plane updates", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/tegra: fbdev: Remove offset into framebuffer memory", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/virtio: Return proper error codes instead of -1", " - drm/virtio: bound EDID block reads to the response buffer", " - media: aspeed: fix missing of_reserved_mem_device_release() on probe", " failure", " - drm/i915/vrr: require valid min/max vfreq for VRR", " - drm/i915/hdcp: check streams[] bounds before overflow", " - drm/i915/hdcp: require monotonically increasing seq_num_v", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: i2c: imx219: Drop IMX219_VTS_* macros", " - media: i2c: imx219: Correct the minimum vblanking value", " - media: i2c: imx219: Rename VTS to FRM_LENGTH", " - media: imx219: Fix maximum frame length in lines", " - wifi: ath6kl: fix use-after-free in aggr_reset_state()", " - media: v4l: async: Set owner for async sub-devices", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", " - ALSA: seq: close a re-opened queue timer in the destructor", " - wifi: brcmfmac: drain bus_reset work on device removal", " - serial: 8250_mid: Remove unneeded test for ->setup() presence", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " - wifi: brcmfmac: fix 43752 SDIO FWVID incorrectly labelled as Cypress", " (CYW)", " - wifi: brcmfmac: set F2 blocksize to 256 for BCM43752", " - sc16is7xx: Properly resume TX after stop", " - serial: sc16is7xx: Fill in rs485_supported", " - serial: sc16is7xx: remove obsolete out_thread label", " - serial: sc16is7xx: fix regression with GPIO configuration", " - serial: sc16is7xx: implement gpio get_direction() callback", " - mptcp: cleanup MPJ subflow list handling", " - mptcp: fix subflow accounting on close", " - mptcp: decrement subflows counter on failed passive join", " - sctp: avoid auth_enable sysctl UAF during netns teardown", " - ceph: avoid fs reclaim while using current->journal_info", " - libceph: Amend checking to fix `make W=1` build breakage", " - libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE", " - libceph: add doutc and *_client debug macros support", " - ceph: rename _to_client() to _to_fs_client()", " - ceph: print cluster fsid and client global_id in all debug logs", " - ceph: fix hanging __ceph_get_caps() with stale mds_wanted", " - libceph: fix two unsafe bare decodes in decode_lockers()", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", " - net/sched: serialize qdisc_rtab_list against concurrent get/put", " - ftrace: Add global mutex to serialize trace_parser access", " - super: fix emergency thaw deadlock on frozen block devices", " - ksmbd: rename smb2_get_msg to smb_get_msg", " - smb/server: fix minimum SMB1 PDU size", " - smb/server: fix minimum SMB2 PDU size", " - ksmbd: validate minimum PDU size for transform requests", " - mm/vmstat: fold stranded per-cpu node stats when a node comes online", " - ksmbd: conn lock to serialize smb2 negotiate", " - ksmbd: reject repeated SMB2 NEGOTIATE requests", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", " - igc: remove napi_synchronize() in igc_down()", " - net: pktgen: fix code style (WARNING: Block comments)", " - net: pktgen: fix proc entry use-after-free", " - scsi: sd: sd_zbc: Improve source code documentation", " - scsi: sd: sd_zbc: Use logical blocks as unit when querying zones", " - scsi: sd: sd_zbc: Introduce struct zoned_disk_info", " - scsi: sd: sd_zbc: Return early in sd_zbc_check_zoned_characteristics()", " - scsi: scsi_debug: Rename zone type constants", " - scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write", " - ice: fix VF interrupts cleanup", " - ice: fix memory leak in ice_lbtest_prepare_rings()", " - fsnotify: opt-in for permission events at file open time", " - fs: don't block write during exec on pre-content watched files", " - binfmt_misc: restore write access when removing an entry", " - i2c: imx: Fix slave registration race and error handling", " - i2c: bcm-iproc: remove printout on handled timeouts", " - i2c: iproc: reset bus after timeout if START_BUSY is stuck", " - can: gs_usb: gs_usb_receive_bulk_callback(): resubmit URB on skb", " allocation failure", " - jiffies: Define secs_to_jiffies()", " - ice: wait for reset completion in ice_resume()", " - drm/amd/pm: fix torn gpu metrics reads", " - sched/psi: Shut down rtpoll_timer in psi_cgroup_free()", " - mm/ptdump: always stabilise against page table freeing using init_mm", " - net: add a couple of helpers for iph tot_len", " - openvswitch: use skb_ip_totlen in conntrack", " - net: sched: use skb_ip_totlen and iph_totlen", " - openvswitch: move key and ovs_cb update out of handle_fragments", " - net/sched: act_ct: fix sk_buff leak when the header checks reject a", " packet", " - net: atlantic: free stranded TX buffers on ring deinit", " - net/smc: rdma write inline if qp has sufficient inline space", " - net: smc: fix splice entry lifetime imbalance in smc_rx_splice", " - arm64: tegra: Add EL2 virtual timer interrupt for Tegra194", " - crypto: ccm - Set rfc4309 maxauthsize from child", " - netfilter: ipset: fix refcount race between list:set GC and swap", " - netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort", " path", " - netfilter: flowtable: publish GC-visible tuple last", " - netfilter: ipset: fix list type element drift bug", " - net: packet: fix wrong transport_header when sending VLAN-tagged frame", " - ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers", " - af_packet: Don't send zero-byte data in tpacket_snd().", " - net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG", " - net/x25: fix use-after-free of the socket by its timers", " - binfmt_misc: use exe_file_deny_write_access() for the interpreter clone", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - drm/vmwgfx: Reserve fence slots on buffer objects in cotables", " - drm/virtio: Unlock reservations on dma_resv_reserve_fences() error", " - jiffies: Cast to unsigned long in secs_to_jiffies() conversion", " - ring-buffer: Remove jump to out label in ring_buffer_swap_cpu()", " - ring-buffer: Use current_context for safe per-CPU buffer swap", " - Linux 5.15.217", "" ], "package": "linux-kvm", "version": "5.15.0-1111.116", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2170108, 2170970, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2169603, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168726, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168586, 2168549, 2168549, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168525, 2168510 ], "author": "Alessio Faina ", "date": "Fri, 16 Oct 2026 09:22:17 +0200" }, { "cves": [ { "cve": "CVE-2022-1205", "url": "https://ubuntu.com/security/CVE-2022-1205", "cve_description": "A NULL pointer dereference flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system.", "cve_priority": "high", "cve_public_date": "2022-08-31 16:15:00 UTC" }, { "cve": "CVE-2022-50303", "url": "https://ubuntu.com/security/CVE-2022-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix double release compute pasid If kfd_process_device_init_vm returns failure after vm is converted to compute vm and vm->pasid set to compute pasid, KFD will not take pdd->drm_file reference. As a result, drm close file handler maybe called to release the compute pasid before KFD process destroy worker to release the same pasid and set vm->pasid to zero, this generates below WARNING backtrace and NULL pointer access. Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step of kfd_process_device_init_vm, to ensure vm pasid is the original pasid if acquiring vm failed or is the compute pasid with pdd->drm_file reference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10", "cve_priority": "medium", "cve_public_date": "2025-09-15 15:15:00 UTC" }, { "cve": "CVE-2023-53320", "url": "https://ubuntu.com/security/CVE-2023-53320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info() The function mpi3mr_get_all_tgt_info() has four issues: 1) It calculates valid entry length in alltgt_info assuming the header part of the struct mpi3mr_device_map_info would equal to sizeof(u32). The correct size is sizeof(u64). 2) When it calculates the valid entry length kern_entrylen, it excludes one entry by subtracting 1 from num_devices. 3) It copies num_device by calling memcpy(). Substitution is enough. 4) It does not specify the calculated length to sg_copy_from_buffer(). Instead, it specifies the payload length which is larger than the alltgt_info size. It causes \"BUG: KASAN: slab-out-of-bounds\". Fix the issues by using the correct header size, removing the subtraction from num_devices, replacing the memcpy() with substitution and specifying the correct length to sg_copy_from_buffer().", "cve_priority": "low", "cve_public_date": "2025-09-16 17:15:00 UTC" }, { "cve": "CVE-2025-39726", "url": "https://ubuntu.com/security/CVE-2025-39726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ism: fix concurrency management in ism_cmd() The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that. This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well. A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it. On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.", "cve_priority": "high", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39779", "url": "https://ubuntu.com/security/CVE-2025-39779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: subpage: keep TOWRITE tag until folio is cleaned btrfs_subpage_set_writeback() calls folio_start_writeback() the first time a folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tag even if there are still dirty blocks in the folio. This can break ordering guarantees, such as those required by btrfs_wait_ordered_extents(). That ordering breakage leads to a real failure. For example, running generic/464 on a zoned setup will hit the following ASSERT. This happens because the broken ordering fails to flush existing dirty pages before the file size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode or for compressed writes, it locks several folios for delalloc and starts writing them out. Let's call the last locked folio folio X. Suppose the write range only partially covers folio X, leaving some pages dirty. Process A calls btrfs_subpage_set_writeback() when building a bio. This function call clears the TOWRITE tag of folio X, whose size = 8K and the block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range. Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. It calls tag_pages_for_writeback() to tag dirty folios with PAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then, B collects tagged folios using filemap_get_folios_tag() and must wait for folio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE) However, between tagging and collecting, process A may call btrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY) As a result, process B won't see folio X in its batch, and returns without waiting for it. This breaks the WB_SYNC_ALL ordering requirement. Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retains the TOWRITE tag. We now manually clear the tag only after the folio becomes clean, via the xas operation.", "cve_priority": "medium", "cve_public_date": "2025-09-11 17:15:00 UTC" }, { "cve": "CVE-2025-39810", "url": "https://ubuntu.com/security/CVE-2025-39810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix memory corruption when FW resources change during ifdown bnxt_set_dflt_rings() assumes that it is always called before any TC has been created. So it doesn't take bp->num_tc into account and assumes that it is always 0 or 1. In the FW resource or capability change scenario, the FW will return flags in bnxt_hwrm_if_change() that will cause the driver to reinitialize and call bnxt_cancel_reservations(). This will lead to bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc may be greater than 1. This will cause bp->tx_ring[] to be sized too small and cause memory corruption in bnxt_alloc_cp_rings(). Fix it by properly scaling the TX rings by bp->num_tc in the code paths mentioned above. Add 2 helper functions to determine bp->tx_nr_rings and bp->tx_nr_rings_per_tc.", "cve_priority": "low", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-37861", "url": "https://ubuntu.com/security/CVE-2025-37861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.", "cve_priority": "low", "cve_public_date": "2025-05-09 07:16:00 UTC" }, { "cve": "CVE-2025-38643", "url": "https://ubuntu.com/security/CVE-2025-38643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() Callers of wdev_chandef() must hold the wiphy mutex. But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes: WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985", "cve_priority": "low", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-38615", "url": "https://ubuntu.com/security/CVE-2025-38615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: cancle set bad inode after removing name fails The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted. The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's \"icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier\". In some it's outright \"we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles\".", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38361", "url": "https://ubuntu.com/security/CVE-2025-38361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check dce_hwseq before dereferencing it [WHAT] hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used. (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)", "cve_priority": "low", "cve_public_date": "2025-07-25 13:15:00 UTC" }, { "cve": "CVE-2025-38259", "url": "https://ubuntu.com/security/CVE-2025-38259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd9335: Fix missing free of regulator supplies Driver gets and enables all regulator supplies in probe path (wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup in final error paths and in unbind (missing remove() callback). This leads to leaked memory and unbalanced regulator enable count during probe errors or unbind. Fix this by converting entire code into devm_regulator_bulk_get_enable() which also greatly simplifies the code.", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38239", "url": "https://ubuntu.com/security/CVE-2025-38239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix invalid node index On a system with DRAM interleave enabled, out-of-bound access is detected: megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it accordingly.", "cve_priority": "low", "cve_public_date": "2025-07-09 11:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2022-50071", "url": "https://ubuntu.com/security/CVE-2022-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: move subflow cleanup in mptcp_destroy_common() If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE eBPF program, the MPTCP protocol ends-up leaking all the subflows: the related cleanup happens in __mptcp_destroy_sock() that is not invoked in such code path. Address the issue moving the subflow sockets cleanup in the mptcp_destroy_common() helper, which is invoked in every msk cleanup path. Additionally get rid of the intermediate list_splice_init step, which is an unneeded relic from the past. The issue is present since before the reported root cause commit, but any attempt to backport the fix before that hash will require a complete rewrite.", "cve_priority": "medium", "cve_public_date": "2025-06-18 11:15:00 UTC" }, { "cve": "CVE-2025-37920", "url": "https://ubuntu.com/security/CVE-2025-37920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: Fix race condition in AF_XDP generic RX path Move rx_lock from xsk_socket to xsk_buff_pool. Fix synchronization for shared umem mode in generic RX path where multiple sockets share single xsk_buff_pool. RX queue is exclusive to xsk_socket, while FILL queue can be shared between multiple sockets. This could result in race condition where two CPU cores access RX path of two different sockets sharing the same umem. Protect both queues by acquiring spinlock in shared xsk_buff_pool. Lock contention may be minimized in the future by some per-thread FQ buffering. It's safe and necessary to move spin_lock_bh(rx_lock) after xsk_rcv_check(): * xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers. * xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-43456", "url": "https://ubuntu.com/security/CVE-2026-43456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix type confusion in bond_setup_by_slave() kernel BUG at net/core/skbuff.c:2306! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306 RSP: 0018:ffffc90004aff760 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900 RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780 R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0 Call Trace: ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900 dev_hard_header include/linux/netdevice.h:3439 [inline] packet_snd net/packet/af_packet.c:3028 [inline] packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592 ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646 __sys_sendmsg+0x170/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe1a0e6c1a9 When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond, bond_setup_by_slave() directly copies the slave's header_ops to the bond device: bond_dev->header_ops = slave_dev->header_ops; This causes a type confusion when dev_hard_header() is later called on the bond device. Functions like ipgre_header(), ip6gre_header(),all use netdev_priv(dev) to access their device-specific private data. When called with the bond device, netdev_priv() returns the bond's private data (struct bonding) instead of the expected type (e.g. struct ip_tunnel), leading to garbage values being read and kernel crashes. Fix this by introducing bond_header_ops with wrapper functions that delegate to the active slave's header_ops using the slave's own device. This ensures netdev_priv() in the slave's header functions always receives the correct device. The fix is placed in the bonding driver rather than individual device drivers, as the root cause is bond blindly inheriting header_ops from the slave without considering that these callbacks expect a specific netdev_priv() layout. The type confusion can be observed by adding a printk in ipgre_header() and running the following commands: ip link add dummy0 type dummy ip addr add 10.0.0.1/24 dev dummy0 ip link set dummy0 up ip link add gre1 type gre local 10.0.0.1 ip link add bond1 type bond mode active-backup ip link set gre1 master bond1 ip link set gre1 up ip link set bond1 up ip addr add fe80::1/64 dev bond1", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2022-49858", "url": "https://ubuntu.com/security/CVE-2022-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix SQE threshold checking Current way of checking available SQE count which is based on HW updated SQB count could result in driver submitting an SQE even before CQE for the previously transmitted SQE at the same index is processed in NAPI resulting losing SKB pointers, hence a leak. Fix this by checking a consumer index which is updated once CQE is processed.", "cve_priority": "medium", "cve_public_date": "2025-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-22057", "url": "https://ubuntu.com/security/CVE-2025-22057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: decrease cached dst counters in dst_release Upstream fix ac888d58869b (\"net: do not delay dst_entries_add() in dst_release()\") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30 Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-22083", "url": "https://ubuntu.com/security/CVE-2025-22083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang: 1. Use-after-free when no tpgs are found: This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If a scsi request is then sent we do: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend which sees the vs_tpg we just did a kfree on. 2. Tpg dir removal hang: This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1. The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg. Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir. 3. Tpg leak: This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names. The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs. Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2024-58096", "url": "https://ubuntu.com/security/CVE-2024-58096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode ath11k_hal_srng_* should be used with srng->lock to protect srng data. For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock. So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319 So add srng->lock for them to avoid such warnings. Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct hal_srng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_process_rx(). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-21947", "url": "https://ubuntu.com/security/CVE-2025-21947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix type confusion via race condition when using ipc_msg_send_request req->handle is allocated using ksmbd_acquire_id(&ipc_ida), based on ida_alloc. req->handle from ksmbd_ipc_login_request and FSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion between messages, resulting in access to unexpected parts of memory after an incorrect delivery. ksmbd check type of ipc response but missing add continue to check next ipc reponse.", "cve_priority": "high", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2022-49562", "url": "https://ubuntu.com/security/CVE-2022-49562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing \"random\" pfns for pretty much any other VM_PFNMAP case.", "cve_priority": "low", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2025-21812", "url": "https://ubuntu.com/security/CVE-2025-21812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: rcu protect dev->ax25_ptr syzbot found a lockdep issue [1]. We should remove ax25 RTNL dependency in ax25_setsockopt() This should also fix a variety of possible UAF in ax25. [1] WARNING: possible circular locking dependency detected 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted ------------------------------------------------------ syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated---", "cve_priority": "high", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21801", "url": "https://ubuntu.com/security/CVE-2025-21801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ravb: Fix missing rtnl lock in suspend/resume path Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations. Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down", "cve_priority": "low", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-54683", "url": "https://ubuntu.com/security/CVE-2024-54683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: IDLETIMER: Fix for possible ABBA deadlock Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs: | ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20 | | but task is already holding lock: | ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v] | | which lock already depends on the new lock. A simple reproducer is: | #!/bin/bash | | while true; do | iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\" | iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label \"testme\" | done & | while true; do | cat /sys/class/xt_idletimer/timers/testme >/dev/null | done Avoid this by freeing list_mutex right after deleting the element from the list, then continuing with the teardown.", "cve_priority": "medium", "cve_public_date": "2025-01-11 13:15:00 UTC" }, { "cve": "CVE-2024-53220", "url": "https://ubuntu.com/security/CVE-2024-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to account dirty data in __get_secs_required() It will trigger system panic w/ testcase in [1]: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2752! RIP: 0010:new_curseg+0xc81/0x2110 Call Trace: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is if checkpoint_disabling and lfs_mode are both on, it will trigger OPU for all overwritten data, it may cost more free segment than expected, so f2fs must account those data correctly to calculate cosumed free segments later, and return ENOSPC earlier to avoid run out of free segment during block allocation. [1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2025-21759", "url": "https://ubuntu.com/security/CVE-2025-21759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: extend RCU protection in igmp6_send() igmp6_send() can be called without RTNL or RCU being held. Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection.", "cve_priority": "high", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57999", "url": "https://ubuntu.com/security/CVE-2024-57999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing. These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range. The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries Workqueue: events work_for_cpu_fn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100 LR [c00000000005e830] iommu_init_table+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620 [c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 There are 2 issues in the code 1. The index is \"int\" while the address is \"unsigned long\". This results in negative value when setting the bitmap. 2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well.", "cve_priority": "low", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57982", "url": "https://ubuntu.com/security/CVE-2024-57982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: state: fix out-of-bounds read during lookup lookup and resize can run in parallel. The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array. rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask; While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) { This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again). Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent. The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side. xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2022-49651", "url": "https://ubuntu.com/security/CVE-2022-49651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: srcu: Tighten cleanup_srcu_struct() GP checks Currently, cleanup_srcu_struct() checks for a grace period in progress, but it does not check for a grace period that has not yet started but which might start at any time. Such a situation could result in a use-after-free bug, so this commit adds a check for a grace period that is needed but not yet started to cleanup_srcu_struct().", "cve_priority": "low", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2022-49359", "url": "https://ubuntu.com/security/CVE-2022-49359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Job should reference MMU not file_priv For a while now it's been allowed for a MMU context to outlive it's corresponding panfrost_priv, however the job structure still references panfrost_priv to get hold of the MMU context. If panfrost_priv has been freed this is a use-after-free which I've been able to trigger resulting in a splat. To fix this, drop the reference to panfrost_priv in the job structure and add a direct reference to the MMU structure which is what's actually needed.", "cve_priority": "high", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2022-49234", "url": "https://ubuntu.com/security/CVE-2022-49234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: Avoid cross-chip syncing of VLAN filtering Changes to VLAN filtering are not applicable to cross-chip notifications. On a system like this: .-----. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-' '-1-2-' '-1-2-' Before this change, upon sw1p1 leaving a bridge, a call to dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1. In this scenario: .---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-' When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be called for sw2 and sw3 with a non-existing port - leading to array out-of-bounds accesses and crashes on mv88e6xxx.", "cve_priority": "medium", "cve_public_date": "2025-02-26 07:01:00 UTC" }, { "cve": "CVE-2024-57945", "url": "https://ubuntu.com/security/CVE-2024-57945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Fix the out of bound issue of vmemmap address In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)). However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page. For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END. This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base.", "cve_priority": "low", "cve_public_date": "2025-01-21 13:15:00 UTC" }, { "cve": "CVE-2024-53210", "url": "https://ubuntu.com/security/CVE-2024-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct() Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skb_queue_purge() and WARN_ON in iucv_sock_destruct() during socket close. To fix this decrease skb refcount by one if MSG_PEEK is set in order to prevent memory leak and WARN_ON. WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53187", "url": "https://ubuntu.com/security/CVE-2024-53187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check for overflows in io_pin_pages WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1110.115 -proposed tracker (LP: #2168199)", "", " [ Ubuntu: 5.15.0-199.209 ]", "", " * jammy/linux: 5.15.0-199.209 -proposed tracker (LP: #2168214)", " * [SRU] selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value", " (LP: #2107442)", " - selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value", " * CVE-2022-1205", " - ax25: Fix ax25 session cleanup problems", " * CVE-2022-50303", " - drm/amdkfd: Fix double release compute pasid", " * CVE-2023-53320", " - scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info()", " * CVE-2025-39726", " - s390/ism: fix concurrency management in ism_cmd()", " * CVE-2025-39779", " - btrfs: subpage: keep TOWRITE tag until folio is cleaned", " * CVE-2025-39810", " - bnxt_en: Fix memory corruption when FW resources change during ifdown", " * udpgro.sh from ubuntu_kselftests_net failed with J-5.15 (udpgso_bench_rx:", " recv: bad packet len) (LP: #2129861)", " - selftests: udpgro: no need to load xdp for gro", " * CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", " * CVE-2025-37861", " - scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue", " * CVE-2025-38643", " - wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()", " * CVE-2025-38615", " - fs/ntfs3: cancle set bad inode after removing name fails", " * CVE-2025-38361", " - drm/amd/display: Check dce_hwseq before dereferencing it", " * CVE-2025-38259", " - ASoC: codecs: wcd9335: Fix missing free of regulator supplies", " * CVE-2025-38239", " - scsi: megaraid_sas: Fix invalid node index", " * CVE-2025-38069", " - PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops", " * CVE-2022-50071", " - mptcp: move subflow cleanup in mptcp_destroy_common()", " * CVE-2025-37920", " - xsk: Fix race condition in AF_XDP generic RX path", " * CVE-2026-43456", " - bonding: fix type confusion in bond_setup_by_slave()", " - bonding: prevent potential infinite loop in bond_header_parse()", " * CVE-2022-49858", " - octeontx2-pf: Fix SQE threshold checking", " * CVE-2025-22057", " - net: decrease cached dst counters in dst_release", " * CVE-2025-22083", " - vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint", " * CVE-2024-58096", " - wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode", " * CVE-2025-21947", " - ksmbd: fix type confusion via race condition when using", " ipc_msg_send_request", " * CVE-2022-49562", " - KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits", " * CVE-2025-21812", " - ax25: rcu protect dev->ax25_ptr", " * CVE-2025-21801", " - net: ravb: Fix missing rtnl lock in suspend/resume path", " * CVE-2024-54683", " - netfilter: IDLETIMER: Fix for possible ABBA deadlock", " * CVE-2024-53220", " - f2fs: fix to account dirty data in __get_secs_required()", " * CVE-2025-21759", " - ipv6: mcast: extend RCU protection in igmp6_send()", " * CVE-2024-57999", " - powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW", " * CVE-2024-57982", " - xfrm: state: fix out-of-bounds read during lookup", " * CVE-2022-49651", " - srcu: Tighten cleanup_srcu_struct() GP checks", " * CVE-2022-49359", " - drm/panfrost: Job should reference MMU not file_priv", " * CVE-2022-49234", " - net: dsa: Avoid cross-chip syncing of VLAN filtering", " * CVE-2024-57945", " - riscv: mm: Fix the out of bound issue of vmemmap address", " * CVE-2024-53210", " - s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()", " * CVE-2024-53187", " - io_uring: check for overflows in io_pin_pages", "" ], "package": "linux-kvm", "version": "5.15.0-1110.115", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2168199, 2168214, 2107442, 2129861 ], "author": "Alessio Faina ", "date": "Mon, 28 Sep 2026 14:57:31 +0200" } ], "notes": "linux-modules-5.15.0-1111-kvm version '5.15.0-1111.116' (source package linux-kvm version '5.15.0-1111.116') was added. linux-modules-5.15.0-1111-kvm version '5.15.0-1111.116' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1109-kvm. As such we can use the source package version of the removed package, '5.15.0-1109.114', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-5.15.0-1109-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1109.114", "version": "5.15.0-1109.114" }, "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-1109-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1109.114", "version": "5.15.0-1109.114" }, "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-1109", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1109.114", "version": "5.15.0-1109.114" }, "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-1109-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1109.114", "version": "5.15.0-1109.114" }, "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 20261020 to 20261028", "from_series": "jammy", "to_series": "jammy", "from_serial": "20261020", "to_serial": "20261028", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }