<?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>Tue, 29 Sep 2026 22:58:00 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-72157 — net: thunderbolt: Fix frags[] overflow by bounding frame_count</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-72157</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;net: thunderbolt: Fix frags[] overflow by bounding frame_count&lt;/p&gt;
&lt;p&gt;tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The
first frame goes into the skb linear area and every further frame is added as
a page fragment.&lt;/p&gt;
&lt;p&gt;skb_add_rx_frag(skb, skb_shinfo(skb)-&amp;gt;nr_frags,
			page, hdr_size, frame_size,
			TBNET_RX_PAGE_SIZE - hdr_size);&lt;/p&gt;
&lt;p&gt;A packet of frame_count frames therefore ends up with frame_count - 1
fragments. tbnet_check_frame() only bounds the peer supplied frame_count to
TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A
peer that sends a packet of 19 or more small frames pushes nr_frags past
MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()-&amp;gt;frags[] and
corrupts memory after the shared info.&lt;/p&gt;
&lt;p&gt;Tighten the start of packet bound to MAX_SKB_FRAGS + 1 so a packet can never
produce more fragments than frags[] can hold. This matches the recent skb
frags overflow fixes in other receive paths, for example f0813bcd2d9d (&amp;#34;net:
wwan: t7xx: fix potential skb-&amp;gt;frags overflow in RX path&amp;#34;) and 600dc40554dc
(&amp;#34;net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()&amp;#34;).&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;net: thunderbolt: Fix frags[] overflow by bounding frame_count&lt;/p&gt;
&lt;p&gt;tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The
first frame goes into the skb linear area and every further frame is added as
a page fragment.&lt;/p&gt;
&lt;p&gt;skb_add_rx_frag(skb, skb_shinfo(skb)-&amp;gt;nr_frags,
			page, hdr_size, frame_size,
			TBNET_RX_PAGE_SIZE - hdr_size);&lt;/p&gt;
&lt;p&gt;A packet of frame_count frames therefore ends up with frame_count - 1
fragments. tbnet_check_frame() only bounds the peer supplied frame_count to
TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A
peer that sends a packet of 19 or more small frames pushes nr_frags past
MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()-&amp;gt;frags[] and
corrupts memory after the shared info.&lt;/p&gt;
&lt;p&gt;Tighten the start of packet bound to MAX_SKB_FRAGS + 1 so a packet can never
produce more fragments than frags[] can hold. This matches the recent skb
frags overflow fixes in other receive paths, for example f0813bcd2d9d (&amp;#34;net:
wwan: t7xx: fix potential skb-&amp;gt;frags overflow in RX path&amp;#34;) and 600dc40554dc
(&amp;#34;net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()&amp;#34;).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-72157</guid>
    </item>
  </channel>
</rss>
