https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 20:52:56 +0000 https://cve.radiocsirt.org/vuln/alsa-2024:6567 <p><strong>Affected:</strong> AlmaLinux:9: bpftool, AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core and 52 more</p> <p>The kernel packages contain the Linux kernel, the core of any Linux operating system.</p> <p>Security Fix(es):</p> <p>* kernel: efivarfs: force RO when remounting if SetVariable is not supported (CVE-2023-52463) * kernel: nfsd: fix RELEASE_LOCKOWNER (CVE-2024-26629) * kernel: mm: cachestat: fix folio read-after-free in cache walk (CVE-2024-26630) * kernel: mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again (CVE-2024-26720) * kernel: Bluetooth: af_bluetooth: Fix deadlock (CVE-2024-26886) * kernel: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address (CVE-2024-26946) * kernel: KVM: SVM: Flush pages under kvm-&amp;gt;lock to fix UAF in svm_register_enc_region() (CVE-2024-35791) * kernel: mm: cachestat: fix two shmem bugs (CVE-2024-35797) * kernel: x86/coco: Require seeding RNG with RDRAND on CoCo systems (CVE-2024-35875) * kernel: mm/hugetlb: fix missing hugetlb_lock for resv uncharge (CVE-2024-36000) * kernel: iommufd: Fix missing update of domains_itree after splitting iopt_area (CVE-2023-52801) * kernel: net: fix out-of-bounds access in ops_init (CVE-2024-36883) * kernel: regmap: maple: Fix cache corruption in regcache_maple_drop() (CVE-2024-36019) * kernel: usb-storage: alauda: Check whether the media is initialized (CVE-2024-38619) * kernel: net: bridge: mst: fix vlan use-after-free (CVE-2024-36979) * kernel: scsi: qedf: Ensure the copied buf is NUL terminated (CVE-2024-38559) * kernel: xhci: Handle TD clearing fo…</p> <p><strong>Affected:</strong> AlmaLinux:9: bpftool, AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core and 52 more</p> <p>The kernel packages contain the Linux kernel, the core of any Linux operating system.</p> <p>Security Fix(es):</p> <p>* kernel: efivarfs: force RO when remounting if SetVariable is not supported (CVE-2023-52463) * kernel: nfsd: fix RELEASE_LOCKOWNER (CVE-2024-26629) * kernel: mm: cachestat: fix folio read-after-free in cache walk (CVE-2024-26630) * kernel: mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again (CVE-2024-26720) * kernel: Bluetooth: af_bluetooth: Fix deadlock (CVE-2024-26886) * kernel: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address (CVE-2024-26946) * kernel: KVM: SVM: Flush pages under kvm-&amp;gt;lock to fix UAF in svm_register_enc_region() (CVE-2024-35791) * kernel: mm: cachestat: fix two shmem bugs (CVE-2024-35797) * kernel: x86/coco: Require seeding RNG with RDRAND on CoCo systems (CVE-2024-35875) * kernel: mm/hugetlb: fix missing hugetlb_lock for resv uncharge (CVE-2024-36000) * kernel: iommufd: Fix missing update of domains_itree after splitting iopt_area (CVE-2023-52801) * kernel: net: fix out-of-bounds access in ops_init (CVE-2024-36883) * kernel: regmap: maple: Fix cache corruption in regcache_maple_drop() (CVE-2024-36019) * kernel: usb-storage: alauda: Check whether the media is initialized (CVE-2024-38619) * kernel: net: bridge: mst: fix vlan use-after-free (CVE-2024-36979) * kernel: scsi: qedf: Ensure the copied buf is NUL terminated (CVE-2024-38559) * kernel: xhci: Handle TD clearing fo…</p> https://cve.radiocsirt.org/vuln/alsa-2024:6567 https://cve.radiocsirt.org/vuln/bdu:2025-03404 bdu:2025-03404 https://cve.radiocsirt.org/vuln/bdu:2025-03404 https://cve.radiocsirt.org/vuln/bell-cve-2024-40927 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2024-40927 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0613 certfr-2024-avi-0613 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0613 https://cve.radiocsirt.org/vuln/euvd-2026-312946 EUVD-2026-312946 https://cve.radiocsirt.org/vuln/euvd-2026-312946 https://cve.radiocsirt.org/vuln/fkie_cve-2024-40927 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>xhci: Handle TD clearing for multiple streams case</p> <p>When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N&gt;1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/&#34;should never happen&#34; paths to ensure we at least clear any affected TDs, even if we can&#39;t issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens.</p> <p>This problem case dates back to commit e9df17eb1408 (&#34;USB: xhci: Correct assumptions about number of rings per endpoint.&#34;) early on in the XHCI driver&#39;s life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 (&#34;xhci: split handling halted endpoints into two steps&#34;), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious).</p> <p>Then later, in commit 94f339147fc3 (&#34;xhci: Fix failure to give back some cached cancelled URBs.&#34;), it was acknowledged again.</p> <p>[Mathias: commit 94f339147fc3 (&#34;xhci: Fix failure to…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>xhci: Handle TD clearing for multiple streams case</p> <p>When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N&gt;1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/&#34;should never happen&#34; paths to ensure we at least clear any affected TDs, even if we can&#39;t issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens.</p> <p>This problem case dates back to commit e9df17eb1408 (&#34;USB: xhci: Correct assumptions about number of rings per endpoint.&#34;) early on in the XHCI driver&#39;s life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 (&#34;xhci: split handling halted endpoints into two steps&#34;), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious).</p> <p>Then later, in commit 94f339147fc3 (&#34;xhci: Fix failure to give back some cached cancelled URBs.&#34;), it was acknowledged again.</p> <p>[Mathias: commit 94f339147fc3 (&#34;xhci: Fix failure to…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-40927 https://cve.radiocsirt.org/vuln/ghsa-38vr-8qrj-3x4h <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>xhci: Handle TD clearing for multiple streams case</p> <p>When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N&gt;1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/&#34;should never happen&#34; paths to ensure we at least clear any affected TDs, even if we can&#39;t issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens.</p> <p>This problem case dates back to commit e9df17eb1408 (&#34;USB: xhci: Correct assumptions about number of rings per endpoint.&#34;) early on in the XHCI driver&#39;s life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 (&#34;xhci: split handling halted endpoints into two steps&#34;), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious).</p> <p>Then later, in commit 94f339147fc3 (&#34;xhci: Fix failure to give back some cached cancelled URBs.&#34;), it was acknowledged again.</p> <p>[Mathias: commit 94f339147fc3 (&#34;xhci: Fix failure to…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>xhci: Handle TD clearing for multiple streams case</p> <p>When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N&gt;1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/&#34;should never happen&#34; paths to ensure we at least clear any affected TDs, even if we can&#39;t issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens.</p> <p>This problem case dates back to commit e9df17eb1408 (&#34;USB: xhci: Correct assumptions about number of rings per endpoint.&#34;) early on in the XHCI driver&#39;s life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 (&#34;xhci: split handling halted endpoints into two steps&#34;), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious).</p> <p>Then later, in commit 94f339147fc3 (&#34;xhci: Fix failure to give back some cached cancelled URBs.&#34;), it was acknowledged again.</p> <p>[Mathias: commit 94f339147fc3 (&#34;xhci: Fix failure to…</p> https://cve.radiocsirt.org/vuln/ghsa-38vr-8qrj-3x4h https://cve.radiocsirt.org/vuln/oesa-2024-2534 <p><strong>Affected:</strong> openEuler:22.03-LTS-SP3: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N&amp;gt;1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/&amp;quot;should never happen&amp;quot; paths to ensure we at least clear any affected TDs, even if we can&amp;apos;t issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 (&amp;quot;USB: xhci: Correct assumptions about number of rings per endpoint.&amp;quot;) early on in the XHCI driver&amp;apos;s life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 (&amp;quot;xhci: split handling halted endpoints into two steps&amp;quot;), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 (&amp;quot;xhci: Fix failure…</p> <p><strong>Affected:</strong> openEuler:22.03-LTS-SP3: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N&amp;gt;1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/&amp;quot;should never happen&amp;quot; paths to ensure we at least clear any affected TDs, even if we can&amp;apos;t issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 (&amp;quot;USB: xhci: Correct assumptions about number of rings per endpoint.&amp;quot;) early on in the XHCI driver&amp;apos;s life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 (&amp;quot;xhci: split handling halted endpoints into two steps&amp;quot;), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 (&amp;quot;xhci: Fix failure…</p> https://cve.radiocsirt.org/vuln/oesa-2024-2534 https://cve.radiocsirt.org/vuln/rhsa-2024:5101 <p>kernel: tracing: Restructure trace_clock_global() to never block kernel: ensure definition of the fixmap area is in a limit kernel: net: ieee802154: fix null deref in parse dev addr kernel: isdn: mISDN: netjet: Fix crash in nj_probe kernel: tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized kernel: irqchip/gic-v3-its: Fix potential VPE leak on error kernel: netfilter: conntrack: serialize hash resizes and cleanups kernel: userfaultfd: fix a race between writeprotect and exit_mmap() kernel: isdn: mISDN: Fix sleeping function called from invalid context kernel: mm: khugepaged: skip huge page collapse for special files kernel: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() kernel: ovl: fix warning in ovl_create_real() kernel: net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: net: amd-xgbe: Fix skb data length underflow kernel: block: Fix wrong offset in bio_truncate() kernel: net: fix information leakage in /proc/net/ptype kernel: cifs: Fix memory leak when build ntlmssp negotiate blob failed kernel: x86/xen: Fix memory leak in xen_smp_intr_init{_pv}() kernel: Local information disclosure on Intel(R) Atom(R) processors kernel: powerpc: Fix access beyond end of drmem array kernel: efivarfs: force RO when remounting if SetVariable is not supported kernel: use-after-free in kv_parse_power_table kernel: null po…</p> <p>kernel: tracing: Restructure trace_clock_global() to never block kernel: ensure definition of the fixmap area is in a limit kernel: net: ieee802154: fix null deref in parse dev addr kernel: isdn: mISDN: netjet: Fix crash in nj_probe kernel: tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized kernel: irqchip/gic-v3-its: Fix potential VPE leak on error kernel: netfilter: conntrack: serialize hash resizes and cleanups kernel: userfaultfd: fix a race between writeprotect and exit_mmap() kernel: isdn: mISDN: Fix sleeping function called from invalid context kernel: mm: khugepaged: skip huge page collapse for special files kernel: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() kernel: ovl: fix warning in ovl_create_real() kernel: net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: net: amd-xgbe: Fix skb data length underflow kernel: block: Fix wrong offset in bio_truncate() kernel: net: fix information leakage in /proc/net/ptype kernel: cifs: Fix memory leak when build ntlmssp negotiate blob failed kernel: x86/xen: Fix memory leak in xen_smp_intr_init{_pv}() kernel: Local information disclosure on Intel(R) Atom(R) processors kernel: powerpc: Fix access beyond end of drmem array kernel: efivarfs: force RO when remounting if SetVariable is not supported kernel: use-after-free in kv_parse_power_table kernel: null po…</p> https://cve.radiocsirt.org/vuln/rhsa-2024:5101 https://cve.radiocsirt.org/vuln/rhsa-2024:5102 <p>kernel: tracing: Restructure trace_clock_global() to never block kernel: net: ieee802154: fix null deref in parse dev addr kernel: isdn: mISDN: netjet: Fix crash in nj_probe kernel: tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized kernel: irqchip/gic-v3-its: Fix potential VPE leak on error kernel: netfilter: conntrack: serialize hash resizes and cleanups kernel: userfaultfd: fix a race between writeprotect and exit_mmap() kernel: isdn: mISDN: Fix sleeping function called from invalid context kernel: mm: khugepaged: skip huge page collapse for special files kernel: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() kernel: ovl: fix warning in ovl_create_real() kernel: net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: net: amd-xgbe: Fix skb data length underflow kernel: block: Fix wrong offset in bio_truncate() kernel: net: fix information leakage in /proc/net/ptype kernel: efivarfs: force RO when remounting if SetVariable is not supported kernel: use-after-free in kv_parse_power_table kernel: null pointer dereference issues in ice_ptp.c kernel: drm: Don&#39;t unref the same fb many times by mistake due to deadlock handling kernel: wifi: mac80211: fix potential key use-after-free kernel: pstore/ram: Fix crash when setting number of cpus to an odd number kernel: ext4: avoid online resizing failures due to oversiz…</p> <p>kernel: tracing: Restructure trace_clock_global() to never block kernel: net: ieee802154: fix null deref in parse dev addr kernel: isdn: mISDN: netjet: Fix crash in nj_probe kernel: tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized kernel: irqchip/gic-v3-its: Fix potential VPE leak on error kernel: netfilter: conntrack: serialize hash resizes and cleanups kernel: userfaultfd: fix a race between writeprotect and exit_mmap() kernel: isdn: mISDN: Fix sleeping function called from invalid context kernel: mm: khugepaged: skip huge page collapse for special files kernel: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() kernel: ovl: fix warning in ovl_create_real() kernel: net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: net: amd-xgbe: Fix skb data length underflow kernel: block: Fix wrong offset in bio_truncate() kernel: net: fix information leakage in /proc/net/ptype kernel: efivarfs: force RO when remounting if SetVariable is not supported kernel: use-after-free in kv_parse_power_table kernel: null pointer dereference issues in ice_ptp.c kernel: drm: Don&#39;t unref the same fb many times by mistake due to deadlock handling kernel: wifi: mac80211: fix potential key use-after-free kernel: pstore/ram: Fix crash when setting number of cpus to an odd number kernel: ext4: avoid online resizing failures due to oversiz…</p> https://cve.radiocsirt.org/vuln/rhsa-2024:5102 https://cve.radiocsirt.org/vuln/suse-su-2024:2894-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2024:2894-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-40927 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 184 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N&gt;1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/&#34;should never happen&#34; paths to ensure we at least clear any affected TDs, even if we can&#39;t issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 (&#34;USB: xhci: Correct assumptions about number of rings per endpoint.&#34;) early on in the XHCI driver&#39;s life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 (&#34;xhci: split handling halted endpoints into two steps&#34;), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 (&#34;xhci: Fix failure to give back some cached cancelled URBs.&#34;), it was acknowledged again. [Mathias: commit 94f339147fc3 (&#34;xhci: Fix failure to give…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 184 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N&gt;1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/&#34;should never happen&#34; paths to ensure we at least clear any affected TDs, even if we can&#39;t issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 (&#34;USB: xhci: Correct assumptions about number of rings per endpoint.&#34;) early on in the XHCI driver&#39;s life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 (&#34;xhci: split handling halted endpoints into two steps&#34;), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 (&#34;xhci: Fix failure to give back some cached cancelled URBs.&#34;), it was acknowledged again. [Mathias: commit 94f339147fc3 (&#34;xhci: Fix failure to give…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-40927 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1607 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um seine Privilegien zu erweitern, einen Denial-of-Service-Zustand zu erzeugen, vertrauliche Informationen offenzulegen oder einen unspezifischen Angriff durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um seine Privilegien zu erweitern, einen Denial-of-Service-Zustand zu erzeugen, vertrauliche Informationen offenzulegen oder einen unspezifischen Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1607