[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2026020426-CVE-2026-23095-66e8@gregkh>
Date: Wed, 4 Feb 2026 17:14:54 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2026-23095: gue: Fix skb memleak with inner IP protocol 0.
From: Greg Kroah-Hartman <gregkh@...nel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
gue: Fix skb memleak with inner IP protocol 0.
syzbot reported skb memleak below. [0]
The repro generated a GUE packet with its inner protocol 0.
gue_udp_recv() returns -guehdr->proto_ctype for "resubmit"
in ip_protocol_deliver_rcu(), but this only works with
non-zero protocol number.
Let's drop such packets.
Note that 0 is a valid number (IPv6 Hop-by-Hop Option).
I think it is not practical to encap HOPOPT in GUE, so once
someone starts to complain, we could pass down a resubmit
flag pointer to distinguish two zeros from the upper layer:
* no error
* resubmit HOPOPT
[0]
BUG: memory leak
unreferenced object 0xffff888109695a00 (size 240):
comm "syz.0.17", pid 6088, jiffies 4294943096
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@..............
backtrace (crc a84b336f):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4958 [inline]
slab_alloc_node mm/slub.c:5263 [inline]
kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270
__build_skb+0x23/0x60 net/core/skbuff.c:474
build_skb+0x20/0x190 net/core/skbuff.c:490
__tun_build_skb drivers/net/tun.c:1541 [inline]
tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636
tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770
tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x45d/0x710 fs/read_write.c:686
ksys_write+0xa7/0x170 fs/read_write.c:738
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The Linux kernel CVE team has assigned CVE-2026-23095 to this issue.
Affected and fixed versions
===========================
Issue introduced in 3.18 with commit 37dd0247797b168ad1cc7f5dbec825a1ee66535b and fixed in 6.6.122 with commit f87b9b7a618c82e7465e872eb10e14c803871892
Issue introduced in 3.18 with commit 37dd0247797b168ad1cc7f5dbec825a1ee66535b and fixed in 6.12.68 with commit ce569b389a5c78d64788a5ea94560e17fa574b35
Issue introduced in 3.18 with commit 37dd0247797b168ad1cc7f5dbec825a1ee66535b and fixed in 6.18.8 with commit 5437a279804ced8088cabb945dba88a26d828f8c
Issue introduced in 3.18 with commit 37dd0247797b168ad1cc7f5dbec825a1ee66535b and fixed in 6.19-rc7 with commit 9a56796ad258786d3624eef5aefba394fc9bdded
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-23095
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
net/ipv4/fou_core.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/f87b9b7a618c82e7465e872eb10e14c803871892
https://git.kernel.org/stable/c/ce569b389a5c78d64788a5ea94560e17fa574b35
https://git.kernel.org/stable/c/5437a279804ced8088cabb945dba88a26d828f8c
https://git.kernel.org/stable/c/9a56796ad258786d3624eef5aefba394fc9bdded
Powered by blists - more mailing lists