cve-2024-36003
Vulnerability from cvelistv5
Published
2024-05-20 09:48
Modified
2024-12-19 09:00
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: ice: fix LAG and VF lock dependency in ice_reset_vf() 9f74a3dfcf83 ("ice: Fix VF Reset paths when interface in a failed over aggregate"), the ice driver has acquired the LAG mutex in ice_reset_vf(). The commit placed this lock acquisition just prior to the acquisition of the VF configuration lock. If ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK flag, this could deadlock with ice_vc_cfg_qs_msg() because it always acquires the locks in the order of the VF configuration lock and then the LAG mutex. Lockdep reports this violation almost immediately on creating and then removing 2 VF: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-rc6 #54 Tainted: G W O ------------------------------------------------------ kworker/60:3/6771 is trying to acquire lock: ff40d43e099380a0 (&vf->cfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice] but task is already holding lock: ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&pf->lag_mutex){+.+.}-{3:3}: __lock_acquire+0x4f8/0xb40 lock_acquire+0xd4/0x2d0 __mutex_lock+0x9b/0xbf0 ice_vc_cfg_qs_msg+0x45/0x690 [ice] ice_vc_process_vf_msg+0x4f5/0x870 [ice] __ice_clean_ctrlq+0x2b5/0x600 [ice] ice_service_task+0x2c9/0x480 [ice] process_one_work+0x1e9/0x4d0 worker_thread+0x1e1/0x3d0 kthread+0x104/0x140 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1b/0x30 -> #0 (&vf->cfg_lock){+.+.}-{3:3}: check_prev_add+0xe2/0xc50 validate_chain+0x558/0x800 __lock_acquire+0x4f8/0xb40 lock_acquire+0xd4/0x2d0 __mutex_lock+0x9b/0xbf0 ice_reset_vf+0x22f/0x4d0 [ice] ice_process_vflr_event+0x98/0xd0 [ice] ice_service_task+0x1cc/0x480 [ice] process_one_work+0x1e9/0x4d0 worker_thread+0x1e1/0x3d0 kthread+0x104/0x140 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1b/0x30 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&pf->lag_mutex); lock(&vf->cfg_lock); lock(&pf->lag_mutex); lock(&vf->cfg_lock); *** DEADLOCK *** 4 locks held by kworker/60:3/6771: #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0 #1: ff50d06e05197e58 ((work_completion)(&pf->serv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0 #2: ff40d43ea1960e50 (&pf->vfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice] #3: ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice] stack backtrace: CPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G W O 6.8.0-rc6 #54 Hardware name: Workqueue: ice ice_service_task [ice] Call Trace: <TASK> dump_stack_lvl+0x4a/0x80 check_noncircular+0x12d/0x150 check_prev_add+0xe2/0xc50 ? save_trace+0x59/0x230 ? add_chain_cache+0x109/0x450 validate_chain+0x558/0x800 __lock_acquire+0x4f8/0xb40 ? lockdep_hardirqs_on+0x7d/0x100 lock_acquire+0xd4/0x2d0 ? ice_reset_vf+0x22f/0x4d0 [ice] ? lock_is_held_type+0xc7/0x120 __mutex_lock+0x9b/0xbf0 ? ice_reset_vf+0x22f/0x4d0 [ice] ? ice_reset_vf+0x22f/0x4d0 [ice] ? rcu_is_watching+0x11/0x50 ? ice_reset_vf+0x22f/0x4d0 [ice] ice_reset_vf+0x22f/0x4d0 [ice] ? process_one_work+0x176/0x4d0 ice_process_vflr_event+0x98/0xd0 [ice] ice_service_task+0x1cc/0x480 [ice] process_one_work+0x1e9/0x4d0 worker_thread+0x1e1/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x104/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> To avoid deadlock, we must acquire the LAG ---truncated---
Impacted products
Vendor Product Version
Linux Linux Version: 6.7
Show details on NVD website


