CVE-2024-35884

{"id": "CVE-2024-35884", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}, {"type": "Secondary", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 8.8, "attackVector": "NETWORK", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 5.9, "exploitabilityScore": 2.8}]}, "published": "2024-05-19T09:15:09.603", "references": [{"url": "https://git.kernel.org/stable/c/3001e7aa43d6691db2a878b0745b854bf12ddd19", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/3391b157780bbedf8ef9f202cbf10ee90bf6b0f8", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/35fe0e0b5c00bef7dde74842a2564c43856fbce4", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/3d010c8031e39f5fa1e8b13ada77e0321091011f", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/d12245080cb259d82b34699f6cd4ec11bdb688bd", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/d49ae15a5767d4e9ef8bbb79e42df1bfebc94670", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/3001e7aa43d6691db2a878b0745b854bf12ddd19", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/3391b157780bbedf8ef9f202cbf10ee90bf6b0f8", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/35fe0e0b5c00bef7dde74842a2564c43856fbce4", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/3d010c8031e39f5fa1e8b13ada77e0321091011f", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/d12245080cb259d82b34699f6cd4ec11bdb688bd", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/d49ae15a5767d4e9ef8bbb79e42df1bfebc94670", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html", "tags": ["Third Party Advisory"], "source": "af854a3a-2127-422b-91ae-364da2661108"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-617"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nudp: do not accept non-tunnel GSO skbs landing in a tunnel\n\nWhen rx-udp-gro-forwarding is enabled UDP packets might be GROed when\nbeing forwarded. If such packets might land in a tunnel this can cause\nvarious issues and udp_gro_receive makes sure this isn't the case by\nlooking for a matching socket. This is performed in\nudp4/6_gro_lookup_skb but only in the current netns. This is an issue\nwith tunneled packets when the endpoint is in another netns. In such\ncases the packets will be GROed at the UDP level, which leads to various\nissues later on. The same thing can happen with rx-gro-list.\n\nWe saw this with geneve packets being GROed at the UDP level. In such\ncase gso_size is set; later the packet goes through the geneve rx path,\nthe geneve header is pulled, the offset are adjusted and frag_list skbs\nare not adjusted with regard to geneve. When those skbs hit\nskb_fragment, it will misbehave. Different outcomes are possible\ndepending on what the GROed skbs look like; from corrupted packets to\nkernel crashes.\n\nOne example is a BUG_ON[1] triggered in skb_segment while processing the\nfrag_list. Because gso_size is wrong (geneve header was pulled)\nskb_segment thinks there is \"geneve header size\" of data in frag_list,\nalthough it's in fact the next packet. The BUG_ON itself has nothing to\ndo with the issue. This is only one of the potential issues.\n\nLooking up for a matching socket in udp_gro_receive is fragile: the\nlookup could be extended to all netns (not speaking about performances)\nbut nothing prevents those packets from being modified in between and we\ncould still not find a matching socket. It's OK to keep the current\nlogic there as it should cover most cases but we also need to make sure\nwe handle tunnel packets being GROed too early.\n\nThis is done by extending the checks in udp_unexpected_gso: GSO packets\nlacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must\nbe segmented.\n\n[1] kernel BUG at net/core/skbuff.c:4408!\n RIP: 0010:skb_segment+0xd2a/0xf70\n __udp_gso_segment+0xaa/0x560"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: no acepte skbs GSO que no sean de t\u00fanel que aterricen en un t\u00fanel Cuando rx-udp-gro-forwarding est\u00e1 habilitado, los paquetes UDP pueden recibir GRO al reenviarse. Si dichos paquetes pudieran aterrizar en un t\u00fanel, esto puede causar varios problemas y udp_gro_receive se asegura de que este no sea el caso buscando un socket coincidente. Esto se realiza en udp4/6_gro_lookup_skb pero s\u00f3lo en las redes actuales. Este es un problema con los paquetes tunelizados cuando el punto final est\u00e1 en otra red. En tales casos, los paquetes se almacenar\u00e1n en el nivel UDP, lo que generar\u00e1 varios problemas m\u00e1s adelante. Lo mismo puede pasar con rx-gro-list. Vimos esto con paquetes geneve siendo GRO en el nivel UDP. En tal caso, se establece gso_size; luego, el paquete pasa por la ruta geneve rx, se extrae el encabezado geneve, se ajusta el desplazamiento y los skbs frag_list no se ajustan con respecto a geneve. Cuando esos skbs lleguen a skb_fragment, se comportar\u00e1 mal. Son posibles diferentes resultados dependiendo del aspecto de los skbs GROed; desde paquetes corruptos hasta fallas del kernel. Un ejemplo es un BUG_ON[1] activado en skb_segment mientras se procesa frag_list. Debido a que gso_size es incorrecto (se extrajo el encabezado geneve), skb_segment cree que hay un \"tama\u00f1o de encabezado geneve\" de datos en frag_list, aunque en realidad es el siguiente paquete. El BUG_ON en s\u00ed no tiene nada que ver con el problema. \u00c9ste es s\u00f3lo uno de los posibles problemas. Buscar un socket coincidente en udp_gro_receive es fr\u00e1gil: la b\u00fasqueda podr\u00eda extenderse a todas las redes (sin hablar de rendimiento), pero nada impide que esos paquetes se modifiquen en el medio y todav\u00eda no pudimos encontrar un socket coincidente. Est\u00e1 bien mantener la l\u00f3gica actual all\u00ed, ya que deber\u00eda cubrir la mayor\u00eda de los casos, pero tambi\u00e9n debemos asegurarnos de manejar los paquetes de t\u00fanel que se procesan en GRO demasiado pronto. Esto se hace ampliando las comprobaciones en udp_unexpected_gso: los paquetes OSG que carecen de los bits SKB_GSO_UDP_TUNNEL/_CSUM y que aterrizan en un t\u00fanel deben segmentarse. [1] \u00a1BUG del kernel en net/core/skbuff.c:4408! RIP: 0010:skb_segment+0xd2a/0xf70 __udp_gso_segment+0xaa/0x560"}], "lastModified": "2025-12-23T19:28:50.830", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "AA5E7B02-005F-4B5E-AFCA-13D2AE4EF328", "versionEndExcluding": "5.10.215", "versionStartIncluding": "5.6"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "577E212E-7E95-4A71-9B5C-F1D1A3AFFF46", "versionEndExcluding": "5.15.154", "versionStartIncluding": "5.11"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "325665BF-2409-49D9-B391-39AD4566FDBD", "versionEndExcluding": "6.1.85", "versionStartIncluding": "5.16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "C520696A-A594-4FFC-A32D-12DA535CE911", "versionEndExcluding": "6.6.26", "versionStartIncluding": "6.2"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "DBD6C99E-4250-4DFE-8447-FF2075939D10", "versionEndExcluding": "6.8.5", "versionStartIncluding": "6.7"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc1:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "22BEDD49-2C6D-402D-9DBF-6646F6ECD10B"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc2:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "DF73CB2A-DFFD-46FB-9BFE-AA394F27EA37"}], "operator": "OR"}]}, {"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "07B237A9-69A3-4A9C-9DA0-4E06BD37AE73"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}