[PATCH 1/2] ata: libata-scsi: Fix system suspend for a security locked drive

[PATCH 1/2] ata: libata-scsi: Fix system suspend for a security locked drive

[Niklas Cassel]

Commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status
handling") fixed ata_to_sense_error() to properly generate sense key
ABORTED COMMAND (without any additional sense code), instead of the
previous bogus sense key ILLEGAL REQUEST with the additional sense code
UNALIGNED WRITE COMMAND, for a failed command.

However, this broke suspend for Security locked drives (drives that have
Security enabled, and have not been Security unlocked by boot firmware).

The reason for this is that the SCSI disk driver, for the Synchronize
Cache command only, treats any sense data with sense key ILLEGAL REQUEST
as a successful command (regardless of ASC / ASCQ).

After commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error()
status handling") the code that treats any sense data with sense key
ILLEGAL REQUEST as a successful command is no longer applicable, so the
command fails, which causes the system suspend to be aborted:

  sd 1:0:0:0: PM: dpm_run_callback(): scsi_bus_suspend returns -5
  sd 1:0:0:0: PM: failed to suspend async: error -5
  PM: Some devices failed to suspend, or early wake event detected

To make suspend work once again, for a Security locked device only,
return sense data LOGICAL UNIT ACCESS NOT AUTHORIZED, the actual sense
data which a real SCSI device would have returned if locked.
The SCSI disk driver treats this sense data as a successful command.

Cc: stable@vger.kernel.org
Reported-by: Ilia Baryshnikov <qwelias@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220704
Fixes: cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling")
Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 drivers/ata/libata-scsi.c | 7 +++++++
 include/linux/ata.h       | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index b43a3196e2be..58efa88e4882 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -992,6 +992,13 @@ static void ata_gen_ata_sense(struct ata_queued_cmd *qc)
 		return;
 	}
 
