From: Andrew Morton <akpm@linux-foundation.org>
To: Kees Cook <keescook@chromium.org>
Cc: llvm@lists.linux.dev, Marco Elver <elver@google.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, stable@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Christoph Lameter <cl@linux.com>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Daniel Micay <danielmicay@gmail.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] mm: Handle ksize() vs __alloc_size by forgetting size
Date: Fri, 25 Feb 2022 15:45:18 -0800 [thread overview]
Message-ID: <20220225154518.0d1159fdc6f37ee38e39e90c@linux-foundation.org> (raw)
In-Reply-To: <20220225221625.3531852-1-keescook@chromium.org>
On Fri, 25 Feb 2022 14:16:25 -0800 Kees Cook <keescook@chromium.org> wrote:
> If ksize() is used on an allocation, the compiler cannot make any
> assumptions about its size any more (as hinted by __alloc_size). Force
> it to forget.
>
> One caller was using a container_of() construction that needed to be
> worked around.
Please, when fixing something do fully explain what that thing is. I,
for one, simply cannot understand why this change is being proposed.
Especially when proposing a -stable backport! Tell readers what was
the end-user impact of the bug.
> Link: https://github.com/ClangBuiltLinux/linux/issues/1599
Even that didn't tell me. Is it just a clang warning? Does the kernel
post your private keys on reddit then scribble all over your disk
drive? I dunno.
next prev parent reply other threads:[~2022-02-25 23:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 22:16 [PATCH] mm: Handle ksize() vs __alloc_size by forgetting size Kees Cook
2022-02-25 23:45 ` Andrew Morton [this message]
2022-02-28 23:16 ` Kees Cook
2022-02-28 11:24 ` Marco Elver
2022-02-28 14:30 ` Matthew Wilcox
2022-02-28 14:48 ` Daniel Micay
2022-02-28 15:15 ` Daniel Micay
2022-02-28 23:54 ` Kees Cook
2022-02-28 22:42 ` Nick Desaulniers
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=20220225154518.0d1159fdc6f37ee38e39e90c@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=danielmicay@gmail.com \
--cc=elver@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=penberg@kernel.org \
--cc=rafael@kernel.org \
--cc=rientjes@google.com \
--cc=stable@vger.kernel.org \
--cc=vbabka@suse.cz \
/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.