{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-04-18T12:06:04.301","vulnerabilities":[{"cve":{"id":"CVE-2025-68768","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2026-01-13T16:15:56.247","lastModified":"2026-04-15T00:35:42.020","vulnStatus":"Deferred","cveTags":[],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\ninet: frags: flush pending skbs in fqdir_pre_exit()\n\nWe have been seeing occasional deadlocks on pernet_ops_rwsem since\nSeptember in NIPA. The stuck task was usually modprobe (often loading\na driver like ipvlan), trying to take the lock as a Writer.\nlockdep does not track readers for rwsems so the read wasn't obvious\nfrom the reports.\n\nOn closer inspection the Reader holding the lock was conntrack looping\nforever in nf_conntrack_cleanup_net_list(). Based on past experience\nwith occasional NIPA crashes I looked thru the tests which run before\nthe crash and noticed that the crash follows ip_defrag.sh. An immediate\nred flag. Scouring thru (de)fragmentation queues reveals skbs sitting\naround, holding conntrack references.\n\nThe problem is that since conntrack depends on nf_defrag_ipv6,\nnf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its\nnetns exit hooks run _after_ conntrack's netns exit hook.\n\nFlush all fragment queue SKBs during fqdir_pre_exit() to release\nconntrack references before conntrack cleanup runs. Also flush\nthe queues in timer expiry handlers when they discover fqdir->dead\nis set, in case packet sneaks in while we're running the pre_exit\nflush.\n\nThe commit under Fixes is not exactly the culprit, but I think\npreviously the timer firing would eventually unblock the spinning\nconntrack."},{"lang":"es","value":"En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\ninet: frags: vaciar skbs pendientes en fqdir_pre_exit()\n\nHemos estado viendo interbloqueos ocasionales en pernet_ops_rwsem desde septiembre en NIPA. La tarea atascada era usualmente modprobe (a menudo cargando un controlador como ipvlan), intentando tomar el bloqueo como un Escritor. lockdep no rastrea lectores para rwsems por lo que la lectura no era obvia de los informes.\n\nEn una inspección más cercana, el Lector que mantenía el bloqueo era conntrack haciendo un bucle para siempre en nf_conntrack_cleanup_net_list(). Basado en la experiencia pasada con fallos ocasionales de NIPA, revisé las pruebas que se ejecutan antes del fallo y noté que el fallo sigue a ip_defrag.sh. Una bandera roja inmediata. Revisar a fondo las colas de (des)fragmentación revela skbs que permanecen, manteniendo referencias de conntrack.\n\nEl problema es que, dado que conntrack depende de nf_defrag_ipv6, nf_defrag_ipv6 se cargará primero. Dado que nf_defrag_ipv6 se carga primero, sus hooks de salida de netns se ejecutan _después_ del hook de salida de netns de conntrack.\n\nVaciar todos los SKBs de la cola de fragmentos durante fqdir_pre_exit() para liberar referencias de conntrack antes de que se ejecute la limpieza de conntrack. También vaciar las colas en los manejadores de expiración del temporizador cuando descubren que fqdir->dead está establecido, en caso de que un paquete se cuele mientras estamos ejecutando el vaciado de pre_exit.\n\nEl commit bajo Fixes no es exactamente el culpable, pero creo que anteriormente el disparo del temporizador eventualmente desbloquearía el conntrack en bucle."}],"metrics":{},"references":[{"url":"https://git.kernel.org/stable/c/006a5035b495dec008805df249f92c22c89c3d2e","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/c70df25214ac9b32b53e18e6ae3b8f073ffa6903","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}]}}]}