<?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://vulnerability.circl.lu</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 14:43:36 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-68341 — veth: reduce XDP no_direct return section to fix race</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-68341</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;veth: reduce XDP no_direct return section to fix race&lt;/p&gt;
&lt;p&gt;As explain in commit fa349e396e48 (&amp;#34;veth: Fix race with AF_XDP exposing
old or uninitialized descriptors&amp;#34;) for veth there is a chance after
napi_complete_done() that another CPU can manage start another NAPI
instance running veth_pool(). For NAPI this is correctly handled as the
napi_schedule_prep() check will prevent multiple instances from getting
scheduled, but for the remaining code in veth_pool() this can run
concurrent with the newly started NAPI instance.&lt;/p&gt;
&lt;p&gt;The problem/race is that xdp_clear_return_frame_no_direct() isn&amp;#39;t
designed to be nested.&lt;/p&gt;
&lt;p&gt;Prior to commit 401cb7dae813 (&amp;#34;net: Reference bpf_redirect_info via
task_struct on PREEMPT_RT.&amp;#34;) the temporary BPF net context
bpf_redirect_info was stored per CPU, where this wasn&amp;#39;t an issue. Since
this commit the BPF context is stored in &amp;#39;current&amp;#39; task_struct. When
running veth in threaded-NAPI mode, then the kthread becomes the storage
area. Now a race exists between two concurrent veth_pool() function calls
one exiting NAPI and one running new NAPI, both using the same BPF net
context.&lt;/p&gt;
&lt;p&gt;Race is when another CPU gets within the xdp_set_return_frame_no_direct()
section before exiting veth_pool() calls the clear-function
xdp_clear_return_frame_no_direct().&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;veth: reduce XDP no_direct return section to fix race&lt;/p&gt;
&lt;p&gt;As explain in commit fa349e396e48 (&amp;#34;veth: Fix race with AF_XDP exposing
old or uninitialized descriptors&amp;#34;) for veth there is a chance after
napi_complete_done() that another CPU can manage start another NAPI
instance running veth_pool(). For NAPI this is correctly handled as the
napi_schedule_prep() check will prevent multiple instances from getting
scheduled, but for the remaining code in veth_pool() this can run
concurrent with the newly started NAPI instance.&lt;/p&gt;
&lt;p&gt;The problem/race is that xdp_clear_return_frame_no_direct() isn&amp;#39;t
designed to be nested.&lt;/p&gt;
&lt;p&gt;Prior to commit 401cb7dae813 (&amp;#34;net: Reference bpf_redirect_info via
task_struct on PREEMPT_RT.&amp;#34;) the temporary BPF net context
bpf_redirect_info was stored per CPU, where this wasn&amp;#39;t an issue. Since
this commit the BPF context is stored in &amp;#39;current&amp;#39; task_struct. When
running veth in threaded-NAPI mode, then the kthread becomes the storage
area. Now a race exists between two concurrent veth_pool() function calls
one exiting NAPI and one running new NAPI, both using the same BPF net
context.&lt;/p&gt;
&lt;p&gt;Race is when another CPU gets within the xdp_set_return_frame_no_direct()
section before exiting veth_pool() calls the clear-function
xdp_clear_return_frame_no_direct().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-68341</guid>
    </item>
  </channel>
</rss>
