Re: BUG: KASAN: global-out-of-bounds in ata_exec_internal_sg+0x50f/0xc70

[Jeffrin Thalakkottoor <jeffrin@rajagiritech.edu.in>]

hello Jens Axboe,

Please can you take a look at related code and also patch from Kees ?

On Tue, Jul 16, 2019 at 11:58 PM Nick Desaulniers
<ndesaulniers@google.com> 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
> >
> > [   30.040241] Memory state around the buggy address:
> > [   30.040362]  ffffffff91f41e80: fa fa fa fa 00 00 fa fa fa fa fa fa
> > 00 00 07 fa
> > [   30.040498]  ffffffff91f41f00: fa fa fa fa 00 00 00 00 00 00 00 03
> > fa fa fa fa
> > [   30.040628] >ffffffff91f41f80: 00 04 fa fa fa fa fa fa 00 00 fa fa
> > fa fa fa fa
> > [   30.040755]                       ^
> > [   30.040868]  ffffffff91f42000: 00 00 00 04 fa fa fa fa 00 fa fa fa
> > fa fa fa fa
> > [   30.041003]  ffffffff91f42080: 04 fa fa fa fa fa fa fa 00 04 fa fa
> > fa fa fa fa
> >
> > ---------------------------x--------------------------x----------------
> > $uname -a
> > Linux debian 5.2.0-rc7+ #4 SMP Tue Jul 9 02:54:07 IST 2019 x86_64 GNU/Linux
> > $
> >
> > --------------------x----------------------------x---------------------------
> > (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);
> > 360 }
> > 361
> > 362 __FORTIFY_INLINE void *memmove(void *p, const void *q, __kernel_size_t size)
>
> ...a call to memmove is made? Without having looked at the source of
> ata_exec_internal_sg(), it's possible that either through inlining, or
> the compiler generating a memmove, that one of the arguments was not
> quite right.  I suggest spending more time isolating where this is
> coming from, if you can reliably reproduce, or CC whoever wrote or
> maintains the code and ask them to take a look.
>
> The cited code looks like a check comparing that the pointer distance
> is greater than the size of bytes being passed in.  I'd wager
> someone's calling memmove with overlapping memory regions when they
> really wanted memcpy.  Maybe a better question, is why was memmove
> ever used; if there was some invariant that the memory regions
> overlapped, why is that invariant no longer holding.
>
> Anyways, sorry I don't have more time to look into this.  Thank you
> for the report.
>
> > 363 {
> > (gdb)
> > --------------------------x--------------------------
> > GNU Make            4.2.1
> > Binutils            2.31.1
> > Util-linux          2.33.1
> > Mount                2.33.1
> > Linux C Library      2.28
> > Dynamic linker (ldd) 2.28
> > Procps              3.3.15
> > Kbd                  2.0.4
> > Console-tools        2.0.4
> > Sh-utils            8.30
> > Udev                241
> > ---------------------x--------------------------------x
> > Thread model: posix
> > gcc version 8.3.0 (Debian 8.3.0-7)
> > ---------------------x--------------------------------x
> >
> > Please ask if more information is needed.
> >
> > --
> > software engineer
> > rajagiri school of engineering and technology
>
>
>
> --
> Thanks,
> ~Nick Desaulniers



-- 
software engineer
rajagiri school of engineering and technology