All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Jeffrin Thalakkottoor <jeffrin@rajagiritech.edu.in>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	tobin@kernel.org, lkml <linux-kernel@vger.kernel.org>,
	Dmitry Vyukov <dvyukov@google.com>,
	Alexander Potapenko <glider@google.com>
Subject: Re: BUG: KASAN: global-out-of-bounds in ata_exec_internal_sg+0x50f/0xc70
Date: Thu, 18 Jul 2019 14:35:45 -0700	[thread overview]
Message-ID: <201907181423.E808958@keescook> (raw)
In-Reply-To: <CAKwvOdmg2b2PMzuzNmutacFArBNagjtwG=_VZvKhb4okzSkdiA@mail.gmail.com>

On Tue, Jul 16, 2019 at 11:28:29AM -0700, Nick Desaulniers wrote:
> On Wed, Jul 10, 2019 at 10:44 AM Jeffrin Thalakkottoor
> <jeffrin@rajagiritech.edu.in> wrote:
> >
> > hello all ,
> >
> > i encountered a KASAN bug related .    here are some related information...
> >
> >
> > -------------------x-----------------------------x------------------
> > [   30.037312] BUG: KASAN: global-out-of-bounds in
> > ata_exec_internal_sg+0x50f/0xc70
> > [   30.037447] Read of size 16 at addr ffffffff91f41f80 by task scsi_eh_1/149
> >
> >
> > [   30.039935] The buggy address belongs to the variable:
> > [   30.040059]  cdb.48319+0x0/0x40
> > (gdb) l *ata_exec_internal_sg+0x50f
> > 0xffffffff81c7b59f is in ata_exec_internal_sg (./include/linux/string.h:359).
> 
> So looks like ata_exec_internal_sg() is panic'ing when...
> 
> > 354 if (q_size < size)
> > 355 __read_overflow2();
> > 356 }
> > 357 if (p_size < size || q_size < size)
> > 358 fortify_panic(__func__);
> > 359 return __builtin_memcpy(p, q, size);

^^^ here, so within memcpy(), but after the "easy" sanity checks.

The only place where I see ata_exec_internal_sg() calling memcpy() is
here:

        /* prepare & issue qc */
        qc->tf = *tf;
        if (cdb)
                memcpy(qc->cdb, cdb, ATAPI_CDB_LEN);

the "16" is consistent with the report:

include/linux/ata.h:    ATAPI_CDB_LEN           = 16,

which matches the claim about the cdb variable from KASAN. And it's a
read, so "cdb" is wrong. Do you have a longer back trace? What called
ata_exec_internal_sg()?

ata_exec_internal() is the only caller of ata_exec_internal_sg(). Nearly
all callers of ata_exec_internal() pass a NULL cdb. Those that don't
are:

atapi_eh_tur()
	u8 cdb[ATAPI_CDB_LEN] = ...
atapi_eh_request_sense()
	u8 cdb[ATAPI_CDB_LEN] = ...

These two are on the static and correctly sized.

eject_tray()
        static const char cdb[ATAPI_CDB_LEN] = ...
zpodd_get_mech_type()
	static const char cdb[] = ...

These are both in rodata, and only the first is correctly sized. I
assume the following will fix it:


diff --git a/drivers/ata/libata-zpodd.c b/drivers/ata/libata-zpodd.c
index 173e6f2dd9af..eefda51f97d3 100644
--- a/drivers/ata/libata-zpodd.c
+++ b/drivers/ata/libata-zpodd.c
@@ -56,7 +56,7 @@ static enum odd_mech_type zpodd_get_mech_type(struct ata_device *dev)
 	unsigned int ret;
 	struct rm_feature_desc *desc;
 	struct ata_taskfile tf;
-	static const char cdb[] = {  GPCMD_GET_CONFIGURATION,
+	static const char cdb[ATAPI_CDB_LEN] = {  GPCMD_GET_CONFIGURATION,
 			2,      /* only 1 feature descriptor requested */
 			0, 3,   /* 3, removable medium feature */
 			0, 0, 0,/* reserved */



-- 
Kees Cook

  parent reply	other threads:[~2019-07-18 21:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10 17:44 BUG: KASAN: global-out-of-bounds in ata_exec_internal_sg+0x50f/0xc70 Jeffrin Thalakkottoor
2019-07-16 18:28 ` Nick Desaulniers
2019-07-16 18:57   ` Steven Rostedt
2019-07-16 19:45     ` Nick Desaulniers
2019-07-18 21:35   ` Kees Cook [this message]
2019-07-29 19:34     ` Jeffrin Thalakkottoor
2019-07-29 19:55       ` Jens Axboe
2019-07-29 20:13         ` Jeffrin Thalakkottoor
2019-07-25 21:34   ` Jeffrin Thalakkottoor
  -- strict thread matches above, loose matches on Subject: below --
2019-06-13 18:36 Jeffrin Thalakkottoor

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=201907181423.E808958@keescook \
    --to=keescook@chromium.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=jeffrin@rajagiritech.edu.in \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=rostedt@goodmis.org \
    --cc=tobin@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.