fkie_cve-2024-56641
Vulnerability from fkie_nvd
Published
2024-12-27 15:15
Modified
2024-12-27 15:15
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: net/smc: initialize close_work early to avoid warning We encountered a warning that close_work was canceled before initialization. WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: events smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Call Trace: ? __wake_up_common+0x7a/0x190 ? work_busy+0x80/0x80 __cancel_work_timer+0xe3/0x160 smc_close_cancel_work+0x1a/0x70 [smc] smc_close_active_abort+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] process_one_work+0x19e/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30 This is because when smc_close_cancel_work is triggered, e.g. the RDMA driver is rmmod and the LGR is terminated, the conn->close_work is flushed before initialization, resulting in WARN_ON(!work->func). __smc_lgr_terminate | smc_connect_{rdma|ism} ------------------------------------------------------------- | smc_conn_create | \- smc_lgr_register_conn for conn in lgr->conns_all | \- smc_conn_kill | \- smc_close_active_abort | \- smc_close_cancel_work | \- cancel_work_sync | \- __flush_work | (close_work) | | smc_close_init | \- INIT_WORK(&close_work) So fix this by initializing close_work before establishing the connection.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/0541db8ee32c09463a72d0987382b3a3336b0043
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/6638e52dcfafaf1b9cbc34544f0c832db0069ea1
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/f0c37002210aaede10dae849d1a78efc2243add2
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: initialize close_work early to avoid warning\n\nWe encountered a warning that close_work was canceled before\ninitialization.\n\n  WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0\n  Workqueue: events smc_lgr_terminate_work [smc]\n  RIP: 0010:__flush_work+0x19e/0x1b0\n  Call Trace:\n   ? __wake_up_common+0x7a/0x190\n   ? work_busy+0x80/0x80\n   __cancel_work_timer+0xe3/0x160\n   smc_close_cancel_work+0x1a/0x70 [smc]\n   smc_close_active_abort+0x207/0x360 [smc]\n   __smc_lgr_terminate.part.38+0xc8/0x180 [smc]\n   process_one_work+0x19e/0x340\n   worker_thread+0x30/0x370\n   ? process_one_work+0x340/0x340\n   kthread+0x117/0x130\n   ? __kthread_cancel_work+0x50/0x50\n   ret_from_fork+0x22/0x30\n\nThis is because when smc_close_cancel_work is triggered, e.g. the RDMA\ndriver is rmmod and the LGR is terminated, the conn-\u003eclose_work is\nflushed before initialization, resulting in WARN_ON(!work-\u003efunc).\n\n__smc_lgr_terminate             | smc_connect_{rdma|ism}\n-------------------------------------------------------------\n                                | smc_conn_create\n\t\t\t\t| \\- smc_lgr_register_conn\nfor conn in lgr-\u003econns_all      |\n\\- smc_conn_kill                |\n   \\- smc_close_active_abort    |\n      \\- smc_close_cancel_work  |\n         \\- cancel_work_sync    |\n            \\- __flush_work     |\n\t         (close_work)   |\n\t                        | smc_close_init\n\t                        | \\- INIT_WORK(\u0026close_work)\n\nSo fix this by initializing close_work before establishing the\nconnection."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: inicializar close_work antes para evitar advertencias Encontramos una advertencia que indicaba que close_work se cancel\u00f3 antes de la inicializaci\u00f3n. ADVERTENCIA: CPU: 7 PID: 111103 en kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: eventos smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Rastreo de llamadas: ? __wake_up_common+0x7a/0x190 ? trabajo_ocupado+0x80/0x80 __cancelar_temporizador_trabajo+0xe3/0x160 smc_cerrar_cancelar_trabajo+0x1a/0x70 [smc] smc_cerrar_aborto_activo+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] proceso_uno_trabajo+0x19e/0x340 subproceso_trabajador+0x30/0x370 ? proceso_uno_trabajo+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30 Esto se debe a que cuando se activa smc_close_cancel_work, p. ej., el controlador RDMA es rmmod y se termina el LGR, conn-\u0026gt;close_work se vac\u00eda antes de la inicializaci\u00f3n, lo que genera WARN_ON(!work-\u0026gt;func). __smc_lgr_terminate | smc_connect_{rdma|ism} ------------------------------------------------------------- | smc_conn_create | \\- smc_lgr_register_conn para conn en lgr-\u0026gt;conns_all | \\- smc_conn_kill | \\- smc_close_active_abort | \\- smc_close_cancel_work | \\- cancel_work_sync | \\- __flush_work | (close_work) | | smc_close_init | \\- INIT_WORK(\u0026amp;close_work) Solucione esto inicializando close_work antes de establecer la conexi\u00f3n."
    }
  ],
  "id": "CVE-2024-56641",
  "lastModified": "2024-12-27T15:15:23.830",
  "metrics": {},
  "published": "2024-12-27T15:15:23.830",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/0541db8ee32c09463a72d0987382b3a3336b0043"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/6638e52dcfafaf1b9cbc34544f0c832db0069ea1"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f0c37002210aaede10dae849d1a78efc2243add2"
    }
  ],
  "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.