https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 15:17:47 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-12069 bdu:2025-12069 https://cve.radiocsirt.org/vuln/bdu:2025-12069 https://cve.radiocsirt.org/vuln/bell-cve-2025-37885 <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-2025-37885 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0463 certfr-2025-avi-0463 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0463 https://cve.radiocsirt.org/vuln/euvd-2026-346841 EUVD-2026-346841 https://cve.radiocsirt.org/vuln/euvd-2026-346841 https://cve.radiocsirt.org/vuln/fkie_cve-2025-37885 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86: Reset IRTE to host control if *new* route isn&#39;t postable</p> <p>Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU.</p> <p>The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn&#39;t freed.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86: Reset IRTE to host control if *new* route isn&#39;t postable</p> <p>Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU.</p> <p>The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn&#39;t freed.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-37885 https://cve.radiocsirt.org/vuln/ghsa-jrv2-7qh6-cgcr <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86: Reset IRTE to host control if *new* route isn&#39;t postable</p> <p>Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU.</p> <p>The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn&#39;t freed.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86: Reset IRTE to host control if *new* route isn&#39;t postable</p> <p>Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU.</p> <p>The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn&#39;t freed.</p> https://cve.radiocsirt.org/vuln/ghsa-jrv2-7qh6-cgcr https://cve.radiocsirt.org/vuln/msrc_cve-2025-37885 msrc_CVE-2025-37885 https://cve.radiocsirt.org/vuln/msrc_cve-2025-37885 https://cve.radiocsirt.org/vuln/oesa-2025-2118 <p><strong>Affected:</strong> openEuler:22.03-LTS-SP3: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netfilter: nf_tables: avoid skb access on nf_stolen</p> <p>When verdict is NF_STOLEN, the skb might have been freed.</p> <p>When tracing is enabled, this can result in a use-after-free: 1. access to skb-&amp;gt;nf_trace 2. access to skb-&amp;gt;mark 3. computation of trace id 4. dump of packet payload</p> <p>To avoid 1, keep a cached copy of skb-&amp;gt;nf_trace in the trace state struct. Refresh this copy whenever verdict is != STOLEN.</p> <p>Avoid 2 by skipping skb-&amp;gt;mark access if verdict is STOLEN.</p> <p>3 is avoided by precomputing the trace id.</p> <p>Only dump the packet when verdict is not &amp;quot;STOLEN&amp;quot;.(CVE-2022-49622)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>nfsd: release svc_expkey/svc_export with rcu_work</p> <p>The last reference for `cache_head` can be reduced to zero in `c_show` and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently, `svc_export_put` and `expkey_put` will be invoked, leading to two issues:</p> <p>1. The `svc_export_put` will directly free ex_uuid. However, `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can trigger a use-after-free issue, shown below.</p> <p>================================================================== BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870</p> <p>CPU: 1 UID: 0 PID: 870 Comm: cat…</p> <p><strong>Affected:</strong> openEuler:22.03-LTS-SP3: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netfilter: nf_tables: avoid skb access on nf_stolen</p> <p>When verdict is NF_STOLEN, the skb might have been freed.</p> <p>When tracing is enabled, this can result in a use-after-free: 1. access to skb-&amp;gt;nf_trace 2. access to skb-&amp;gt;mark 3. computation of trace id 4. dump of packet payload</p> <p>To avoid 1, keep a cached copy of skb-&amp;gt;nf_trace in the trace state struct. Refresh this copy whenever verdict is != STOLEN.</p> <p>Avoid 2 by skipping skb-&amp;gt;mark access if verdict is STOLEN.</p> <p>3 is avoided by precomputing the trace id.</p> <p>Only dump the packet when verdict is not &amp;quot;STOLEN&amp;quot;.(CVE-2022-49622)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>nfsd: release svc_expkey/svc_export with rcu_work</p> <p>The last reference for `cache_head` can be reduced to zero in `c_show` and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently, `svc_export_put` and `expkey_put` will be invoked, leading to two issues:</p> <p>1. The `svc_export_put` will directly free ex_uuid. However, `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can trigger a use-after-free issue, shown below.</p> <p>================================================================== BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870</p> <p>CPU: 1 UID: 0 PID: 870 Comm: cat…</p> https://cve.radiocsirt.org/vuln/oesa-2025-2118 https://cve.radiocsirt.org/vuln/suse-su-2025:02846-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2025:02846-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-37885 <p><strong>Affected:</strong> 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, Ubuntu:16.04:LTS: linux-hwe-edge and 206 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reset IRTE to host control if *new* route isn&#39;t postable Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU. The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn&#39;t freed.</p> <p><strong>Affected:</strong> 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, Ubuntu:16.04:LTS: linux-hwe-edge and 206 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reset IRTE to host control if *new* route isn&#39;t postable Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU. The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn&#39;t freed.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-37885 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0991 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff und weitere, nicht näher spezifizierte Angriffe durchzuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff und weitere, nicht näher spezifizierte Angriffe durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0991