Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:EOL][EOL]soundwire: revisit driver bind/unbind and callbacks[EOL][EOL]In the SoundWire probe, we store a pointer from the driver ops into[EOL]the 'slave' structure. This can lead to kernel oopses when unbinding[EOL]codec drivers, e.g. with the following sequence to remove machine[EOL]driver and codec driver.[EOL][EOL]/sbin/modprobe -r snd_soc_sof_sdw[EOL]/sbin/modprobe -r snd_soc_rt711[EOL][EOL]The full details can be found in the BugLink below, for reference the[EOL]two following examples show different cases of driver ops/callbacks[EOL]being invoked after the driver .remove().[EOL][EOL]kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150[EOL]kernel: Workqueue: events cdns_update_slave_status_work [soundwire_cadence][EOL]kernel: RIP: 0010:mutex_lock+0x19/0x30[EOL]kernel: Call Trace:[EOL]kernel:  ? sdw_handle_slave_status+0x426/0xe00 [soundwire_bus 94ff184bf398570c3f8ff7efe9e32529f532e4ae][EOL]kernel:  ? newidle_balance+0x26a/0x400[EOL]kernel:  ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82][EOL][EOL]kernel: BUG: unable to handle page fault for address: ffffffffc07654c8[EOL]kernel: Workqueue: pm pm_runtime_work[EOL]kernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus][EOL]kernel: Call Trace:[EOL]kernel:  <TASK>[EOL]kernel:  sdw_cdns_clock_stop+0xb5/0x1b0 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82][EOL]kernel:  intel_suspend_runtime+0x5f/0x120 [soundwire_intel aca858f7c87048d3152a4a41bb68abb9b663a1dd][EOL]kernel:  ? dpm_sysfs_remove+0x60/0x60[EOL][EOL]This was not detected earlier in Intel tests since the tests first[EOL]remove the parent PCI device and shut down the bus. The sequence[EOL]above is a corner case which keeps the bus operational but without a[EOL]driver bound.[EOL][EOL]While trying to solve this kernel oopses, it became clear that the[EOL]existing SoundWire bus does not deal well with the unbind case.[EOL][EOL]Commit 528be501b7d4a ("soundwire: sdw_slave: add probe_complete structure and new fields")[EOL]added a 'probed' status variable and a 'probe_complete'[EOL]struct completion. This status is however not reset on remove and[EOL]likewise the 'probe complete' is not re-initialized, so the[EOL]bind/unbind/bind test cases would fail. The timeout used before the[EOL]'update_status' callback was also a bad idea in hindsight, there[EOL]should really be no timing assumption as to if and when a driver is[EOL]bound to a device.[EOL][EOL]An initial draft was based on device_lock() and device_unlock() was[EOL]tested. This proved too complicated, with deadlocks created during the[EOL]suspend-resume sequences, which also use the same device_lock/unlock()[EOL]as the bind/unbind sequences. On a CometLake device, a bad DSDT/BIOS[EOL]caused spurious resumes and the use of device_lock() caused hangs[EOL]during suspend. After multiple weeks or testing and painful[EOL]reverse-engineering of deadlocks on different devices, we looked for[EOL]alternatives that did not interfere with the device core.[EOL][EOL]A bus notifier was used successfully to keep track of DRIVER_BOUND and[EOL]DRIVER_UNBIND events. This solved the bind-unbind-bind case in tests,[EOL]but it can still be defeated with a theoretical corner case where the[EOL]memory is freed by a .remove while the callback is in use. The[EOL]notifier only helps make sure the driver callbacks are valid, but not[EOL]that the memory allocated in probe remains valid while the callbacks[EOL]are invoked.[EOL][EOL]This patch suggests the introduction of a new 'sdw_dev_lock' mutex[EOL]protecting probe/remove and all driver callbacks. Since this mutex is[EOL]'local' to SoundWire only, it does not interfere with existing locks[EOL]and does not create deadlocks. In addition, this patch removes the[EOL]'probe_complete' completion, instead we directly invoke the[EOL]'update_status' from the probe routine. That removes any sort of[EOL]timing dependency and a much better support for the device/driver[EOL]model, the driver could be bound before the bus started, or eons after[EOL]the bus started and the hardware would be properly initialized in all[EOL]cases.[EOL][EOL]BugLink: https://github.com/thesofproject/linux/is[EOL]---truncated---

CREATE(Triage):(User=lchen-cn) [CVE-2022-50144 (https://nvd.nist.gov/vuln/detail/CVE-2022-50144)