<?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 23:58:24 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-02253</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-02253</link>
      <description>bdu:2026-02253</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-02253</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0252 — 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-2025-avi-0252</link>
      <description>certfr-2025-avi-0252</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0252</guid>
    </item>
    <item>
      <title>EUVD-2026-310722</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-310722</link>
      <description>EUVD-2026-310722</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-310722</guid>
    </item>
    <item>
      <title>fkie_cve-2022-49674</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-49674</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;dm raid: fix accesses beyond end of raid member array&lt;/p&gt;
&lt;p&gt;On dm-raid table load (using raid_ctr), dm-raid allocates an array
rs-&amp;gt;devs[rs-&amp;gt;raid_disks] for the raid device members. rs-&amp;gt;raid_disks
is defined by the number of raid metadata and image tupples passed
into the target&amp;#39;s constructor.&lt;/p&gt;
&lt;p&gt;In the case of RAID layout changes being requested, that number can be
different from the current number of members for existing raid sets as
defined in their superblocks. Example RAID layout changes include:
- raid1 legs being added/removed
- raid4/5/6/10 number of stripes changed (stripe reshaping)
- takeover to higher raid level (e.g. raid5 -&amp;gt; raid6)&lt;/p&gt;
&lt;p&gt;When accessing array members, rs-&amp;gt;raid_disks must be used in control
loops instead of the potentially larger value in rs-&amp;gt;md.raid_disks.
Otherwise it will cause memory access beyond the end of the rs-&amp;gt;devs
array.&lt;/p&gt;
&lt;p&gt;Fix this by changing code that is prone to out-of-bounds access.
Also fix validate_raid_redundancy() to validate all devices that are
added. Also, use braces to help clean up raid_iterate_devices().&lt;/p&gt;
&lt;p&gt;The out-of-bounds memory accesses was discovered using KASAN.&lt;/p&gt;
&lt;p&gt;This commit was verified to pass all LVM2 RAID tests (with KASAN
enabled).&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;dm raid: fix accesses beyond end of raid member array&lt;/p&gt;
&lt;p&gt;On dm-raid table load (using raid_ctr), dm-raid allocates an array
rs-&amp;gt;devs[rs-&amp;gt;raid_disks] for the raid device members. rs-&amp;gt;raid_disks
is defined by the number of raid metadata and image tupples passed
into the target&amp;#39;s constructor.&lt;/p&gt;
&lt;p&gt;In the case of RAID layout changes being requested, that number can be
different from the current number of members for existing raid sets as
defined in their superblocks. Example RAID layout changes include:
- raid1 legs being added/removed
- raid4/5/6/10 number of stripes changed (stripe reshaping)
- takeover to higher raid level (e.g. raid5 -&amp;gt; raid6)&lt;/p&gt;
&lt;p&gt;When accessing array members, rs-&amp;gt;raid_disks must be used in control
loops instead of the potentially larger value in rs-&amp;gt;md.raid_disks.
Otherwise it will cause memory access beyond the end of the rs-&amp;gt;devs
array.&lt;/p&gt;
&lt;p&gt;Fix this by changing code that is prone to out-of-bounds access.
Also fix validate_raid_redundancy() to validate all devices that are
added. Also, use braces to help clean up raid_iterate_devices().&lt;/p&gt;
&lt;p&gt;The out-of-bounds memory accesses was discovered using KASAN.&lt;/p&gt;
&lt;p&gt;This commit was verified to pass all LVM2 RAID tests (with KASAN
enabled).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-49674</guid>
    </item>
    <item>
      <title>GHSA-7522-w99f-pjfx</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7522-w99f-pjfx</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;dm raid: fix accesses beyond end of raid member array&lt;/p&gt;
