CVE-2022-50816 in Linux
Summary
by MITRE • 12/30/2025
In the Linux kernel, the following vulnerability has been resolved:
ipv6: ensure sane device mtu in tunnels
Another syzbot report [1] with no reproducer hints
at a bug in ip6_gre tunnel (dev:ip6gretap0)
Since ipv6 mcast code makes sure to read dev->mtu once and applies a sanity check on it (see commit b9b312a7a451 "ipv6: mcast: better catch silly mtu values"), a remaining possibility is that a layer is able to set dev->mtu to an underflowed value (high order bit set).
This could happen indeed in ip6gre_tnl_link_config_route(), ip6_tnl_link_config() and ipip6_tunnel_bind_dev()
Make sure to sanitize mtu value in a local variable before it is written once on dev->mtu, as lockless readers could catch wrong temporary value.
[1]
skbuff: skb_over_panic: text:ffff80000b7a2f38 len:40 put:40 head:ffff000149dcf200 data:ffff000149dcf2b0 tail:0xd8 end:0xc0 dev:ip6gretap0 ------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:120 Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in: CPU: 1 PID: 10241 Comm: kworker/1:1 Not tainted 6.0.0-rc7-syzkaller-18095-gbbed346d5a96 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/30/2022 Workqueue: mld mld_ifc_work pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic+0x4c/0x50 net/core/skbuff.c:116 lr : skb_panic+0x4c/0x50 net/core/skbuff.c:116 sp : ffff800020dd3b60 x29: ffff800020dd3b70 x28: 0000000000000000 x27: ffff00010df2a800 x26: 00000000000000c0 x25: 00000000000000b0 x24: ffff000149dcf200 x23: 00000000000000c0 x22: 00000000000000d8 x21: ffff80000b7a2f38 x20: ffff00014c2f7800 x19: 0000000000000028 x18: 00000000000001a9 x17: 0000000000000000 x16: ffff80000db49158 x15: ffff000113bf1a80 x14: 0000000000000000 x13: 00000000ffffffff x12: ffff000113bf1a80 x11: ff808000081c0d5c x10: 0000000000000000 x9 : 73f125dc5c63ba00 x8 : 73f125dc5c63ba00 x7 : ffff800008161d1c x6 : 0000000000000000 x5 : 0000000000000080 x4 : 0000000000000001 x3 : 0000000000000000 x2 : ffff0001fefddcd0 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skb_panic+0x4c/0x50 net/core/skbuff.c:116 skb_over_panic net/core/skbuff.c:125 [inline]
skb_put+0xd4/0xdc net/core/skbuff.c:2049 ip6_mc_hdr net/ipv6/mcast.c:1714 [inline]
mld_newpack+0x14c/0x270 net/ipv6/mcast.c:1765 add_grhead net/ipv6/mcast.c:1851 [inline]
add_grec+0xa20/0xae0 net/ipv6/mcast.c:1989 mld_send_cr+0x438/0x5a8 net/ipv6/mcast.c:2115 mld_ifc_work+0x38/0x290 net/ipv6/mcast.c:2653 process_one_work+0x2d8/0x504 kernel/workqueue.c:2289 worker_thread+0x340/0x610 kernel/workqueue.c:2436 kthread+0x12c/0x158 kernel/kthread.c:376 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 Code: 91011400 aa0803e1 a90027ea 94373093 (d4210000)
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 02/13/2026
The vulnerability described in CVE-2022-50816 resides within the Linux kernel's IPv6 tunneling implementation, specifically affecting the ip6_gre tunnel functionality. This issue stems from a potential race condition and improper sanitization of the Maximum Transmission Unit (MTU) value associated with network devices. The problem manifests when a layer attempts to set dev->mtu to an underflowed value, which can occur in three critical functions: ip6gre_tnl_link_config_route(), ip6_tnl_link_config(), and ipip6_tunnel_bind_dev(). These functions are responsible for configuring tunnel links and managing device parameters, making them prime candidates for manipulation that could lead to system instability.
The root cause of this vulnerability lies in the lack of proper validation before writing MTU values to device structures. While the IPv6 multicast code already implements a sanity check to read dev->mtu once and validate its value, this protection is insufficient when dealing with concurrent access patterns. The kernel's network subsystem relies on lockless readers that may encounter temporary inconsistent values during the MTU update process, creating a window where invalid MTU values can be consumed by network operations. This behavior directly violates the principle of atomic updates in concurrent systems and can lead to unpredictable outcomes when network packets are processed with malformed MTU information.
The operational impact of this vulnerability is severe and manifests through kernel panics and system crashes, as evidenced by the syzbot report showing an Oops condition in the kernel's skbuff.c module. The crash occurs when skb_over_panic is triggered, indicating that packet buffers have been corrupted due to incorrect MTU values. The specific error trace shows that the kernel attempts to access memory regions beyond packet buffer boundaries, resulting in a BUG at net/core/skbuff.c:120. This type of vulnerability creates a direct path for privilege escalation or denial-of-service attacks, as malicious actors could exploit the race condition to inject invalid MTU values that cause kernel memory corruption during network packet processing.
Mitigation strategies for this vulnerability involve implementing proper sanitization of MTU values before they are written to device structures, ensuring that all MTU assignments are validated against reasonable bounds and atomic operations. The fix should include bounds checking and validation of MTU values in the affected functions to prevent underflowed or excessively large values from being assigned. Additionally, the kernel should implement proper synchronization mechanisms to prevent concurrent access during MTU updates, ensuring that readers always observe consistent values. This vulnerability aligns with CWE-129 and CWE-369 categories, representing issues with input validation and improper handling of exceptional conditions. The ATT&CK framework would classify this as a system service compromise technique, potentially enabling privilege escalation through kernel memory corruption and system instability. Organizations should prioritize applying kernel patches that address this specific MTU validation issue and monitor for similar race condition patterns in other network subsystem components.