<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 04 Oct 2026 15:16:37 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-07474</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-07474</link>
      <description>bdu:2024-07474</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-07474</guid>
    </item>
    <item>
      <title>EUVD-2026-310240</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-310240</link>
      <description>EUVD-2026-310240</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-310240</guid>
    </item>
    <item>
      <title>fkie_cve-2022-48922</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-48922</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;riscv: fix oops caused by irqsoff latency tracer&lt;/p&gt;
&lt;p&gt;The trace_hardirqs_{on,off}() require the caller to setup frame pointer
properly. This because these two functions use macro &amp;#39;CALLER_ADDR1&amp;#39; (aka.
__builtin_return_address(1)) to acquire caller info. If the $fp is used
for other purpose, the code generated this macro (as below) could trigger
memory access fault.&lt;/p&gt;
&lt;p&gt;0xffffffff8011510e &amp;lt;+80&amp;gt;:    ld      a1,-16(s0)
   0xffffffff80115112 &amp;lt;+84&amp;gt;:    ld      s2,-8(a1)  # &amp;lt;-- paging fault here&lt;/p&gt;
&lt;p&gt;The oops message during booting if compiled with &amp;#39;irqoff&amp;#39; tracer enabled:
[    0.039615][    T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8
[    0.041925][    T0] Oops [#1]
[    0.042063][    T0] Modules linked in:
[    0.042864][    T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29
[    0.043568][    T0] Hardware name: riscv-virtio,qemu (DT)
[    0.044343][    T0] epc : trace_hardirqs_on+0x56/0xe2
[    0.044601][    T0]  ra : restore_all+0x12/0x6e
[    0.044721][    T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0
[    0.044801][    T0]  gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020
[    0.044882][    T0]  t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0
[    0.044967][    T0]  s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100
[    0.045046][    T0]  a2 : 0000000000000000 a3 : 00…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;riscv: fix oops caused by irqsoff latency tracer&lt;/p&gt;
&lt;p&gt;The trace_hardirqs_{on,off}() require the caller to setup frame pointer
properly. This because these two functions use macro &amp;#39;CALLER_ADDR1&amp;#39; (aka.
__builtin_return_address(1)) to acquire caller info. If the $fp is used
for other purpose, the code generated this macro (as below) could trigger
memory access fault.&lt;/p&gt;
&lt;p&gt;0xffffffff8011510e &amp;lt;+80&amp;gt;:    ld      a1,-16(s0)
   0xffffffff80115112 &amp;lt;+84&amp;gt;:    ld      s2,-8(a1)  # &amp;lt;-- paging fault here&lt;/p&gt;
&lt;p&gt;The oops message during booting if compiled with &amp;#39;irqoff&amp;#39; tracer enabled:
[    0.039615][    T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8
[    0.041925][    T0] Oops [#1]
[    0.042063][    T0] Modules linked in:
[    0.042864][    T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29
[    0.043568][    T0] Hardware name: riscv-virtio,qemu (DT)
[    0.044343][    T0] epc : trace_hardirqs_on+0x56/0xe2
[    0.044601][    T0]  ra : restore_all+0x12/0x6e
[    0.044721][    T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0
[    0.044801][    T0]  gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020
[    0.044882][    T0]  t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0
[    0.044967][    T0]  s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100
[    0.045046][    T0]  a2 : 0000000000000000 a3 : 00…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-48922</guid>
    </item>
    <item>
      <title>GHSA-cp82-8q86-pm99</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-cp82-8q86-pm99</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;riscv: fix oops caused by irqsoff latency tracer&lt;/p&gt;
&lt;p&gt;The trace_hardirqs_{on,off}() require the caller to setup frame pointer
properly. This because these two functions use macro &amp;#39;CALLER_ADDR1&amp;#39; (aka.
__builtin_return_address(1)) to acquire caller info. If the $fp is used
for other purpose, the code generated this macro (as below) could trigger
memory access fault.&lt;/p&gt;
&lt;p&gt;0xffffffff8011510e &amp;lt;+80&amp;gt;:    ld      a1,-16(s0)
   0xffffffff80115112 &amp;lt;+84&amp;gt;:    ld      s2,-8(a1)  # &amp;lt;-- paging fault here&lt;/p&gt;
&lt;p&gt;The oops message during booting if compiled with &amp;#39;irqoff&amp;#39; tracer enabled:
[    0.039615][    T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8
[    0.041925][    T0] Oops [#1]
[    0.042063][    T0] Modules linked in:
[    0.042864][    T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29
[    0.043568][    T0] Hardware name: riscv-virtio,qemu (DT)
[    0.044343][    T0] epc : trace_hardirqs_on+0x56/0xe2
[    0.044601][    T0]  ra : restore_all+0x12/0x6e
[    0.044721][    T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0
[    0.044801][    T0]  gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020
[    0.044882][    T0]  t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0
[    0.044967][    T0]  s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100
[    0.045046][    T0]  a2 : 0000000000000000 a3 : 00…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;riscv: fix oops caused by irqsoff latency tracer&lt;/p&gt;
&lt;p&gt;The trace_hardirqs_{on,off}() require the caller to setup frame pointer
properly. This because these two functions use macro &amp;#39;CALLER_ADDR1&amp;#39; (aka.
__builtin_return_address(1)) to acquire caller info. If the $fp is used
for other purpose, the code generated this macro (as below) could trigger
memory access fault.&lt;/p&gt;
&lt;p&gt;0xffffffff8011510e &amp;lt;+80&amp;gt;:    ld      a1,-16(s0)
   0xffffffff80115112 &amp;lt;+84&amp;gt;:    ld      s2,-8(a1)  # &amp;lt;-- paging fault here&lt;/p&gt;
&lt;p&gt;The oops message during booting if compiled with &amp;#39;irqoff&amp;#39; tracer enabled:
[    0.039615][    T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8
[    0.041925][    T0] Oops [#1]
[    0.042063][    T0] Modules linked in:
[    0.042864][    T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29
[    0.043568][    T0] Hardware name: riscv-virtio,qemu (DT)
[    0.044343][    T0] epc : trace_hardirqs_on+0x56/0xe2
[    0.044601][    T0]  ra : restore_all+0x12/0x6e
[    0.044721][    T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0
[    0.044801][    T0]  gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020
[    0.044882][    T0]  t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0
[    0.044967][    T0]  s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100
[    0.045046][    T0]  a2 : 0000000000000000 a3 : 00…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-cp82-8q86-pm99</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-48922</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-48922</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 67 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: riscv: fix oops caused by irqsoff latency tracer The trace_hardirqs_{on,off}() require the caller to setup frame pointer properly. This because these two functions use macro &amp;#39;CALLER_ADDR1&amp;#39; (aka. __builtin_return_address(1)) to acquire caller info. If the $fp is used for other purpose, the code generated this macro (as below) could trigger memory access fault.    0xffffffff8011510e &amp;lt;+80&amp;gt;:    ld      a1,-16(s0)    0xffffffff80115112 &amp;lt;+84&amp;gt;:    ld      s2,-8(a1)  # &amp;lt;-- paging fault here The oops message during booting if compiled with &amp;#39;irqoff&amp;#39; tracer enabled: [    0.039615][    T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 [    0.041925][    T0] Oops [#1] [    0.042063][    T0] Modules linked in: [    0.042864][    T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29 [    0.043568][    T0] Hardware name: riscv-virtio,qemu (DT) [    0.044343][    T0] epc : trace_hardirqs_on+0x56/0xe2 [    0.044601][    T0]  ra : restore_all+0x12/0x6e [    0.044721][    T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0 [    0.044801][    T0]  gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020 [    0.044882][    T0]  t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0 [    0.044967][    T0]  s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100 [    0.045046][    T0]  a2 : 0000000000000000 a3 : 000000…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 67 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: riscv: fix oops caused by irqsoff latency tracer The trace_hardirqs_{on,off}() require the caller to setup frame pointer properly. This because these two functions use macro &amp;#39;CALLER_ADDR1&amp;#39; (aka. __builtin_return_address(1)) to acquire caller info. If the $fp is used for other purpose, the code generated this macro (as below) could trigger memory access fault.    0xffffffff8011510e &amp;lt;+80&amp;gt;:    ld      a1,-16(s0)    0xffffffff80115112 &amp;lt;+84&amp;gt;:    ld      s2,-8(a1)  # &amp;lt;-- paging fault here The oops message during booting if compiled with &amp;#39;irqoff&amp;#39; tracer enabled: [    0.039615][    T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 [    0.041925][    T0] Oops [#1] [    0.042063][    T0] Modules linked in: [    0.042864][    T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29 [    0.043568][    T0] Hardware name: riscv-virtio,qemu (DT) [    0.044343][    T0] epc : trace_hardirqs_on+0x56/0xe2 [    0.044601][    T0]  ra : restore_all+0x12/0x6e [    0.044721][    T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0 [    0.044801][    T0]  gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020 [    0.044882][    T0]  t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0 [    0.044967][    T0]  s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100 [    0.045046][    T0]  a2 : 0000000000000000 a3 : 000000…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-48922</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1898 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1898</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1898</guid>
    </item>
  </channel>
</rss>
