Commit 9d638a9c authored by Andrea Righi's avatar Andrea Righi Committed by Yongqiang Liu
Browse files

xen-netfront: fix potential deadlock in xennet_remove()

stable inclusion
from stable-v4.19.137
commit 4b635fc2b3491bdaa69fd80b376b216fae2d1461
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5GLZZ


CVE: CVE-2022-33741

--------------------------------

[ Upstream commit c2c63310 ]

There's a potential race in xennet_remove(); this is what the driver is
doing upon unregistering a network device:

  1. state = read bus state
  2. if state is not "Closed":
  3.    request to set state to "Closing"
  4.    wait for state to be set to "Closing"
  5.    request to set state to "Closed"
  6.    wait for state to be set to "Closed"

If the state changes to "Closed" immediately after step 1 we are stuck
forever in step 4, because the state will never go back from "Closed" to
"Closing".

Make sure to check also for state == "Closed" in step 4 to prevent the
deadlock.

Also add a 5 sec timeout any time we wait for the bus state to change,
to avoid getting stuck forever in wait_event().

Signed-off-by: default avatarAndrea Righi <andrea.righi@canonical.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
Signed-off-by: default avatarChenXiaoSong <chenxiaosong2@huawei.com>
Reviewed-by: default avatarJason Yan <yanaijie@huawei.com>
Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
parent e24409ef
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment