<?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>Sat, 03 Oct 2026 03:33:23 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-03074</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-03074</link>
      <description>bdu:2025-03074</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-03074</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-35973</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-35973</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2024-35973</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0496 — 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-0496</link>
      <description>certfr-2024-avi-0496</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0496</guid>
    </item>
    <item>
      <title>EUVD-2026-320599</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320599</link>
      <description>EUVD-2026-320599</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320599</guid>
    </item>
    <item>
      <title>fkie_cve-2024-35973</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-35973</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;geneve: fix header validation in geneve[6]_xmit_skb&lt;/p&gt;
&lt;p&gt;syzbot is able to trigger an uninit-value in geneve_xmit() [1]&lt;/p&gt;
&lt;p&gt;Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())
uses skb_protocol(skb, true), pskb_inet_may_pull() is only using
skb-&amp;gt;protocol.&lt;/p&gt;
&lt;p&gt;If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb-&amp;gt;protocol,
pskb_inet_may_pull() does nothing at all.&lt;/p&gt;
&lt;p&gt;If a vlan tag was provided by the caller (af_packet in the syzbot case),
the network header might not point to the correct location, and skb
linear part could be smaller than expected.&lt;/p&gt;
&lt;p&gt;Add skb_vlan_inet_prepare() to perform a complete mac validation.&lt;/p&gt;
&lt;p&gt;Use this in geneve for the moment, I suspect we need to adopt this
more broadly.&lt;/p&gt;
&lt;p&gt;v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest
   - Only call __vlan_get_protocol() for vlan types.&lt;/p&gt;
&lt;p&gt;v2,v3 - Addressed Sabrina comments on v1 and v2&lt;/p&gt;
&lt;p&gt;[1]&lt;/p&gt;
&lt;p&gt;BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]
 BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
  geneve_xmit_skb drivers/net/geneve.c:910 [inline]
  geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
  __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
  netdev_start_xmit include/linux/netdevice.h:4917 [inline]
  xmit_one net/core/dev.c:3531 [inline]
  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
  __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335
  dev_queu…&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;geneve: fix header validation in geneve[6]_xmit_skb&lt;/p&gt;
&lt;p&gt;syzbot is able to trigger an uninit-value in geneve_xmit() [1]&lt;/p&gt;
&lt;p&gt;Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())
uses skb_protocol(skb, true), pskb_inet_may_pull() is only using
skb-&amp;gt;protocol.&lt;/p&gt;
&lt;p&gt;If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb-&amp;gt;protocol,
pskb_inet_may_pull() does nothing at all.&lt;/p&gt;
&lt;p&gt;If a vlan tag was provided by the caller (af_packet in the syzbot case),
the network header might not point to the correct location, and skb
linear part could be smaller than expected.&lt;/p&gt;
&lt;p&gt;Add skb_vlan_inet_prepare() to perform a complete mac validation.&lt;/p&gt;
&lt;p&gt;Use this in geneve for the moment, I suspect we need to adopt this
more broadly.&lt;/p&gt;
&lt;p&gt;v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest
   - Only call __vlan_get_protocol() for vlan types.&lt;/p&gt;
&lt;p&gt;v2,v3 - Addressed Sabrina comments on v1 and v2&lt;/p&gt;
&lt;p&gt;[1]&lt;/p&gt;
&lt;p&gt;BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]
 BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
  geneve_xmit_skb drivers/net/geneve.c:910 [inline]
  geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
  __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
  netdev_start_xmit include/linux/netdevice.h:4917 [inline]
  xmit_one net/core/dev.c:3531 [inline]
  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
  __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335
  dev_queu…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-35973</guid>
    </item>
    <item>
      <title>GHSA-hv5r-r2vq-gcrh</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-hv5r-r2vq-gcrh</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;geneve: fix header validation in geneve[6]_xmit_skb&lt;/p&gt;
