From: Kees Cook <keescook@chromium.org>
To: Paul Moore <paul@paul-moore.com>
Cc: Lu Yao <yaolu@kylinos.cn>,
linux-hardening@vger.kernel.org, jmorris@namei.org,
serge@hallyn.com, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] lsm: Resolve compiling 'security.c' error
Date: Wed, 17 Jan 2024 12:51:10 -0800 [thread overview]
Message-ID: <202401171236.5175FA9FA9@keescook> (raw)
In-Reply-To: <CAHC9VhSs6bxXFCAhw7i5cN=iZtuG3-E8xDBRjyGsop=BrhbmSw@mail.gmail.com>
On Wed, Jan 17, 2024 at 09:32:33AM -0500, Paul Moore wrote:
> On Tue, Jan 16, 2024 at 8:46 PM Lu Yao <yaolu@kylinos.cn> wrote:
> >
> > The following error log is displayed during the current compilation
> > > 'security/security.c:810:2: error: ‘memcpy’ offset 32 is
> > > out of the bounds [0, 0] [-Werror=array-bounds]'
> >
> > GCC version is '10.3.0 (Ubuntu 10.3.0-1ubuntu1~18.04~1)'
As an aside, Ubuntu 18.04 went out of support back in June 2023, and
never officially supported gcc 10:
https://launchpad.net/ubuntu/+source/gcc-10
That said, I still see this error with gcc 10.5 on supported Ubuntu
releases. I'm surprised this is the first time I've seen this error!
> >
> > Signed-off-by: Lu Yao <yaolu@kylinos.cn>
> > ---
> > security/security.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> I'm adding the linux-hardening folks to the to To: line as this has
> now come up multiple times and my best guess is that this is an issue
> with the struct_size() macro, compiler annotations, or something
> similar and I suspect they are the experts in that area. My
> understanding is that using the struct_size() macro is preferable to
> open coding the math, as this patch does, but if we have to do
> something like this to silence the warnings, that's okay with me.
>
> So linux-hardening folks, what do you say?
This is a GCC bug -- it thinks nctx_len could be 0, so it gets mad about
the array bounds.
>
> > diff --git a/security/security.c b/security/security.c
> > index 0144a98d3712..37168f6bee25 100644
> > --- a/security/security.c
> > +++ b/security/security.c
> > @@ -792,7 +792,7 @@ int lsm_fill_user_ctx(struct lsm_ctx __user *uctx, size_t *uctx_len,
> > size_t nctx_len;
> > int rc = 0;
> >
> > - nctx_len = ALIGN(struct_size(nctx, ctx, val_len), sizeof(void *));
> > + nctx_len = ALIGN(sizeof(struct lsm_ctx) + val_len, sizeof(void *));
> > if (nctx_len > *uctx_len) {
> > rc = -E2BIG;
> > goto out;
Please don't do this -- it regresses the efforts to make sure we can
never wrap the math on here. We need to pick one of these two diffs
instead. The first disables -Warray-bounds for GCC 10.* also (since we
keep having false positives). The latter silences this 1 particular
case by explicitly checking nctx_len for 0:
diff --git a/init/Kconfig b/init/Kconfig
index 8d4e836e1b6b..af4833430aca 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -874,7 +874,7 @@ config GCC11_NO_ARRAY_BOUNDS
config CC_NO_ARRAY_BOUNDS
bool
- default y if CC_IS_GCC && GCC_VERSION >= 110000 && GCC11_NO_ARRAY_BOUNDS
+ default y if CC_IS_GCC && GCC_VERSION >= 100000 && GCC11_NO_ARRAY_BOUNDS
# Currently, disable -Wstringop-overflow for GCC 11, globally.
config GCC11_NO_STRINGOP_OVERFLOW
diff --git a/security/security.c b/security/security.c
index 0144a98d3712..ab403136958f 100644
--- a/security/security.c
+++ b/security/security.c
@@ -793,7 +793,7 @@ int lsm_fill_user_ctx(struct lsm_ctx __user *uctx, size_t *uctx_len,
int rc = 0;
nctx_len = ALIGN(struct_size(nctx, ctx, val_len), sizeof(void *));
- if (nctx_len > *uctx_len) {
+ if (nctx_len == 0 || nctx_len > *uctx_len) {
rc = -E2BIG;
goto out;
}
--
Kees Cook
next prev parent reply other threads:[~2024-01-17 20:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 1:45 [PATCH] lsm: Resolve compiling 'security.c' error Lu Yao
2024-01-17 14:32 ` Paul Moore
2024-01-17 20:51 ` Kees Cook [this message]
2024-01-17 22:03 ` Paul Moore
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=202401171236.5175FA9FA9@keescook \
--to=keescook@chromium.org \
--cc=jmorris@namei.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=yaolu@kylinos.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox