DEBIAN-CVE-2023-53586

See a problem?
Please try reporting it to the source first.
Source
https://security-tracker.debian.org/tracker/CVE-2023-53586
Import Source
https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2023-53586.json
JSON Data
https://api.test.osv.dev/v1/vulns/DEBIAN-CVE-2023-53586
Upstream
Published
2025-10-04T16:15:54Z
Modified
2025-10-05T09:18:32.078009Z
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix multiple LUNRESET handling This fixes a bug where an initiator thinks a LUNRESET has cleaned up running commands when it hasn't. The bug was added in commit 51ec502a3266 ("target: Delete tmr from list before processing"). The problem occurs when: 1. We have N I/O cmds running in the target layer spread over 2 sessions. 2. The initiator sends a LUNRESET for each session. 3. session1's LUNRESET loops over all the running commands from both sessions and moves them to its local draintasklist. 4. session2's LUNRESET does not see the LUNRESET from session1 because the commit above has it remove itself. session2 also does not see any commands since the other reset moved them off the state lists. 5. sessions2's LUNRESET will then complete with a successful response. 6. sessions2's inititor believes the running commands on its session are now cleaned up due to the successful response and cleans up the running commands from its side. It then restarts them. 7. The commands do eventually complete on the backend and the target starts to return aborted task statuses for them. The initiator will either throw a invalid ITT error or might accidentally lookup a new task if the ITT has been reallocated already. Fix the bug by reverting the patch, and serialize the execution of LUNRESETs and Preempt and Aborts. Also prevent us from waiting on LUNRESETs in coretmrdraintmrlist, because it turns out the original patch fixed a bug that was not mentioned. For LUNRESET1 coretmrdraintmrlist can see a second LUNRESET and wait on it. Then the second reset will run coretmrdraintmr_list and see the first reset and wait on it resulting in a deadlock.

References

Affected packages

Debian:11 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
5.10.191-1

Affected versions

5.*

5.10.46-4
5.10.46-5
5.10.70-1~bpo10+1
5.10.70-1
5.10.84-1
5.10.92-1~bpo10+1
5.10.92-1
5.10.92-2
5.10.103-1~bpo10+1
5.10.103-1
5.10.106-1
5.10.113-1
5.10.120-1~bpo10+1
5.10.120-1
5.10.127-1
5.10.127-2~bpo10+1
5.10.127-2
5.10.136-1
5.10.140-1
5.10.148-1
5.10.149-1
5.10.149-2
5.10.158-1
5.10.158-2
5.10.162-1
5.10.178-1
5.10.178-2
5.10.178-3
5.10.179-1
5.10.179-2
5.10.179-3
5.10.179-4
5.10.179-5

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

Debian:12 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.1.37-1

Affected versions

6.*

6.1.27-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

Debian:13 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.3.7-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

Debian:14 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.3.7-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}