+	if (ata_id_is_locked(dev->id)) {
+		/* Security locked */
+		/* LOGICAL UNIT ACCESS NOT AUTHORIZED */
+		ata_scsi_set_sense(dev, cmd, DATA_PROTECT, 0x74, 0x71);
+		return;
+	}
+
 	if (!(qc->flags & ATA_QCFLAG_RTF_FILLED)) {
 		ata_dev_dbg(dev,
 			    "Missing result TF: reporting aborted command\n");
diff --git a/include/linux/ata.h b/include/linux/ata.h
index 792e10a09787..c9013e472aa3 100644
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -566,6 +566,7 @@ struct ata_bmdma_prd {
 #define ata_id_has_ncq(id)	((id)[ATA_ID_SATA_CAPABILITY] & (1 << 8))
 #define ata_id_queue_depth(id)	(((id)[ATA_ID_QUEUE_DEPTH] & 0x1f) + 1)
 #define ata_id_removable(id)	((id)[ATA_ID_CONFIG] & (1 << 7))
+#define ata_id_is_locked(id)	(((id)[ATA_ID_DLF] & 0x7) == 0x7)
 #define ata_id_has_atapi_AN(id)	\
 	((((id)[ATA_ID_SATA_CAPABILITY] != 0x0000) && \
 	  ((id)[ATA_ID_SATA_CAPABILITY] != 0xffff)) && \
-- 
2.51.1

[PATCH 2/2] ata: libata-core: Set capacity to zero for a security locked drive

[Niklas Cassel]

For Security locked drives (drives that have Security enabled, and have
not been Security unlocked by boot firmware), the automatic partition
scanning will result in the user being spammed with errors such as:

  ata5.00: failed command: READ DMA
  ata5.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 7 dma 4096 in
           res 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
  ata5.00: status: { DRDY ERR }
  ata5.00: error: { ABRT }
  sd 4:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
  sd 4:0:0:0: [sda] tag#7 Sense Key : Aborted Command [current]
  sd 4:0:0:0: [sda] tag#7 Add. Sense: No additional sense information

during boot, because most commands except for IDENTIFY will be aborted by
a Security locked drive.

For a Security locked drive, set capacity to zero, so that no automatic
partition scanning will happen.

If the user later unlocks the drive using e.g. hdparm, the close() by the
user space application should trigger a revalidation of the drive.

Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 drivers/ata/libata-core.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 2a210719c4ce..f48fb63d7e85 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3006,6 +3006,16 @@ int ata_dev_configure(struct ata_device *dev)
 		}
 
 		dev->n_sectors = ata_id_n_sectors(id);
+		if (ata_id_is_locked(id)) {
+			/*
+			 * If Security locked, set capacity to zero to prevent
+			 * any I/O, e.g. partition scanning, as any I/O to a
+			 * locked drive will result in user visible errors.
+			 */
+			ata_dev_info(dev,
+				"Security locked, setting capacity to zero\n");
+			dev->n_sectors = 0;
+		}
 
 		/* get current R/W Multiple count setting */
 		if ((dev->id[47] >> 8) == 0x80 && (dev->id[59] & 0x100)) {
-- 
2.51.1

Re: [PATCH 2/2] ata: libata-core: Set capacity to zero for a security locked drive

[Damien Le Moal]

On 11/19/25 11:13 PM, Niklas Cassel wrote:
> For Security locked drives (drives that have Security enabled, and have
> not been Security unlocked by boot firmware), the automatic partition
> scanning will result in the user being spammed with errors such as:
> 
>   ata5.00: failed command: READ DMA
>   ata5.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 7 dma 4096 in
>            res 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>   ata5.00: status: { DRDY ERR }
>   ata5.00: error: { ABRT }
>   sd 4:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
>   sd 4:0:0:0: [sda] tag#7 Sense Key : Aborted Command [current]
>   sd 4:0:0:0: [sda] tag#7 Add. Sense: No additional sense information
> 
> during boot, because most commands except for IDENTIFY will be aborted by
> a Security locked drive.
> 
> For a Security locked drive, set capacity to zero, so that no automatic
> partition scanning will happen.
> 
> If the user later unlocks the drive using e.g. hdparm, the close() by the
> user space application should trigger a revalidation of the drive.
> 
> Signed-off-by: Niklas Cassel <cassel@kernel.org>

Looks good.

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>

-- 
Damien Le Moal
Western Digital Research

Re: [PATCH 2/2] ata: libata-core: Set capacity to zero for a security locked drive

[Martin K. Petersen]

Niklas,

> For Security locked drives (drives that have Security enabled, and have
> not been Security unlocked by boot firmware), the automatic partition
> scanning will result in the user being spammed with errors such as:

Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>

-- 
Martin K. Petersen

Re: [PATCH 2/2] ata: libata-core: Set capacity to zero for a security locked drive

[Hannes Reinecke]

On 11/19/25 15:13, Niklas Cassel wrote:
> For Security locked drives (drives that have Security enabled, and have
> not been Security unlocked by boot firmware), the automatic partition
> scanning will result in the user being spammed with errors such as:
> 
>    ata5.00: failed command: READ DMA
>    ata5.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 7 dma 4096 in
>             res 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>    ata5.00: status: { DRDY ERR }
>    ata5.00: error: { ABRT }
>    sd 4:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
>    sd 4:0:0:0: [sda] tag#7 Sense Key : Aborted Command [current]
>    sd 4:0:0:0: [sda] tag#7 Add. Sense: No additional sense information
> 
> during boot, because most commands except for IDENTIFY will be aborted by
> a Security locked drive.
> 
> For a Security locked drive, set capacity to zero, so that no automatic
> partition scanning will happen.
> 
> If the user later unlocks the drive using e.g. hdparm, the close() by the
> user space application should trigger a revalidation of the drive.
> 
> Signed-off-by: Niklas Cassel <cassel@kernel.org>
> ---
>   drivers/ata/libata-core.c | 10 ++++++++++
>   1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 2a210719c4ce..f48fb63d7e85 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -3006,6 +3006,16 @@ int ata_dev_configure(struct ata_device *dev)
>   		}
>   
>   		dev->n_sectors = ata_id_n_sectors(id);
> +		if (ata_id_is_locked(id)) {
> +			/*
> +			 * If Security locked, set capacity to zero to prevent
> +			 * any I/O, e.g. partition scanning, as any I/O to a
> +			 * locked drive will result in user visible errors.
> +			 */
> +			ata_dev_info(dev,
> +				"Security locked, setting capacity to zero\n");
> +			dev->n_sectors = 0;
> +		}
>   
>   		/* get current R/W Multiple count setting */
>   		if ((dev->id[47] >> 8) == 0x80 && (dev->id[59] & 0x100)) {

Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

Re: [PATCH 1/2] ata: libata-scsi: Fix system suspend for a security locked drive

[Damien Le Moal]

On 11/19/25 11:13 PM, Niklas Cassel wrote:
> Commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status
> handling") fixed ata_to_sense_error() to properly generate sense key
> ABORTED COMMAND (without any additional sense code), instead of the
> previous bogus sense key ILLEGAL REQUEST with the additional sense code
> UNALIGNED WRITE COMMAND, for a failed command.
> 
> However, this broke suspend for Security locked drives (drives that have
> Security enabled, and have not been Security unlocked by boot firmware).
> 
> The reason for this is that the SCSI disk driver, for the Synchronize
> Cache command only, treats any sense data with sense key ILLEGAL REQUEST
> as a successful command (regardless of ASC / ASCQ).
> 
> After commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error()
> status handling") the code that treats any sense data with sense key
> ILLEGAL REQUEST as a successful command is no longer applicable, so the
> command fails, which causes the system suspend to be aborted:
> 
>   sd 1:0:0:0: PM: dpm_run_callback(): scsi_bus_suspend returns -5
>   sd 1:0:0:0: PM: failed to suspend async: error -5
>   PM: Some devices failed to suspend, or early wake event detected
> 
> To make suspend work once again, for a Security locked device only,
> return sense data LOGICAL UNIT ACCESS NOT AUTHORIZED, the actual sense
> data which a real SCSI device would have returned if locked.
> The SCSI disk driver treats this sense data as a successful command.
> 
> Cc: stable@vger.kernel.org
> Reported-by: Ilia Baryshnikov <qwelias@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220704
> Fixes: cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling")
> Signed-off-by: Niklas Cassel <cassel@kernel.org>

I think that adding this to ata_scsi_flush_xlat() would be better, but this way
may be able to catch more cases like sync failure. So for now, let's go with this.

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH 1/2] ata: libata-scsi: Fix system suspend for a security locked drive

[Martin K. Petersen]

Niklas,

> Commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error()
> status handling") fixed ata_to_sense_error() to properly generate
> sense key ABORTED COMMAND (without any additional sense code), instead
> of the previous bogus sense key ILLEGAL REQUEST with the additional
> sense code UNALIGNED WRITE COMMAND, for a failed command.

Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>

-- 
Martin K. Petersen

Re: [PATCH 1/2] ata: libata-scsi: Fix system suspend for a security locked drive

[Hannes Reinecke]

On 11/19/25 15:13, Niklas Cassel wrote:
> Commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status
> handling") fixed ata_to_sense_error() to properly generate sense key
> ABORTED COMMAND (without any additional sense code), instead of the
> previous bogus sense key ILLEGAL REQUEST with the additional sense code
> UNALIGNED WRITE COMMAND, for a failed command.
> 
> However, this broke suspend for Security locked drives (drives that have
> Security enabled, and have not been Security unlocked by boot firmware).
> 
> The reason for this is that the SCSI disk driver, for the Synchronize
> Cache command only, treats any sense data with sense key ILLEGAL REQUEST
> as a successful command (regardless of ASC / ASCQ).
> 
> After commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error()
> status handling") the code that treats any sense data with sense key
> ILLEGAL REQUEST as a successful command is no longer applicable, so the
> command fails, which causes the system suspend to be aborted:
> 
>    sd 1:0:0:0: PM: dpm_run_callback(): scsi_bus_suspend returns -5
>    sd 1:0:0:0: PM: failed to suspend async: error -5
>    PM: Some devices failed to suspend, or early wake event detected
> 
> To make suspend work once again, for a Security locked device only,
> return sense data LOGICAL UNIT ACCESS NOT AUTHORIZED, the actual sense
> data which a real SCSI device would have returned if locked.
> The SCSI disk driver treats this sense data as a successful command.
> 
> Cc: stable@vger.kernel.org
> Reported-by: Ilia Baryshnikov <qwelias@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220704
> Fixes: cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling")
> Signed-off-by: Niklas Cassel <cassel@kernel.org>
> ---
>   drivers/ata/libata-scsi.c | 7 +++++++
>   include/linux/ata.h       | 1 +
>   2 files changed, 8 insertions(+)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

Re: [PATCH 1/2] ata: libata-scsi: Fix system suspend for a security locked drive

[Niklas Cassel]

On Wed, 19 Nov 2025 15:13:14 +0100, Niklas Cassel wrote:
> Commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status
> handling") fixed ata_to_sense_error() to properly generate sense key
> ABORTED COMMAND (without any additional sense code), instead of the
> previous bogus sense key ILLEGAL REQUEST with the additional sense code
> UNALIGNED WRITE COMMAND, for a failed command.
> 
> However, this broke suspend for Security locked drives (drives that have
> Security enabled, and have not been Security unlocked by boot firmware).
> 
> [...]

Applied to libata/linux.git (for-6.18-fixes), thanks!

[1/2] ata: libata-scsi: Fix system suspend for a security locked drive
      https://git.kernel.org/libata/linux/c/b1189068
[2/2] ata: libata-core: Set capacity to zero for a security locked drive
      https://git.kernel.org/libata/linux/c/91842ed8

Kind regards,
Niklas