<?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 15:06:34 +0000</lastBuildDate>
    <item>
      <title>ALSA-2024:10939 — Moderate: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/alsa-2024:10939</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:9: bpftool, AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core and 53 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: net/smc: fix illegal rmb_desc access in SMC-D connection dump (CVE-2024-26615)
  * kernel: block: initialize integrity buffer to zero before writing it to media (CVE-2024-43854)
  * kernel: iommu: Restore lost return in iommu_report_device_fault() (CVE-2024-44994)
  * kernel: netfilter: flowtable: initialise extack before use (CVE-2024-45018)
  * kernel: selinux,smack: don&amp;#39;t bypass permissions check in inode_setsecctx hook (CVE-2024-46695)
  * kernel: net: avoid potential underflow in qdisc_pkt_len_init() with UFO (CVE-2024-49949)
  * kernel: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() (CVE-2024-50251)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:9: bpftool, AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core and 53 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: net/smc: fix illegal rmb_desc access in SMC-D connection dump (CVE-2024-26615)
  * kernel: block: initialize integrity buffer to zero before writing it to media (CVE-2024-43854)
  * kernel: iommu: Restore lost return in iommu_report_device_fault() (CVE-2024-44994)
  * kernel: netfilter: flowtable: initialise extack before use (CVE-2024-45018)
  * kernel: selinux,smack: don&amp;#39;t bypass permissions check in inode_setsecctx hook (CVE-2024-46695)
  * kernel: net: avoid potential underflow in qdisc_pkt_len_init() with UFO (CVE-2024-49949)
  * kernel: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() (CVE-2024-50251)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/alsa-2024:10939</guid>
    </item>
    <item>
      <title>bdu:2025-04703</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-04703</link>
      <description>bdu:2025-04703</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-04703</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-49949</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-49949</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-49949</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0999 — 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-0999</link>
      <description>certfr-2024-avi-0999</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0999</guid>
    </item>
    <item>
      <title>EUVD-2026-320706</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320706</link>
      <description>EUVD-2026-320706</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320706</guid>
    </item>
    <item>
      <title>fkie_cve-2024-49949</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-49949</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: avoid potential underflow in qdisc_pkt_len_init() with UFO&lt;/p&gt;
