CVE-2022-48936
Linux Kernel virtue_net IPVS IPip Tunnel GSO Vulnerability
Description
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
INFO
Published Date :
Aug. 22, 2024, 4:15 a.m.
Last Modified :
Aug. 31, 2024, 6:15 a.m.
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Remotely Exploitable :
No
Impact Score :
3.6
Exploitability Score :
1.8
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2022-48936
vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2022-48936
vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
CVE Rejected by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Aug. 31, 2024
Action Type Old Value New Value -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Aug. 31, 2024
Action Type Old Value New Value Changed Description In the Linux kernel, the following vulnerability has been resolved: gso: do not skip outer ip header in case of ipip and net_failover We encounter a tcp drop issue in our cloud environment. Packet GROed in host forwards to a VM virtio_net nic with net_failover enabled. VM acts as a IPVS LB with ipip encapsulation. The full path like: host gro -> vm virtio_net rx -> net_failover rx -> ipvs fullnat -> ipip encap -> net_failover tx -> virtio_net tx When net_failover transmits a ipip pkt (gso_type = 0x0103, which means SKB_GSO_TCPV4, SKB_GSO_DODGY and SKB_GSO_IPXIP4), there is no gso did because it supports TSO and GSO_IPXIP4. But network_header points to inner ip header. Call Trace: tcp4_gso_segment ------> return NULL inet_gso_segment ------> inner iph, network_header points to ipip_gso_segment inet_gso_segment ------> outer iph skb_mac_gso_segment Afterwards virtio_net transmits the pkt, only inner ip header is modified. And the outer one just keeps unchanged. The pkt will be dropped in remote host. Call Trace: inet_gso_segment ------> inner iph, outer iph is skipped skb_mac_gso_segment __skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit __qdisc_run __dev_queue_xmit ------> virtio_net dev_hard_start_xmit __dev_queue_xmit ------> net_failover ip_finish_output2 ip_output iptunnel_xmit ip_tunnel_xmit ipip_tunnel_xmit ------> ipip dev_hard_start_xmit __dev_queue_xmit ip_finish_output2 ip_output ip_forward ip_rcv __netif_receive_skb_one_core netif_receive_skb_internal napi_gro_receive receive_buf virtnet_poll net_rx_action The root cause of this issue is specific with the rare combination of SKB_GSO_DODGY and a tunnel device that adds an SKB_GSO_ tunnel option. SKB_GSO_DODGY is set from external virtio_net. We need to reset network header when callbacks.gso_segment() returns NULL. This patch also includes ipv6_gso_segment(), considering SIT, etc. Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. Removed Reference kernel.org https://git.kernel.org/stable/c/45d006c2c7ed7baf1fa258fa7b5bc9923d3a983e Removed Reference kernel.org https://git.kernel.org/stable/c/7840e559799a08a8588ee6de27516a991cb2e5e7 Removed Reference kernel.org https://git.kernel.org/stable/c/e9ffbe63f6f32f526a461756309b61c395168d73 Removed Reference kernel.org https://git.kernel.org/stable/c/2b3cdd70ea5f5a694f95ea1788393fb3b83071ea Removed Reference kernel.org https://git.kernel.org/stable/c/dac2490d9ee0b89dffc72f1172b8bbeb60eaec39 Removed Reference kernel.org https://git.kernel.org/stable/c/899e56a1ad435261812355550ae869d8be3df395 Removed Reference kernel.org https://git.kernel.org/stable/c/a739963f43269297c3f438b776194542e2a97499 Removed Reference kernel.org https://git.kernel.org/stable/c/cc20cced0598d9a5ff91ae4ab147b3b5e99ee819 Removed CWE NIST NVD-CWE-noinfo Removed CVSS V3.1 NIST AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Removed CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.16 from (excluding) 5.16.12 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.11 from (excluding) 5.15.26 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.5 from (excluding) 5.10.103 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 4.20 from (excluding) 5.4.182 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 4.15 from (excluding) 4.19.232 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 4.10 from (excluding) 4.14.269 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 3.13 from (excluding) 4.9.304 -
CVE Translated by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Aug. 31, 2024
Action Type Old Value New Value Removed Translation Title: kernel de Linux Description: En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gso: no omita el encabezado de IP externo en caso de ipip y net_failover. Nos encontramos con un problema de caída de TCP en nuestro entorno de nube. El paquete GROed en el host se reenvía a una NIC virtio_net de VM con net_failover habilitado. VM actúa como IPVS LB con encapsulación ipip. La ruta completa como: host gro -> vm virtio_net rx -> net_failover rx -> ipvs fullnat -> ipip encap -> net_failover tx -> virtio_net tx Cuando net_failover transmite un paquete ipip (gso_type = 0x0103, que significa SKB_GSO_TCPV4, SKB_GSO_DODGY y SKB_GSO_IPXIP 4 ), no existe gso porque admite TSO y GSO_IPXIP4. Pero network_header apunta al encabezado IP interno. Seguimiento de llamadas: tcp4_gso_segment ------> return NULL inet_gso_segment ------> iph interno, network_header apunta a ipip_gso_segment inet_gso_segment ------> iph externo skb_mac_gso_segment Luego, virtio_net transmite el paquete, solo se muestra el encabezado de IP interno modificado. Y el exterior simplemente se mantiene sin cambios. El paquete se colocará en el host remoto. Seguimiento de llamadas: inet_gso_segment ------> iph interno, se omite el iph externo skb_mac_gso_segment __skb_gso_segment validar_xmit_skb validar_xmit_skb_list sch_direct_xmit __qdisc_run __dev_queue_xmit ------> virtio_net dev_hard_start_xmit __dev_queue_xmit --- ---> net_failover ip_finish_output2 ip_output iptunnel_xmit ip_tunnel_xmit ipip_tunnel_xmit -- ----> ipip dev_hard_start_xmit __dev_queue_xmit ip_finish_output2 ip_output ip_forward ip_rcv __netif_receive_skb_one_core netif_receive_skb_internal napi_gro_receiveceived_buf virtnet_poll net_rx_action La causa raíz de este problema es específica de la rara combinación de SKB_GSO_DODGY y un dispositivo de túnel que agrega una opción de túnel SKB_GSO_. SKB_GSO_DODGY se configura desde virtio_net externo. Necesitamos restablecer el encabezado de la red cuando callbacks.gso_segment() devuelve NULL. Este parche también incluye ipv6_gso_segment(), considerando SIT, etc. -
Initial Analysis by [email protected]
Aug. 22, 2024
Action Type Old Value New Value Added CVSS V3.1 NIST AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Changed Reference Type https://git.kernel.org/stable/c/2b3cdd70ea5f5a694f95ea1788393fb3b83071ea No Types Assigned https://git.kernel.org/stable/c/2b3cdd70ea5f5a694f95ea1788393fb3b83071ea Patch Changed Reference Type https://git.kernel.org/stable/c/45d006c2c7ed7baf1fa258fa7b5bc9923d3a983e No Types Assigned https://git.kernel.org/stable/c/45d006c2c7ed7baf1fa258fa7b5bc9923d3a983e Patch Changed Reference Type https://git.kernel.org/stable/c/7840e559799a08a8588ee6de27516a991cb2e5e7 No Types Assigned https://git.kernel.org/stable/c/7840e559799a08a8588ee6de27516a991cb2e5e7 Patch Changed Reference Type https://git.kernel.org/stable/c/899e56a1ad435261812355550ae869d8be3df395 No Types Assigned https://git.kernel.org/stable/c/899e56a1ad435261812355550ae869d8be3df395 Patch Changed Reference Type https://git.kernel.org/stable/c/a739963f43269297c3f438b776194542e2a97499 No Types Assigned https://git.kernel.org/stable/c/a739963f43269297c3f438b776194542e2a97499 Patch Changed Reference Type https://git.kernel.org/stable/c/cc20cced0598d9a5ff91ae4ab147b3b5e99ee819 No Types Assigned https://git.kernel.org/stable/c/cc20cced0598d9a5ff91ae4ab147b3b5e99ee819 Patch Changed Reference Type https://git.kernel.org/stable/c/dac2490d9ee0b89dffc72f1172b8bbeb60eaec39 No Types Assigned https://git.kernel.org/stable/c/dac2490d9ee0b89dffc72f1172b8bbeb60eaec39 Patch Changed Reference Type https://git.kernel.org/stable/c/e9ffbe63f6f32f526a461756309b61c395168d73 No Types Assigned https://git.kernel.org/stable/c/e9ffbe63f6f32f526a461756309b61c395168d73 Patch Added CWE NIST NVD-CWE-noinfo Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 3.13 up to (excluding) 4.9.304 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 4.10 up to (excluding) 4.14.269 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 4.15 up to (excluding) 4.19.232 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 4.20 up to (excluding) 5.4.182 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.5 up to (excluding) 5.10.103 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.11 up to (excluding) 5.15.26 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.16 up to (excluding) 5.16.12 -
CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Aug. 22, 2024
Action Type Old Value New Value Added Description In the Linux kernel, the following vulnerability has been resolved: gso: do not skip outer ip header in case of ipip and net_failover We encounter a tcp drop issue in our cloud environment. Packet GROed in host forwards to a VM virtio_net nic with net_failover enabled. VM acts as a IPVS LB with ipip encapsulation. The full path like: host gro -> vm virtio_net rx -> net_failover rx -> ipvs fullnat -> ipip encap -> net_failover tx -> virtio_net tx When net_failover transmits a ipip pkt (gso_type = 0x0103, which means SKB_GSO_TCPV4, SKB_GSO_DODGY and SKB_GSO_IPXIP4), there is no gso did because it supports TSO and GSO_IPXIP4. But network_header points to inner ip header. Call Trace: tcp4_gso_segment ------> return NULL inet_gso_segment ------> inner iph, network_header points to ipip_gso_segment inet_gso_segment ------> outer iph skb_mac_gso_segment Afterwards virtio_net transmits the pkt, only inner ip header is modified. And the outer one just keeps unchanged. The pkt will be dropped in remote host. Call Trace: inet_gso_segment ------> inner iph, outer iph is skipped skb_mac_gso_segment __skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit __qdisc_run __dev_queue_xmit ------> virtio_net dev_hard_start_xmit __dev_queue_xmit ------> net_failover ip_finish_output2 ip_output iptunnel_xmit ip_tunnel_xmit ipip_tunnel_xmit ------> ipip dev_hard_start_xmit __dev_queue_xmit ip_finish_output2 ip_output ip_forward ip_rcv __netif_receive_skb_one_core netif_receive_skb_internal napi_gro_receive receive_buf virtnet_poll net_rx_action The root cause of this issue is specific with the rare combination of SKB_GSO_DODGY and a tunnel device that adds an SKB_GSO_ tunnel option. SKB_GSO_DODGY is set from external virtio_net. We need to reset network header when callbacks.gso_segment() returns NULL. This patch also includes ipv6_gso_segment(), considering SIT, etc. Added Reference kernel.org https://git.kernel.org/stable/c/45d006c2c7ed7baf1fa258fa7b5bc9923d3a983e [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/7840e559799a08a8588ee6de27516a991cb2e5e7 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/e9ffbe63f6f32f526a461756309b61c395168d73 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/2b3cdd70ea5f5a694f95ea1788393fb3b83071ea [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/dac2490d9ee0b89dffc72f1172b8bbeb60eaec39 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/899e56a1ad435261812355550ae869d8be3df395 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/a739963f43269297c3f438b776194542e2a97499 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/cc20cced0598d9a5ff91ae4ab147b3b5e99ee819 [No types assigned]
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2022-48936
is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2022-48936
weaknesses.