linux-kernel - Re: [PATCH] scsi: ses: Handle enclosure with just a primary component gracefully

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: <nycvar.YFH.7.76.2304100037190.29760@cbobk.fhfr.pm>
Date:   Mon, 10 Apr 2023 00:38:36 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     Ding Hui <dinghui@...gfor.com.cn>
cc:     jejb@...ux.ibm.com,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
        Michal Kolar <mich.k@...nam.cz>
Subject: Re: [PATCH] scsi: ses: Handle enclosure with just a primary component
 gracefully

On Wed, 5 Apr 2023, Ding Hui wrote:

> >> This reverts 3fe97ff3d9493 ("scsi: ses: Don't attach if enclosure has
> >> no components") and introduces proper handling of case where there
> >> are no detected secondary components, but primary component
> >> (enumerated in num_enclosures) does exist. That fix was originally
> >> proposed by Ding Hui <dinghui@...gfor.com.cn>.
> > 
> > I think everything in here looks fine except this:
> > 
> >> --- a/drivers/scsi/ses.c
> >> +++ b/drivers/scsi/ses.c
> >> @@ -509,9 +509,6 @@ static int ses_enclosure_find_by_addr(struct
> >> enclosure_device *edev,
> >>          int i;
> >>          struct ses_component *scomp;
> >>   -       if (!edev->component[0].scratch)
> >> -               return 0;
> >> -
> >>          for (i = 0; i < edev->components; i++) {
> >>                  scomp = edev->component[i].scratch;
> >>                  if (scomp->addr != efd->addr)
> > 
> > If you remove the check, then scomp could be NULL here and we'll oops
> > on scomp->addr.
> 
> I think we should remove the check, because the edev->components 
> represented the effectiveness of array pointers, so we need check 
> edev->components firstly instead of checking edev->component[0].scratch, 
> if edev->components is 0, we won't enter the for loop, don't worry about 
> dereference scomp.

Right you are. So v1 is actually more correct.

Martin, could you please consider adding

	Tested-by: Michal Kolar <mich.k@...nam.cz>

to v1 and applying? Thanks,

-- 
Jiri Kosina
SUSE Labs