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@xxxxxxxxxx> wrote:
>
> On Wed, Jul 10, 2019 at 10:44 AM Jeffrin Thalakkottoor
> <jeffrin@xxxxxxxxxxxxxxxxxxx> 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
