<?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 13:40:44 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-01769</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-01769</link>
      <description>bdu:2025-01769</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-01769</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-46679</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-46679</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-46679</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0837 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0837</link>
      <description>certfr-2024-avi-0837</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0837</guid>
    </item>
    <item>
      <title>EUVD-2026-317051</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-317051</link>
      <description>EUVD-2026-317051</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-317051</guid>
    </item>
    <item>
      <title>fkie_cve-2024-46679</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-46679</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ethtool: check device is present when getting link settings&lt;/p&gt;
&lt;p&gt;A sysfs reader can race with a device reset or removal, attempting to
read device state when the device is not actually present. eg:&lt;/p&gt;
&lt;p&gt;[exception RIP: qed_get_current_link+17]
  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
 #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
 #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
 #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb&lt;/p&gt;
&lt;p&gt;crash&amp;gt; struct net_device.state ffff9a9d21336000
    state = 5,&lt;/p&gt;
&lt;p&gt;state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
The device is not present, note lack of __LINK_STATE_PRESENT (0b10).&lt;/p&gt;
&lt;p&gt;This is the same sort of panic as observed in commit 4224cfd7fb65
(&amp;#34;net-sysfs: add check for netdevice being present to speed_show&amp;#34;).&lt;/p&gt;
&lt;p&gt;There are many other callers of __ethtool_get_link_ksettings() which
don&amp;#39;t have a device presence check.&lt;/p&gt;
&lt;p&gt;Move this check into ethtool to protect all callers.&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;ethtool: check device is present when getting link settings&lt;/p&gt;
&lt;p&gt;A sysfs reader can race with a device reset or removal, attempting to
read device state when the device is not actually present. eg:&lt;/p&gt;
&lt;p&gt;[exception RIP: qed_get_current_link+17]
  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
 #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
 #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
 #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb&lt;/p&gt;
&lt;p&gt;crash&amp;gt; struct net_device.state ffff9a9d21336000
    state = 5,&lt;/p&gt;
&lt;p&gt;state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
The device is not present, note lack of __LINK_STATE_PRESENT (0b10).&lt;/p&gt;
&lt;p&gt;This is the same sort of panic as observed in commit 4224cfd7fb65
(&amp;#34;net-sysfs: add check for netdevice being present to speed_show&amp;#34;).&lt;/p&gt;
&lt;p&gt;There are many other callers of __ethtool_get_link_ksettings() which
don&amp;#39;t have a device presence check.&lt;/p&gt;
&lt;p&gt;Move this check into ethtool to protect all callers.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-46679</guid>
    </item>
    <item>
      <title>GHSA-c2m5-hm36-mq75</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-c2m5-hm36-mq75</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ethtool: check device is present when getting link settings&lt;/p&gt;
&lt;p&gt;A sysfs reader can race with a device reset or removal, attempting to
read device state when the device is not actually present. eg:&lt;/p&gt;
&lt;p&gt;[exception RIP: qed_get_current_link+17]
  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
 #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
 #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
 #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb&lt;/p&gt;
&lt;p&gt;crash&amp;gt; struct net_device.state ffff9a9d21336000
    state = 5,&lt;/p&gt;
&lt;p&gt;state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
The device is not present, note lack of __LINK_STATE_PRESENT (0b10).&lt;/p&gt;
&lt;p&gt;This is the same sort of panic as observed in commit 4224cfd7fb65
(&amp;#34;net-sysfs: add check for netdevice being present to speed_show&amp;#34;).&lt;/p&gt;
&lt;p&gt;There are many other callers of __ethtool_get_link_ksettings() which
don&amp;#39;t have a device presence check.&lt;/p&gt;
&lt;p&gt;Move this check into ethtool to protect all callers.&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;ethtool: check device is present when getting link settings&lt;/p&gt;
&lt;p&gt;A sysfs reader can race with a device reset or removal, attempting to
read device state when the device is not actually present. eg:&lt;/p&gt;
&lt;p&gt;[exception RIP: qed_get_current_link+17]
  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
 #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
 #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
 #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb&lt;/p&gt;
&lt;p&gt;crash&amp;gt; struct net_device.state ffff9a9d21336000
    state = 5,&lt;/p&gt;
&lt;p&gt;state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
The device is not present, note lack of __LINK_STATE_PRESENT (0b10).&lt;/p&gt;
&lt;p&gt;This is the same sort of panic as observed in commit 4224cfd7fb65
(&amp;#34;net-sysfs: add check for netdevice being present to speed_show&amp;#34;).&lt;/p&gt;
&lt;p&gt;There are many other callers of __ethtool_get_link_ksettings() which
don&amp;#39;t have a device presence check.&lt;/p&gt;
&lt;p&gt;Move this check into ethtool to protect all callers.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-c2m5-hm36-mq75</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>msrc_CVE-2024-46679 — ethtool: check device is present when getting link settings</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-46679</link>
      <description>msrc_CVE-2024-46679</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-46679</guid>
    </item>
    <item>
      <title>OESA-2024-2216 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2216</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: 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;
ALSA: usb-audio: Stop parsing channels bits when all channels are found.&#13;
&#13;
If a usb audio device sets more bits than the amount of channels
it could write outside of the map array.(CVE-2024-27436)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete&#13;
&#13;
FFS based applications can utilize the aio_cancel() callback to dequeue
pending USB requests submitted to the UDC.  There is a scenario where the
FFS application issues an AIO cancel call, while the UDC is handling a
soft disconnect.  For a DWC3 based implementation, the callstack looks
like the following:&#13;
&#13;
    DWC3 Gadget                               FFS Application
dwc3_gadget_soft_disconnect()              ...
  --&amp;amp;gt; dwc3_stop_active_transfers()
    --&amp;amp;gt; dwc3_gadget_giveback(-ESHUTDOWN)
      --&amp;amp;gt; ffs_epfile_async_io_complete()   ffs_aio_cancel()
        --&amp;amp;gt; usb_ep_free_request()            --&amp;amp;gt; usb_ep_dequeue()&#13;
&#13;
There is currently no locking implemented between the AIO completion
handler and AIO cancel, so the issue occurs if the completion routine is
running in parallel to an AIO cancel call coming from the FFS application.
As the completion call frees the USB request (io_data-&amp;amp;gt;req) the FFS
application is also referencing it for the usb_ep_dequeue() call.  This can…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: 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;
ALSA: usb-audio: Stop parsing channels bits when all channels are found.&#13;
&#13;
If a usb audio device sets more bits than the amount of channels
it could write outside of the map array.(CVE-2024-27436)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete&#13;
&#13;
FFS based applications can utilize the aio_cancel() callback to dequeue
pending USB requests submitted to the UDC.  There is a scenario where the
FFS application issues an AIO cancel call, while the UDC is handling a
soft disconnect.  For a DWC3 based implementation, the callstack looks
like the following:&#13;
&#13;
    DWC3 Gadget                               FFS Application
dwc3_gadget_soft_disconnect()              ...
  --&amp;amp;gt; dwc3_stop_active_transfers()
    --&amp;amp;gt; dwc3_gadget_giveback(-ESHUTDOWN)
      --&amp;amp;gt; ffs_epfile_async_io_complete()   ffs_aio_cancel()
        --&amp;amp;gt; usb_ep_free_request()            --&amp;amp;gt; usb_ep_dequeue()&#13;
&#13;
There is currently no locking implemented between the AIO completion
handler and AIO cancel, so the issue occurs if the completion routine is
running in parallel to an AIO cancel call coming from the FFS application.
As the completion call frees the USB request (io_data-&amp;amp;gt;req) the FFS
application is also referencing it for the usb_ep_dequeue() call.  This can…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2216</guid>
    </item>
    <item>
      <title>RHSA-2024:10274 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:10274</link>
      <description>&lt;p&gt;kernel: bpf: Fix overrunning reservations in ringbuf kernel: USB: serial: mos7840: fix crash on resume kernel: ethtool: check device is present when getting link settings kernel: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: bpf: Fix overrunning reservations in ringbuf kernel: USB: serial: mos7840: fix crash on resume kernel: ethtool: check device is present when getting link settings kernel: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:10274</guid>
    </item>
    <item>
      <title>RHSA-2024:8107 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:8107</link>
      <description>&lt;p&gt;kernel: watchdog: Fix possible use-after-free by calling del_timer_sync() kernel: mlxsw: spectrum: Protect driver from buggy firmware kernel: ovl: fix use after free in struct ovl_aio_req kernel: udp: do not accept non-tunnel GSO skbs landing in a tunnel kernel: scsi: qla2xxx: Fix off by one in qla_edif_app_getstats() kernel: scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up() kernel: scsi: lpfc: Move NPIV&amp;#39;s transport unregistration to after resource clean up kernel: net: openvswitch: fix overwriting ct original tuple for ICMPv6 kernel: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING kernel: ext4: fix uninitialized ratelimit_state-&amp;amp;gt;lock access in __ext4_fill_super() kernel: net/sched: Fix UAF when resolving a clash kernel: tipc: Return non-zero value from tipc_udp_addr2str() on error kernel: ethtool: check device is present when getting link settings&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: watchdog: Fix possible use-after-free by calling del_timer_sync() kernel: mlxsw: spectrum: Protect driver from buggy firmware kernel: ovl: fix use after free in struct ovl_aio_req kernel: udp: do not accept non-tunnel GSO skbs landing in a tunnel kernel: scsi: qla2xxx: Fix off by one in qla_edif_app_getstats() kernel: scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up() kernel: scsi: lpfc: Move NPIV&amp;#39;s transport unregistration to after resource clean up kernel: net: openvswitch: fix overwriting ct original tuple for ICMPv6 kernel: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING kernel: ext4: fix uninitialized ratelimit_state-&amp;amp;gt;lock access in __ext4_fill_super() kernel: net/sched: Fix UAF when resolving a clash kernel: tipc: Return non-zero value from tipc_udp_addr2str() on error kernel: ethtool: check device is present when getting link settings&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:8107</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:3551-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:3551-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:3551-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-46679</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-46679</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, 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 and 186 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ethtool: check device is present when getting link settings A sysfs reader can race with a device reset or removal, attempting to read device state when the device is not actually present. eg:      [exception RIP: qed_get_current_link+17]   #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]   #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3  #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4  #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300  #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c  #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b  #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3  #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1  #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f  #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb  crash&amp;gt; struct net_device.state ffff9a9d21336000     state = 5, state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100). The device is not present, note lack of __LINK_STATE_PRESENT (0b10). This is the same sort of panic as observed in commit 4224cfd7fb65 (&amp;#34;net-sysfs: add check for netdevice being present to speed_show&amp;#34;). There are many other callers of __ethtool_get_link_ksettings() which don&amp;#39;t have a device presence check. Move this check into ethtool to protect all callers.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, 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 and 186 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ethtool: check device is present when getting link settings A sysfs reader can race with a device reset or removal, attempting to read device state when the device is not actually present. eg:      [exception RIP: qed_get_current_link+17]   #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]   #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3  #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4  #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300  #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c  #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b  #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3  #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1  #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f  #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb  crash&amp;gt; struct net_device.state ffff9a9d21336000     state = 5, state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100). The device is not present, note lack of __LINK_STATE_PRESENT (0b10). This is the same sort of panic as observed in commit 4224cfd7fb65 (&amp;#34;net-sysfs: add check for netdevice being present to speed_show&amp;#34;). There are many other callers of __ethtool_get_link_ksettings() which don&amp;#39;t have a device presence check. Move this check into ethtool to protect all callers.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-46679</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-2133 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-2133</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen 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 Angriff durchzuführen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-2133</guid>
    </item>
  </channel>
</rss>