&lt;p&gt;On dm-raid table load (using raid_ctr), dm-raid allocates an array
rs-&amp;gt;devs[rs-&amp;gt;raid_disks] for the raid device members. rs-&amp;gt;raid_disks
is defined by the number of raid metadata and image tupples passed
into the target&amp;#39;s constructor.&lt;/p&gt;
&lt;p&gt;In the case of RAID layout changes being requested, that number can be
different from the current number of members for existing raid sets as
defined in their superblocks. Example RAID layout changes include:
- raid1 legs being added/removed
- raid4/5/6/10 number of stripes changed (stripe reshaping)
- takeover to higher raid level (e.g. raid5 -&amp;gt; raid6)&lt;/p&gt;
&lt;p&gt;When accessing array members, rs-&amp;gt;raid_disks must be used in control
loops instead of the potentially larger value in rs-&amp;gt;md.raid_disks.
Otherwise it will cause memory access beyond the end of the rs-&amp;gt;devs
array.&lt;/p&gt;
&lt;p&gt;Fix this by changing code that is prone to out-of-bounds access.
Also fix validate_raid_redundancy() to validate all devices that are
added. Also, use braces to help clean up raid_iterate_devices().&lt;/p&gt;
&lt;p&gt;The out-of-bounds memory accesses was discovered using KASAN.&lt;/p&gt;
&lt;p&gt;This commit was verified to pass all LVM2 RAID tests (with KASAN
enabled).&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;dm raid: fix accesses beyond end of raid member array&lt;/p&gt;
&lt;p&gt;On dm-raid table load (using raid_ctr), dm-raid allocates an array
rs-&amp;gt;devs[rs-&amp;gt;raid_disks] for the raid device members. rs-&amp;gt;raid_disks
is defined by the number of raid metadata and image tupples passed
into the target&amp;#39;s constructor.&lt;/p&gt;
&lt;p&gt;In the case of RAID layout changes being requested, that number can be
different from the current number of members for existing raid sets as
defined in their superblocks. Example RAID layout changes include:
- raid1 legs being added/removed
- raid4/5/6/10 number of stripes changed (stripe reshaping)
- takeover to higher raid level (e.g. raid5 -&amp;gt; raid6)&lt;/p&gt;
&lt;p&gt;When accessing array members, rs-&amp;gt;raid_disks must be used in control
loops instead of the potentially larger value in rs-&amp;gt;md.raid_disks.
Otherwise it will cause memory access beyond the end of the rs-&amp;gt;devs
array.&lt;/p&gt;
&lt;p&gt;Fix this by changing code that is prone to out-of-bounds access.
Also fix validate_raid_redundancy() to validate all devices that are
added. Also, use braces to help clean up raid_iterate_devices().&lt;/p&gt;
&lt;p&gt;The out-of-bounds memory accesses was discovered using KASAN.&lt;/p&gt;
&lt;p&gt;This commit was verified to pass all LVM2 RAID tests (with KASAN
enabled).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7522-w99f-pjfx</guid>
    </item>
    <item>
      <title>OESA-2025-1432 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1432</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: x86: Handle SRCU initialization failure during page track init&lt;/p&gt;
&lt;p&gt;Check the return of init_srcu_struct(), which can fail due to OOM, when
initializing the page track mechanism.  Lack of checking leads to a NULL
pointer deref found by a modified syzkaller.&lt;/p&gt;
&lt;p&gt;[Move the call towards the beginning of kvm_arch_init_vm. - Paolo](CVE-2021-47407)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;NFSD: prevent underflow in nfssvc_decode_writeargs()&lt;/p&gt;
&lt;p&gt;Smatch complains:&lt;/p&gt;
&lt;p&gt;fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs()
	warn: no lower bound on &amp;amp;apos;args-&amp;amp;gt;len&amp;amp;apos;&lt;/p&gt;
