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] [thread-next>] [day] [month] [year] [list]

Message-ID: <202410171059.C2C395030@keescook>
Date: Thu, 17 Oct 2024 11:00:11 -0700
From: Kees Cook <kees@...nel.org>
To: Paul Moore <paul@...l-moore.com>
Cc: Yafang Shao <laoar.shao@...il.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 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?

-- 
Kees Cook