FKIE_CVE-2025-68768

Vulnerability from fkie_nvd - Published: 2026-01-13 16:15 - Updated: 2026-04-15 00:35
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.
Impacted products
Vendor Product Version

{
  "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\u0027t 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\u0027s 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-\u003edead\nis set, in case packet sneaks in while we\u0027re 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\u00f3n m\u00e1s cercana, el Lector que manten\u00eda 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\u00e9 las pruebas que se ejecutan antes del fallo y not\u00e9 que el fallo sigue a ip_defrag.sh. Una bandera roja inmediata. Revisar a fondo las colas de (des)fragmentaci\u00f3n 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\u00e1 primero. Dado que nf_defrag_ipv6 se carga primero, sus hooks de salida de netns se ejecutan _despu\u00e9s_ 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\u00e9n vaciar las colas en los manejadores de expiraci\u00f3n del temporizador cuando descubren que fqdir-\u0026gt;dead est\u00e1 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\u00eda el conntrack en bucle."
    }
  ],
  "id": "CVE-2025-68768",
  "lastModified": "2026-04-15T00:35:42.020",
  "metrics": {},
  "published": "2026-01-13T16:15:56.247",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/006a5035b495dec008805df249f92c22c89c3d2e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c70df25214ac9b32b53e18e6ae3b8f073ffa6903"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Deferred"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…