linux-kernel - Re: [PATCH 4.4 128/268] scsi: sd: Keep disk read-only when re-reading partition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 13 Jun 2018 22:25:10 +0100
From:   Ben Hutchings <ben.hutchings@...ethink.co.uk>
To:     Jeremy Cline <jeremy@...ine.org>,
        "Martin K. Petersen" <martin.petersen@...cle.com>
Cc:     stable@...r.kernel.org, Li Ning <lining916740672@...oud.com>,
        Sasha Levin <alexander.levin@...rosoft.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4.4 128/268] scsi: sd: Keep disk read-only when
 re-reading partition

On Mon, 2018-05-28 at 12:01 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Jeremy Cline <jeremy@...ine.org>
> 
> [ Upstream commit 20bd1d026aacc5399464f8328f305985c493cde3 ]
> 
> If the read-only flag is true on a SCSI disk, re-reading the partition
> table sets the flag back to false.
> 
> To observe this bug, you can run:
> 
> 1. blockdev --setro /dev/sda
> 2. blockdev --rereadpt /dev/sda
> 3. blockdev --getro /dev/sda
> 
> This commit reads the disk's old state and combines it with the device
> disk-reported state rather than unconditionally marking it as RW.

It seems to me that this change is likely to cause a regression: if a
SCSI device switches from read-only to read-write state then a
subsequent rescan won't automatically change the block device to read-
write state.  The administrator will have to use the blockdev command
too.

Even if this change in behaviour is acceptable, this commit does not
implement it consistently.  The function starts by clearing the ro flag
and this commit only changes one of the three exit paths to preserve
it.  (The log message about Write Protect status also reports the
underlying SCSI device flag and not the combined ro flag, but maybe
that was intentional.)

I think this commit should be reverted, both in stable and upstream.  A
proper fix would involve splitting the ro flag into two flags—one
controlled by user-space and one read from the device—with the
effective read-only status being the logical-or of those two.

Ben.

> Reported-by: Li Ning <lining916740672@...oud.com>
> Signed-off-by: Jeremy Cline <jeremy@...ine.org>
> Signed-off-by: Martin K. Petersen <martin.petersen@...cle.com>
> Signed-off-by: Sasha Levin <alexander.levin@...rosoft.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> ---
>  drivers/scsi/sd.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -2395,6 +2395,7 @@ sd_read_write_protect_flag(struct scsi_d
>  	int res;
>  	struct scsi_device *sdp = sdkp->device;
>  	struct scsi_mode_data data;
> +	int disk_ro = get_disk_ro(sdkp->disk);
>  	int old_wp = sdkp->write_prot;
>  
>  	set_disk_ro(sdkp->disk, 0);
> @@ -2435,7 +2436,7 @@ sd_read_write_protect_flag(struct scsi_d
>  			  "Test WP failed, assume Write Enabled\n");
>  	} else {
>  		sdkp->write_prot = ((data.device_specific & 0x80) != 0);
> -		set_disk_ro(sdkp->disk, sdkp->write_prot);
> +		set_disk_ro(sdkp->disk, sdkp->write_prot || disk_ro);
>  		if (sdkp->first_scan || old_wp != sdkp->write_prot) {
>  			sd_printk(KERN_NOTICE, sdkp, "Write Protect is %s\n",
> 				  sdkp->write_prot ? "on" : "off");

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom