vulnerability
Amazon Linux 2023: CVE-2025-21807: Medium priority package update for kernel6.12 (Multiple Advisories)
| Severity | CVSS | Published | Added | Modified |
|---|---|---|---|---|
| 4 | (AV:L/AC:H/Au:M/C:N/I:N/A:C) | Feb 27, 2025 | Jun 3, 2025 | Dec 4, 2025 |
Severity
4
CVSS
(AV:L/AC:H/Au:M/C:N/I:N/A:C)
Published
Feb 27, 2025
Added
Jun 3, 2025
Modified
Dec 4, 2025
Description
In the Linux kernel, the following vulnerability has been resolved:
block: fix queue freeze vs limits lock order in sysfs store methods
queue_attr_store() always freezes a device queue before calling the
attribute store operation. For attributes that control queue limits, the
store operation will also lock the queue limits with a call to
queue_limits_start_update(). However, some drivers (e.g. SCSI sd) may
need to issue commands to a device to obtain limit values from the
hardware with the queue limits locked. This creates a potential ABBA
deadlock situation if a user attempts to modify a limit (thus freezing
the device queue) while the device driver starts a revalidation of the
device queue limits.
Avoid such deadlock by not freezing the queue before calling the
->store_limit() method in struct queue_sysfs_entry and instead use the
queue_limits_commit_update_frozen helper to freeze the queue after taking
the limits lock.
This also removes taking the sysfs lock for the store_limit method as
it doesn't protect anything here, but creates even more nesting.
Hopefully it will go away from the actual sysfs methods entirely soon.
(commit log adapted from a similar patch from Damien Le Moal)
block: fix queue freeze vs limits lock order in sysfs store methods
queue_attr_store() always freezes a device queue before calling the
attribute store operation. For attributes that control queue limits, the
store operation will also lock the queue limits with a call to
queue_limits_start_update(). However, some drivers (e.g. SCSI sd) may
need to issue commands to a device to obtain limit values from the
hardware with the queue limits locked. This creates a potential ABBA
deadlock situation if a user attempts to modify a limit (thus freezing
the device queue) while the device driver starts a revalidation of the
device queue limits.
Avoid such deadlock by not freezing the queue before calling the
->store_limit() method in struct queue_sysfs_entry and instead use the
queue_limits_commit_update_frozen helper to freeze the queue after taking
the limits lock.
This also removes taking the sysfs lock for the store_limit method as
it doesn't protect anything here, but creates even more nesting.
Hopefully it will go away from the actual sysfs methods entirely soon.
(commit log adapted from a similar patch from Damien Le Moal)
Solutions
amazon-linux-2023-upgrade-bpftoolamazon-linux-2023-upgrade-bpftool-debuginfoamazon-linux-2023-upgrade-kernel6-12amazon-linux-2023-upgrade-kernel6-12-debuginfoamazon-linux-2023-upgrade-kernel6-12-debuginfo-common-aarch64amazon-linux-2023-upgrade-kernel6-12-debuginfo-common-x86-64amazon-linux-2023-upgrade-kernel6-12-modules-extraamazon-linux-2023-upgrade-kernel-develamazon-linux-2023-upgrade-kernel-headersamazon-linux-2023-upgrade-kernel-libbpfamazon-linux-2023-upgrade-kernel-libbpf-debuginfoamazon-linux-2023-upgrade-kernel-libbpf-develamazon-linux-2023-upgrade-kernel-libbpf-staticamazon-linux-2023-upgrade-kernel-livepatch-6-12-29-33-102amazon-linux-2023-upgrade-kernel-modules-extra-commonamazon-linux-2023-upgrade-kernel-toolsamazon-linux-2023-upgrade-kernel-tools-debuginfoamazon-linux-2023-upgrade-kernel-tools-develamazon-linux-2023-upgrade-perf6-12amazon-linux-2023-upgrade-perf6-12-debuginfoamazon-linux-2023-upgrade-python3-perf6-12amazon-linux-2023-upgrade-python3-perf6-12-debuginfo
NEW
Explore Exposure Command
Confidently identify and prioritize exposures from endpoint to cloud with full attack surface visibility and threat-aware risk context.