From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f68.google.com ([74.125.82.68]:34317 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753847AbdIDQ4E (ORCPT ); Mon, 4 Sep 2017 12:56:04 -0400 Received: by mail-wm0-f68.google.com with SMTP id r75so828241wmf.1 for ; Mon, 04 Sep 2017 09:56:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170904142233.GV5426@ZenIV.linux.org.uk> References: <201709042112.BFB76862.FQVFMSOtOJFHOL@I-love.SAKURA.ne.jp> <20170904132106.GU5426@ZenIV.linux.org.uk> <201709042311.IIE60447.OJSQFMHtOFLVOF@I-love.SAKURA.ne.jp> <20170904142233.GV5426@ZenIV.linux.org.uk> From: Vegard Nossum Date: Mon, 4 Sep 2017 18:56:02 +0200 Message-ID: Subject: Re: fs: Uninitialized memory read at take_dentry_name_snapshot To: Al Viro Cc: Tetsuo Handa , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 4 September 2017 at 16:22, Al Viro wrote: > On Mon, Sep 04, 2017 at 11:11:04PM +0900, Tetsuo Handa wrote: >> at __d_alloc() which leaves a room for some of d_iname[] bytes uninitialized? >> So, I think either pad explicitly at __f_alloc() or use dentry->d_name.len + 1 is needed. > > It's the same situation as with > struct foo {char s[10];int v;} *p, *q; > p = malloc(sizeof struct foo); > strcpy(p->s, "foo"); > p->v = 69; > ... > q = malloc(sizeof struct foo); > memcpy(q, p, sizeof(struct foo)); > > Sure, bytes after NUL are uninitialized, but that NUL is there > in both copies. FWIW, kmemcheck could simply copy the information > about source to that about destination - in the example above > we'd end up with "q->v initialized, along with the first 4 bytes of > q->s", which matches the reality. BTW, how do you handle struct > assignments? kmemcheck knows how to memcpy() the shadow memory state between two slab-allocated objects, but it doesn't track memory state for the stack so if you're copying partially uninitialised object to the stack (which I'm guessing is the case here?) then it will produce the warning Tetsuo Handa saw. BTW as soon as msan/kmsan support for the kernel [1] is merged I am planning to nuke kmemcheck from the kernel. msan/kmsan should handle it properly. [1]: https://github.com/google/kmsan Vegard