<?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-04T02:49:04.082466+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:2026-12442</id>
    <title>bdu:2026-12442</title>
    <updated>2026-10-04T02:49:04.359341+00:00</updated>
    <content>bdu:2026-12442</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2026-12442"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2023-53667</id>
    <title>BELL-CVE-2023-53667</title>
    <updated>2026-10-04T02:49:04.359398+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2023-53667"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2025-avi-1032</id>
    <title>certfr-2025-avi-1032 — 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-04T02:49:04.359433+00:00</updated>
    <content>certfr-2025-avi-1032</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2025-avi-1032"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-312195</id>
    <title>EUVD-2026-312195</title>
    <updated>2026-10-04T02:49:04.359451+00:00</updated>
    <content>EUVD-2026-312195</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-312195"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2023-53667</id>
    <title>fkie_cve-2023-53667</title>
    <updated>2026-10-04T02:49:04.359462+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: cdc_ncm: Deal with too low values of dwNtbOutMaxSize</p>
<p>Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than
the calculated "min" 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.</p>
<p>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 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")</p>
<p>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).</p>
<p>However, if more elements (for example 3 x u64 = [24b]) were added to
one of the SKB header structs, say 'struct skb_shared_info',
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).</p>
<p>Consequently the SKB bounds checking semantics fails and panics:</p>
<p>skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2023-53667"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-j9p8-cc5q-cg54</id>
    <title>GHSA-j9p8-cc5q-cg54</title>
    <updated>2026-10-04T02:49:04.359512+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: cdc_ncm: Deal with too low values of dwNtbOutMaxSize</p>
<p>Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than
the calculated "min" 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.</p>
<p>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 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")</p>
<p>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).</p>
<p>However, if more elements (for example 3 x u64 = [24b]) were added to
one of the SKB header structs, say 'struct skb_shared_info',
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).</p>
<p>Consequently the SKB bounds checking semantics fails and panics:</p>
<p>skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-j9p8-cc5q-cg54"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2025:4139-1</id>
    <title>SUSE-SU-2025:4139-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-04T02:49:04.359548+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:4139-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53667</id>
    <title>UBUNTU-CVE-2023-53667</title>
    <updated>2026-10-04T02:49:04.359659+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, 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 and 163 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than the calculated "min" 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. 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 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero") 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). However, if more elements (for example 3 x u64 = [24b]) were added to one of the SKB header structs, say 'struct skb_shared_info', 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). Consequently the SKB bounds checking semantics fails and panics: skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:f…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53667"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2229</id>
    <title>WID-SEC-W-2025-2229 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-10-04T02:49:04.359902+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 Denial of Service Angriff durchzuführen und andere nicht näher spezifizierte Angriffe durchzuführen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2229"/>
  </entry>
</feed>