&lt;p&gt;After commit 7c6d2ecbda83 (&amp;#34;net: be more gentle about silly gso
requests coming from user&amp;#34;) virtio_net_hdr_to_skb() had sanity check
to detect malicious attempts from user space to cook a bad GSO packet.&lt;/p&gt;
&lt;p&gt;Then commit cf9acc90c80ec (&amp;#34;net: virtio_net_hdr_to_skb: count
transport header in UFO&amp;#34;) while fixing one issue, allowed user space
to cook a GSO packet with the following characteristic :&lt;/p&gt;
&lt;p&gt;IPv4 SKB_GSO_UDP, gso_size=3, skb-&amp;gt;len = 28.&lt;/p&gt;
&lt;p&gt;When this packet arrives in qdisc_pkt_len_init(), we end up
with hdr_len = 28 (IPv4 header + UDP header), matching skb-&amp;gt;len&lt;/p&gt;
&lt;p&gt;Then the following sets gso_segs to 0 :&lt;/p&gt;
&lt;p&gt;gso_segs = DIV_ROUND_UP(skb-&amp;gt;len - hdr_len,
                        shinfo-&amp;gt;gso_size);&lt;/p&gt;
&lt;p&gt;Then later we set qdisc_skb_cb(skb)-&amp;gt;pkt_len to back to zero :/&lt;/p&gt;
&lt;p&gt;qdisc_skb_cb(skb)-&amp;gt;pkt_len += (gso_segs - 1) * hdr_len;&lt;/p&gt;
&lt;p&gt;This leads to the following crash in fq_codel [1]&lt;/p&gt;
&lt;p&gt;qdisc_pkt_len_init() is best effort, we only want an estimation
of the bytes sent on the wire, not crashing the kernel.&lt;/p&gt;
&lt;p&gt;This patch is fixing this particular issue, a following one
adds more sanity checks for another potential bug.&lt;/p&gt;
&lt;p&gt;[1]
[   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000
[   70.724561] #PF: supervisor read access in kernel mode
[   70.724561] #PF: error_code(0x0000) - not-present page
[   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0
[…&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: avoid potential underflow in qdisc_pkt_len_init() with UFO&lt;/p&gt;
&lt;p&gt;After commit 7c6d2ecbda83 (&amp;#34;net: be more gentle about silly gso
requests coming from user&amp;#34;) virtio_net_hdr_to_skb() had sanity check
to detect malicious attempts from user space to cook a bad GSO packet.&lt;/p&gt;
&lt;p&gt;Then commit cf9acc90c80ec (&amp;#34;net: virtio_net_hdr_to_skb: count
transport header in UFO&amp;#34;) while fixing one issue, allowed user space
to cook a GSO packet with the following characteristic :&lt;/p&gt;
&lt;p&gt;IPv4 SKB_GSO_UDP, gso_size=3, skb-&amp;gt;len = 28.&lt;/p&gt;
&lt;p&gt;When this packet arrives in qdisc_pkt_len_init(), we end up
with hdr_len = 28 (IPv4 header + UDP header), matching skb-&amp;gt;len&lt;/p&gt;
&lt;p&gt;Then the following sets gso_segs to 0 :&lt;/p&gt;
&lt;p&gt;gso_segs = DIV_ROUND_UP(skb-&amp;gt;len - hdr_len,
                        shinfo-&amp;gt;gso_size);&lt;/p&gt;
&lt;p&gt;Then later we set qdisc_skb_cb(skb)-&amp;gt;pkt_len to back to zero :/&lt;/p&gt;
&lt;p&gt;qdisc_skb_cb(skb)-&amp;gt;pkt_len += (gso_segs - 1) * hdr_len;&lt;/p&gt;
&lt;p&gt;This leads to the following crash in fq_codel [1]&lt;/p&gt;
&lt;p&gt;qdisc_pkt_len_init() is best effort, we only want an estimation
of the bytes sent on the wire, not crashing the kernel.&lt;/p&gt;
&lt;p&gt;This patch is fixing this particular issue, a following one
adds more sanity checks for another potential bug.&lt;/p&gt;
&lt;p&gt;[1]
[   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000
[   70.724561] #PF: supervisor read access in kernel mode
[   70.724561] #PF: error_code(0x0000) - not-present page
[   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0
[…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-49949</guid>
    </item>
    <item>
      <title>GHSA-4x74-8q36-fc3h</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-4x74-8q36-fc3h</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: avoid potential underflow in qdisc_pkt_len_init() with UFO&lt;/p&gt;
&lt;p&gt;After commit 7c6d2ecbda83 (&amp;#34;net: be more gentle about silly gso
requests coming from user&amp;#34;) virtio_net_hdr_to_skb() had sanity check
to detect malicious attempts from user space to cook a bad GSO packet.&lt;/p&gt;
&lt;p&gt;Then commit cf9acc90c80ec (&amp;#34;net: virtio_net_hdr_to_skb: count
transport header in UFO&amp;#34;) while fixing one issue, allowed user space
to cook a GSO packet with the following characteristic :&lt;/p&gt;
&lt;p&gt;IPv4 SKB_GSO_UDP, gso_size=3, skb-&amp;gt;len = 28.&lt;/p&gt;
&lt;p&gt;When this packet arrives in qdisc_pkt_len_init(), we end up
with hdr_len = 28 (IPv4 header + UDP header), matching skb-&amp;gt;len&lt;/p&gt;
&lt;p&gt;Then the following sets gso_segs to 0 :&lt;/p&gt;
&lt;p&gt;gso_segs = DIV_ROUND_UP(skb-&amp;gt;len - hdr_len,
                        shinfo-&amp;gt;gso_size);&lt;/p&gt;
&lt;p&gt;Then later we set qdisc_skb_cb(skb)-&amp;gt;pkt_len to back to zero :/&lt;/p&gt;
&lt;p&gt;qdisc_skb_cb(skb)-&amp;gt;pkt_len += (gso_segs - 1) * hdr_len;&lt;/p&gt;
&lt;p&gt;This leads to the following crash in fq_codel [1]&lt;/p&gt;
&lt;p&gt;qdisc_pkt_len_init() is best effort, we only want an estimation
of the bytes sent on the wire, not crashing the kernel.&lt;/p&gt;
&lt;p&gt;This patch is fixing this particular issue, a following one
adds more sanity checks for another potential bug.&lt;/p&gt;
&lt;p&gt;[1]
[   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000
[   70.724561] #PF: supervisor read access in kernel mode
[   70.724561] #PF: error_code(0x0000) - not-present page
[   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0
[…&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: avoid potential underflow in qdisc_pkt_len_init() with UFO&lt;/p&gt;
&lt;p&gt;After commit 7c6d2ecbda83 (&amp;#34;net: be more gentle about silly gso
requests coming from user&amp;#34;) virtio_net_hdr_to_skb() had sanity check
to detect malicious attempts from user space to cook a bad GSO packet.&lt;/p&gt;
&lt;p&gt;Then commit cf9acc90c80ec (&amp;#34;net: virtio_net_hdr_to_skb: count
transport header in UFO&amp;#34;) while fixing one issue, allowed user space
to cook a GSO packet with the following characteristic :&lt;/p&gt;
&lt;p&gt;IPv4 SKB_GSO_UDP, gso_size=3, skb-&amp;gt;len = 28.&lt;/p&gt;
&lt;p&gt;When this packet arrives in qdisc_pkt_len_init(), we end up
with hdr_len = 28 (IPv4 header + UDP header), matching skb-&amp;gt;len&lt;/p&gt;
&lt;p&gt;Then the following sets gso_segs to 0 :&lt;/p&gt;
&lt;p&gt;gso_segs = DIV_ROUND_UP(skb-&amp;gt;len - hdr_len,
                        shinfo-&amp;gt;gso_size);&lt;/p&gt;
&lt;p&gt;Then later we set qdisc_skb_cb(skb)-&amp;gt;pkt_len to back to zero :/&lt;/p&gt;
&lt;p&gt;qdisc_skb_cb(skb)-&amp;gt;pkt_len += (gso_segs - 1) * hdr_len;&lt;/p&gt;
&lt;p&gt;This leads to the following crash in fq_codel [1]&lt;/p&gt;
&lt;p&gt;qdisc_pkt_len_init() is best effort, we only want an estimation
of the bytes sent on the wire, not crashing the kernel.&lt;/p&gt;
&lt;p&gt;This patch is fixing this particular issue, a following one
adds more sanity checks for another potential bug.&lt;/p&gt;
&lt;p&gt;[1]
[   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000
[   70.724561] #PF: supervisor read access in kernel mode
[   70.724561] #PF: error_code(0x0000) - not-present page
[   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0
[…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-4x74-8q36-fc3h</guid>
    </item>
    <item>
      <title>ICSA-23-348-10 — Siemens SIMATIC S7-1500</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-23-348-10</link>
      <description>&lt;p&gt;expat 2.1.0 and earlier does not properly handle entities expansion unless an application developer uses the XML_SetEntityDeclHandler function, which allows remote attackers to cause a denial of service (resource consumption), send HTTP requests to intranet servers, or read arbitrary files via a crafted XML document, aka an XML External Entity (XXE) issue.  NOTE: it could be argued that because expat already provides the ability to disable external entity expansion, the responsibility for resolving this issue lies with application developers; according to this argument, this entry should be REJECTed, and each affected application would need its own CVE. shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees run-mailcap in the Debian mime-support package before 3.52-1+deb7u1 allows context-dependent attackers to execute arbitrary commands via shell metacharacters in a filename. In Python (aka CPython) up to 3.10.8, the mailcap module does not add escape characters into commands discovered in the system mailcap file. This may allow attackers to inject shell commands into applications that call mailcap.findmatch with untrusted input (if they lack validation of user-provided filenames or arguments). The fix is also back-ported to 3.7, 3.8, 3.9 Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start o…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;expat 2.1.0 and earlier does not properly handle entities expansion unless an application developer uses the XML_SetEntityDeclHandler function, which allows remote attackers to cause a denial of service (resource consumption), send HTTP requests to intranet servers, or read arbitrary files via a crafted XML document, aka an XML External Entity (XXE) issue.  NOTE: it could be argued that because expat already provides the ability to disable external entity expansion, the responsibility for resolving this issue lies with application developers; according to this argument, this entry should be REJECTed, and each affected application would need its own CVE. shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees run-mailcap in the Debian mime-support package before 3.52-1+deb7u1 allows context-dependent attackers to execute arbitrary commands via shell metacharacters in a filename. In Python (aka CPython) up to 3.10.8, the mailcap module does not add escape characters into commands discovered in the system mailcap file. This may allow attackers to inject shell commands into applications that call mailcap.findmatch with untrusted input (if they lack validation of user-provided filenames or arguments). The fix is also back-ported to 3.7, 3.8, 3.9 Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start o…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-23-348-10</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-49949 — net: avoid potential underflow in qdisc_pkt_len_init() with UFO</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-49949</link>
      <description>msrc_CVE-2024-49949</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-49949</guid>
    </item>
    <item>
      <title>OESA-2024-2424 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2424</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: 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;
pinctrl: single: fix potential NULL dereference in pcs_get_function()&#13;
&#13;
pinmux_generic_get_function() can return NULL and the pointer &amp;amp;apos;function&amp;amp;apos;
was dereferenced without checking against NULL. Add checking of pointer
&amp;amp;apos;function&amp;amp;apos; in pcs_get_function().&#13;
&#13;
Found by code review.(CVE-2024-46685)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
thunderbolt: Mark XDomain as unplugged when router is removed&#13;
&#13;
I noticed that when we do discrete host router NVM upgrade and it gets
hot-removed from the PCIe side as a result of NVM firmware authentication,
if there is another host connected with enabled paths we hang in tearing
them down. This is due to fact that the Thunderbolt networking driver
also tries to cleanup the paths and ends up blocking in
tb_disconnect_xdomain_paths() waiting for the domain lock.&#13;
&#13;
However, at this point we already cleaned the paths in tb_stop() so
there is really no need for tb_disconnect_xdomain_paths() to do that
anymore. Furthermore it already checks if the XDomain is unplugged and
bails out early so take advantage of that and mark the XDomain as
unplugged when we remove the parent router.(CVE-2024-46702)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]&#13;
&#13;
[WHY &amp;amp;amp;…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: 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;
pinctrl: single: fix potential NULL dereference in pcs_get_function()&#13;
&#13;
pinmux_generic_get_function() can return NULL and the pointer &amp;amp;apos;function&amp;amp;apos;
was dereferenced without checking against NULL. Add checking of pointer
&amp;amp;apos;function&amp;amp;apos; in pcs_get_function().&#13;
&#13;
Found by code review.(CVE-2024-46685)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
thunderbolt: Mark XDomain as unplugged when router is removed&#13;
&#13;
I noticed that when we do discrete host router NVM upgrade and it gets
hot-removed from the PCIe side as a result of NVM firmware authentication,
if there is another host connected with enabled paths we hang in tearing
them down. This is due to fact that the Thunderbolt networking driver
also tries to cleanup the paths and ends up blocking in
tb_disconnect_xdomain_paths() waiting for the domain lock.&#13;
&#13;
However, at this point we already cleaned the paths in tb_stop() so
there is really no need for tb_disconnect_xdomain_paths() to do that
anymore. Furthermore it already checks if the XDomain is unplugged and
bails out early so take advantage of that and mark the XDomain as
unplugged when we remove the parent router.(CVE-2024-46702)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]&#13;
&#13;
[WHY &amp;amp;amp;…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2424</guid>
    </item>
    <item>
      <title>openSUSE-SU-2024:14500-1 — kernel-devel-6.11.8-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1</link>
      <description>&lt;p&gt;kernel-devel-6.11.8-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-6.11.8-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1</guid>
    </item>
    <item>
      <title>RHSA-2024:10944 — Red Hat Security Advisory: kernel-rt security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:10944</link>
      <description>&lt;p&gt;kernel: selinux,smack: don&amp;#39;t bypass permissions check in inode_setsecctx hook kernel: net: avoid potential underflow in qdisc_pkt_len_init() with UFO kernel: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race kernel: arm64: probes: Remove broken LDR (literal) uprobe support kernel: xfrm: fix one more kernel-infoleak in algo dumping kernel: xfrm: validate new SA&amp;amp;#39;s prefixlen using SA family when sel.family is unset kernel: irqchip/gic-v4: Don&amp;#39;t allow a VMOVP on a dying VPE kernel: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() kernel: vsock/virtio: Initialization of the dangling pointer occurring in vsk-&amp;gt;trans&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: selinux,smack: don&amp;#39;t bypass permissions check in inode_setsecctx hook kernel: net: avoid potential underflow in qdisc_pkt_len_init() with UFO kernel: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race kernel: arm64: probes: Remove broken LDR (literal) uprobe support kernel: xfrm: fix one more kernel-infoleak in algo dumping kernel: xfrm: validate new SA&amp;amp;#39;s prefixlen using SA family when sel.family is unset kernel: irqchip/gic-v4: Don&amp;#39;t allow a VMOVP on a dying VPE kernel: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() kernel: vsock/virtio: Initialization of the dangling pointer occurring in vsk-&amp;gt;trans&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:10944</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:3983-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:3983-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:3983-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-49949</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-49949</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 176 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (&amp;#34;net: be more gentle about silly gso requests coming from user&amp;#34;) virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (&amp;#34;net: virtio_net_hdr_to_skb: count transport header in UFO&amp;#34;) while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb-&amp;gt;len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb-&amp;gt;len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb-&amp;gt;len - hdr_len,                         shinfo-&amp;gt;gso_size); Then later we set qdisc_skb_cb(skb)-&amp;gt;pkt_len to back to zero :/ qdisc_skb_cb(skb)-&amp;gt;pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [   70.724561] #PF: supervisor read access in kernel mode [   70.724561] #PF: error_code(0x0000) - not-present page [   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [   70.724561] O…&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 176 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (&amp;#34;net: be more gentle about silly gso requests coming from user&amp;#34;) virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (&amp;#34;net: virtio_net_hdr_to_skb: count transport header in UFO&amp;#34;) while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb-&amp;gt;len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb-&amp;gt;len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb-&amp;gt;len - hdr_len,                         shinfo-&amp;gt;gso_size); Then later we set qdisc_skb_cb(skb)-&amp;gt;pkt_len to back to zero :/ qdisc_skb_cb(skb)-&amp;gt;pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [   70.724561] #PF: supervisor read access in kernel mode [   70.724561] #PF: error_code(0x0000) - not-present page [   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [   70.724561] O…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-49949</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-3251 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bekannte Auswirkungen zu erzielen..&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bekannte Auswirkungen zu erzielen..&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251</guid>
    </item>
  </channel>
</rss>
