CVE-2024-57992

In the Linux kernel, the following vulnerability has been resolved:

wifi: wilc1000: unregister wiphy only if it has been registered

There is a specific error path in probe functions in wilc drivers (both sdio and spi) which can lead to kernel panic, as this one for example when using SPI:

Unable to handle kernel paging request at virtual address 9f000000 when read [9f000000] *pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: wilc1000spi(+) crcitut crc7 wilc1000 cfg80211 bluetooth ecdhgeneric ecc CPU: 0 UID: 0 PID: 106 Comm: modprobe Not tainted 6.13.0-rc3+ #22 Hardware name: Atmel SAMA5 PC is at wiphyunregister+0x244/0xc40 [cfg80211] LR is at wiphyunregister+0x1c0/0xc40 [cfg80211] [...] wiphyunregister [cfg80211] from wilcnetdevcleanup+0x380/0x494 [wilc1000] wilcnetdevcleanup [wilc1000] from wilcbusprobe+0x360/0x834 [wilc1000spi] wilcbusprobe [wilc1000spi] from spiprobe+0x15c/0x1d4 spiprobe from reallyprobe+0x270/0xb2c really_probe from __driverprobedevice+0x1dc/0x4e8 __driverprobedevice from driverprobedevice+0x5c/0x140 driverprobedevice from __driver_attach+0x220/0x540 _driverattach from busforeachdev+0x13c/0x1a8 busforeachdev from busadddriver+0x2a0/0x6a4 busadddriver from driverregister+0x27c/0x51c driverregister from dooneinitcall+0xf8/0x564 dooneinitcall from doinitmodule+0x2e4/0x82c doinitmodule from loadmodule+0x59a0/0x70c4 loadmodule from initmodulefromfile+0x100/0x148 initmodulefromfile from sysfinitmodule+0x2fc/0x924 sysfinitmodule from retfastsyscall+0x0/0x1c

The issue can easily be reproduced, for example by not wiring correctly a wilc device through SPI (and so, make it unresponsive to early SPI commands). It is due to a recent change decoupling wiphy allocation from wiphy registration, however wilcnetdevcleanup has not been updated accordingly, letting it possibly call wiphy unregister on a wiphy which has never been registered.

Fix this crash by moving wiphyunregister/wiphyfree out of wilcnetdevcleanup, and by adjusting error paths in both drivers