Look up another CVE · open CVE-2026-89847 in the interactive tracker

CVE-2026-89847

scsi: qla2xxx: Avoid double completion in async IOCB timeout

9.8 EPSS 0.7% AV:N

Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem drivers/scsi. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-89847 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	fixedDLA-4841-1 · 2026-10-17 · text	6.1.190-1	Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixie	fixedDSA-6528-1 · 2026-09-29 · text	6.12.111-1	Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.2.6-1	Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.2.6-1	Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12	fixedDLA-4817-1 · 2026-10-04 · text	6.12.111-1~deb12u1	Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates "if (sp->comp) complete(sp->comp)"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout().

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/scsi/qla2xxx/qla_init.c

What this is: QLOGIC QLA2XXX FC-SCSI DRIVERMAINTAINERS section matched on drivers/scsi/qla2xxx/ · linux-scsi@vger.kernel.org · Supported
Kernel module: qla2xxx

Check it on the machine

grep -w CONFIG_SCSI_QLA_FC /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w qla2xxx

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, s390x/s390x
forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, s390x/s390x
bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp

M: a module where it is built at all; some flavours do not build it

Build switch: CONFIG_SCSI_QLA_FC

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-09-16 (33 days ago)source
CVSS: 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: network (AV:N)source
EPSS: 0.68%, higher than 51.3% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: drivers/scsi

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
4.19	5.10.270	71a7b6e3c7f1
4.19	5.15.221	7257b5e1fb6c
4.19	6.1.188	f5b660e0b0d9
4.19	6.6.157	6e217a9482ea
4.19	6.12.110	d6d856c722f4
4.19	6.18.51	9fa1d71233a8
4.19	7.2.5	845d4abd92cd
4.19	7.3	bb45bc4bd53c

Debian advisories

Advisory	Date	Shipped to	Debian
DLA-4841-1	2026-10-17	bookworm 6.1.190-1	tracker
DLA-4817-1	2026-10-04	bookworm 6.12.111-1~deb12u1	tracker
DSA-6528-1	2026-09-29	trixie 6.12.111-1	tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:NAttack vector, network: qla2x00_async_iocb_timeout() runs on fabric login, CT/SNS, and target-mode NACK IOCBs; a remote FC/FCoE/FCIP peer delays then completes those exchanges so the response ISR races the timer. That is a SAN-network path, consistent with other qla2xxx FC-peer memory-corruption scores.
AC:LAttack complexity, low: The peer controls both sides of the race by withholding the login/CT/NACK completion until the async timer fires, then posting it so the ISR removes the SRB while timeout still calls sp->done(). Abort failure is also attacker-driven via GFP_ATOMIC SRB exhaustion or ISP-abort from injected link errors.
PR:NPrivileges required, none: Fabric login, name-server CT, and target-mode notify-ack run in driver ISR/DPC context with no Linux credential or capability check. FC-SP/EDIF is opt-in and rare, so a fabric peer needs no account on the victim host.
UI:NUser interaction, none: Discovery, PLOGI, and NACK IOCBs are posted automatically on link-up, RSCN, and inbound ELS. The async timer and response ISR then run without any victim mount, open, or administrator action.
S:UScope, unchanged: Double completion corrupts host-kernel SRB and completion state inside the qla2xxx driver. The impact stays in that kernel authority and is not a VM escape, IOMMU bypass, or other cross-boundary breakout.
C:HConfidentiality impact, high: The extra sp->done() drops the SRB INIT kref twice so the timeout path later frees a mempool SRB still in use, a use-after-free that can disclose reused heap contents. The CTRL_VP path also complete()s a reclaimed on-stack completion.
I:HIntegrity impact, high: The same mempool SRB use-after-free and complete() write into a freed stack frame are kernel write primitives. Reuse of the freed SRB can hijack control flow rather than producing only a clean timeout.
A:HAvailability impact, high: Double completion of a live SRB is a use-after-free that oopses or panics the host, as in the original switch-CT crash in qla2x00_chk_ms_status from the response ISR, taking down storage on the adapter.