From: Anton Blanchard <anton@ozlabs.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Kees Cook <keescook@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>,
Chandan Rajendra <chandan@linux.vnet.ibm.com>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] ext4: fix warning about stack corruption
Date: Tue, 22 Aug 2017 21:08:49 +1000 [thread overview]
Message-ID: <20170822210849.0edb91cc@kryten> (raw)
In-Reply-To: <20170801120438.1582336-1-arnd@arndb.de>
Hi Arnd,
> After commit 62d1034f53e3 ("fortify: use WARN instead of BUG for
> now"), we get a warning about possible stack overflow from a memcpy
> that was not strictly bounded to the size of the local variable:
>
> inlined from 'ext4_mb_seq_groups_show' at
> fs/ext4/mballoc.c:2322:2: include/linux/string.h:309:9: error:
> '__builtin_memcpy': writing between 161 and 1116 bytes into a region
> of size 160 overflows the destination [-Werror=stringop-overflow=]
>
> We actually had a bug here that would have been found by the warning,
> but it was already fixed last year in commit 30a9d7afe70e ("ext4: fix
> stack memory corruption with 64k block size").
>
> This replaces the fixed-length structure on the stack with a
> variable-length structure, using the correct upper bound that tells
> the compiler that everything is really fine here. I also change the
> loop count to check for the same upper bound for consistency, but the
> existing code is already correct here.
>
> Note that while clang won't allow certain kinds of variable-length
> arrays in structures, this particular instance is fine, as the array
> is at the end of the structure, and the size is strictly bounded.
Unfortunately it doesn't appear to work, at least with ppc64le clang:
fs/ext4/mballoc.c:2303:17: error: fields must have a constant size: 'variable length array in structure' extension will never be supported
ext4_grpblk_t counters[blocksize_bits + 2];
Anton
next prev parent reply other threads:[~2017-08-22 11:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-26 18:52 [PATCH v2] fortify: Use WARN instead of BUG for now Kees Cook
2017-07-26 19:55 ` Josh Poimboeuf
2017-07-26 21:33 ` Kees Cook
2017-07-29 8:56 ` kbuild test robot
2017-08-01 12:04 ` [PATCH 1/2] ext4: fix warning about stack corruption Arnd Bergmann
2017-08-01 12:04 ` [PATCH 2/2] adfs: use 'unsigned' types for memcpy length Arnd Bergmann
2017-08-01 18:20 ` Kees Cook
2017-08-01 21:43 ` Stephen Rothwell
2017-08-01 18:26 ` [PATCH 1/2] ext4: fix warning about stack corruption Kees Cook
2017-08-06 1:53 ` Theodore Ts'o
2017-08-06 20:34 ` Arnd Bergmann
2017-08-07 6:42 ` Chandan Rajendra
2017-08-22 11:08 ` Anton Blanchard [this message]
2017-08-22 11:57 ` Arnd Bergmann
2017-08-22 12:23 ` Anton Blanchard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170822210849.0edb91cc@kryten \
--to=anton@ozlabs.org \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=chandan@linux.vnet.ibm.com \
--cc=jack@suse.cz \
--cc=keescook@chromium.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.