CVE-2022-50818
Unknown Unknown - Not Provided
Race Condition in Linux pm8001 SCSI Driver Causing System Hang

Publication date: 2025-12-30

Last updated on: 2025-12-30

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix running_req for internal abort commands Disabling the remote phy for a SATA disk causes a hang: root@(none)$ more /sys/class/sas_phy/phy-0:0:8/target_port_protocols sata root@(none)$ echo 0 > sys/class/sas_phy/phy-0:0:8/enable root@(none)$ [ 67.855950] sas: ex 500e004aaaaaaa1f phy08 change count has changed [ 67.920585] sd 0:0:2:0: [sdc] Synchronizing SCSI cache [ 67.925780] sd 0:0:2:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=DRIVER_OK [ 67.935094] sd 0:0:2:0: [sdc] Stopping disk [ 67.939305] sd 0:0:2:0: [sdc] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=DRIVER_OK ... [ 123.998998] INFO: task kworker/u192:1:642 blocked for more than 30 seconds. [ 124.005960] Not tainted 6.0.0-rc1-205202-gf26f8f761e83 #218 [ 124.012049] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 124.019872] task:kworker/u192:1 state:D stack:0 pid: 642 ppid: 2 flags:0x00000008 [ 124.028223] Workqueue: 0000:04:00.0_event_q sas_port_event_worker [ 124.034319] Call trace: [ 124.036758] __switch_to+0x128/0x278 [ 124.040333] __schedule+0x434/0xa58 [ 124.043820] schedule+0x94/0x138 [ 124.047045] schedule_timeout+0x2fc/0x368 [ 124.051052] wait_for_completion+0xdc/0x200 [ 124.055234] __flush_workqueue+0x1a8/0x708 [ 124.059328] sas_porte_broadcast_rcvd+0xa8/0xc0 [ 124.063858] sas_port_event_worker+0x60/0x98 [ 124.068126] process_one_work+0x3f8/0x660 [ 124.072134] worker_thread+0x70/0x700 [ 124.075793] kthread+0x1a4/0x1b8 [ 124.079014] ret_from_fork+0x10/0x20 The issue is that the per-device running_req read in pm8001_dev_gone_notify() never goes to zero and we never make progress. This is caused by missing accounting for running_req for when an internal abort command completes. In commit 2cbbf489778e ("scsi: pm8001: Use libsas internal abort support") we started to send internal abort commands as a proper sas_task. In this when we deliver a sas_task to HW the per-device running_req is incremented in pm8001_queue_command(). However it is never decremented for internal abort commnds, so decrement in pm8001_mpi_task_abort_resp().
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-30
Last Modified
2025-12-30
Generated
2026-05-07
AI Q&A
2025-12-30
EPSS Evaluated
2026-05-05
NVD
CVE-2022-50818
EUVD
EUVD-2022-55880
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is in the Linux kernel's SCSI pm8001 driver. It occurs because the running_req counter, which tracks active commands per device, is not properly decremented when internal abort commands complete. This causes the system to hang when disabling the remote phy for a SATA disk, as the running_req never reaches zero and the system cannot make progress, leading to blocked tasks and potential system hangs.


How can this vulnerability impact me? :

The vulnerability can cause the Linux system to hang or become unresponsive when disabling the remote phy for a SATA disk. This happens because the internal abort commands do not properly decrement the running_req counter, causing tasks to block indefinitely and potentially leading to system instability or downtime.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing system logs for hangs or blocked tasks related to SATA disks when disabling the remote phy. Specifically, checking the contents of /sys/class/sas_phy/phy-0:0:8/target_port_protocols to see if it shows 'sata', and then disabling the phy by echoing 0 to /sys/class/sas_phy/phy-0:0:8/enable. Afterwards, monitor the kernel logs (e.g., using dmesg) for messages indicating synchronization failures, disk stopping errors, and hung tasks such as 'task kworker/u192:1 blocked for more than 30 seconds'. Example commands include: more /sys/class/sas_phy/phy-0:0:8/target_port_protocols echo 0 > /sys/class/sas_phy/phy-0:0:8/enable dmesg | tail -n 50


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves avoiding disabling the remote phy for SATA disks, as this triggers the hang condition. Additionally, updating the Linux kernel to a version that includes the fix for the pm8001 driver (which properly decrements running_req for internal abort commands) will resolve the issue.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart