CVE-2026-98644
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
bpf: Evitar soft lockup en __htab_map_lookup_and_delete_batch()
__htab_map_lookup_and_delete_batch() no tiene ningún punto de reprogramación. El recuento del lote limita cuántas entradas se copian, no cuántos buckets se visitan, por lo que una única llamada a BPF_MAP_LOOKUP_BATCH puede recorrer el mapa de principio a fin. La ruta rápida para buckets vacíos es todavía peor: permanece dentro de una única sección rcu_read_lock() / bpf_disable_instrumentation() para cualquier secuencia de buckets vacíos consecutivos.
Esto se sostiene en mapas pequeños, pero falla a gran escala. En un host arm64 de 144 CPU que ejecuta un kernel CONFIG_PREEMPT_NONE, llamadas periódicas a BPF_MAP_LOOKUP_BATCH contra un mapa hash LRU con 16.777.216 buckets mantuvieron una CPU dentro de la operación de lote durante más de 77 segundos y activaron el watchdog de soft lockup.
Leer descripción completaMostrar menos
El commit 75134f16e7dd ("bpf: Add schedule points in batch ops") corrigió este mismo problema en las operaciones de lote genéricas, pero no en esta ruta nativa de htab, que usan todas las variantes de mapas hash basadas en htab para sus operaciones de lookup[_and_delete] por lotes.
Completar aquí esa corrección. Abandonar la sección crítica tras 64 buckets vacíos consecutivos, llamar a cond_resched_tasks_rcu_qs() y reanudar en el cursor de bucket guardado. En ese punto no se mantiene ningún bloqueo, y reanudar desde el cursor ya es el comportamiento de la función para buckets no vacíos. Añadir la misma llamada al bucle por bucket tras copy_to_user(), donde ya se han liberado todos los bloqueos. cond_resched_rcu() no basta aquí: dormir con bpf_prog_active elevado hace que los programas de trazado de esa CPU omitan silenciosamente sus invocaciones.
cond_resched() tampoco basta. No tiene efecto en los modos PREEMPT y PREEMPT_LAZY, los únicos que arm64 y x86 han ofrecido desde el commit 7dadeaa6e851 ("sched: Further restrict the preemption modes"). Además, nunca constituye un estado de quiescencia de Tasks RCU, en ningún modo: la reprogramación cuenta como una expropiación. La tarea en ejecución sigue siendo un holdout y bloquea a todos los llamadores de synchronize_rcu_tasks(), incluida la desmontaje de trampolines de ftrace y BPF, hasta que la llamada al sistema retorna [1]. cond_resched_tasks_rcu_qs() es la herramienta habitual para ello [2]. Informa del estado de quiescencia en cada cesión y, como cond_resched() en kernels PREEMPT_NONE y PREEMPT_VOLUNTARY, sigue reprogramando la tarea.
Traducción automática del texto original de NVD (en inglés).
CVSS
NVD no ha asignado puntuación CVSS a esta CVE (habitual desde el cambio de política de abril de 2026).
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días
- 0.21 %
- Percentil entre todas las CVEs puntuadas
- 10
- Fecha de la puntuación
- 20/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
Tecnologías afectadas (1)
⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.
Referencias
Mostrar las 7 referencias
- https://git.kernel.org/stable/c/44f9bcb5ab2b268bc763ed3ebec83308b4972936
- https://git.kernel.org/stable/c/4e48fe9b1c77966bede0a73feb3059d7595f642d
- https://git.kernel.org/stable/c/5c8b1869cb99a32a962388848cd19604fb41263e
- https://git.kernel.org/stable/c/77a3b52b4455e6377e549539e757bc55eedefb51
- https://git.kernel.org/stable/c/85136bf22404474a815fc0ed26ec0d1cbc1bc3f9
- https://git.kernel.org/stable/c/ca5bd55fc508fbb5c08c62206d02237a5b6fc7e8
- https://git.kernel.org/stable/c/f0c09de08ec077098b7e1563f2285f1c136cd816
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-98644",
"cveTags": [],
"metrics": {},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "057996380a42bb64ccc04383cfa9c0ace4ea11f0",
"lessThan": "5c8b1869cb99a32a962388848cd19604fb41263e",
"versionType": "git"
},
{
"status": "affected",
"version": "057996380a42bb64ccc04383cfa9c0ace4ea11f0",
"lessThan": "ca5bd55fc508fbb5c08c62206d02237a5b6fc7e8",
"versionType": "git"
},
{
"status": "affected",
"version": "057996380a42bb64ccc04383cfa9c0ace4ea11f0",
"lessThan": "77a3b52b4455e6377e549539e757bc55eedefb51",
"versionType": "git"
},
{
"status": "affected",
"version": "057996380a42bb64ccc04383cfa9c0ace4ea11f0",
"lessThan": "f0c09de08ec077098b7e1563f2285f1c136cd816",
"versionType": "git"
},
{
"status": "affected",
"version": "057996380a42bb64ccc04383cfa9c0ace4ea11f0",
"lessThan": "44f9bcb5ab2b268bc763ed3ebec83308b4972936",
"versionType": "git"
},
{
"status": "affected",
"version": "057996380a42bb64ccc04383cfa9c0ace4ea11f0",
"lessThan": "4e48fe9b1c77966bede0a73feb3059d7595f642d",
"versionType": "git"
},
{
"status": "affected",
"version": "057996380a42bb64ccc04383cfa9c0ace4ea11f0",
"lessThan": "85136bf22404474a815fc0ed26ec0d1cbc1bc3f9",
"versionType": "git"
}
],
"programFiles": [
"kernel/bpf/hashtab.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "5.6"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "5.6",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "5.15.222",
"versionType": "semver",
"lessThanOrEqual": "5.15.*"
},
{
"status": "unaffected",
"version": "6.1.189",
"versionType": "semver",
"lessThanOrEqual": "6.1.*"
},
{
"status": "unaffected",
"version": "6.6.158",
"versionType": "semver",
"lessThanOrEqual": "6.6.*"
},
{
"status": "unaffected",
"version": "6.12.112",
"versionType": "semver",
"lessThanOrEqual": "6.12.*"
},
{
"status": "unaffected",
"version": "6.18.55",
"versionType": "semver",
"lessThanOrEqual": "6.18.*"
},
{
"status": "unaffected",
"version": "7.2.9",
"versionType": "semver",
"lessThanOrEqual": "7.2.*"
},
{
"status": "unaffected",
"version": "7.3",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"kernel/bpf/hashtab.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-10-18T16:17:17.623",
"references": [
{
"url": "https://git.kernel.org/stable/c/44f9bcb5ab2b268bc763ed3ebec83308b4972936",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/4e48fe9b1c77966bede0a73feb3059d7595f642d",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/5c8b1869cb99a32a962388848cd19604fb41263e",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/77a3b52b4455e6377e549539e757bc55eedefb51",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/85136bf22404474a815fc0ed26ec0d1cbc1bc3f9",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/ca5bd55fc508fbb5c08c62206d02237a5b6fc7e8",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/f0c09de08ec077098b7e1563f2285f1c136cd816",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch()\n\n__htab_map_lookup_and_delete_batch() has no rescheduling point. The\nbatch count bounds how many entries are copied out, not how many\nbuckets are visited, so one BPF_MAP_LOOKUP_BATCH call can walk the\nmap end to end. The empty-bucket fast path is worse: it stays inside\na single rcu_read_lock() / bpf_disable_instrumentation() section for\nany run of consecutive empty buckets.\n\nThat holds up on small maps, but it falls apart at scale. On a\n144-CPU arm64 host running a CONFIG_PREEMPT_NONE kernel, periodic\nBPF_MAP_LOOKUP_BATCH calls against an LRU hash map with 16,777,216\nbuckets held a CPU inside the batch op for 77+ seconds and triggered\nthe soft lockup watchdog.\n\nCommit 75134f16e7dd (\"bpf: Add schedule points in batch ops\") fixed this\nsame problem in the generic batch ops, but not in this htab-native path,\nwhich every htab-based hash map variant uses for its lookup[_and_delete]\nbatch ops.\n\nComplete that fix here. Leave the critical section after 64 consecutive\nempty buckets, call cond_resched_tasks_rcu_qs(), and resume at the saved\nbucket cursor. No locks are held at that point, and resuming from the\ncursor is already the function's behavior for non-empty buckets. Add the\nsame call to the per-bucket loop after copy_to_user(), where every lock\nhas been dropped. cond_resched_rcu() is not enough here: sleeping with\nbpf_prog_active elevated makes tracing programs on that CPU silently\nskip their invocations.\n\nPlain cond_resched() is not enough either. It is a no-op under PREEMPT\nand PREEMPT_LAZY, the only models arm64 and x86 have offered since\ncommit 7dadeaa6e851 (\"sched: Further restrict the preemption modes\").\nIt is also never a Tasks RCU quiescent state, in any model: the\nreschedule counts as a preemption. The walking task stays a holdout and\nstalls every synchronize_rcu_tasks() caller, ftrace and BPF trampoline\nteardown included, until the syscall returns [1].\ncond_resched_tasks_rcu_qs() is the usual tool for that [2]. It reports\nthe quiescent state at each yield and still reschedules as\ncond_resched() does on PREEMPT_NONE and PREEMPT_VOLUNTARY kernels."
}
],
"lastModified": "2026-10-19T10:19:28.723",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}