fkie_cve-2025-38311
Vulnerability from fkie_nvd
Published
2025-07-10 08:15
Modified
2025-07-10 13:17
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: iavf: get rid of the crit lock Get rid of the crit lock. That frees us from the error prone logic of try_locks. Thanks to netdev_lock() by Jakub it is now easy, and in most cases we were protected by it already - replace crit lock by netdev lock when it was not the case. Lockdep reports that we should cancel the work under crit_lock [splat1], and that was the scheme we have mostly followed since [1] by Slawomir. But when that is done we still got into deadlocks [splat2]. So instead we should look at the bigger problem, namely "weird locking/scheduling" of the iavf. The first step to fix that is to remove the crit lock. I will followup with a -next series that simplifies scheduling/tasks. Cancel the work without netdev lock (weird unlock+lock scheme), to fix the [splat2] (which would be totally ugly if we would kept the crit lock). Extend protected part of iavf_watchdog_task() to include scheduling more work. Note that the removed comment in iavf_reset_task() was misplaced, it belonged to inside of the removed if condition, so it's gone now. [splat1] - w/o this patch - The deadlock during VF removal: WARNING: possible circular locking dependency detected sh/3825 is trying to acquire lock: ((work_completion)(&(&adapter->watchdog_task)->work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470 but task is already holding lock: (&adapter->crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf] which lock already depends on the new lock. [splat2] - when cancelling work under crit lock, w/o this series, see [2] for the band aid attempt WARNING: possible circular locking dependency detected sh/3550 is trying to acquire lock: ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 but task is already holding lock: (&dev->lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf] which lock already depends on the new lock. [1] fc2e6b3b132a ("iavf: Rework mutexes for better synchronisation") [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/120f28a6f314fef7f282c99f196923fe44081cad
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/620ab4d6215de0b25227f9fff1a8c7fb66837cb8
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: get rid of the crit lock\n\nGet rid of the crit lock.\nThat frees us from the error prone logic of try_locks.\n\nThanks to netdev_lock() by Jakub it is now easy, and in most cases we were\nprotected by it already - replace crit lock by netdev lock when it was not\nthe case.\n\nLockdep reports that we should cancel the work under crit_lock [splat1],\nand that was the scheme we have mostly followed since [1] by Slawomir.\nBut when that is done we still got into deadlocks [splat2]. So instead\nwe should look at the bigger problem, namely \"weird locking/scheduling\"\nof the iavf. The first step to fix that is to remove the crit lock.\nI will followup with a -next series that simplifies scheduling/tasks.\n\nCancel the work without netdev lock (weird unlock+lock scheme),\nto fix the [splat2] (which would be totally ugly if we would kept\nthe crit lock).\n\nExtend protected part of iavf_watchdog_task() to include scheduling\nmore work.\n\nNote that the removed comment in iavf_reset_task() was misplaced,\nit belonged to inside of the removed if condition, so it\u0027s gone now.\n\n[splat1] - w/o this patch - The deadlock during VF removal:\n     WARNING: possible circular locking dependency detected\n     sh/3825 is trying to acquire lock:\n      ((work_completion)(\u0026(\u0026adapter-\u003ewatchdog_task)-\u003ework)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470\n          but task is already holding lock:\n      (\u0026adapter-\u003ecrit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf]\n          which lock already depends on the new lock.\n\n[splat2] - when cancelling work under crit lock, w/o this series,\n\t   see [2] for the band aid attempt\n    WARNING: possible circular locking dependency detected\n    sh/3550 is trying to acquire lock:\n    ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90\n        but task is already holding lock:\n    (\u0026dev-\u003elock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf]\n        which lock already depends on the new lock.\n\n[1] fc2e6b3b132a (\"iavf: Rework mutexes for better synchronisation\")\n[2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iavf: eliminar el bloqueo cr\u00edtico. Eliminar el bloqueo cr\u00edtico. Esto nos libera de la l\u00f3gica propensa a errores de try_locks. Gracias a netdev_lock() de Jakub, ahora es f\u00e1cil, y en la mayor\u00eda de los casos ya est\u00e1bamos protegidos por \u00e9l: reemplazar el bloqueo cr\u00edtico por el bloqueo netdev cuando no era el caso. Lockdep informa que debemos cancelar el trabajo bajo crit_lock [splat1], y ese fue el esquema que hemos seguido principalmente desde [1] de Slawomir. Pero una vez hecho esto, seguimos teniendo interbloqueos [splat2]. As\u00ed que, en lugar de eso, deber\u00edamos analizar el problema m\u00e1s grave, es decir, el \"bloqueo/programaci\u00f3n extra\u00f1o\" de iavf. El primer paso para solucionarlo es eliminar el bloqueo cr\u00edtico. Seguir\u00e9 con una serie de -next que simplifica la programaci\u00f3n/tareas. Cancelar el trabajo sin el bloqueo de netdev (un esquema extra\u00f1o de desbloqueo y bloqueo) para corregir el [splat2] (que ser\u00eda un desastre si hubi\u00e9ramos mantenido el bloqueo cr\u00edtico). Extender la parte protegida de iavf_watchdog_task() para incluir la programaci\u00f3n de m\u00e1s trabajo. Tenga en cuenta que el comentario eliminado en iavf_reset_task() estaba mal ubicado; pertenec\u00eda a la condici\u00f3n if eliminada, por lo que ya no est\u00e1. [splat1] - sin este parche - El bloqueo durante la eliminaci\u00f3n de VF: ADVERTENCIA: se detect\u00f3 una posible dependencia de bloqueo circular sh/3825 est\u00e1 intentando adquirir el bloqueo: ((work_completion)(\u0026amp;(\u0026amp;adapter-\u0026gt;watchdog_task)-\u0026gt;work)){+.+.}-{0:0}, en: start_flush_work+0x1a1/0x470 pero la tarea ya tiene el bloqueo: (\u0026amp;adapter-\u0026gt;crit_lock){+.+.}-{4:4}, en: iavf_remove+0xd1/0x690 [iavf] cuyo bloqueo ya depende del nuevo bloqueo. [splat2] - al cancelar trabajo bajo bloqueo cr\u00edtico, sin esta serie, vea [2] para el intento de curita ADVERTENCIA: posible dependencia de bloqueo circular detectada sh/3550 est\u00e1 intentando adquirir el bloqueo: ((wq_completion)iavf){+.+.}-{0:0}, en: touch_wq_lockdep_map+0x26/0x90 pero la tarea ya tiene el bloqueo: (\u0026amp;dev-\u0026gt;lock){+.+.}-{4:4}, en: iavf_remove+0xa6/0x6e0 [iavf] cuyo bloqueo ya depende del nuevo bloqueo. [1] fc2e6b3b132a (\"iavf: Rehacer mutexes para mejor sincronizaci\u00f3n\") [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a"
    }
  ],
  "id": "CVE-2025-38311",
  "lastModified": "2025-07-10T13:17:30.017",
  "metrics": {},
  "published": "2025-07-10T08:15:30.010",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/120f28a6f314fef7f282c99f196923fe44081cad"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/620ab4d6215de0b25227f9fff1a8c7fb66837cb8"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • 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.