CVE-2024-36933: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment(). syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols: ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls skb_mac_gso_segment() to invoke inner protocol GSO handlers. nsh_gso_segment() does the following for the original skb before calling skb_mac_gso_segment() 1. reset skb->network_header 2. save the original skb->{mac_heaeder,mac_len} in a local variable 3. pull the NSH header 4. resets skb->mac_header 5. set up skb->mac_len and skb->protocol for the inner protocol. and does the following for the segmented skb 6. set ntohs(ETH_P_NSH) to skb->protocol 7. push the NSH header 8. restore skb->mac_header 9. set skb->mac_header + mac_len to skb->network_header 10. restore skb->mac_len There are two problems in 6-7 and 8-9. (a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev. Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skb_pull() in the first nsh_gso_segment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nsh_gso_segment(). (b) While restoring skb->{mac_header,network_header} in 8 & 9, nsh_gso_segment() does not assume that the data in the linear buffer is shifted. However, udp6_ufo_fragment() could shift the data and change skb->mac_header accordingly as demonstrated by syzbot. If this happens, even the restored skb->mac_header points to the middle of the outer header. It seems nsh_gso_segment() has never worked with outer headers so far. At the end of nsh_gso_segment(), the outer header must be restored for the segmented skb, instead of the NSH header. To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,mac_header,protocol} properly. [0]: BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222 __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3547 [inline] dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] __do_kmalloc_node mm/slub.c:3980 [inline] __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 __ ---truncated---
AI Analysis
Technical Summary
CVE-2024-36933 is a vulnerability in the Linux kernel's handling of Network Service Header (NSH) Generic Segmentation Offload (GSO) packets, specifically within the nsh_gso_segment() function. NSH is a protocol used for service function chaining and can encapsulate various inner protocols such as IPv4, IPv6, Ethernet, NSH itself, and MPLS. The vulnerability arises when processing crafted GSO packets that layer multiple protocols, including ETH_P_8021AD (Q-in-Q VLAN tagging), ETH_P_NSH, ETH_P_IPV6, and UDP. The nsh_gso_segment() function is responsible for segmenting large packets for transmission but mishandles the restoration of skb (socket buffer) metadata fields related to the outer headers after segmentation. Specifically, two main issues are identified: (a) after pushing the NSH header back onto the skb, the skb->data pointer points to the NSH header rather than the outer header, causing the outer header (e.g., ETH_P_8021AD) to be stripped when the packet is transmitted; (b) when restoring skb->mac_header and skb->network_header, nsh_gso_segment() does not account for potential data shifts caused by subsequent fragmentation functions like udp6_ufo_fragment(), leading to skb->mac_header pointing incorrectly to the middle of the outer header. This improper restoration can cause kernel memory corruption or undefined behavior, potentially leading to kernel crashes (kernel panics) or memory safety issues. The vulnerability was discovered through syzbot fuzzing, which triggered various kernel splats and uninitialized value bugs in related network code paths. The root cause is that nsh_gso_segment() has never properly handled outer headers during segmentation, and the fix involves correctly calculating and restoring the outer header positions relative to the inner headers in skb metadata fields. No known exploits are reported in the wild as of the publication date. The vulnerability affects Linux kernel versions containing the specified commit hash c411ed854584a71b0e86ac3019b60e4789d88086 and likely other versions with similar nsh_gso_segment() implementations. No CVSS score has been assigned yet.
Potential Impact
For European organizations, this vulnerability poses a risk primarily to environments using Linux-based systems with NSH-enabled networking features, particularly those employing service function chaining or advanced network virtualization technologies that utilize NSH encapsulation. The impact includes potential kernel crashes leading to denial of service (DoS) conditions, which can disrupt critical network functions and services. In high-availability or real-time systems, such disruptions could cause significant operational downtime. Additionally, the memory corruption risks could be leveraged in complex attack chains to escalate privileges or execute arbitrary code within the kernel, although no public exploits currently exist. Given the widespread use of Linux in European data centers, cloud infrastructures, telecom networks, and enterprise environments, the vulnerability could affect a broad range of sectors including finance, healthcare, telecommunications, and government. The complexity of the vulnerability and the requirement for crafted GSO packets with specific protocol layering limit the ease of exploitation, but targeted attacks against vulnerable network infrastructure remain a concern. Organizations relying on NSH for network service chaining or those using virtualized network functions (VNFs) should be particularly vigilant. The vulnerability also highlights risks in kernel network stack processing that could affect containerized or cloud-native deployments using Linux networking features.
Mitigation Recommendations
1. Apply the official Linux kernel patches that address CVE-2024-36933 as soon as they become available from trusted sources or Linux distribution vendors. Monitor kernel mailing lists and vendor advisories for updates. 2. If immediate patching is not possible, consider disabling NSH support or the affected GSO features in the kernel configuration or via runtime parameters to reduce the attack surface. 3. Implement network-level filtering to block or scrutinize packets with suspicious protocol layering, especially those involving ETH_P_8021AD, ETH_P_NSH, and complex encapsulations, to prevent crafted packets from reaching vulnerable systems. 4. Employ kernel hardening techniques such as enabling Kernel Address Sanitizer (KASAN) and Kernel Memory Sanitizer (KMSAN) in test environments to detect similar memory corruption issues proactively. 5. Conduct thorough testing of network virtualization and service chaining configurations to identify abnormal behavior or crashes related to NSH packet processing. 6. Maintain strict network segmentation and access controls to limit exposure of vulnerable Linux hosts to untrusted networks or users who could send crafted packets. 7. Monitor system logs and kernel crash reports for signs of exploitation attempts or instability related to network packet processing. 8. Coordinate with Linux distribution maintainers to ensure timely deployment of security updates across all affected systems.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Italy, Spain
CVE-2024-36933: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment(). syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols: ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls skb_mac_gso_segment() to invoke inner protocol GSO handlers. nsh_gso_segment() does the following for the original skb before calling skb_mac_gso_segment() 1. reset skb->network_header 2. save the original skb->{mac_heaeder,mac_len} in a local variable 3. pull the NSH header 4. resets skb->mac_header 5. set up skb->mac_len and skb->protocol for the inner protocol. and does the following for the segmented skb 6. set ntohs(ETH_P_NSH) to skb->protocol 7. push the NSH header 8. restore skb->mac_header 9. set skb->mac_header + mac_len to skb->network_header 10. restore skb->mac_len There are two problems in 6-7 and 8-9. (a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev. Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skb_pull() in the first nsh_gso_segment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nsh_gso_segment(). (b) While restoring skb->{mac_header,network_header} in 8 & 9, nsh_gso_segment() does not assume that the data in the linear buffer is shifted. However, udp6_ufo_fragment() could shift the data and change skb->mac_header accordingly as demonstrated by syzbot. If this happens, even the restored skb->mac_header points to the middle of the outer header. It seems nsh_gso_segment() has never worked with outer headers so far. At the end of nsh_gso_segment(), the outer header must be restored for the segmented skb, instead of the NSH header. To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,mac_header,protocol} properly. [0]: BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222 __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3547 [inline] dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] __do_kmalloc_node mm/slub.c:3980 [inline] __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 __ ---truncated---
AI-Powered Analysis
Technical Analysis
CVE-2024-36933 is a vulnerability in the Linux kernel's handling of Network Service Header (NSH) Generic Segmentation Offload (GSO) packets, specifically within the nsh_gso_segment() function. NSH is a protocol used for service function chaining and can encapsulate various inner protocols such as IPv4, IPv6, Ethernet, NSH itself, and MPLS. The vulnerability arises when processing crafted GSO packets that layer multiple protocols, including ETH_P_8021AD (Q-in-Q VLAN tagging), ETH_P_NSH, ETH_P_IPV6, and UDP. The nsh_gso_segment() function is responsible for segmenting large packets for transmission but mishandles the restoration of skb (socket buffer) metadata fields related to the outer headers after segmentation. Specifically, two main issues are identified: (a) after pushing the NSH header back onto the skb, the skb->data pointer points to the NSH header rather than the outer header, causing the outer header (e.g., ETH_P_8021AD) to be stripped when the packet is transmitted; (b) when restoring skb->mac_header and skb->network_header, nsh_gso_segment() does not account for potential data shifts caused by subsequent fragmentation functions like udp6_ufo_fragment(), leading to skb->mac_header pointing incorrectly to the middle of the outer header. This improper restoration can cause kernel memory corruption or undefined behavior, potentially leading to kernel crashes (kernel panics) or memory safety issues. The vulnerability was discovered through syzbot fuzzing, which triggered various kernel splats and uninitialized value bugs in related network code paths. The root cause is that nsh_gso_segment() has never properly handled outer headers during segmentation, and the fix involves correctly calculating and restoring the outer header positions relative to the inner headers in skb metadata fields. No known exploits are reported in the wild as of the publication date. The vulnerability affects Linux kernel versions containing the specified commit hash c411ed854584a71b0e86ac3019b60e4789d88086 and likely other versions with similar nsh_gso_segment() implementations. No CVSS score has been assigned yet.
Potential Impact
For European organizations, this vulnerability poses a risk primarily to environments using Linux-based systems with NSH-enabled networking features, particularly those employing service function chaining or advanced network virtualization technologies that utilize NSH encapsulation. The impact includes potential kernel crashes leading to denial of service (DoS) conditions, which can disrupt critical network functions and services. In high-availability or real-time systems, such disruptions could cause significant operational downtime. Additionally, the memory corruption risks could be leveraged in complex attack chains to escalate privileges or execute arbitrary code within the kernel, although no public exploits currently exist. Given the widespread use of Linux in European data centers, cloud infrastructures, telecom networks, and enterprise environments, the vulnerability could affect a broad range of sectors including finance, healthcare, telecommunications, and government. The complexity of the vulnerability and the requirement for crafted GSO packets with specific protocol layering limit the ease of exploitation, but targeted attacks against vulnerable network infrastructure remain a concern. Organizations relying on NSH for network service chaining or those using virtualized network functions (VNFs) should be particularly vigilant. The vulnerability also highlights risks in kernel network stack processing that could affect containerized or cloud-native deployments using Linux networking features.
Mitigation Recommendations
1. Apply the official Linux kernel patches that address CVE-2024-36933 as soon as they become available from trusted sources or Linux distribution vendors. Monitor kernel mailing lists and vendor advisories for updates. 2. If immediate patching is not possible, consider disabling NSH support or the affected GSO features in the kernel configuration or via runtime parameters to reduce the attack surface. 3. Implement network-level filtering to block or scrutinize packets with suspicious protocol layering, especially those involving ETH_P_8021AD, ETH_P_NSH, and complex encapsulations, to prevent crafted packets from reaching vulnerable systems. 4. Employ kernel hardening techniques such as enabling Kernel Address Sanitizer (KASAN) and Kernel Memory Sanitizer (KMSAN) in test environments to detect similar memory corruption issues proactively. 5. Conduct thorough testing of network virtualization and service chaining configurations to identify abnormal behavior or crashes related to NSH packet processing. 6. Maintain strict network segmentation and access controls to limit exposure of vulnerable Linux hosts to untrusted networks or users who could send crafted packets. 7. Monitor system logs and kernel crash reports for signs of exploitation attempts or instability related to network packet processing. 8. Coordinate with Linux distribution maintainers to ensure timely deployment of security updates across all affected systems.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-05-30T15:25:07.071Z
- Cisa Enriched
- true
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9828c4522896dcbe26fd
Added to database: 5/21/2025, 9:08:56 AM
Last enriched: 6/29/2025, 10:25:02 AM
Last updated: 8/17/2025, 6:39:17 PM
Views: 19
Actions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.