<?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 10:39:40 +0000</lastBuildDate>
    <item>
      <title>CVE-2023-53752 — net: deal with integer overflows in kmalloc_reserve()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2023-53752</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: deal with integer overflows in kmalloc_reserve()&lt;/p&gt;
&lt;p&gt;Blamed commit changed:
    ptr = kmalloc(size);
    if (ptr)
      size = ksize(ptr);&lt;/p&gt;
&lt;p&gt;size = kmalloc_size_roundup(size);
    ptr = kmalloc(size);&lt;/p&gt;
&lt;p&gt;This allowed various crash as reported by syzbot [1]
and Kyle Zeng.&lt;/p&gt;
&lt;p&gt;Problem is that if @size is bigger than 0x80000001,
kmalloc_size_roundup(size) returns 2^32.&lt;/p&gt;
&lt;p&gt;kmalloc_reserve() uses a 32bit variable (obj_size),
so 2^32 is truncated to 0.&lt;/p&gt;
&lt;p&gt;kmalloc(0) returns ZERO_SIZE_PTR which is not handled by
skb allocations.&lt;/p&gt;
&lt;p&gt;Following trace can be triggered if a netdev-&amp;gt;mtu is set
close to 0x7fffffff&lt;/p&gt;
&lt;p&gt;We might in the future limit netdev-&amp;gt;mtu to more sensible
limit (like KMALLOC_MAX_SIZE).&lt;/p&gt;
&lt;p&gt;This patch is based on a syzbot report, and also a report
and tentative fix from Kyle Zeng.&lt;/p&gt;
&lt;p&gt;[1]
BUG: KASAN: user-memory-access in __build_skb_around net/core/skbuff.c:294 [inline]
BUG: KASAN: user-memory-access in __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527
Write of size 32 at addr 00000000fffffd10 by task syz-executor.4/22554&lt;/p&gt;
&lt;p&gt;CPU: 1 PID: 22554 Comm: syz-executor.4 Not tainted 6.1.39-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023
Call trace:
dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:279
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106
print_report+0xe4/0x4b4…&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: deal with integer overflows in kmalloc_reserve()&lt;/p&gt;
&lt;p&gt;Blamed commit changed:
    ptr = kmalloc(size);
    if (ptr)
      size = ksize(ptr);&lt;/p&gt;
&lt;p&gt;size = kmalloc_size_roundup(size);
    ptr = kmalloc(size);&lt;/p&gt;
&lt;p&gt;This allowed various crash as reported by syzbot [1]
and Kyle Zeng.&lt;/p&gt;
&lt;p&gt;Problem is that if @size is bigger than 0x80000001,
kmalloc_size_roundup(size) returns 2^32.&lt;/p&gt;
&lt;p&gt;kmalloc_reserve() uses a 32bit variable (obj_size),
so 2^32 is truncated to 0.&lt;/p&gt;
&lt;p&gt;kmalloc(0) returns ZERO_SIZE_PTR which is not handled by
skb allocations.&lt;/p&gt;
&lt;p&gt;Following trace can be triggered if a netdev-&amp;gt;mtu is set
close to 0x7fffffff&lt;/p&gt;
&lt;p&gt;We might in the future limit netdev-&amp;gt;mtu to more sensible
limit (like KMALLOC_MAX_SIZE).&lt;/p&gt;
&lt;p&gt;This patch is based on a syzbot report, and also a report
and tentative fix from Kyle Zeng.&lt;/p&gt;
&lt;p&gt;[1]
BUG: KASAN: user-memory-access in __build_skb_around net/core/skbuff.c:294 [inline]
BUG: KASAN: user-memory-access in __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527
Write of size 32 at addr 00000000fffffd10 by task syz-executor.4/22554&lt;/p&gt;
&lt;p&gt;CPU: 1 PID: 22554 Comm: syz-executor.4 Not tainted 6.1.39-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023
Call trace:
dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:279
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106
print_report+0xe4/0x4b4…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2023-53752</guid>
    </item>
  </channel>
</rss>