{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-36003",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-05-20T14:21:30.887078Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-06-04T17:47:37.057Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T03:30:12.307Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/740717774dc37338404d10726967d582414f638c"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/de8631d8c9df08440268630200e64b623a5f69e6"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/96fdd1f6b4ed72a741fb0eb705c0e13049b8721f"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/intel/ice/ice_vf_lib.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "740717774dc37338404d10726967d582414f638c",
              "status": "affected",
              "version": "fd7f7a8ad3363fd94fc3868616cc70a1d8dfc01b",
              "versionType": "git"
            },
            {
              "lessThan": "de8631d8c9df08440268630200e64b623a5f69e6",
              "status": "affected",
              "version": "9f74a3dfcf83e11aedcb98250b8040dbc6d9659a",
              "versionType": "git"
            },
            {
              "lessThan": "96fdd1f6b4ed72a741fb0eb705c0e13049b8721f",
              "status": "affected",
              "version": "9f74a3dfcf83e11aedcb98250b8040dbc6d9659a",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/intel/ice/ice_vf_lib.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.7"
            },
            {
              "lessThan": "6.7",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.30",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.8.*",
              "status": "unaffected",
              "version": "6.8.9",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.9",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix LAG and VF lock dependency in ice_reset_vf()\n\n9f74a3dfcf83 (\"ice: Fix VF Reset paths when interface in a failed over\naggregate\"), the ice driver has acquired the LAG mutex in ice_reset_vf().\nThe commit placed this lock acquisition just prior to the acquisition of\nthe VF configuration lock.\n\nIf ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK\nflag, this could deadlock with ice_vc_cfg_qs_msg() because it always\nacquires the locks in the order of the VF configuration lock and then the\nLAG mutex.\n\nLockdep reports this violation almost immediately on creating and then\nremoving 2 VF:\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.8.0-rc6 #54 Tainted: G        W  O\n------------------------------------------------------\nkworker/60:3/6771 is trying to acquire lock:\nff40d43e099380a0 (\u0026vf-\u003ecfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice]\n\nbut task is already holding lock:\nff40d43ea1961210 (\u0026pf-\u003elag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #1 (\u0026pf-\u003elag_mutex){+.+.}-{3:3}:\n       __lock_acquire+0x4f8/0xb40\n       lock_acquire+0xd4/0x2d0\n       __mutex_lock+0x9b/0xbf0\n       ice_vc_cfg_qs_msg+0x45/0x690 [ice]\n       ice_vc_process_vf_msg+0x4f5/0x870 [ice]\n       __ice_clean_ctrlq+0x2b5/0x600 [ice]\n       ice_service_task+0x2c9/0x480 [ice]\n       process_one_work+0x1e9/0x4d0\n       worker_thread+0x1e1/0x3d0\n       kthread+0x104/0x140\n       ret_from_fork+0x31/0x50\n       ret_from_fork_asm+0x1b/0x30\n\n-\u003e #0 (\u0026vf-\u003ecfg_lock){+.+.}-{3:3}:\n       check_prev_add+0xe2/0xc50\n       validate_chain+0x558/0x800\n       __lock_acquire+0x4f8/0xb40\n       lock_acquire+0xd4/0x2d0\n       __mutex_lock+0x9b/0xbf0\n       ice_reset_vf+0x22f/0x4d0 [ice]\n       ice_process_vflr_event+0x98/0xd0 [ice]\n       ice_service_task+0x1cc/0x480 [ice]\n       process_one_work+0x1e9/0x4d0\n       worker_thread+0x1e1/0x3d0\n       kthread+0x104/0x140\n       ret_from_fork+0x31/0x50\n       ret_from_fork_asm+0x1b/0x30\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n       CPU0                    CPU1\n       ----                    ----\n  lock(\u0026pf-\u003elag_mutex);\n                               lock(\u0026vf-\u003ecfg_lock);\n                               lock(\u0026pf-\u003elag_mutex);\n  lock(\u0026vf-\u003ecfg_lock);\n\n *** DEADLOCK ***\n4 locks held by kworker/60:3/6771:\n #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0\n #1: ff50d06e05197e58 ((work_completion)(\u0026pf-\u003eserv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0\n #2: ff40d43ea1960e50 (\u0026pf-\u003evfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice]\n #3: ff40d43ea1961210 (\u0026pf-\u003elag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]\n\nstack backtrace:\nCPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G        W  O       6.8.0-rc6 #54\nHardware name:\nWorkqueue: ice ice_service_task [ice]\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x4a/0x80\n check_noncircular+0x12d/0x150\n check_prev_add+0xe2/0xc50\n ? save_trace+0x59/0x230\n ? add_chain_cache+0x109/0x450\n validate_chain+0x558/0x800\n __lock_acquire+0x4f8/0xb40\n ? lockdep_hardirqs_on+0x7d/0x100\n lock_acquire+0xd4/0x2d0\n ? ice_reset_vf+0x22f/0x4d0 [ice]\n ? lock_is_held_type+0xc7/0x120\n __mutex_lock+0x9b/0xbf0\n ? ice_reset_vf+0x22f/0x4d0 [ice]\n ? ice_reset_vf+0x22f/0x4d0 [ice]\n ? rcu_is_watching+0x11/0x50\n ? ice_reset_vf+0x22f/0x4d0 [ice]\n ice_reset_vf+0x22f/0x4d0 [ice]\n ? process_one_work+0x176/0x4d0\n ice_process_vflr_event+0x98/0xd0 [ice]\n ice_service_task+0x1cc/0x480 [ice]\n process_one_work+0x1e9/0x4d0\n worker_thread+0x1e1/0x3d0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x104/0x140\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u003c/TASK\u003e\n\nTo avoid deadlock, we must acquire the LAG \n---truncated---"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-12-19T09:00:19.329Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/740717774dc37338404d10726967d582414f638c"
        },
        {
          "url": "https://git.kernel.org/stable/c/de8631d8c9df08440268630200e64b623a5f69e6"
        },
        {
          "url": "https://git.kernel.org/stable/c/96fdd1f6b4ed72a741fb0eb705c0e13049b8721f"
        }
      ],
      "title": "ice: fix LAG and VF lock dependency in ice_reset_vf()",
      "x_generator": {
        "engine": "bippy-5f407fcff5a0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-36003",
    "datePublished": "2024-05-20T09:48:04.263Z",
    "dateReserved": "2024-05-17T13:50:33.150Z",
    "dateUpdated": "2024-12-19T09:00:19.329Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-36003\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-05-20T10:15:14.360\",\"lastModified\":\"2024-11-21T09:21:24.537\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nice: fix LAG and VF lock dependency in ice_reset_vf()\\n\\n9f74a3dfcf83 (\\\"ice: Fix VF Reset paths when interface in a failed over\\naggregate\\\"), the ice driver has acquired the LAG mutex in ice_reset_vf().\\nThe commit placed this lock acquisition just prior to the acquisition of\\nthe VF configuration lock.\\n\\nIf ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK\\nflag, this could deadlock with ice_vc_cfg_qs_msg() because it always\\nacquires the locks in the order of the VF configuration lock and then the\\nLAG mutex.\\n\\nLockdep reports this violation almost immediately on creating and then\\nremoving 2 VF:\\n\\n======================================================\\nWARNING: possible circular locking dependency detected\\n6.8.0-rc6 #54 Tainted: G        W  O\\n------------------------------------------------------\\nkworker/60:3/6771 is trying to acquire lock:\\nff40d43e099380a0 (\u0026vf-\u003ecfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice]\\n\\nbut task is already holding lock:\\nff40d43ea1961210 (\u0026pf-\u003elag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]\\n\\nwhich lock already depends on the new lock.\\n\\nthe existing dependency chain (in reverse order) is:\\n\\n-\u003e #1 (\u0026pf-\u003elag_mutex){+.+.}-{3:3}:\\n       __lock_acquire+0x4f8/0xb40\\n       lock_acquire+0xd4/0x2d0\\n       __mutex_lock+0x9b/0xbf0\\n       ice_vc_cfg_qs_msg+0x45/0x690 [ice]\\n       ice_vc_process_vf_msg+0x4f5/0x870 [ice]\\n       __ice_clean_ctrlq+0x2b5/0x600 [ice]\\n       ice_service_task+0x2c9/0x480 [ice]\\n       process_one_work+0x1e9/0x4d0\\n       worker_thread+0x1e1/0x3d0\\n       kthread+0x104/0x140\\n       ret_from_fork+0x31/0x50\\n       ret_from_fork_asm+0x1b/0x30\\n\\n-\u003e #0 (\u0026vf-\u003ecfg_lock){+.+.}-{3:3}:\\n       check_prev_add+0xe2/0xc50\\n       validate_chain+0x558/0x800\\n       __lock_acquire+0x4f8/0xb40\\n       lock_acquire+0xd4/0x2d0\\n       __mutex_lock+0x9b/0xbf0\\n       ice_reset_vf+0x22f/0x4d0 [ice]\\n       ice_process_vflr_event+0x98/0xd0 [ice]\\n       ice_service_task+0x1cc/0x480 [ice]\\n       process_one_work+0x1e9/0x4d0\\n       worker_thread+0x1e1/0x3d0\\n       kthread+0x104/0x140\\n       ret_from_fork+0x31/0x50\\n       ret_from_fork_asm+0x1b/0x30\\n\\nother info that might help us debug this:\\n Possible unsafe locking scenario:\\n       CPU0                    CPU1\\n       ----                    ----\\n  lock(\u0026pf-\u003elag_mutex);\\n                               lock(\u0026vf-\u003ecfg_lock);\\n                               lock(\u0026pf-\u003elag_mutex);\\n  lock(\u0026vf-\u003ecfg_lock);\\n\\n *** DEADLOCK ***\\n4 locks held by kworker/60:3/6771:\\n #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0\\n #1: ff50d06e05197e58 ((work_completion)(\u0026pf-\u003eserv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0\\n #2: ff40d43ea1960e50 (\u0026pf-\u003evfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice]\\n #3: ff40d43ea1961210 (\u0026pf-\u003elag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]\\n\\nstack backtrace:\\nCPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G        W  O       6.8.0-rc6 #54\\nHardware name:\\nWorkqueue: ice ice_service_task [ice]\\nCall Trace:\\n \u003cTASK\u003e\\n dump_stack_lvl+0x4a/0x80\\n check_noncircular+0x12d/0x150\\n check_prev_add+0xe2/0xc50\\n ? save_trace+0x59/0x230\\n ? add_chain_cache+0x109/0x450\\n validate_chain+0x558/0x800\\n __lock_acquire+0x4f8/0xb40\\n ? lockdep_hardirqs_on+0x7d/0x100\\n lock_acquire+0xd4/0x2d0\\n ? ice_reset_vf+0x22f/0x4d0 [ice]\\n ? lock_is_held_type+0xc7/0x120\\n __mutex_lock+0x9b/0xbf0\\n ? ice_reset_vf+0x22f/0x4d0 [ice]\\n ? ice_reset_vf+0x22f/0x4d0 [ice]\\n ? rcu_is_watching+0x11/0x50\\n ? ice_reset_vf+0x22f/0x4d0 [ice]\\n ice_reset_vf+0x22f/0x4d0 [ice]\\n ? process_one_work+0x176/0x4d0\\n ice_process_vflr_event+0x98/0xd0 [ice]\\n ice_service_task+0x1cc/0x480 [ice]\\n process_one_work+0x1e9/0x4d0\\n worker_thread+0x1e1/0x3d0\\n ? __pfx_worker_thread+0x10/0x10\\n kthread+0x104/0x140\\n ? __pfx_kthread+0x10/0x10\\n ret_from_fork+0x31/0x50\\n ? __pfx_kthread+0x10/0x10\\n ret_from_fork_asm+0x1b/0x30\\n \u003c/TASK\u003e\\n\\nTo avoid deadlock, we must acquire the LAG \\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige la dependencia de bloqueo de LAG y VF en ice_reset_vf() 9f74a3dfcf83 (\\\"ice: corrige las rutas de restablecimiento de VF cuando la interfaz est\u00e1 en un agregado de conmutaci\u00f3n por error\\\"), el controlador ice ha adquirido el LAG mutex en ice_reset_vf(). La confirmaci\u00f3n coloc\u00f3 esta adquisici\u00f3n de bloqueo justo antes de la adquisici\u00f3n del bloqueo de configuraci\u00f3n VF. Si ice_reset_vf() adquiere el bloqueo de configuraci\u00f3n a trav\u00e9s del indicador ICE_VF_RESET_LOCK, esto podr\u00eda bloquearse con ice_vc_cfg_qs_msg() porque siempre adquiere los bloqueos en el orden del bloqueo de configuraci\u00f3n VF y luego el mutex LAG. Lockdep informa esta infracci\u00f3n casi inmediatamente al crear y luego eliminar 2 VF: ===================================== ================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.8.0-rc6 #54 Contaminado: GWO --------------- --------------------------------------- kworker/60:3/6771 est\u00e1 intentando adquirir bloqueo: ff40d43e099380a0 (\u0026amp;vf-\u0026gt;cfg_lock){+.+.}-{3:3}, en: ice_reset_vf+0x22f/0x4d0 [ice] pero la tarea ya mantiene el bloqueo: ff40d43ea1961210 (\u0026amp;pf-\u0026gt;lag_mutex){+.+ .}-{3:3}, en: ice_reset_vf+0xb7/0x4d0 [ice] cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -\u0026gt; #1 (\u0026amp;pf-\u0026gt;lag_mutex){+.+.}-{3:3}: __lock_acquire+0x4f8/0xb40 lock_acquire+0xd4/0x2d0 __mutex_lock+0x9b/0xbf0 ice_vc_cfg_qs_msg +0x45/0x690 [ice] ice_vc_process_vf_msg+0x4f5/0x870 [ice] __ice_clean_ctrlq+0x2b5/0x600 [ice] ice_service_task+0x2c9/0x480 [ice] Process_one_work+0x1e9/0x4d0 trabajador_thread+0x1e1/0x3d0 leer+0x104/0x140 ret_from_fork+0x31/ 0x50 ret_from_fork_asm+0x1b/0x30 -\u0026gt; #0 (\u0026amp;vf-\u0026gt;cfg_lock){+.+.}-{3:3}: check_prev_add+0xe2/0xc50 validar_chain+0x558/0x800 __lock_acquire+0x4f8/0xb40 lock_acquire+0xd4/0x2d0 ex_lock +0x9b/0xbf0 ice_reset_vf+0x22f/0x4d0 [ice] ice_process_vflr_event+0x98/0xd0 [ice] ice_service_task+0x1cc/0x480 [ice] Process_one_work+0x1e9/0x4d0 trabajador_thread+0x1e1/0x3d0 kthread+0x104/0x1 40 ret_from_fork+0x31/0x50 ret_from_fork_asm+ 0x1b/0x30 otra informaci\u00f3n que podr\u00eda ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- lock(\u0026amp;pf-\u0026gt;lag_mutex); bloquear(\u0026amp;vf-\u0026gt;cfg_lock); bloquear(\u0026amp;pf-\u0026gt;lag_mutex); bloquear(\u0026amp;vf-\u0026gt;cfg_lock); *** DEADLOCK *** 4 bloqueos retenidos por kworker/60:3/6771: #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, en: Process_one_work+0x176/0x4d0 # 1: ff50d06e05197e58 ((work_completion)(\u0026amp;pf-\u0026gt;serv_task)){+.+.}-{0:0}, en: Process_one_work+0x176/0x4d0 #2: ff40d43ea1960e50 (\u0026amp;pf-\u0026gt;vfs.table_lock){+.+ .}-{3:3}, en: ice_process_vflr_event+0x48/0xd0 [ice] #3: ff40d43ea1961210 (\u0026amp;pf-\u0026gt;lag_mutex){+.+.}-{3:3}, en: ice_reset_vf+0xb7/0x4d0 [ ice] seguimiento de pila: CPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: GWO 6.8.0-rc6 #54 Nombre de hardware: Cola de trabajo: ice ice_service_task [ice] Seguimiento de llamadas:  dump_stack_lvl+0x4a/0x80 check_noncircular +0x12d/0x150 check_prev_add+0xe2/0xc50 ? save_trace+0x59/0x230? add_chain_cache+0x109/0x450 validar_chain+0x558/0x800 __lock_acquire+0x4f8/0xb40? lockdep_hardirqs_on+0x7d/0x100 lock_acquire+0xd4/0x2d0? ice_reset_vf+0x22f/0x4d0 [ice]? lock_is_held_type+0xc7/0x120 __mutex_lock+0x9b/0xbf0 ? ice_reset_vf+0x22f/0x4d0 [ice]? ice_reset_vf+0x22f/0x4d0 [ice]? rcu_is_watching+0x11/0x50? ice_reset_vf+0x22f/0x4d0 [ice] ice_reset_vf+0x22f/0x4d0 [ice] ? Process_one_work+0x176/0x4d0 ice_process_vflr_event+0x98/0xd0 [ice] ice_service_task+0x1cc/0x480 [ice] Process_one_work+0x1e9/0x4d0 trabajador_thread+0x1e1/0x3d0? __pfx_worker_thread+0x10/0x10 kthread+0x104/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30  Para evitar un punto muerto, debemos adquirir el LAG ---truncado---\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/740717774dc37338404d10726967d582414f638c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/96fdd1f6b4ed72a741fb0eb705c0e13049b8721f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/de8631d8c9df08440268630200e64b623a5f69e6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/740717774dc37338404d10726967d582414f638c\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/96fdd1f6b4ed72a741fb0eb705c0e13049b8721f\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/de8631d8c9df08440268630200e64b623a5f69e6\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.