CVE-2022-50144

{"id": "CVE-2022-50144", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2025-06-18T11:15:44.413", "references": [{"url": "https://git.kernel.org/stable/c/250b46505175889c6b5958c3829f610f52199f5f", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/432b30f08ca3303d2ebb22352cb04c4b6cfefe65", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/8fd6b03646b9a9e16d1ec19bd724cd6bd78e0ea5", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/bd29c00edd0a5dac8b6e7332bb470cd50f92e893", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-476"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoundwire: revisit driver bind/unbind and callbacks\n\nIn the SoundWire probe, we store a pointer from the driver ops into\nthe 'slave' structure. This can lead to kernel oopses when unbinding\ncodec drivers, e.g. with the following sequence to remove machine\ndriver and codec driver.\n\n/sbin/modprobe -r snd_soc_sof_sdw\n/sbin/modprobe -r snd_soc_rt711\n\nThe full details can be found in the BugLink below, for reference the\ntwo following examples show different cases of driver ops/callbacks\nbeing invoked after the driver .remove().\n\nkernel: BUG: kernel NULL pointer dereference, address: 0000000000000150\nkernel: Workqueue: events cdns_update_slave_status_work [soundwire_cadence]\nkernel: RIP: 0010:mutex_lock+0x19/0x30\nkernel: Call Trace:\nkernel: ? sdw_handle_slave_status+0x426/0xe00 [soundwire_bus 94ff184bf398570c3f8ff7efe9e32529f532e4ae]\nkernel: ? newidle_balance+0x26a/0x400\nkernel: ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]\n\nkernel: BUG: unable to handle page fault for address: ffffffffc07654c8\nkernel: Workqueue: pm pm_runtime_work\nkernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus]\nkernel: Call Trace:\nkernel: <TASK>\nkernel: sdw_cdns_clock_stop+0xb5/0x1b0 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]\nkernel: intel_suspend_runtime+0x5f/0x120 [soundwire_intel aca858f7c87048d3152a4a41bb68abb9b663a1dd]\nkernel: ? dpm_sysfs_remove+0x60/0x60\n\nThis was not detected earlier in Intel tests since the tests first\nremove the parent PCI device and shut down the bus. The sequence\nabove is a corner case which keeps the bus operational but without a\ndriver bound.\n\nWhile trying to solve this kernel oopses, it became clear that the\nexisting SoundWire bus does not deal well with the unbind case.\n\nCommit 528be501b7d4a (\"soundwire: sdw_slave: add probe_complete structure and new fields\")\nadded a 'probed' status variable and a 'probe_complete'\nstruct completion. This status is however not reset on remove and\nlikewise the 'probe complete' is not re-initialized, so the\nbind/unbind/bind test cases would fail. The timeout used before the\n'update_status' callback was also a bad idea in hindsight, there\nshould really be no timing assumption as to if and when a driver is\nbound to a device.\n\nAn initial draft was based on device_lock() and device_unlock() was\ntested. This proved too complicated, with deadlocks created during the\nsuspend-resume sequences, which also use the same device_lock/unlock()\nas the bind/unbind sequences. On a CometLake device, a bad DSDT/BIOS\ncaused spurious resumes and the use of device_lock() caused hangs\nduring suspend. After multiple weeks or testing and painful\nreverse-engineering of deadlocks on different devices, we looked for\nalternatives that did not interfere with the device core.\n\nA bus notifier was used successfully to keep track of DRIVER_BOUND and\nDRIVER_UNBIND events. This solved the bind-unbind-bind case in tests,\nbut it can still be defeated with a theoretical corner case where the\nmemory is freed by a .remove while the callback is in use. The\nnotifier only helps make sure the driver callbacks are valid, but not\nthat the memory allocated in probe remains valid while the callbacks\nare invoked.\n\nThis patch suggests the introduction of a new 'sdw_dev_lock' mutex\nprotecting probe/remove and all driver callbacks. Since this mutex is\n'local' to SoundWire only, it does not interfere with existing locks\nand does not create deadlocks. In addition, this patch removes the\n'probe_complete' completion, instead we directly invoke the\n'update_status' from the probe routine. That removes any sort of\ntiming dependency and a much better support for the device/driver\nmodel, the driver could be bound before the bus started, or eons after\nthe bus started and the hardware would be properly initialized in all\ncases.\n\nBugLink: https://github.com/thesofproject/linux/is\n---truncated---"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soundwire: revisitar la vinculaci\u00f3n/desvinculaci\u00f3n del controlador y las devoluciones de llamada. En la sonda SoundWire, almacenamos un puntero desde las operaciones del controlador en la estructura \"slave\". Esto puede provocar errores en el kernel al desvincular los controladores de c\u00f3dec, por ejemplo, con la siguiente secuencia para eliminar el controlador de la m\u00e1quina y el controlador de c\u00f3dec: /sbin/modprobe -r snd_soc_sof_sdw /sbin/modprobe -r snd_soc_rt711. Los detalles completos se pueden encontrar en el enlace de error a continuaci\u00f3n. Como referencia, los dos ejemplos siguientes muestran diferentes casos de operaciones/devoluciones de llamada del controlador que se invocan despu\u00e9s de la instrucci\u00f3n `.remove()` del controlador. kernel: ERROR: desreferencia de puntero NULL del kernel, direcci\u00f3n: 0000000000000150 kernel: Cola de trabajo: eventos cdns_update_slave_status_work [cadencia_soundwire] kernel: RIP: 0010:mutex_lock+0x19/0x30 kernel: Rastreo de llamadas: kernel: ? sdw_handle_slave_status+0x426/0xe00 [bus_soundwire 94ff184bf398570c3f8ff7efe9e32529f532e4ae] kernel: ? newidle_balance+0x26a/0x400 kernel: ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82] kernel: ERROR: no se puede manejar el error de p\u00e1gina para la direcci\u00f3n: ffffffffc07654c8 kernel: Cola de trabajo: pm pm_runtime_work kernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus] kernel: Rastreo de llamadas: kernel: kernel: sdw_cdns_clock_stop+0xb5/0x1b0 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82] kernel: intel_suspend_runtime+0x5f/0x120 [soundwire_intel aca858f7c87048d3152a4a41bb68abb9b663a1dd] kernel: ? dpm_sysfs_remove+0x60/0x60 Esto no se detect\u00f3 previamente en las pruebas de Intel, ya que estas primero eliminan el dispositivo PCI principal y apagan el bus. La secuencia anterior es un caso excepcional que mantiene el bus operativo, pero sin un controlador vinculado. Al intentar resolver este error del kernel, se hizo evidente que el bus SoundWire existente no gestiona bien el caso de desvinculaci\u00f3n. el commit 528be501b7d4a (\"soundwire: sdw_slave: a\u00f1adir estructura probe_complete y nuevos campos\") a\u00f1adi\u00f3 una variable de estado \"probed\" y una finalizaci\u00f3n de estructura \"probe_complete\". Sin embargo, este estado no se restablece al eliminar el dispositivo y, del mismo modo, la prueba \"probe complete\" no se reinicializa, por lo que las pruebas de vinculaci\u00f3n/desvinculaci\u00f3n/vinculaci\u00f3n fallar\u00edan. El tiempo de espera utilizado antes de la devoluci\u00f3n de llamada \"update_status\" tambi\u00e9n fue una mala idea en retrospectiva; no deber\u00eda haber suposiciones sobre el tiempo que determina si un controlador est\u00e1 vinculado a un dispositivo y cu\u00e1ndo. Un borrador inicial se bas\u00f3 en device_lock() y se prob\u00f3 device_unlock(). Esto result\u00f3 ser demasiado complicado, con interbloqueos creados durante las secuencias de suspensi\u00f3n-reinicio, que tambi\u00e9n utilizan el mismo device_lock/unlock() que las secuencias de vinculaci\u00f3n/desvinculaci\u00f3n. En un dispositivo CometLake, un DSDT/BIOS defectuoso provoc\u00f3 reanudaciones falsas y el uso de device_lock() provoc\u00f3 bloqueos durante la suspensi\u00f3n. Tras varias semanas de pruebas y una ardua ingenier\u00eda inversa de interbloqueos en diferentes dispositivos, buscamos alternativas que no interfirieran con el n\u00facleo del dispositivo. Se utiliz\u00f3 con \u00e9xito un notificador de bus para realizar un seguimiento de los eventos DRIVER_BOUND y DRIVER_UNBIND. Esto solucion\u00f3 el problema de enlazar-desenlazar-enlazar en las pruebas, pero a\u00fan se puede solucionar con un caso l\u00edmite te\u00f3rico donde la memoria se libera mediante un `.remove` mientras se usa la devoluci\u00f3n de llamada. El notificador solo ayuda a garantizar que las devoluciones de llamada del controlador sean v\u00e1lidas, pero no que la memoria asignada en la sonda siga siendo v\u00e1lida mientras se invocan las devoluciones de llamada. Este parche sugiere la introducci\u00f3n de un nuevo ---truncado---"}], "lastModified": "2025-11-20T21:38:58.637", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "BB46D507-9C6C-4EFB-8C7E-F2B302DF084C", "versionEndExcluding": "5.15.61", "versionStartIncluding": "4.16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "5B42E453-8837-49D0-A5EF-03F818A6DC11", "versionEndExcluding": "5.18.18", "versionStartIncluding": "5.16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "A1A2A5A5-4598-4D7E-BA07-4660398D6C8F", "versionEndExcluding": "5.19.2", "versionStartIncluding": "5.19"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}