cve/published/2024/CVE-2024-36003.mbox - pub/scm/linux/security/vulns - Git at Google

 From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
 From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 To: <linux-cve-announce@vger.kernel.org>
 Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
 Subject: CVE-2024-36003: ice: fix LAG and VF lock dependency in ice_reset_vf()

 Description
 ===========

 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 mutex only after acquiring the
 VF configuration lock. Fix the ice_reset_vf() to acquire the LAG mutex only
 after we either acquire or check that the VF configuration lock is held.

 The Linux kernel CVE team has assigned CVE-2024-36003 to this issue.


 Affected and fixed versions
 ===========================

 	Issue introduced in 6.6.5 with commit fd7f7a8ad3363fd94fc3868616cc70a1d8dfc01b and fixed in 6.6.30 with commit 740717774dc37338404d10726967d582414f638c
 	Issue introduced in 6.7 with commit 9f74a3dfcf83e11aedcb98250b8040dbc6d9659a and fixed in 6.8.9 with commit de8631d8c9df08440268630200e64b623a5f69e6
 	Issue introduced in 6.7 with commit 9f74a3dfcf83e11aedcb98250b8040dbc6d9659a and fixed in 6.9 with commit 96fdd1f6b4ed72a741fb0eb705c0e13049b8721f

 Please see https://www.kernel.org for a full list of currently supported
 kernel versions by the kernel community.

 Unaffected versions might change over time as fixes are backported to
 older supported kernel versions.  The official CVE entry at
 	https://cve.org/CVERecord/?id=CVE-2024-36003
 will be updated if fixes are backported, please check that for the most
 up to date information about this issue.


 Affected files
 ==============

 The file(s) affected by this issue are:
 	drivers/net/ethernet/intel/ice/ice_vf_lib.c


 Mitigation
 ==========

 The Linux kernel CVE team recommends that you update to the latest
 stable kernel version for this, and many other bugfixes.  Individual
 changes are never tested alone, but rather are part of a larger kernel
 release.  Cherry-picking individual commits is not recommended or
 supported by the Linux kernel community at all.  If however, updating to
 the latest release is impossible, the individual changes to resolve this
 issue can be found at these commits:
 	https://git.kernel.org/stable/c/740717774dc37338404d10726967d582414f638c
 	https://git.kernel.org/stable/c/de8631d8c9df08440268630200e64b623a5f69e6
 	https://git.kernel.org/stable/c/96fdd1f6b4ed72a741fb0eb705c0e13049b8721f
	From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
	From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
	To: <linux-cve-announce@vger.kernel.org>
	Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
	Subject: CVE-2024-36003: ice: fix LAG and VF lock dependency in ice_reset_vf()

	Description
	===========

	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 mutex only after acquiring the
	VF configuration lock. Fix the ice_reset_vf() to acquire the LAG mutex only
	after we either acquire or check that the VF configuration lock is held.

	The Linux kernel CVE team has assigned CVE-2024-36003 to this issue.


	Affected and fixed versions
	===========================

	Issue introduced in 6.6.5 with commit fd7f7a8ad3363fd94fc3868616cc70a1d8dfc01b and fixed in 6.6.30 with commit 740717774dc37338404d10726967d582414f638c
	Issue introduced in 6.7 with commit 9f74a3dfcf83e11aedcb98250b8040dbc6d9659a and fixed in 6.8.9 with commit de8631d8c9df08440268630200e64b623a5f69e6
	Issue introduced in 6.7 with commit 9f74a3dfcf83e11aedcb98250b8040dbc6d9659a and fixed in 6.9 with commit 96fdd1f6b4ed72a741fb0eb705c0e13049b8721f

	Please see https://www.kernel.org for a full list of currently supported
	kernel versions by the kernel community.

	Unaffected versions might change over time as fixes are backported to
	older supported kernel versions. The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-36003
	will be updated if fixes are backported, please check that for the most
	up to date information about this issue.


	Affected files
	==============

	The file(s) affected by this issue are:
	drivers/net/ethernet/intel/ice/ice_vf_lib.c


	Mitigation
	==========

	The Linux kernel CVE team recommends that you update to the latest
	stable kernel version for this, and many other bugfixes. Individual
	changes are never tested alone, but rather are part of a larger kernel
	release. Cherry-picking individual commits is not recommended or
	supported by the Linux kernel community at all. If however, updating to
	the latest release is impossible, the individual changes to resolve this
	issue can be found at these commits:
	https://git.kernel.org/stable/c/740717774dc37338404d10726967d582414f638c
	https://git.kernel.org/stable/c/de8631d8c9df08440268630200e64b623a5f69e6
	https://git.kernel.org/stable/c/96fdd1f6b4ed72a741fb0eb705c0e13049b8721f