linux-hardening - Re: Fwd: [linux-next:master 4380/4439] include/linux/fortify-string.h:293:17: error: call to '__write_overflow' declared with attribute error: detected write beyond size of object (1st parameter)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALOAHbDDx3ban6xgxX0M52MNs0vUE4U2oFEy6LFAphjtU20avA@mail.gmail.com>
Date: Mon, 21 Oct 2024 11:48:15 +0800
From: Yafang Shao <laoar.shao@...il.com>
To: Kees Cook <kees@...nel.org>
Cc: Paul Moore <paul@...l-moore.com>, linux-hardening@...r.kernel.org
Subject: Re: Fwd: [linux-next:master 4380/4439] include/linux/fortify-string.h:293:17:
 error: call to '__write_overflow' declared with attribute error: detected
 write beyond size of object (1st parameter)

On Fri, Oct 18, 2024 at 2:00 AM Kees Cook <kees@...nel.org> wrote:
>
> On Thu, Oct 17, 2024 at 09:48:18AM -0700, Kees Cook wrote:
> > On Thu, Oct 17, 2024 at 09:23:25AM -0700, Kees Cook wrote:
> > > On Thu, Oct 17, 2024 at 09:07:13AM -0700, Kees Cook wrote:
> > > > Something in the .config is causing the error. (!?) I will start a
> > > > CONFIG bisect...
> > >
> > > Well, I did a code bisect first, and it reported this which makes _no_
> > > sense:
> > > 8afd8c8faa24 ("lsm: remove lsm_prop scaffolding")
> > >
> > > O_o
> >
> > Looks like a GCC inlining bug. If I query the size of the destination
> > buffer before calling strscpy the warning magically vanishes. :|
> >
> > Lovely. I will see if I can construct a work-around.
>
> I am extremely bothered that this fixes it:
>
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index bc052b4b5a1d..891f4294361d 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2728,8 +2728,8 @@ void __audit_ptrace(struct task_struct *t)
>         context->target_auid = audit_get_loginuid(t);
>         context->target_uid = task_uid(t);
>         context->target_sessionid = audit_get_sessionid(t);
> -       security_task_getlsmprop_obj(t, &context->target_ref);
>         strscpy(context->target_comm, t->comm);
> +       security_task_getlsmprop_obj(t, &context->target_ref);
>  }
>
>  /**
> @@ -2755,8 +2755,8 @@ int audit_signal_info_syscall(struct task_struct *t)
>                 ctx->target_auid = audit_get_loginuid(t);
>                 ctx->target_uid = t_uid;
>                 ctx->target_sessionid = audit_get_sessionid(t);
> -               security_task_getlsmprop_obj(t, &ctx->target_ref);
>                 strscpy(ctx->target_comm, t->comm);
> +               security_task_getlsmprop_obj(t, &ctx->target_ref);
>                 return 0;
>         }
>
>
> I will continue trying to figure out why GCC is getting confused here,
> but in the meantime, perhaps this is a viable workaround?

Thank you for the analysis. I was able to reproduce the issue with GCC
11 and confirmed that your change resolves it. While this does appear
to be a GCC bug, identifying the root cause may not be
straightforward. I agree that a workaround is the best approach for
now.

Feel free to include your change.

Tested-by: Yafang Shao <laoar.shao@...il.com>


--
Regards
Yafang