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]
Message-ID: <87dc535f-609f-040a-5c47-5b6bb5b17b59@huawei.com>
Date:   Tue, 25 Jan 2022 14:38:51 +0000
From:   John Garry <john.garry@...wei.com>
To:     Matthew Wilcox <willy@...radead.org>
CC:     <jejb@...ux.ibm.com>, <martin.petersen@...cle.com>,
        <artur.paszkiewicz@...el.com>, <jinpu.wang@...ud.ionos.com>,
        <chenxiang66@...ilicon.com>, <Ajish.Koshy@...rochip.com>,
        <yanaijie@...wei.com>, <linux-doc@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-scsi@...r.kernel.org>,
        <linuxarm@...wei.com>, <liuqi115@...wei.com>,
        <Viswas.G@...rochip.com>, <damien.lemoal@...nsource.wdc.com>
Subject: Re: [PATCH 05/16] scsi: libsas: Add struct sas_tmf_task

On 25/01/2022 14:15, Matthew Wilcox wrote:
>> Sure, but the pm8001 HW does has a 32b field, which is strange as the SAS
>> spec defines a 16b field in the task management Function information unit
>> "tag of task to be managed" field.
> My point is that it's only safe because the pm8001 driver already limits
> it to smaller than u16.
>  Seeing language like "should be enough" made
> me think you'd just assumed that it would be.

I can update that wording to be confident that u16 is enough.

>  Seeing a line like:
>          u32 tag = 0xdeadbeef, rc = 0, n_elem = 0;
> made me think it might not be; perhaps 0xdeadbeef was being used as
> a flag value somewhere in the driver.
> 
> For example ...
> 
> drivers/scsi/pm8001/pm8001_hwi.c:       int rc, tag = 0xdeadbeef;
> drivers/scsi/pm8001/pm8001_sas.c:       u32 tag = 0xdeadbeef, rc = 0, n_elem = 0;
> drivers/scsi/pm8001/pm8001_sas.c:       u32 tag = 0xdeadbeef;
> drivers/scsi/pm8001/pm80xx_hwi.c:                       if (ibutton0 == 0xdeadbeef && ibutton1 == 0xdeadbeef) {
> drivers/scsi/pm8001/pm80xx_hwi.c:       int rc, tag = 0xdeadbeef;
> 
> That doesn't seem to be the case though; as far as I can tell the
> tag value is never checked against 0xdeadbeef.
> .

Right, 0xdeadbeef is initially assigned just as a safety measure.

Thanks,
John

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