CVE-2022-49290

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: fix potential double free on mesh join<br /> <br /> While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving<br /> mesh") fixed a memory leak on mesh leave / teardown it introduced a<br /> potential memory corruption caused by a double free when rejoining the<br /> mesh:<br /> <br /> ieee80211_leave_mesh()<br /> -&gt; kfree(sdata-&gt;u.mesh.ie);<br /> ...<br /> ieee80211_join_mesh()<br /> -&gt; copy_mesh_setup()<br /> -&gt; old_ie = ifmsh-&gt;ie;<br /> -&gt; kfree(old_ie);<br /> <br /> This double free / kernel panics can be reproduced by using wpa_supplicant<br /> with an encrypted mesh (if set up without encryption via "iw" then<br /> ifmsh-&gt;ie is always NULL, which avoids this issue). And then calling:<br /> <br /> $ iw dev mesh0 mesh leave<br /> $ iw dev mesh0 mesh join my-mesh<br /> <br /> Note that typically these commands are not used / working when using<br /> wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going<br /> through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join<br /> where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of<br /> default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids<br /> the memory corruption, too.<br /> <br /> The issue was first observed in an application which was not using<br /> wpa_supplicant but "Senf" instead, which implements its own calls to<br /> nl80211.<br /> <br /> Fixing the issue by removing the kfree()&amp;#39;ing of the mesh IE in the mesh<br /> join function and leaving it solely up to the mesh leave to free the<br /> mesh IE.