Skip to content

In the Linux kernel, the following vulnerability has been...

Moderate severity Unreviewed Published Jan 11, 2025 to the GitHub Advisory Database • Updated Jan 16, 2025

Package

No package listedSuggest a package

Affected versions

Unknown

Patched versions

Unknown

Description

In the Linux kernel, the following vulnerability has been resolved:

block: Prevent potential deadlocks in zone write plug error recovery

Zone write plugging for handling writes to zones of a zoned block
device always execute a zone report whenever a write BIO to a zone
fails. The intent of this is to ensure that the tracking of a zone write
pointer is always correct to ensure that the alignment to a zone write
pointer of write BIOs can be checked on submission and that we can
always correctly emulate zone append operations using regular write
BIOs.

However, this error recovery scheme introduces a potential deadlock if a
device queue freeze is initiated while BIOs are still plugged in a zone
write plug and one of these write operation fails. In such case, the
disk zone write plug error recovery work is scheduled and executes a
report zone. This in turn can result in a request allocation in the
underlying driver to issue the report zones command to the device. But
with the device queue freeze already started, this allocation will
block, preventing the report zone execution and the continuation of the
processing of the plugged BIOs. As plugged BIOs hold a queue usage
reference, the queue freeze itself will never complete, resulting in a
deadlock.

Avoid this problem by completely removing from the zone write plugging
code the use of report zones operations after a failed write operation,
instead relying on the device user to either execute a report zones,
reset the zone, finish the zone, or give up writing to the device (which
is a fairly common pattern for file systems which degrade to read-only
after write failures). This is not an unreasonnable requirement as all
well-behaved applications, FSes and device mapper already use report
zones to recover from write errors whenever possible by comparing the
current position of a zone write pointer with what their assumption
about the position is.

The changes to remove the automatic error recovery are as follows:

  • Completely remove the error recovery work and its associated
    resources (zone write plug list head, disk error list, and disk
    zone_wplugs_work work struct). This also removes the functions
    disk_zone_wplug_set_error() and disk_zone_wplug_clear_error().

  • Change the BLK_ZONE_WPLUG_ERROR zone write plug flag into
    BLK_ZONE_WPLUG_NEED_WP_UPDATE. This new flag is set for a zone write
    plug whenever a write opration targetting the zone of the zone write
    plug fails. This flag indicates that the zone write pointer offset is
    not reliable and that it must be updated when the next report zone,
    reset zone, finish zone or disk revalidation is executed.

  • Modify blk_zone_write_plug_bio_endio() to set the
    BLK_ZONE_WPLUG_NEED_WP_UPDATE flag for the target zone of a failed
    write BIO.

  • Modify the function disk_zone_wplug_set_wp_offset() to clear this
    new flag, thus implementing recovery of a correct write pointer
    offset with the reset (all) zone and finish zone operations.

  • Modify blkdev_report_zones() to always use the disk_report_zones_cb()
    callback so that disk_zone_wplug_sync_wp_offset() can be called for
    any zone marked with the BLK_ZONE_WPLUG_NEED_WP_UPDATE flag.
    This implements recovery of a correct write pointer offset for zone
    write plugs marked with BLK_ZONE_WPLUG_NEED_WP_UPDATE and within
    the range of the report zones operation executed by the user.

  • Modify blk_revalidate_seq_zone() to call
    disk_zone_wplug_sync_wp_offset() for all sequential write required
    zones when a zoned block device is revalidated, thus always resolving
    any inconsistency between the write pointer offset of zone write
    plugs and the actual write pointer position of sequential zones.

References

Published by the National Vulnerability Database Jan 11, 2025
Published to the GitHub Advisory Database Jan 11, 2025
Last updated Jan 16, 2025

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Local
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

EPSS score

0.043%
(11th percentile)

Weaknesses

CVE ID

CVE-2024-55642

GHSA ID

GHSA-6mfj-59wv-v5jx

Source code

No known source code

Dependabot alerts are not supported on this advisory because it does not have a package from a supported ecosystem with an affected and fixed version.

Learn more about GitHub language support

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.