<?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>Fri, 02 Oct 2026 15:26:01 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-14250</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-14250</link>
      <description>bdu:2025-14250</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-14250</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0420 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de
SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0420</link>
      <description>certfr-2024-avi-0420</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0420</guid>
    </item>
    <item>
      <title>EUVD-2026-344550</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-344550</link>
      <description>EUVD-2026-344550</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-344550</guid>
    </item>
    <item>
      <title>fkie_cve-2022-48673</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-48673</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/smc: Fix possible access to freed memory in link clear&lt;/p&gt;
&lt;p&gt;After modifying the QP to the Error state, all RX WR would be completed
with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not
wait for it is done, but destroy the QP and free the link group directly.
So there is a risk that accessing the freed memory in tasklet context.&lt;/p&gt;
&lt;p&gt;Here is a crash example:&lt;/p&gt;
&lt;p&gt;BUG: unable to handle page fault for address: ffffffff8f220860
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060
 Oops: 0002 [#1] SMP PTI
 CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S         OE     5.10.0-0607+ #23
 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018
 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0
 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e &amp;lt;48&amp;gt; 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32
 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086
 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000
 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00
 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b
 R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010
 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040
 F…&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;net/smc: Fix possible access to freed memory in link clear&lt;/p&gt;
&lt;p&gt;After modifying the QP to the Error state, all RX WR would be completed
with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not
wait for it is done, but destroy the QP and free the link group directly.
So there is a risk that accessing the freed memory in tasklet context.&lt;/p&gt;
&lt;p&gt;Here is a crash example:&lt;/p&gt;
&lt;p&gt;BUG: unable to handle page fault for address: ffffffff8f220860
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060
 Oops: 0002 [#1] SMP PTI
 CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S         OE     5.10.0-0607+ #23
 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018
 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0
 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e &amp;lt;48&amp;gt; 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32
 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086
 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000
 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00
 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b
 R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010
 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040
 F…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-48673</guid>
    </item>
    <item>
      <title>GHSA-798m-xwf9-pjw6</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-798m-xwf9-pjw6</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/smc: Fix possible access to freed memory in link clear&lt;/p&gt;
&lt;p&gt;After modifying the QP to the Error state, all RX WR would be completed
with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not
wait for it is done, but destroy the QP and free the link group directly.
So there is a risk that accessing the freed memory in tasklet context.&lt;/p&gt;
&lt;p&gt;Here is a crash example:&lt;/p&gt;
&lt;p&gt;BUG: unable to handle page fault for address: ffffffff8f220860
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060
 Oops: 0002 [#1] SMP PTI
 CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S         OE     5.10.0-0607+ #23
 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018
 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0
 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e &amp;lt;48&amp;gt; 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32
 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086
 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000
 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00
 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b
 R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010
 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040
 F…&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;net/smc: Fix possible access to freed memory in link clear&lt;/p&gt;
&lt;p&gt;After modifying the QP to the Error state, all RX WR would be completed
with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not
wait for it is done, but destroy the QP and free the link group directly.
So there is a risk that accessing the freed memory in tasklet context.&lt;/p&gt;
&lt;p&gt;Here is a crash example:&lt;/p&gt;
&lt;p&gt;BUG: unable to handle page fault for address: ffffffff8f220860
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060
 Oops: 0002 [#1] SMP PTI
 CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S         OE     5.10.0-0607+ #23
 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018
 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0
 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e &amp;lt;48&amp;gt; 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32
 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086
 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000
 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00
 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b
 R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010
 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040
 F…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-798m-xwf9-pjw6</guid>
    </item>
    <item>
      <title>gsd-2022-48673</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2022-48673</link>
      <description>gsd-2022-48673</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2022-48673</guid>
    </item>
    <item>
      <title>msrc_CVE-2022-48673 — net/smc: Fix possible access to freed memory in link clear</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2022-48673</link>
      <description>msrc_CVE-2022-48673</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2022-48673</guid>
    </item>
    <item>
      <title>OESA-2024-1737 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1737</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server&#13;
&#13;
AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and
Linux&amp;amp;apos;s afs client switches between them when talking to a non-YFS server
if the read size, the file position or the sum of the two have the upper 32
bits set of the 64-bit value.&#13;
&#13;
This is a problem, however, since the file position and length fields of
FS.FetchData are *signed* 32-bit values.&#13;
&#13;
Fix this by capturing the capability bits obtained from the fileserver when
it&amp;amp;apos;s sent an FS.GetCapabilities RPC, rather than just discarding them, and
then picking out the VICED_CAPABILITY_64BITFILES flag.  This can then be
used to decide whether to use FS.FetchData or FS.FetchData64 - and also
FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to
switch on the parameter values.&#13;
&#13;
This capabilities flag could also be used to limit the maximum size of the
file, but all servers must be checked for that.&#13;
&#13;
Note that the issue does not exist with FS.StoreData - that uses *unsigned*
32-bit values.  It&amp;amp;apos;s also not a problem with Auristor servers as its
YFS.FetchData64 op uses unsigned 64-bit values.&#13;
&#13;
This can be tested by cloning a git repo through an OpenAFS client to an
OpenAFS server and then doing &amp;amp;quot;git status&amp;amp;quot; on it from a Linux afs
client[1].  Provided…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server&#13;
&#13;
AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and
Linux&amp;amp;apos;s afs client switches between them when talking to a non-YFS server
if the read size, the file position or the sum of the two have the upper 32
bits set of the 64-bit value.&#13;
&#13;
This is a problem, however, since the file position and length fields of
FS.FetchData are *signed* 32-bit values.&#13;
&#13;
Fix this by capturing the capability bits obtained from the fileserver when
it&amp;amp;apos;s sent an FS.GetCapabilities RPC, rather than just discarding them, and
then picking out the VICED_CAPABILITY_64BITFILES flag.  This can then be
used to decide whether to use FS.FetchData or FS.FetchData64 - and also
FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to
switch on the parameter values.&#13;
&#13;
This capabilities flag could also be used to limit the maximum size of the
file, but all servers must be checked for that.&#13;
&#13;
Note that the issue does not exist with FS.StoreData - that uses *unsigned*
32-bit values.  It&amp;amp;apos;s also not a problem with Auristor servers as its
YFS.FetchData64 op uses unsigned 64-bit values.&#13;
&#13;
This can be tested by cloning a git repo through an OpenAFS client to an
OpenAFS server and then doing &amp;amp;quot;git status&amp;amp;quot; on it from a Linux afs
client[1].  Provided…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1737</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:1644-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:1644-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2024:1644-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-48673</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-48673</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, 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, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 144 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net/smc: Fix possible access to freed memory in link clear After modifying the QP to the Error state, all RX WR would be completed with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not wait for it is done, but destroy the QP and free the link group directly. So there is a risk that accessing the freed memory in tasklet context. Here is a crash example:  BUG: unable to handle page fault for address: ffffffff8f220860  #PF: supervisor write access in kernel mode  #PF: error_code(0x0002) - not-present page  PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060  Oops: 0002 [#1] SMP PTI  CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S         OE 5.10.0-0607+ #23  Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018  RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0  Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e &amp;lt;48&amp;gt; 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32  RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086  RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000  RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00  RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b  R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010  R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040  FS:  0000…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, 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, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 144 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net/smc: Fix possible access to freed memory in link clear After modifying the QP to the Error state, all RX WR would be completed with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not wait for it is done, but destroy the QP and free the link group directly. So there is a risk that accessing the freed memory in tasklet context. Here is a crash example:  BUG: unable to handle page fault for address: ffffffff8f220860  #PF: supervisor write access in kernel mode  #PF: error_code(0x0002) - not-present page  PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060  Oops: 0002 [#1] SMP PTI  CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S         OE 5.10.0-0607+ #23  Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018  RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0  Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e &amp;lt;48&amp;gt; 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32  RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086  RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000  RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00  RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b  R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010  R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040  FS:  0000…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-48673</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1025 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1025</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder um einen nicht spezifizierten 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 Angriff durchzuführen oder um einen nicht spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1025</guid>
    </item>
  </channel>
</rss>
