CVE-2022-48941

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix concurrent reset and removal of VFs<br /> <br /> Commit c503e63200c6 ("ice: Stop processing VF messages during teardown")<br /> introduced a driver state flag, ICE_VF_DEINIT_IN_PROGRESS, which is<br /> intended to prevent some issues with concurrently handling messages from<br /> VFs while tearing down the VFs.<br /> <br /> This change was motivated by crashes caused while tearing down and<br /> bringing up VFs in rapid succession.<br /> <br /> It turns out that the fix actually introduces issues with the VF driver<br /> caused because the PF no longer responds to any messages sent by the VF<br /> during its .remove routine. This results in the VF potentially removing<br /> its DMA memory before the PF has shut down the device queues.<br /> <br /> Additionally, the fix doesn&amp;#39;t actually resolve concurrency issues within<br /> the ice driver. It is possible for a VF to initiate a reset just prior<br /> to the ice driver removing VFs. This can result in the remove task<br /> concurrently operating while the VF is being reset. This results in<br /> similar memory corruption and panics purportedly fixed by that commit.<br /> <br /> Fix this concurrency at its root by protecting both the reset and<br /> removal flows using the existing VF cfg_lock. This ensures that we<br /> cannot remove the VF while any outstanding critical tasks such as a<br /> virtchnl message or a reset are occurring.<br /> <br /> This locking change also fixes the root cause originally fixed by commit<br /> c503e63200c6 ("ice: Stop processing VF messages during teardown"), so we<br /> can simply revert it.<br /> <br /> Note that I kept these two changes together because simply reverting the<br /> original commit alone would leave the driver vulnerable to worse race<br /> conditions.