&lt;p&gt;syzbot is able to trigger an uninit-value in geneve_xmit() [1]&lt;/p&gt;
&lt;p&gt;Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())
uses skb_protocol(skb, true), pskb_inet_may_pull() is only using
skb-&amp;gt;protocol.&lt;/p&gt;
&lt;p&gt;If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb-&amp;gt;protocol,
pskb_inet_may_pull() does nothing at all.&lt;/p&gt;
&lt;p&gt;If a vlan tag was provided by the caller (af_packet in the syzbot case),
the network header might not point to the correct location, and skb
linear part could be smaller than expected.&lt;/p&gt;
&lt;p&gt;Add skb_vlan_inet_prepare() to perform a complete mac validation.&lt;/p&gt;
&lt;p&gt;Use this in geneve for the moment, I suspect we need to adopt this
more broadly.&lt;/p&gt;
&lt;p&gt;v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest
   - Only call __vlan_get_protocol() for vlan types.&lt;/p&gt;
&lt;p&gt;v2,v3 - Addressed Sabrina comments on v1 and v2&lt;/p&gt;
&lt;p&gt;[1]&lt;/p&gt;
&lt;p&gt;BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]
 BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
  geneve_xmit_skb drivers/net/geneve.c:910 [inline]
  geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
  __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
  netdev_start_xmit include/linux/netdevice.h:4917 [inline]
  xmit_one net/core/dev.c:3531 [inline]
  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
  __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335
  dev_queu…&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;geneve: fix header validation in geneve[6]_xmit_skb&lt;/p&gt;
&lt;p&gt;syzbot is able to trigger an uninit-value in geneve_xmit() [1]&lt;/p&gt;
&lt;p&gt;Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())
uses skb_protocol(skb, true), pskb_inet_may_pull() is only using
skb-&amp;gt;protocol.&lt;/p&gt;
&lt;p&gt;If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb-&amp;gt;protocol,
pskb_inet_may_pull() does nothing at all.&lt;/p&gt;
&lt;p&gt;If a vlan tag was provided by the caller (af_packet in the syzbot case),
the network header might not point to the correct location, and skb
linear part could be smaller than expected.&lt;/p&gt;
&lt;p&gt;Add skb_vlan_inet_prepare() to perform a complete mac validation.&lt;/p&gt;
&lt;p&gt;Use this in geneve for the moment, I suspect we need to adopt this
more broadly.&lt;/p&gt;
&lt;p&gt;v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest
   - Only call __vlan_get_protocol() for vlan types.&lt;/p&gt;
&lt;p&gt;v2,v3 - Addressed Sabrina comments on v1 and v2&lt;/p&gt;
&lt;p&gt;[1]&lt;/p&gt;
&lt;p&gt;BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]
 BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
  geneve_xmit_skb drivers/net/geneve.c:910 [inline]
  geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
  __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
  netdev_start_xmit include/linux/netdevice.h:4917 [inline]
  xmit_one net/core/dev.c:3531 [inline]
  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
  __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335
  dev_queu…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-hv5r-r2vq-gcrh</guid>
    </item>
    <item>
      <title>ICSA-24-102-01 — Siemens SIMATIC S7-1500 TM MFP</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-24-102-01</link>
      <description>&lt;p&gt;An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. fs/nfsd/trace.h in the Linux kernel before 5.13.4 might allow remote attackers to cause a denial of service (out-of-bounds read in strlen) by sending NFS traffic when the trace event framework is being used for nfsd. SUNRPC: null pointer dereference in svc_rqst_free(). When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). NFSD: READDIR buffer overflow. If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. nfsd: NULL dereference in nfs3svc_encode_getaclres. A NULL pointer dereference vulnerability…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. fs/nfsd/trace.h in the Linux kernel before 5.13.4 might allow remote attackers to cause a denial of service (out-of-bounds read in strlen) by sending NFS traffic when the trace event framework is being used for nfsd. SUNRPC: null pointer dereference in svc_rqst_free(). When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). NFSD: READDIR buffer overflow. If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. nfsd: NULL dereference in nfs3svc_encode_getaclres. A NULL pointer dereference vulnerability…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-24-102-01</guid>
    </item>
    <item>
      <title>OESA-2024-1706 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1706</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;
