On Wed, Jul 10, 2019 at 10:44 AM Jeffrin Thalakkottoor
<jeff...@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
