https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 16:32:18 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-03503 bdu:2026-03503 https://cve.radiocsirt.org/vuln/bdu:2026-03503 https://cve.radiocsirt.org/vuln/bell-cve-2024-35873 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2024-35873 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0611 certfr-2024-avi-0611 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0611 https://cve.radiocsirt.org/vuln/euvd-2026-312768 EUVD-2026-312768 https://cve.radiocsirt.org/vuln/euvd-2026-312768 https://cve.radiocsirt.org/vuln/fkie_cve-2024-35873 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>riscv: Fix vector state restore in rt_sigreturn()</p> <p>The RISC-V Vector specification states in &#34;Appendix D: Calling Convention for Vector State&#34; [1] that &#34;Executing a system call causes all caller-saved vector registers (v0-v31, vl, vtype) and vstart to become unspecified.&#34;. In the RISC-V kernel this is called &#34;discarding the vstate&#34;.</p> <p>Returning from a signal handler via the rt_sigreturn() syscall, vector discard is also performed. However, this is not an issue since the vector state should be restored from the sigcontext, and therefore not care about the vector discard.</p> <p>The &#34;live state&#34; is the actual vector register in the running context, and the &#34;vstate&#34; is the vector state of the task. A dirty live state, means that the vstate and live state are not in synch.</p> <p>When vectorized user_from_copy() was introduced, an bug sneaked in at the restoration code, related to the discard of the live state.</p> <p>An example when this go wrong:</p> <p>1. A userland application is executing vector code 2. The application receives a signal, and the signal handler is entered. 3. The application returns from the signal handler, using the rt_sigreturn() syscall. 4. The live vector state is discarded upon entering the rt_sigreturn(), and the live state is marked as &#34;dirty&#34;, indicating that the live state need to be synchronized with the current vstate. 5. rt_sigreturn() restores the vstate, except the V…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>riscv: Fix vector state restore in rt_sigreturn()</p> <p>The RISC-V Vector specification states in &#34;Appendix D: Calling Convention for Vector State&#34; [1] that &#34;Executing a system call causes all caller-saved vector registers (v0-v31, vl, vtype) and vstart to become unspecified.&#34;. In the RISC-V kernel this is called &#34;discarding the vstate&#34;.</p> <p>Returning from a signal handler via the rt_sigreturn() syscall, vector discard is also performed. However, this is not an issue since the vector state should be restored from the sigcontext, and therefore not care about the vector discard.</p> <p>The &#34;live state&#34; is the actual vector register in the running context, and the &#34;vstate&#34; is the vector state of the task. A dirty live state, means that the vstate and live state are not in synch.</p> <p>When vectorized user_from_copy() was introduced, an bug sneaked in at the restoration code, related to the discard of the live state.</p> <p>An example when this go wrong:</p> <p>1. A userland application is executing vector code 2. The application receives a signal, and the signal handler is entered. 3. The application returns from the signal handler, using the rt_sigreturn() syscall. 4. The live vector state is discarded upon entering the rt_sigreturn(), and the live state is marked as &#34;dirty&#34;, indicating that the live state need to be synchronized with the current vstate. 5. rt_sigreturn() restores the vstate, except the V…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-35873 https://cve.radiocsirt.org/vuln/ghsa-x6qv-96vx-xf3h <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>riscv: Fix vector state restore in rt_sigreturn()</p> <p>The RISC-V Vector specification states in &#34;Appendix D: Calling Convention for Vector State&#34; [1] that &#34;Executing a system call causes all caller-saved vector registers (v0-v31, vl, vtype) and vstart to become unspecified.&#34;. In the RISC-V kernel this is called &#34;discarding the vstate&#34;.</p> <p>Returning from a signal handler via the rt_sigreturn() syscall, vector discard is also performed. However, this is not an issue since the vector state should be restored from the sigcontext, and therefore not care about the vector discard.</p> <p>The &#34;live state&#34; is the actual vector register in the running context, and the &#34;vstate&#34; is the vector state of the task. A dirty live state, means that the vstate and live state are not in synch.</p> <p>When vectorized user_from_copy() was introduced, an bug sneaked in at the restoration code, related to the discard of the live state.</p> <p>An example when this go wrong:</p> <p>1. A userland application is executing vector code 2. The application receives a signal, and the signal handler is entered. 3. The application returns from the signal handler, using the rt_sigreturn() syscall. 4. The live vector state is discarded upon entering the rt_sigreturn(), and the live state is marked as &#34;dirty&#34;, indicating that the live state need to be synchronized with the current vstate. 5. rt_sigreturn() restores the vstate, except the V…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>riscv: Fix vector state restore in rt_sigreturn()</p> <p>The RISC-V Vector specification states in &#34;Appendix D: Calling Convention for Vector State&#34; [1] that &#34;Executing a system call causes all caller-saved vector registers (v0-v31, vl, vtype) and vstart to become unspecified.&#34;. In the RISC-V kernel this is called &#34;discarding the vstate&#34;.</p> <p>Returning from a signal handler via the rt_sigreturn() syscall, vector discard is also performed. However, this is not an issue since the vector state should be restored from the sigcontext, and therefore not care about the vector discard.</p> <p>The &#34;live state&#34; is the actual vector register in the running context, and the &#34;vstate&#34; is the vector state of the task. A dirty live state, means that the vstate and live state are not in synch.</p> <p>When vectorized user_from_copy() was introduced, an bug sneaked in at the restoration code, related to the discard of the live state.</p> <p>An example when this go wrong:</p> <p>1. A userland application is executing vector code 2. The application receives a signal, and the signal handler is entered. 3. The application returns from the signal handler, using the rt_sigreturn() syscall. 4. The live vector state is discarded upon entering the rt_sigreturn(), and the live state is marked as &#34;dirty&#34;, indicating that the live state need to be synchronized with the current vstate. 5. rt_sigreturn() restores the vstate, except the V…</p> https://cve.radiocsirt.org/vuln/ghsa-x6qv-96vx-xf3h https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-35873 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 74 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: riscv: Fix vector state restore in rt_sigreturn() The RISC-V Vector specification states in &#34;Appendix D: Calling Convention for Vector State&#34; [1] that &#34;Executing a system call causes all caller-saved vector registers (v0-v31, vl, vtype) and vstart to become unspecified.&#34;. In the RISC-V kernel this is called &#34;discarding the vstate&#34;. Returning from a signal handler via the rt_sigreturn() syscall, vector discard is also performed. However, this is not an issue since the vector state should be restored from the sigcontext, and therefore not care about the vector discard. The &#34;live state&#34; is the actual vector register in the running context, and the &#34;vstate&#34; is the vector state of the task. A dirty live state, means that the vstate and live state are not in synch. When vectorized user_from_copy() was introduced, an bug sneaked in at the restoration code, related to the discard of the live state. An example when this go wrong: 1. A userland application is executing vector code 2. The application receives a signal, and the signal handler is entered. 3. The application returns from the signal handler, using the rt_sigreturn() syscall. 4. The live vector state is discarded upon entering the rt_sigreturn(), and the live state is marked as &#34;dirty&#34;, indicating that the live state need to be synchronized with the current vstate. 5. rt_sigreturn() restores the vstate, except the Vector r…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 74 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: riscv: Fix vector state restore in rt_sigreturn() The RISC-V Vector specification states in &#34;Appendix D: Calling Convention for Vector State&#34; [1] that &#34;Executing a system call causes all caller-saved vector registers (v0-v31, vl, vtype) and vstart to become unspecified.&#34;. In the RISC-V kernel this is called &#34;discarding the vstate&#34;. Returning from a signal handler via the rt_sigreturn() syscall, vector discard is also performed. However, this is not an issue since the vector state should be restored from the sigcontext, and therefore not care about the vector discard. The &#34;live state&#34; is the actual vector register in the running context, and the &#34;vstate&#34; is the vector state of the task. A dirty live state, means that the vstate and live state are not in synch. When vectorized user_from_copy() was introduced, an bug sneaked in at the restoration code, related to the discard of the live state. An example when this go wrong: 1. A userland application is executing vector code 2. The application receives a signal, and the signal handler is entered. 3. The application returns from the signal handler, using the rt_sigreturn() syscall. 4. The live vector state is discarded upon entering the rt_sigreturn(), and the live state is marked as &#34;dirty&#34;, indicating that the live state need to be synchronized with the current vstate. 5. rt_sigreturn() restores the vstate, except the Vector r…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-35873 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1188 <p>Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1188