CVE-2022-50816
published 2025-12-30CVE-2022-50816: 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…
PriorityP423medium4.7
EPSS
0.22%
12.5th percentile
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 : 000
Affected
19 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.0.7-1 (bookworm) | linux 6.0.7-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= c12b395a46646bab69089ce7016ac78177f6001f < 2bab6fa449d16af36d9c9518865f783a15f446c7 | 2bab6fa449d16af36d9c9518865f783a15f446c7 |
| linux | linux | >= c12b395a46646bab69089ce7016ac78177f6001f < 78297d513157a31fd629626fe4cbb85a7dcbb94a | 78297d513157a31fd629626fe4cbb85a7dcbb94a |
| linux | linux | >= c12b395a46646bab69089ce7016ac78177f6001f < af51fc23a03f02b0c6df09ab0d60f23794436052 | af51fc23a03f02b0c6df09ab0d60f23794436052 |
| linux | linux | >= c12b395a46646bab69089ce7016ac78177f6001f < 44affe7ede596f078c4f2f41e0d160266ccda818 | 44affe7ede596f078c4f2f41e0d160266ccda818 |
| linux | linux | >= c12b395a46646bab69089ce7016ac78177f6001f < ad3f1d9bf162c487d23df684852597961b745cae | ad3f1d9bf162c487d23df684852597961b745cae |
| linux | linux | >= c12b395a46646bab69089ce7016ac78177f6001f < ccd94bd4939690e24d13e23814bce7ed853a09f3 | ccd94bd4939690e24d13e23814bce7ed853a09f3 |
| linux | linux | >= c12b395a46646bab69089ce7016ac78177f6001f < d89d7ff01235f218dad37de84457717f699dee79 | d89d7ff01235f218dad37de84457717f699dee79 |
| linux | linux_kernel | >= 0 < 5.10.158-1 | 5.10.158-1 |
| linux | linux_kernel | >= 0 < 6.0.7-1 | 6.0.7-1 |
| linux | linux_kernel | >= 0 < 6.0.7-1 | 6.0.7-1 |
| linux | linux_kernel | >= 0 < 6.0.7-1 | 6.0.7-1 |
| linux | linux_kernel | >= 3.7.0 < 4.14.305 | 4.14.305 |
| linux | linux_kernel | >= 4.15.0 < 4.19.272 | 4.19.272 |
| linux | linux_kernel | >= 4.20.0 < 5.4.231 | 5.4.231 |
| linux | linux_kernel | >= 5.11.0 < 5.15.77 | 5.15.77 |
| linux | linux_kernel | >= 5.16.0 < 6.0.7 | 6.0.7 |
| linux | linux_kernel | >= 5.5.0 < 5.10.153 | 5.10.153 |
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: ipv6: ensure sane device mtu in tunnels
vendor_redhat·2025-12-30·CVSS 4.7
CVE-2022-50816 [MEDIUM] CWE-20 kernel: ipv6: ensure sane device mtu in tunnels
kernel: ipv6: ensure sane device mtu in tunnels
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_p
Debian
CVE-2022-50816: linux - In the Linux kernel, the following vulnerability has been resolved: ipv6: ensur...
vendor_debian·2022
CVE-2022-50816 CVE-2022-50816: linux - In the Linux kernel, the following vulnerability has been resolved: ipv6: ensur...
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:ff
GHSA
GHSA-p2cq-487q-r77f: In the Linux kernel, the following vulnerability has been resolved:
ipv6: ensure sane device mtu in tunnels
Another syzbot report [1] with no reprod
ghsa_unreviewed·2025-12-30
CVE-2022-50816 GHSA-p2cq-487q-r77f: In the Linux kernel, the following vulnerability has been resolved:
ipv6: ensure sane device mtu in tunnels
Another syzbot report [1] with no reprod
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 h
OSV
CVE-2022-50816: In the Linux kernel, the following vulnerability has been resolved: ipv6: ensure sane device mtu in tunnels Another syzbot report [1] with no reproduc
osv·2025-12-30
CVE-2022-50816 CVE-2022-50816: In the Linux kernel, the following vulnerability has been resolved: ipv6: ensure sane device mtu in tunnels Another syzbot report [1] with no reproduc
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:ff
OSV
ipv6: ensure sane device mtu in tunnels
osv·2025-12-30
CVE-2022-50816 ipv6: ensure sane device mtu in tunnels
ipv6: ensure sane device mtu in tunnels
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_pan
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2022-50816 kernel: ipv6: ensure sane device mtu in tunnels
bugzilla·2025-12-30
CVE-2022-50816 [MEDIUM] CVE-2022-50816 kernel: ipv6: ensure sane device mtu in tunnels
CVE-2022-50816 kernel: ipv6: ensure sane device mtu in tunnels
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.
[
Wiz
CVE-2022-50816 Impact, Exploitability, and Mitigation Steps | Wiz
blogs_wiz
CVE-2022-50816 CVE-2022-50816 Impact, Exploitability, and Mitigation Steps | Wiz
## CVE-2022-50816 :
Linux Kernel vulnerability analysis and mitigation
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
https://git.kernel.org/stable/c/2bab6fa449d16af36d9c9518865f783a15f446c7https://git.kernel.org/stable/c/44affe7ede596f078c4f2f41e0d160266ccda818https://git.kernel.org/stable/c/78297d513157a31fd629626fe4cbb85a7dcbb94ahttps://git.kernel.org/stable/c/ad3f1d9bf162c487d23df684852597961b745caehttps://git.kernel.org/stable/c/af51fc23a03f02b0c6df09ab0d60f23794436052https://git.kernel.org/stable/c/ccd94bd4939690e24d13e23814bce7ed853a09f3https://git.kernel.org/stable/c/d89d7ff01235f218dad37de84457717f699dee79
2025-12-30
Published