<?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>Wed, 30 Sep 2026 21:12:09 +0000</lastBuildDate>
    <item>
      <title>CVE-2023-53667 — net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2023-53667</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: cdc_ncm: Deal with too low values of dwNtbOutMaxSize&lt;/p&gt;
&lt;p&gt;Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than
the calculated &amp;#34;min&amp;#34; value, but greater than zero, the logic sets
tx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in
cdc_ncm_fill_tx_frame() where all the data is handled.&lt;/p&gt;
&lt;p&gt;For small values of dwNtbOutMaxSize the memory allocated during
alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to
how size is aligned at alloc time:
	size = SKB_DATA_ALIGN(size);
        size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
Thus we hit the same bug that we tried to squash with
commit 2be6d4d16a084 (&amp;#34;net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero&amp;#34;)&lt;/p&gt;
&lt;p&gt;Low values of dwNtbOutMaxSize do not cause an issue presently because at
alloc_skb() time more memory (512b) is allocated than required for the
SKB headers alone (320b), leaving some space (512b - 320b = 192b)
for CDC data (172b).&lt;/p&gt;
&lt;p&gt;However, if more elements (for example 3 x u64 = [24b]) were added to
one of the SKB header structs, say &amp;#39;struct skb_shared_info&amp;#39;,
increasing its original size (320b [320b aligned]) to something larger
(344b [384b aligned]), then suddenly the CDC data (172b) no longer
fits in the spare SKB data area (512b - 384b = 128b).&lt;/p&gt;
&lt;p&gt;Consequently the SKB bounds checking semantics fails and panics:&lt;/p&gt;
&lt;p&gt;skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00…&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: cdc_ncm: Deal with too low values of dwNtbOutMaxSize&lt;/p&gt;
&lt;p&gt;Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than
the calculated &amp;#34;min&amp;#34; value, but greater than zero, the logic sets
tx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in
cdc_ncm_fill_tx_frame() where all the data is handled.&lt;/p&gt;
&lt;p&gt;For small values of dwNtbOutMaxSize the memory allocated during
alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to
how size is aligned at alloc time:
	size = SKB_DATA_ALIGN(size);
        size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
Thus we hit the same bug that we tried to squash with
commit 2be6d4d16a084 (&amp;#34;net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero&amp;#34;)&lt;/p&gt;
&lt;p&gt;Low values of dwNtbOutMaxSize do not cause an issue presently because at
alloc_skb() time more memory (512b) is allocated than required for the
SKB headers alone (320b), leaving some space (512b - 320b = 192b)
for CDC data (172b).&lt;/p&gt;
&lt;p&gt;However, if more elements (for example 3 x u64 = [24b]) were added to
one of the SKB header structs, say &amp;#39;struct skb_shared_info&amp;#39;,
increasing its original size (320b [320b aligned]) to something larger
(344b [384b aligned]), then suddenly the CDC data (172b) no longer
fits in the spare SKB data area (512b - 384b = 128b).&lt;/p&gt;
&lt;p&gt;Consequently the SKB bounds checking semantics fails and panics:&lt;/p&gt;
&lt;p&gt;skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2023-53667</guid>
    </item>
  </channel>
</rss>
