On Fri, Jan 4, 2019 at 9:50 AM Vlastimil Babka <vbabka@xxxxxxx> wrote: > > On 1/3/19 9:42 AM, Dmitry Vyukov wrote: > > On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka <vbabka@xxxxxxx> wrote: > >> > >> > >> On 12/31/18 8:51 AM, syzbot wrote: > >>> Hello, > >>> > >>> syzbot found the following crash on: > >>> > >>> HEAD commit: 79fc24ff6184 kmsan: highmem: use kmsan_clear_page() in cop.. > >>> git tree: kmsan > >>> console output: https://syzkaller.appspot.com/x/log.txt?x=13c48b67400000 > >>> kernel config: https://syzkaller.appspot.com/x/.config?x=901dd030b2cc57e7 > >>> dashboard link: https://syzkaller.appspot.com/bug?extid=b19c2dc2c990ea657a71 > >>> compiler: clang version 8.0.0 (trunk 349734) > >>> > >>> Unfortunately, I don't have any reproducer for this crash yet. > >>> > >>> IMPORTANT: if you fix the bug, please add the following tag to the commit: > >>> Reported-by: syzbot+b19c2dc2c990ea657a71@xxxxxxxxxxxxxxxxxxxxxxxxx > >>> > >>> ================================================================== > >>> BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:353 [inline] > >>> BUG: KMSAN: uninit-value in mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384 > >> > >> The report doesn't seem to indicate where the uninit value resides in > >> the mempolicy object. > > > > Yes, it doesn't and it's not trivial to do. The tool reports uses of > > unint _values_. Values don't necessary reside in memory. It can be a > > register, that come from another register that was calculated as a sum > > of two other values, which may come from a function argument, etc. > > I see. BTW, the patch I sent will be picked up for testing, or does it > have to be in mmotm/linux-next first? It needs to be in upstream tree. Since KMSAN is not upstream, we have only 1 branch that is based on upstream and is periodically rebased: https://github.com/google/kmsan If the bug would have a repro, then we could ask syzbot to test this patch on top of KMSAN tree. But unfortunately it doesn't.
