gsd-2024-26924
Vulnerability from gsd
Modified
2024-02-20 06:02
Details
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: do not free live element
Pablo reports a crash with large batches of elements with a
back-to-back add/remove pattern. Quoting Pablo:
add_elem("00000000") timeout 100 ms
...
add_elem("0000000X") timeout 100 ms
del_elem("0000000X") <---------------- delete one that was just added
...
add_elem("00005000") timeout 100 ms
1) nft_pipapo_remove() removes element 0000000X
Then, KASAN shows a splat.
Looking at the remove function there is a chance that we will drop a
rule that maps to a non-deactivated element.
Removal happens in two steps, first we do a lookup for key k and return the
to-be-removed element and mark it as inactive in the next generation.
Then, in a second step, the element gets removed from the set/map.
The _remove function does not work correctly if we have more than one
element that share the same key.
This can happen if we insert an element into a set when the set already
holds an element with same key, but the element mapping to the existing
key has timed out or is not active in the next generation.
In such case its possible that removal will unmap the wrong element.
If this happens, we will leak the non-deactivated element, it becomes
unreachable.
The element that got deactivated (and will be freed later) will
remain reachable in the set data structure, this can result in
a crash when such an element is retrieved during lookup (stale
pointer).
Add a check that the fully matching key does in fact map to the element
that we have marked as inactive in the deactivation step.
If not, we need to continue searching.
Add a bug/warn trap at the end of the function as well, the remove
function must not ever be called with an invisible/unreachable/non-existent
element.
v2: avoid uneeded temporary variable (Stefano)
Aliases
{
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2024-26924"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: do not free live element\n\nPablo reports a crash with large batches of elements with a\nback-to-back add/remove pattern. Quoting Pablo:\n\n add_elem(\"00000000\") timeout 100 ms\n ...\n add_elem(\"0000000X\") timeout 100 ms\n del_elem(\"0000000X\") \u003c---------------- delete one that was just added\n ...\n add_elem(\"00005000\") timeout 100 ms\n\n 1) nft_pipapo_remove() removes element 0000000X\n Then, KASAN shows a splat.\n\nLooking at the remove function there is a chance that we will drop a\nrule that maps to a non-deactivated element.\n\nRemoval happens in two steps, first we do a lookup for key k and return the\nto-be-removed element and mark it as inactive in the next generation.\nThen, in a second step, the element gets removed from the set/map.\n\nThe _remove function does not work correctly if we have more than one\nelement that share the same key.\n\nThis can happen if we insert an element into a set when the set already\nholds an element with same key, but the element mapping to the existing\nkey has timed out or is not active in the next generation.\n\nIn such case its possible that removal will unmap the wrong element.\nIf this happens, we will leak the non-deactivated element, it becomes\nunreachable.\n\nThe element that got deactivated (and will be freed later) will\nremain reachable in the set data structure, this can result in\na crash when such an element is retrieved during lookup (stale\npointer).\n\nAdd a check that the fully matching key does in fact map to the element\nthat we have marked as inactive in the deactivation step.\nIf not, we need to continue searching.\n\nAdd a bug/warn trap at the end of the function as well, the remove\nfunction must not ever be called with an invisible/unreachable/non-existent\nelement.\n\nv2: avoid uneeded temporary variable (Stefano)",
"id": "GSD-2024-26924",
"modified": "2024-02-20T06:02:29.075815Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@kernel.org",
"ID": "CVE-2024-26924",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Linux",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_name": "3c4287f62044",
"version_value": "7a1679e2d9bf"
},
{
"version_value": "not down converted",
"x_cve_json_5_version_data": {
"defaultStatus": "affected",
"versions": [
{
"status": "affected",
"version": "5.6"
},
{
"lessThan": "5.6",
"status": "unaffected",
"version": "0",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.157",
"versionType": "custom"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.88",
"versionType": "custom"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.29",
"versionType": "custom"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.8",
"versionType": "custom"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9-rc5",
"versionType": "original_commit_for_fix"
}
]
}
}
]
}
}
]
},
"vendor_name": "Linux"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: do not free live element\n\nPablo reports a crash with large batches of elements with a\nback-to-back add/remove pattern. Quoting Pablo:\n\n add_elem(\"00000000\") timeout 100 ms\n ...\n add_elem(\"0000000X\") timeout 100 ms\n del_elem(\"0000000X\") \u003c---------------- delete one that was just added\n ...\n add_elem(\"00005000\") timeout 100 ms\n\n 1) nft_pipapo_remove() removes element 0000000X\n Then, KASAN shows a splat.\n\nLooking at the remove function there is a chance that we will drop a\nrule that maps to a non-deactivated element.\n\nRemoval happens in two steps, first we do a lookup for key k and return the\nto-be-removed element and mark it as inactive in the next generation.\nThen, in a second step, the element gets removed from the set/map.\n\nThe _remove function does not work correctly if we have more than one\nelement that share the same key.\n\nThis can happen if we insert an element into a set when the set already\nholds an element with same key, but the element mapping to the existing\nkey has timed out or is not active in the next generation.\n\nIn such case its possible that removal will unmap the wrong element.\nIf this happens, we will leak the non-deactivated element, it becomes\nunreachable.\n\nThe element that got deactivated (and will be freed later) will\nremain reachable in the set data structure, this can result in\na crash when such an element is retrieved during lookup (stale\npointer).\n\nAdd a check that the fully matching key does in fact map to the element\nthat we have marked as inactive in the deactivation step.\nIf not, we need to continue searching.\n\nAdd a bug/warn trap at the end of the function as well, the remove\nfunction must not ever be called with an invisible/unreachable/non-existent\nelement.\n\nv2: avoid uneeded temporary variable (Stefano)"
}
]
},
"generator": {
"engine": "bippy-d175d3acf727"
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "n/a"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://git.kernel.org/stable/c/7a1679e2d9bfa3b5f8755c2c7113e54b7d42bd46",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/7a1679e2d9bfa3b5f8755c2c7113e54b7d42bd46"
},
{
"name": "https://git.kernel.org/stable/c/41d8fdf3afaff312e17466e4ab732937738d5644",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/41d8fdf3afaff312e17466e4ab732937738d5644"
},
{
"name": "https://git.kernel.org/stable/c/ebf7c9746f073035ee26209e38c3a1170f7b349a",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/ebf7c9746f073035ee26209e38c3a1170f7b349a"
},
{
"name": "https://git.kernel.org/stable/c/14b001ba221136c15f894577253e8db535b99487",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/14b001ba221136c15f894577253e8db535b99487"
},
{
"name": "https://git.kernel.org/stable/c/3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc"
}
]
}
},
"nvd.nist.gov": {
"cve": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: do not free live element\n\nPablo reports a crash with large batches of elements with a\nback-to-back add/remove pattern. Quoting Pablo:\n\n add_elem(\"00000000\") timeout 100 ms\n ...\n add_elem(\"0000000X\") timeout 100 ms\n del_elem(\"0000000X\") \u003c---------------- delete one that was just added\n ...\n add_elem(\"00005000\") timeout 100 ms\n\n 1) nft_pipapo_remove() removes element 0000000X\n Then, KASAN shows a splat.\n\nLooking at the remove function there is a chance that we will drop a\nrule that maps to a non-deactivated element.\n\nRemoval happens in two steps, first we do a lookup for key k and return the\nto-be-removed element and mark it as inactive in the next generation.\nThen, in a second step, the element gets removed from the set/map.\n\nThe _remove function does not work correctly if we have more than one\nelement that share the same key.\n\nThis can happen if we insert an element into a set when the set already\nholds an element with same key, but the element mapping to the existing\nkey has timed out or is not active in the next generation.\n\nIn such case its possible that removal will unmap the wrong element.\nIf this happens, we will leak the non-deactivated element, it becomes\nunreachable.\n\nThe element that got deactivated (and will be freed later) will\nremain reachable in the set data structure, this can result in\na crash when such an element is retrieved during lookup (stale\npointer).\n\nAdd a check that the fully matching key does in fact map to the element\nthat we have marked as inactive in the deactivation step.\nIf not, we need to continue searching.\n\nAdd a bug/warn trap at the end of the function as well, the remove\nfunction must not ever be called with an invisible/unreachable/non-existent\nelement.\n\nv2: avoid uneeded temporary variable (Stefano)"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_set_pipapo: no liberar elemento activo Pablo informa un bloqueo con grandes lotes de elementos con un patr\u00f3n de agregar/eliminar consecutivos. Citando a Pablo: add_elem(\"00000000\") timeout 100 ms ... add_elem(\"0000000X\") timeout 100 ms del_elem(\"0000000X\") \u0026lt;---------------- elimina uno que se acaba de agregar... add_elem(\"00005000\") tiempo de espera 100 ms 1) nft_pipapo_remove() elimina el elemento 0000000X Luego, KASAN muestra un s\u00edmbolo. Al observar la funci\u00f3n de eliminaci\u00f3n, existe la posibilidad de que eliminemos una regla que se asigne a un elemento no desactivado. La eliminaci\u00f3n se realiza en dos pasos: primero buscamos la clave k, devolvemos el elemento que se va a eliminar y lo marcamos como inactivo en la pr\u00f3xima generaci\u00f3n. Luego, en un segundo paso, el elemento se elimina del conjunto/mapa. La funci\u00f3n _remove no funciona correctamente si tenemos m\u00e1s de un elemento que comparte la misma clave. Esto puede suceder si insertamos un elemento en un conjunto cuando el conjunto ya contiene un elemento con la misma clave, pero la asignaci\u00f3n del elemento a la clave existente ha expirado o no est\u00e1 activa en la pr\u00f3xima generaci\u00f3n. En tal caso, es posible que la eliminaci\u00f3n desasigne el elemento incorrecto. Si esto sucede, filtraremos el elemento no desactivado, se vuelve inalcanzable. El elemento que se desactiv\u00f3 (y se liberar\u00e1 m\u00e1s adelante) permanecer\u00e1 accesible en la estructura de datos establecida, lo que puede provocar un bloqueo cuando dicho elemento se recupere durante la b\u00fasqueda (puntero obsoleto). Agregue una verificaci\u00f3n de que la clave que coincide completamente de hecho se asigna al elemento que hemos marcado como inactivo en el paso de desactivaci\u00f3n. Si no, debemos seguir buscando. Agregue tambi\u00e9n una trampa de error/advertencia al final de la funci\u00f3n; la funci\u00f3n de eliminaci\u00f3n nunca debe llamarse con un elemento invisible/inalcanzable/inexistente. v2: evitar variables temporales innecesarias (Stefano)"
}
],
"id": "CVE-2024-26924",
"lastModified": "2024-04-28T12:15:20.957",
"metrics": {},
"published": "2024-04-25T06:15:57.407",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/14b001ba221136c15f894577253e8db535b99487"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/41d8fdf3afaff312e17466e4ab732937738d5644"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/7a1679e2d9bfa3b5f8755c2c7113e54b7d42bd46"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ebf7c9746f073035ee26209e38c3a1170f7b349a"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
}
}
}
Loading...
Loading...
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.