On Fri, Oct 18, 2024 at 2:00 AM Kees Cook <[email protected]> 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 <[email protected]> -- Regards Yafang