&lt;p&gt;Change the type to unsigned to prevent this issue.(CVE-2022-49280)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()&lt;/p&gt;
&lt;p&gt;When the driver fails at alloc_hdlcdev(), and then we remove the driver
module, we will get the following splat:&lt;/p&gt;
&lt;p&gt;[   25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI
[   25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17]
[   25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0
[   25.077709] Call Trace:
[   25.077924]  &amp;amp;lt;TASK&amp;amp;gt;
[   25.078108]  unregister_hdlc_device+0x16/0x30
[   25.078481]  slgt_cleanup+0x157/0x9f0 [synclink_gt]&lt;/p&gt;
&lt;p&gt;Fix this by checking whe…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: x86: Handle SRCU initialization failure during page track init&lt;/p&gt;
&lt;p&gt;Check the return of init_srcu_struct(), which can fail due to OOM, when
initializing the page track mechanism.  Lack of checking leads to a NULL
pointer deref found by a modified syzkaller.&lt;/p&gt;
&lt;p&gt;[Move the call towards the beginning of kvm_arch_init_vm. - Paolo](CVE-2021-47407)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;NFSD: prevent underflow in nfssvc_decode_writeargs()&lt;/p&gt;
&lt;p&gt;Smatch complains:&lt;/p&gt;
&lt;p&gt;fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs()
	warn: no lower bound on &amp;amp;apos;args-&amp;amp;gt;len&amp;amp;apos;&lt;/p&gt;
&lt;p&gt;Change the type to unsigned to prevent this issue.(CVE-2022-49280)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()&lt;/p&gt;
&lt;p&gt;When the driver fails at alloc_hdlcdev(), and then we remove the driver
module, we will get the following splat:&lt;/p&gt;
&lt;p&gt;[   25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI
[   25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17]
[   25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0
[   25.077709] Call Trace:
[   25.077924]  &amp;amp;lt;TASK&amp;amp;gt;
[   25.078108]  unregister_hdlc_device+0x16/0x30
[   25.078481]  slgt_cleanup+0x157/0x9f0 [synclink_gt]&lt;/p&gt;
&lt;p&gt;Fix this by checking whe…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1432</guid>
    </item>
    <item>
      <title>RHSA-2022:7683 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2022:7683</link>
      <description>&lt;p&gt;kernel: off-path attacker may inject data or terminate victim&amp;#39;s TCP session kernel: race condition in VT_RESIZEX ioctl when vc_cons[i].d is already NULL leading to NULL pointer dereference kernel: use-after-free vulnerability in function sco_sock_sendmsg() kernel: memory leak for large arguments in video_usercopy function in drivers/media/v4l2-core/v4l2-ioctl.c kernel: veth: ensure skb entering GRO are not cloned. kernel: inet: fully convert sk-&amp;gt;sk_rx_dst to RCU rules kernel: NFSD: Fix READDIR buffer overflow kernel: cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_init kernel: nvme-rdma: destroy cm id before destroy qp to avoid use after free kernel: regmap: Fix possible double-free in regcache_rbtree_exit() kernel: ethtool: do not perform operations on net devices being unregistered kernel: scsi: scsi_debug: Fix type in min_t to avoid stack OOB kernel: KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU kernel: udmabuf: validate ubuf-&amp;gt;pagecount kernel: drm/virtio: Ensure that objs is not NULL in virtio_gpu_array_put_free() kernel: smb2_ioctl_query_info NULL pointer dereference kernel: NULL pointer dereference in udf_expand_file_adinicbdue() during writeback kernel: swiotlb information leak with DMA_FROM_DEVICE kernel: uninitialized registers on stack in nft_do_chain can cause kernel pointer leakage to UM kernel: race condition in snd_pcm_hw_free leading to use-after-free kernel: use-after-free in tc_new_tfilter() in net/sched/cls_api.c kernel: KVM: cm…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: off-path attacker may inject data or terminate victim&amp;#39;s TCP session kernel: race condition in VT_RESIZEX ioctl when vc_cons[i].d is already NULL leading to NULL pointer dereference kernel: use-after-free vulnerability in function sco_sock_sendmsg() kernel: memory leak for large arguments in video_usercopy function in drivers/media/v4l2-core/v4l2-ioctl.c kernel: veth: ensure skb entering GRO are not cloned. kernel: inet: fully convert sk-&amp;gt;sk_rx_dst to RCU rules kernel: NFSD: Fix READDIR buffer overflow kernel: cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_init kernel: nvme-rdma: destroy cm id before destroy qp to avoid use after free kernel: regmap: Fix possible double-free in regcache_rbtree_exit() kernel: ethtool: do not perform operations on net devices being unregistered kernel: scsi: scsi_debug: Fix type in min_t to avoid stack OOB kernel: KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU kernel: udmabuf: validate ubuf-&amp;gt;pagecount kernel: drm/virtio: Ensure that objs is not NULL in virtio_gpu_array_put_free() kernel: smb2_ioctl_query_info NULL pointer dereference kernel: NULL pointer dereference in udf_expand_file_adinicbdue() during writeback kernel: swiotlb information leak with DMA_FROM_DEVICE kernel: uninitialized registers on stack in nft_do_chain can cause kernel pointer leakage to UM kernel: race condition in snd_pcm_hw_free leading to use-after-free kernel: use-after-free in tc_new_tfilter() in net/sched/cls_api.c kernel: KVM: cm…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2022:7683</guid>
    </item>
    <item>
      <title>RHSA-2026:6953 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2026:6953</link>
      <description>&lt;p&gt;kernel: Linux kernel: integer overflow and information disclosure via undefined shift operation in drm/amdkfd kernel: Linux kernel: Device Mapper RAID out-of-bounds access kernel: Linux kernel: Use-After-Free vulnerability in ATM subsystem kernel: macvlan: fix error recovery in macvlan_common_newlink()&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: Linux kernel: integer overflow and information disclosure via undefined shift operation in drm/amdkfd kernel: Linux kernel: Device Mapper RAID out-of-bounds access kernel: Linux kernel: Use-After-Free vulnerability in ATM subsystem kernel: macvlan: fix error recovery in macvlan_common_newlink()&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2026:6953</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:1176-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:1176-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-2025:1176-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-49674</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49674</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, 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:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux and 145 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: dm raid: fix accesses beyond end of raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array rs-&amp;gt;devs[rs-&amp;gt;raid_disks] for the raid device members. rs-&amp;gt;raid_disks is defined by the number of raid metadata and image tupples passed into the target&amp;#39;s constructor. In the case of RAID layout changes being requested, that number can be different from the current number of members for existing raid sets as defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed - raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 -&amp;gt; raid6) When accessing array members, rs-&amp;gt;raid_disks must be used in control loops instead of the potentially larger value in rs-&amp;gt;md.raid_disks. Otherwise it will cause memory access beyond the end of the rs-&amp;gt;devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was verified to pass all LVM2 RAID tests (with KASAN enabled).&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:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, 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:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux and 145 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: dm raid: fix accesses beyond end of raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array rs-&amp;gt;devs[rs-&amp;gt;raid_disks] for the raid device members. rs-&amp;gt;raid_disks is defined by the number of raid metadata and image tupples passed into the target&amp;#39;s constructor. In the case of RAID layout changes being requested, that number can be different from the current number of members for existing raid sets as defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed - raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 -&amp;gt; raid6) When accessing array members, rs-&amp;gt;raid_disks must be used in control loops instead of the potentially larger value in rs-&amp;gt;md.raid_disks. Otherwise it will cause memory access beyond the end of the rs-&amp;gt;devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was verified to pass all LVM2 RAID tests (with KASAN enabled).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49674</guid>
    </item>
  </channel>
</rss>
