linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <jejb@linux.ibm.com>
To: Waiman Long <longman@redhat.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] scsi: ses: Fix out-of-bounds memory access in ses_enclosure_data_process()
Date: Mon, 20 May 2019 08:46:52 -0700	[thread overview]
Message-ID: <1558367212.3742.10.camel@linux.ibm.com> (raw)
In-Reply-To: <3385cf54-7b6c-3f28-e037-f0d4037368eb@redhat.com>

On Mon, 2019-05-20 at 11:24 -0400, Waiman Long wrote:
> On 5/20/19 10:52 AM, James Bottomley wrote:
> > On Mon, 2019-05-20 at 10:41 -0400, Waiman Long wrote:
> > [...]
> > > > --- a/drivers/scsi/ses.c
> > > > +++ b/drivers/scsi/ses.c
> > > > @@ -605,9 +605,14 @@ static void
> > > > ses_enclosure_data_process(struct
> > > > enclosure_device *edev,
> > > >  			     /* these elements are optional */
> > > >  			     type_ptr[0] ==
> > > > ENCLOSURE_COMPONENT_SCSI_TARGET_PORT ||
> > > >  			     type_ptr[0] ==
> > > > ENCLOSURE_COMPONENT_SCSI_INITIATOR_PORT ||
> > > > -			     type_ptr[0] ==
> > > > ENCLOSURE_COMPONENT_CONTROLLER_ELECTRONICS))
> > > > +			     type_ptr[0] ==
> > > > ENCLOSURE_COMPONENT_CONTROLLER_ELECTRONICS)) {
> > > >  				addl_desc_ptr +=
> > > > addl_desc_ptr[1]
> > > > + 2;
> > > >  
> > > > +				/* Ensure no out-of-bounds
> > > > memory
> > > > access */
> > > > +				if (addl_desc_ptr >= ses_dev-
> > > > > page10 +
> > > > 
> > > > +						     ses_dev-
> > > > > page10_len)
> > > > 
> > > > +					addl_desc_ptr = NULL;
> > > > +			}
> > > >  		}
> > > >  	}
> > > >  	kfree(buf);
> > > 
> > > Ping! Any comment on this patch.
> > 
> > The update looks fine to me:
> > 
> > Reviewed-by: James E.J. Bottomley <jejb@linux.ibm.com>
> > 
> > It might also be interesting to find out how the proliant is
> > structuring this descriptor array to precipitate the out of bounds:
> > Is it just an off by one or something more serious?
> 
> I didn't look into the detail the enclosure message returned by the
> hardware, but I believe it may have more description entries (page7)
> than extended description entries (page10).
> 
> I can try to reserve the system and find out what exactly is wrong
> with that system if you really want to find that out.

Please.  What I'm interested in is whether this is simply a bug in the
array firmware, in which case the fix is sufficient, or whether there's
some problem with the parser, like mismatched expectations over added
trailing nulls or something.

James


  reply	other threads:[~2019-05-20 15:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-01 18:05 [PATCH] scsi: ses: Fix out-of-bounds memory access in ses_enclosure_data_process() Waiman Long
2019-05-20 14:41 ` Waiman Long
2019-05-20 14:52   ` James Bottomley
2019-05-20 15:24     ` Waiman Long
2019-05-20 15:46       ` James Bottomley [this message]
2019-05-20 15:56         ` Waiman Long
2019-05-21 17:23           ` Waiman Long
2019-05-20 16:05         ` Martin K. Petersen
2019-05-20 21:53           ` Douglas Gilbert
2019-05-21 12:02             ` Martin K. Petersen
2019-07-18 18:18     ` Waiman Long
2019-07-18 18:26       ` Martin K. Petersen
2019-07-18 18:29         ` Waiman Long

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1558367212.3742.10.camel@linux.ibm.com \
    --to=jejb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).