{"id":"CVE-2026-89857","summary":"scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Hold qpair lock when sending NVMe LS reject\n\nqla_nvme_ls_reject_iocb() allocates from and advances the request ring\nthrough __qla2x00_alloc_iocbs() (which assumes the hardware_lock is\nheld) and qla2x00_start_iocbs() (which advances the ring and rings the\nrequest-in doorbell), but takes no lock itself. Two of its callers\ninvoke it without the producer lock held:\n\n - qla_nvme_xmt_ls_rsp(), the NVMe-FC .xmt_ls_rsp transport callback, on\n   its error path, and\n\n - qla2xxx_process_purls_pkt(), run from the purex work/DPC context.\n\nBoth use ha-\u003ebase_qpair, whose qp_lock_ptr is hardware_lock, so they can\nrun concurrently with normal I/O submission on the base ring and corrupt\nthe ring producer state, leading to duplicated or dropped commands. The\nthird caller, qla2xxx_process_purls_iocb(), runs inside\nqla24xx_process_response_queue() with the qpair lock already held and is\nsafe; that is also why the lock cannot be taken inside the helper itself\n(it would recursively re-acquire hardware_lock on the response path).\n\nTake qp_lock_ptr around the two unlocked callers and document the helper\nas caller-locked. Both run in process context, so spin_lock_irqsave() is\nused and nothing in the locked region sleeps.","modified":"2026-09-18T03:48:33.634487780Z","published":"2026-09-16T10:31:30.193Z","database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/89xxx/CVE-2026-89857.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/11834e5773e20fd3742d7eb900876e66b9e7d029"},{"type":"WEB","url":"https://git.kernel.org/stable/c/7eb618877503edbf17aa65e357a81bda1fc8f163"},{"type":"WEB","url":"https://git.kernel.org/stable/c/b02ff132017b28222187ebcf95ce7f4cb576cd36"},{"type":"WEB","url":"https://git.kernel.org/stable/c/b3a362466db6b8ec47cc537ac641ac197fa69b5d"},{"type":"WEB","url":"https://git.kernel.org/stable/c/f743488e4a203049f27ec5d8cd0caccc483af01e"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/89xxx/CVE-2026-89857.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89857"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"875386b98857822b77ac7f95bdf367b70af5b78c"},{"fixed":"7eb618877503edbf17aa65e357a81bda1fc8f163"},{"fixed":"b3a362466db6b8ec47cc537ac641ac197fa69b5d"},{"fixed":"11834e5773e20fd3742d7eb900876e66b9e7d029"},{"fixed":"b02ff132017b28222187ebcf95ce7f4cb576cd36"},{"fixed":"f743488e4a203049f27ec5d8cd0caccc483af01e"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-89857.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.6.0"},{"fixed":"6.6.157"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.7.0"},{"fixed":"6.12.110"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.51"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.2.5"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-89857.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}]}