<?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-03T20:38:02.563204+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/bell-cve-2026-74620</id>
    <title>BELL-CVE-2026-74620</title>
    <updated>2026-10-03T20:38:02.575349+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2026-74620"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1090</id>
    <title>certfr-2026-avi-1090 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
    <updated>2026-10-03T20:38:02.575405+00:00</updated>
    <content>certfr-2026-avi-1090</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2026-avi-1090"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-357927</id>
    <title>EUVD-2026-357927</title>
    <updated>2026-10-03T20:38:02.575426+00:00</updated>
    <content>EUVD-2026-357927</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-357927"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-74620</id>
    <title>fkie_cve-2026-74620</title>
    <updated>2026-10-03T20:38:02.575438+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>net/sched: act_gact, act_police: range check the fallback control action</p>
<p>tcf_action_check_ctrlact() range checks the primary control action:</p>
<p>if (!opcode)
		ret = action &gt; TC_ACT_VALUE_MAX ? -EINVAL : 0;</p>
<p>TC_ACT_VALUE_MAX is TC_ACT_TRAP, so kernel-internal verdicts above it
cannot be set that way. But act_gact and act_police each carry a second,
independent control action supplied by user space that never reaches that
helper - TCA_GACT_PROB.paction and TCA_POLICE_RESULT. Both only reject
TC_ACT_GOTO_CHAIN, so any other value is stored verbatim and returned
verbatim from the action.</p>
<p>In particular user space can store TC_ACT_CONSUMED, which is
TC_ACT_VALUE_MAX + 1 and is deliberately not part of the UAPI value
range. That verdict tells every caller the action took ownership of the
skb, so nobody frees it: sch_handle_ingress(), sch_handle_egress() and
tcf_qevent_handle() all deliberately skip the free for it. The result is
one leaked sk_buff plus its data buffer per packet traversing the filter,
unbounded, for all traffic on the chain including kernel-generated
packets.</p>
<p>Both are trivially deterministic. act_gact clamps tcfg_pval to &gt;= 1, so
with pval = 1 gact_determ() returns the fallback for every packet.
act_police has no mandatory rate, so rate = 0 leaves tcfp_mtu = ~0 and
tcf_police_mtu_check() always passes.</p>
<p>TC_ACT_CONSUMED was added by commit 720f22fed81b ("net: sched: refactor
reinsert action"), af…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-74620"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-x4gp-7h95-w6vp</id>
    <title>GHSA-x4gp-7h95-w6vp</title>
    <updated>2026-10-03T20:38:02.575485+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>net/sched: act_gact, act_police: range check the fallback control action</p>
<p>tcf_action_check_ctrlact() range checks the primary control action:</p>
<p>if (!opcode)
		ret = action &gt; TC_ACT_VALUE_MAX ? -EINVAL : 0;</p>
<p>TC_ACT_VALUE_MAX is TC_ACT_TRAP, so kernel-internal verdicts above it
cannot be set that way. But act_gact and act_police each carry a second,
independent control action supplied by user space that never reaches that
helper - TCA_GACT_PROB.paction and TCA_POLICE_RESULT. Both only reject
TC_ACT_GOTO_CHAIN, so any other value is stored verbatim and returned
verbatim from the action.</p>
<p>In particular user space can store TC_ACT_CONSUMED, which is
TC_ACT_VALUE_MAX + 1 and is deliberately not part of the UAPI value
range. That verdict tells every caller the action took ownership of the
skb, so nobody frees it: sch_handle_ingress(), sch_handle_egress() and
tcf_qevent_handle() all deliberately skip the free for it. The result is
one leaked sk_buff plus its data buffer per packet traversing the filter,
unbounded, for all traffic on the chain including kernel-generated
packets.</p>
<p>Both are trivially deterministic. act_gact clamps tcfg_pval to &gt;= 1, so
with pval = 1 gact_determ() returns the fallback for every packet.
act_police has no mandatory rate, so rate = 0 leaves tcfp_mtu = ~0 and
tcf_police_mtu_check() always passes.</p>
<p>TC_ACT_CONSUMED was added by commit 720f22fed81b ("net: sched: refactor
reinsert action"), af…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-x4gp-7h95-w6vp"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2026-74620</id>
    <title>msrc_CVE-2026-74620 — net/sched: act_gact, act_police: range check the fallback control action</title>
    <updated>2026-10-03T20:38:02.575519+00:00</updated>
    <content>msrc_CVE-2026-74620</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2026-74620"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/oesa-2026-3707</id>
    <title>OESA-2026-3707 — kernel security update</title>
    <updated>2026-10-03T20:38:02.575535+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> openEuler:24.03-LTS-SP1: kernel</p>
<p>The Linux Kernel, the operating system core itself.

Security Fix(es):</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>seg6: separate dst_cache for input and output paths in seg6 lwtunnel</p>
<p>The seg6 lwtunnel uses a single dst_cache per encap route, shared
between seg6_input_core() and seg6_output_core(). These two paths
can perform the post-encap SID lookup in different routing contexts
(e.g., ip rules matching on the ingress interface, or VRF table
separation). Whichever path runs first populates the cache, and the
other reuses it blindly, bypassing its own lookup.</p>
<p>Fix this by splitting the cache into cache_input and cache_output,
so each path maintains its own cached dst independently.(CVE-2026-31668)</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE</p>
<p>The current implementation incorrectly handles memory regions (MRs) with
page sizes different from the system PAGE_SIZE. The core issue is that
rxe_set_page() is called with mr-&amp;gt;page_size step increments, but the
page_list stores individual struct page pointers, each representing
PAGE_SIZE of memory.</p>
<p>ib_sg_to_page() has ensured that when i&amp;gt;=1 either
a) SG[i-1].dma_end and SG[i].dma_addr are contiguous
or
b) SG[i-1].dma_end and SG[i].dma_addr are mr-&amp;gt;page_size aligned.</p>
<p>This leads to incorrect iova-to-va conversion in scenarios:</p>
<p>1) page_size &amp;lt; PAGE_SIZE (e.g., MR: 4K, system: 64K):
   ibmr-&amp;gt;iova = 0x1…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/oesa-2026-3707"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74620</id>
    <title>UBUNTU-CVE-2026-74620</title>
    <updated>2026-10-03T20:38:02.576216+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: net/sched: act_gact, act_police: range check the fallback control action tcf_action_check_ctrlact() range checks the primary control action: 	if (!opcode) 		ret = action &gt; TC_ACT_VALUE_MAX ? -EINVAL : 0; TC_ACT_VALUE_MAX is TC_ACT_TRAP, so kernel-internal verdicts above it cannot be set that way. But act_gact and act_police each carry a second, independent control action supplied by user space that never reaches that helper - TCA_GACT_PROB.paction and TCA_POLICE_RESULT. Both only reject TC_ACT_GOTO_CHAIN, so any other value is stored verbatim and returned verbatim from the action. In particular user space can store TC_ACT_CONSUMED, which is TC_ACT_VALUE_MAX + 1 and is deliberately not part of the UAPI value range. That verdict tells every caller the action took ownership of the skb, so nobody frees it: sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for it. The result is one leaked sk_buff plus its data buffer per packet traversing the filter, unbounded, for all traffic on the chain including kernel-generated packets. Both are trivially deterministic. act_gact clamps tcfg_pval to &gt;= 1, so with pval = 1 gact_determ() returns the fallback for every packet. act_police has no mandatory rate, so rate = 0 leaves tcfp_mtu = ~0 and tcf_police_mtu_check() always passes. TC_ACT_CONSUMED was added by commit 720f22fed81b ("net: sched: refactor reinsert action"), after bot…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74620"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970</id>
    <title>WID-SEC-W-2026-2970 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
    <updated>2026-10-03T20:38:02.576521+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970"/>
  </entry>
</feed>
