linux-kernel - Re: [PATCH 5/5] scsi: Set allocation length to 255 for ATA Information VPD page

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:   Thu, 15 Apr 2021 13:42:02 +0100
From:   Nix <nix@...eri.org.uk>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Khalid Aziz <khalid@...ehiking.org>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Bernd Schubert <bernd.schubert@...m.fraunhofer.de>,
        Christoph Hellwig <hch@....de>, linux-scsi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] scsi: Set allocation length to 255 for ATA Information VPD page

On 14 Apr 2021, Maciej W. Rozycki stated:

> Set the allocation length to 255 for the ATA Information VPD page 
> requested in the WRITE SAME handler, so as not to limit information 
> examined by `scsi_get_vpd_page' in the supported vital product data 
> pages unnecessarily.
>
> Originally it was thought that Areca hardware may have issues with a 
> valid allocation length supplied for a VPD inquiry, however older SCSI 
> standard revisions[1] consider 255 the maximum length allowed and what 

Aaaah. That explains a lot! (Not that I can remember what SCSI standard
rev that Areca firmware claimed to implement. I know I never updated the
firmware, so it's going to be something no newer than mid-2009 and
probably quite a bit older.)

> Nix,
>
>  I can see you're still around.  Would you therefore please be so kind 
> as to verify this change with your Areca hardware if you still have it?

It's been up in the loft for years, but I'll get it out this weekend and
give it a spin :) this'll let me make sure the disks still spin as well,
which matters for an in-case-of-lightning-strike disaster-recovery
backup box.

(I just hope this kernel boots on it at all. It's about three years
since I retired it... let's see!)

>  It looks to me like you were thinking in the right direction with: 
> <https://lore.kernel.org/linux-scsi/87vc3nuipg.fsf@spindle.srvr.nix/>. 

It's the sort of mistake I could see myself making: an easy mistake to
make when so many things in C require buffer size - 1 or you get a
disastrous security hole...

-- 
NULL && (void)