From: "Ewan D. Milne" <emilne@redhat.com>
To: Jianchao Wang <jianchao.w.wang@oracle.com>,
jejb@linux.ibm.com, martin.petersen@oracle.com
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] scsi: ses: fix some risks of out of bound access
Date: Tue, 26 Mar 2019 09:06:09 -0400 [thread overview]
Message-ID: <bc247133bb00ef1f00dd0757c6d84d315cab1bbc.camel@redhat.com> (raw)
In-Reply-To: <1553499602-27810-1-git-send-email-jianchao.w.wang@oracle.com>
See below.
On Mon, 2019-03-25 at 15:40 +0800, Jianchao Wang wrote:
> We have some places with risk of accessing out of bound of the
> buffer allocated from slab, even it could corrupt the memory.
>
> Signed-off-by: Jianchao Wang <jianchao.w.wang@oracle.com>
> ---
> drivers/scsi/ses.c | 27 ++++++++++++++++++++++-----
> 1 file changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
> index 0fc3922..42e6a1f 100644
> --- a/drivers/scsi/ses.c
> +++ b/drivers/scsi/ses.c
> @@ -520,6 +520,7 @@ static void ses_enclosure_data_process(struct enclosure_device *edev,
> struct ses_device *ses_dev = edev->scratch;
> int types = ses_dev->page1_num_types;
> unsigned char *hdr_buf = kzalloc(INIT_ALLOC_SIZE, GFP_KERNEL);
> + unsigned char *page1_end = ses_dev->page1 + ses_dev->page1_len;
>
> if (!hdr_buf)
> goto simple_populate;
> @@ -556,6 +557,11 @@ static void ses_enclosure_data_process(struct enclosure_device *edev,
> type_ptr = ses_dev->page1_types;
> components = 0;
> for (i = 0; i < types; i++, type_ptr += 4) {
> + if (type_ptr > page1_end - 2) {
I think "if (type_ptr + 1 >= page1_end)" would be more consistent.
> + sdev_printk(KERN_ERR, sdev, "Access out of bound of page1"
> + "%p page1_end %p\n", page1_end, type_ptr);
This message is not helpful for someone with a device reporting
invalid enclosure data. It should be more generic, like
"Enclosure data too short" or "invalid" or something. And, the
actual pointer values are irrelevant, it all depends upon the
contents of the buffer.
> + break;
> + }
> for (j = 0; j < type_ptr[1]; j++) {
> char *name = NULL;
> struct enclosure_component *ecomp;
> @@ -566,10 +572,15 @@ static void ses_enclosure_data_process(struct enclosure_device *edev,
> } else {
> len = (desc_ptr[2] << 8) + desc_ptr[3];
> desc_ptr += 4;
> - /* Add trailing zero - pushes into
> - * reserved space */
> - desc_ptr[len] = '\0';
> - name = desc_ptr;
> + if (desc_ptr + len >= buf + page7_len) {
> + desc_ptr = NULL;
> + } else {
> +
> + /* Add trailing zero - pushes into
> + * reserved space */
> + desc_ptr[len] = '\0';
> + name = desc_ptr;
> + }
> }
> }
> if (type_ptr[0] == ENCLOSURE_COMPONENT_DEVICE ||
> @@ -693,7 +704,13 @@ static int ses_intf_add(struct device *cdev,
> /* begin at the enclosure descriptor */
> type_ptr = buf + 8;
> /* skip all the enclosure descriptors */
> - for (i = 0; i < num_enclosures && type_ptr < buf + len; i++) {
> + for (i = 0; i < num_enclosures; i++) {
> + if (type_ptr >= buf + len) {
> + sdev_printk(KERN_ERR, sdev, "Overflow the buf len = %d\n", len);
See above, the message is unhelpful. The actual problem is that
the Enclosure data is too short or invalid.
> + err = -EINVAL;
> + goto err_free;
> + }
> +
> types += type_ptr[2];
> type_ptr += type_ptr[3] + 4;
> }
This will still potentially leave type_ptr past the end of the
buffer in the subsequent code, though, right?
This might fix the problem for your malfunctioning device, but
does not look like it would handle the general case.
-Ewan
next prev parent reply other threads:[~2019-03-26 13:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-25 7:40 [PATCH] scsi: ses: fix some risks of out of bound access Jianchao Wang
2019-03-26 1:19 ` jianchao.wang
2019-03-26 13:06 ` Ewan D. Milne [this message]
2019-03-27 2:21 ` jianchao.wang
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=bc247133bb00ef1f00dd0757c6d84d315cab1bbc.camel@redhat.com \
--to=emilne@redhat.com \
--cc=jejb@linux.ibm.com \
--cc=jianchao.w.wang@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--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