linux-kernel - Re: [PATCH 3/3] tracing/probes: Fix return value when "(fault)" is injected

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: <20230706095039.1cb9c9d1@gandalf.local.home>
Date:   Thu, 6 Jul 2023 09:50:39 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Masami Hiramatsu (Google)" <mhiramat@...nel.org>
Cc:     Dan Carpenter <dan.carpenter@...aro.org>,
        linux-trace-kernel@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] tracing/probes: Fix return value when "(fault)" is
 injected

On Thu, 6 Jul 2023 13:40:36 +0900
Masami Hiramatsu (Google) <mhiramat@...nel.org> wrote:

> On Wed, 5 Jul 2023 22:49:56 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > On Sun,  2 Jul 2023 23:47:35 +0900
> > "Masami Hiramatsu (Google)" <mhiramat@...nel.org> wrote:
> >   
> > > From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
> > > 
> > > When the "(fault)" is injected, the return value of fetch_store_string*()
> > > should be the length of the "(fault)", but an error code is returned.
> > > Fix it to return the correct length and update the data_loc according the
> > > updated length.
> > > This needs to update a ftracetest test case, which expects trace output
> > > to appear as '(fault)' instead of '"(fault)"'.
> > >   
> > 
> > Ah, because of patch 2, the ret < 0 makes it return without printing the
> > "fault"?  
> 
> No, actually set_data_loc() updates the 'ret' argument, but it is just
> disposed... (not returned to the caller)

That's not what I was talking about.

We have:

process_fetch_insn_bottom() {
	[..]
	case FETCH_OP_ST_STRING:
		loc = *(u32 *)dest;
		ret = fetch_store_string(val + code->offset, dest, base);
		break;
	[..]

// And from patch 2 we have:

@@ -193,6 +193,8 @@ process_fetch_insn_bottom(struct fetch_insn *code, unsigned long val,
 	default:
 		return -EILSEQ;
 	}
+	if (ret < 0)
+		return ret;
 	code++;

And now that the return value of fetch_store_string() is being checked, and
if it returns negative, it ends the function before being processed
further. And if there's a fault, it happens to return negative!

This patch now changes fetch_store_string() and fetch_store_string_user()
to not return negative if there's a fault. As this patch has:

@@ -107,9 +106,7 @@ fetch_store_string(unsigned long addr, void *dest, void *base)
 	 * probing.
 	 */
 	ret = strncpy_from_kernel_nofault(__dest, (void *)addr, maxlen);
-	set_data_loc(ret, dest, __dest, base, maxlen);
-
-	return ret;
+	return set_data_loc(ret, dest, __dest, base, maxlen);
 }

But to do that, you needed to update set_data_loc() to return a value.

*that's* what I meant by 

'Ah, because of patch 2, the ret < 0 makes it return without printing the "fault"?'


-- Steve

> 
> -static nokprobe_inline void set_data_loc(int ret, void *dest, void *__dest, void *base, int len)
> +static nokprobe_inline int set_data_loc(int ret, void *dest, void *__dest, void *base, int len)
>  {
> -	if (ret >= 0) {
> -		*(u32 *)dest = make_data_loc(ret, __dest - base);
> -	} else {
> +	if (ret < 0) {
>  		strscpy(__dest, FAULT_STRING, len);
>  		ret = strlen(__dest) + 1;
>  	}
> +
> +	*(u32 *)dest = make_data_loc(ret, __dest - base);
> +	return ret;
>  }
> 
> So this returns updated 'ret', and also update data_loc to use the
> updated 'ret' value (which is the length of the stored data).
> 
> > 
> > Reviewed-by: Steven Rostedt (Google) <rostedt@...dmis.org>  
> 
> Thank you!
> 
> > 
> > -- Steve
> > 
> >   
> > > Fixes: 2e9906f84fc7 ("tracing: Add "(fault)" name injection to kernel probes")
> > > Cc: stable@...r.kernel.org
> > > Signed-off-by: Masami Hiramatsu (Google) <mhiramat@...nel.org>
> > > ---  
> 
>