CVE-2022-50532: scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix possible resource leaks in mpt3sastransportportadd()
In mpt3sastransportportadd(), if sasrphyadd() returns error, sasrphyfree() needs be called to free the resource allocated in sasenddevicealloc(). Otherwise a kernel crash will happen:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G W 6.1.0-rc1+ #189 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : devicedel+0x54/0x3d0 lr : devicedel+0x37c/0x3d0 Call trace: devicedel+0x54/0x3d0 attributecontainerclassdevicedel+0x28/0x38 transportremoveclassdev+0x6c/0x80 attributecontainerdevicetrigger+0x108/0x110 transportremovedevice+0x28/0x38 sasrphyremove+0x50/0x78 [scsitransportsas] sasportdelete+0x30/0x148 [scsitransportsas] dosasphydelete+0x78/0x80 [scsitransportsas] deviceforeachchild+0x68/0xb0 sasremovechildren+0x30/0x50 [scsitransportsas] sasrphyremove+0x38/0x78 [scsitransportsas] sasportdelete+0x30/0x148 [scsitransportsas] dosasphydelete+0x78/0x80 [scsitransportsas] deviceforeachchild+0x68/0xb0 sasremovechildren+0x30/0x50 [scsitransportsas] sasremovehost+0x20/0x38 [scsitransportsas] scsihremove+0xd8/0x420 [mpt3sas]
Because transportadddevice() is not called when sasrphyadd() fails, the device is not added. When sasrphyremove() is subsequently called to remove the device in the remove() path, a NULL pointer dereference happens.
Affected Software
Remediation
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems running the Linux kernel with the mpt3sas SCSI driver are the relevant population. Exploitation requires local access with low privileges; the CVSS vector does not indicate network or user-interaction requirements.
What condition triggers the crash?
The failure path is reached when sas_rphy_add() returns an error during mpt3sas transport port addition. The missing sas_rphy_free() leaves an allocated resource unmanaged, which can later lead to a kernel NULL-pointer dereference and crash.
How can I tell whether a system has encountered this problem?
Check kernel crash logs for a NULL-pointer dereference involving device_del, sas_rphy_remove, sas_port_delete, or do_sas_phy_delete, with scsi_transport_sas shown in the call trace. The provided example also shows the kernel becoming tainted and a crash occurring during SAS device removal paths.
What should be done if the system is affected?
Apply the available patch. The referenced stable kernel commits contain the fix for the error path that frees the SAS rphy resource when sas_rphy_add() fails.