net/mlx5e: Fix use-after-free of encap entry in neigh update handler&#13;
&#13;
Function mlx5e_rep_neigh_update() wasn&amp;amp;apos;t updated to accommodate rtnl lock
removal from TC filter update path and properly handle concurrent encap
entry insertion/deletion which can lead to following use-after-free:&#13;
&#13;
 [23827.464923] ==================================================================
 [23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635
 [23827.472251]
 [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5
 [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 [23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core]
 [23827.476731] Call Trace:
 [23827.477260]  dump_stack+0xbb/0x107
 [23827.477906]  print_address_description.constprop.0+0x18/0x140
 [23827.478896]  ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.479879]  ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.480905]  kasan_report.cold+0x7c/0xd8
 [23827.481701]  ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.482744]  kasan_check_range+0x145/0x1a0
 [23827.493112]  mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.494054]  ? mlx5e_tc_tun_encap_info_equal_ge…&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;
net/mlx5e: Fix use-after-free of encap entry in neigh update handler&#13;
&#13;
Function mlx5e_rep_neigh_update() wasn&amp;amp;apos;t updated to accommodate rtnl lock
removal from TC filter update path and properly handle concurrent encap
entry insertion/deletion which can lead to following use-after-free:&#13;
&#13;
 [23827.464923] ==================================================================
 [23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635
 [23827.472251]
 [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5
 [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 [23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core]
 [23827.476731] Call Trace:
 [23827.477260]  dump_stack+0xbb/0x107
 [23827.477906]  print_address_description.constprop.0+0x18/0x140
 [23827.478896]  ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.479879]  ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.480905]  kasan_report.cold+0x7c/0xd8
 [23827.481701]  ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.482744]  kasan_check_range+0x145/0x1a0
 [23827.493112]  mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.494054]  ? mlx5e_tc_tun_encap_info_equal_ge…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1706</guid>
    </item>
    <item>
      <title>RHSA-2024:9315 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:9315</link>
      <description>&lt;p&gt;kernel: use after free in i2c kernel: bluetooth: BR/EDR Bluetooth Impersonation Attacks (BIAS) kernel: hwmon: (lm90) Prevent integer overflow/underflow in hysteresis calculations kernel: asix: fix uninit-value in asix_mdio_read() kernel: tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc kernel: hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field kernel: powerpc/64s: fix program check interrupt emergency stack path kernel: powerpc/64s: Fix unrecoverable MCE calling async handler from NMI kernel: lib/generic-radix-tree.c: Don&amp;#39;t overflow in peek() kernel: powerpc/smp: do not decrement idle task preempt count in CPU offline kernel: can: isotp: isotp_sendmsg(): add result check for wait_event_interruptible() kernel: usbnet: sanity check for maxpacket kernel: nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells kernel: aio: fix use-after-free due to missing POLLFREE handling kernel: powerpc/pseries: Fix potential memleak in papr_get_attr() kernel: of: fdt: fix off-by-one error in unflatten_dt_nodes() kernel: thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR kernel: vt_ioctl: fix array_index_nospec in vt_setactivate kernel: bpf: Fix crash due to out of bounds access into reg2btf_ids. kernel: lz4: fix LZ4_decompress_safe_partial read out of bound kernel: x86/mce: Work around an erratum on fast string copy instructions…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: use after free in i2c kernel: bluetooth: BR/EDR Bluetooth Impersonation Attacks (BIAS) kernel: hwmon: (lm90) Prevent integer overflow/underflow in hysteresis calculations kernel: asix: fix uninit-value in asix_mdio_read() kernel: tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc kernel: hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field kernel: powerpc/64s: fix program check interrupt emergency stack path kernel: powerpc/64s: Fix unrecoverable MCE calling async handler from NMI kernel: lib/generic-radix-tree.c: Don&amp;#39;t overflow in peek() kernel: powerpc/smp: do not decrement idle task preempt count in CPU offline kernel: can: isotp: isotp_sendmsg(): add result check for wait_event_interruptible() kernel: usbnet: sanity check for maxpacket kernel: nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells kernel: aio: fix use-after-free due to missing POLLFREE handling kernel: powerpc/pseries: Fix potential memleak in papr_get_attr() kernel: of: fdt: fix off-by-one error in unflatten_dt_nodes() kernel: thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR kernel: vt_ioctl: fix array_index_nospec in vt_setactivate kernel: bpf: Fix crash due to out of bounds access into reg2btf_ids. kernel: lz4: fix LZ4_decompress_safe_partial read out of bound kernel: x86/mce: Work around an erratum on fast string copy instructions…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:9315</guid>
    </item>
    <item>
      <title>SSA-265688 — SSA-265688: Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 TM MFP V1.1</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-265688</link>
      <description>&lt;p&gt;An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. fs/nfsd/trace.h in the Linux kernel before 5.13.4 might allow remote attackers to cause a denial of service (out-of-bounds read in strlen) by sending NFS traffic when the trace event framework is being used for nfsd. SUNRPC: null pointer dereference in svc_rqst_free(). When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). NFSD: READDIR buffer overflow. If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. nfsd: NULL dereference in nfs3svc_encode_getaclres. A NULL pointer dereference vulnerability…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. fs/nfsd/trace.h in the Linux kernel before 5.13.4 might allow remote attackers to cause a denial of service (out-of-bounds read in strlen) by sending NFS traffic when the trace event framework is being used for nfsd. SUNRPC: null pointer dereference in svc_rqst_free(). When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). NFSD: READDIR buffer overflow. If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. nfsd: NULL dereference in nfs3svc_encode_getaclres. A NULL pointer dereference vulnerability…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-265688</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:2008-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:2008-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:2008-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-35973</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-35973</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:Pro:16.04:LTS: linux-oracle, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 161 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: geneve: fix header validation in geneve[6]_xmit_skb syzbot is able to trigger an uninit-value in geneve_xmit() [1] Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield()) uses skb_protocol(skb, true), pskb_inet_may_pull() is only using skb-&amp;gt;protocol. If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb-&amp;gt;protocol, pskb_inet_may_pull() does nothing at all. If a vlan tag was provided by the caller (af_packet in the syzbot case), the network header might not point to the correct location, and skb linear part could be smaller than expected. Add skb_vlan_inet_prepare() to perform a complete mac validation. Use this in geneve for the moment, I suspect we need to adopt this more broadly. v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest    - Only call __vlan_get_protocol() for vlan types. v2,v3 - Addressed Sabrina comments on v1 and v2 [1] BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]  BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030   geneve_xmit_skb drivers/net/geneve.c:910 [inline]   geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030   __netdev_start_xmit include/linux/netdevice.h:4903 [inline]   netdev_start_xmit include/linux/netdevice.h:4917 [inline]   xmit_one net/core/dev.c:3531 [inline]   dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547   __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335   dev_queue_xmit incl…&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:Pro:16.04:LTS: linux-oracle, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 161 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: geneve: fix header validation in geneve[6]_xmit_skb syzbot is able to trigger an uninit-value in geneve_xmit() [1] Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield()) uses skb_protocol(skb, true), pskb_inet_may_pull() is only using skb-&amp;gt;protocol. If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb-&amp;gt;protocol, pskb_inet_may_pull() does nothing at all. If a vlan tag was provided by the caller (af_packet in the syzbot case), the network header might not point to the correct location, and skb linear part could be smaller than expected. Add skb_vlan_inet_prepare() to perform a complete mac validation. Use this in geneve for the moment, I suspect we need to adopt this more broadly. v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest    - Only call __vlan_get_protocol() for vlan types. v2,v3 - Addressed Sabrina comments on v1 and v2 [1] BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]  BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030   geneve_xmit_skb drivers/net/geneve.c:910 [inline]   geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030   __netdev_start_xmit include/linux/netdevice.h:4903 [inline]   netdev_start_xmit include/linux/netdevice.h:4917 [inline]   xmit_one net/core/dev.c:3531 [inline]   dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547   __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335   dev_queue_xmit incl…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-35973</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1188 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1188</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1188</guid>
    </item>
  </channel>
</rss>
