<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T22:31:20.145546+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bdu:2025-03057</id>
    <title>bdu:2025-03057</title>
    <updated>2026-10-02T22:31:20.841049+00:00</updated>
    <content>bdu:2025-03057</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2025-03057"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0252</id>
    <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>
    <updated>2026-10-02T22:31:20.841123+00:00</updated>
    <content>certfr-2025-avi-0252</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2025-avi-0252"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-344699</id>
    <title>EUVD-2026-344699</title>
    <updated>2026-10-02T22:31:20.841145+00:00</updated>
    <content>EUVD-2026-344699</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-344699"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2022-49264</id>
    <title>fkie_cve-2022-49264</title>
    <updated>2026-10-02T22:31:20.841159+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>exec: Force single empty string when argv is empty</p>
<p>Quoting[1] Ariadne Conill:</p>
<p>"In several other operating systems, it is a hard requirement that the
second argument to execve(2) be the name of a program, thus prohibiting
a scenario where argc &lt; 1. POSIX 2017 also recommends this behaviour,
but it is not an explicit requirement[2]:</p>
<p>The argument arg0 should point to a filename string that is
    associated with the process being started by one of the exec
    functions.
...
Interestingly, Michael Kerrisk opened an issue about this in 2008[3],
but there was no consensus to support fixing this issue then.
Hopefully now that CVE-2021-4034 shows practical exploitative use[4]
of this bug in a shellcode, we can reconsider.</p>
<p>This issue is being tracked in the KSPP issue tracker[5]."</p>
<p>While the initial code searches[6][7] turned up what appeared to be
mostly corner case tests, trying to that just reject argv == NULL
(or an immediately terminated pointer list) quickly started tripping[8]
existing userspace programs.</p>
<p>The next best approach is forcing a single empty string into argv and
adjusting argc to match. The number of programs depending on argc == 0
seems a smaller set than those calling execve with a NULL argv.</p>
<p>Account for the additional stack space in bprm_stack_limits(). Inject an
empty string when argc == 0 (and set argc = 1). Warn about the case so
userspace has some notice about the change:</p>
<p>pr…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2022-49264"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-w8vv-x828-gjpf</id>
    <title>GHSA-w8vv-x828-gjpf</title>
    <updated>2026-10-02T22:31:20.841215+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>exec: Force single empty string when argv is empty</p>
<p>Quoting[1] Ariadne Conill:</p>
<p>"In several other operating systems, it is a hard requirement that the
second argument to execve(2) be the name of a program, thus prohibiting
a scenario where argc &lt; 1. POSIX 2017 also recommends this behaviour,
but it is not an explicit requirement[2]:</p>
<p>The argument arg0 should point to a filename string that is
    associated with the process being started by one of the exec
    functions.
...
Interestingly, Michael Kerrisk opened an issue about this in 2008[3],
but there was no consensus to support fixing this issue then.
Hopefully now that CVE-2021-4034 shows practical exploitative use[4]
of this bug in a shellcode, we can reconsider.</p>
<p>This issue is being tracked in the KSPP issue tracker[5]."</p>
<p>While the initial code searches[6][7] turned up what appeared to be
mostly corner case tests, trying to that just reject argv == NULL
(or an immediately terminated pointer list) quickly started tripping[8]
existing userspace programs.</p>
<p>The next best approach is forcing a single empty string into argv and
adjusting argc to match. The number of programs depending on argc == 0
seems a smaller set than those calling execve with a NULL argv.</p>
<p>Account for the additional stack space in bprm_stack_limits(). Inject an
empty string when argc == 0 (and set argc = 1). Warn about the case so
userspace has some notice about the change:</p>
<p>pr…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-w8vv-x828-gjpf"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/rhsa-2022:8267</id>
    <title>RHSA-2022:8267 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
    <updated>2026-10-02T22:31:20.841252+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>kernel: off-path attacker may inject data or terminate victim's TCP session kernel: use-after-free vulnerability in function sco_sock_sendmsg() kernel: fix 'struct pid' leaks in 'dbgfs_target_ids_write()' kernel: veth: ensure skb entering GRO are not cloned. kernel: inet: fully convert sk-&gt;sk_rx_dst to RCU rules kernel: irqchip/gic-v3-its: Fix potential VPE leak on error kernel: nvme-rdma: destroy cm id before destroy qp to avoid use after free kernel: ptp: Fix possible memory leak in ptp_clock_register() kernel: ethtool: do not perform operations on net devices being unregistered kernel: ethtool: ioctl: fix potential NULL deref in ethtool_set_coalesce() kernel: net: nexthop: fix null pointer dereference when IPv6 is not enabled 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: Revert "Revert "block, bfq: honor already-setup queue merges"" kernel: udmabuf: validate ubuf-&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: KVM: cmpxchg_gpte can write to pfns outside the userspace region ke…</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/rhsa-2022:8267"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2025:1176-1</id>
    <title>SUSE-SU-2025:1176-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-02T22:31:20.841549+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2025:1176-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49264</id>
    <title>UBUNTU-CVE-2022-49264</title>
    <updated>2026-10-02T22:31:20.841899+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> 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 137 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: exec: Force single empty string when argv is empty Quoting[1] Ariadne Conill: "In several other operating systems, it is a hard requirement that the second argument to execve(2) be the name of a program, thus prohibiting a scenario where argc &lt; 1. POSIX 2017 also recommends this behaviour, but it is not an explicit requirement[2]:     The argument arg0 should point to a filename string that is     associated with the process being started by one of the exec     functions. ... Interestingly, Michael Kerrisk opened an issue about this in 2008[3], but there was no consensus to support fixing this issue then. Hopefully now that CVE-2021-4034 shows practical exploitative use[4] of this bug in a shellcode, we can reconsider. This issue is being tracked in the KSPP issue tracker[5]." While the initial code searches[6][7] turned up what appeared to be mostly corner case tests, trying to that just reject argv == NULL (or an immediately terminated pointer list) quickly started tripping[8] existing userspace programs. The next best approach is forcing a single empty string into argv and adjusting argc to match. The number of programs depending on argc == 0 seems a smaller set than those calling execve with a NULL argv. Account for the additional stack space in bprm_stack_limits(). Inject an empty string when argc == 0 (and set argc = 1). Warn about the case so userspace has some notice about the change:     process './…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49264"/>
  </entry>
</feed>
