mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [patch] perf: potential underflow in perf_sample_ustack_size()
@ 2013-09-20 11:37 Dan Carpenter
  2013-09-21 13:35 ` Jiri Olsa
  0 siblings, 1 reply; 2+ messages in thread
From: Dan Carpenter @ 2013-09-20 11:37 UTC (permalink / raw)
  To: Peter Zijlstra, Jiri Olsa
  Cc: Paul Mackerras, Ingo Molnar, Arnaldo Carvalho de Melo,
	linux-kernel, kernel-janitors

The code here is trying to ensure that we don't have a
"header_size + stack_size" which is more than USHRT_MAX.  I changed
the overflow check a little to make it more clear.

My concern here is that if "header_size + sizeof(u64)" is very large
then we could end up with underflow doing the subtraction and end up
with a "stack_size" larger than intended.

I don't know perf well enough to say if this is possible.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

diff --git a/kernel/events/core.c b/kernel/events/core.c
index dd236b6..eec9e683 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4217,11 +4217,13 @@ perf_sample_ustack_size(u16 stack_size, u16 header_size,
 	header_size += 2 * sizeof(u64);
 
 	/* Do we fit in with the current stack dump size? */
-	if ((u16) (header_size + stack_size) < header_size) {
+	if (header_size > USHRT_MAX - stack_size) {
 		/*
 		 * If we overflow the maximum size for the sample,
 		 * we customize the stack dump size to fit in.
 		 */
+		if (header_size + sizeof(u64) > USHRT_MAX)
+			return 0;
 		stack_size = USHRT_MAX - header_size - sizeof(u64);
 		stack_size = round_up(stack_size, sizeof(u64));
 	}

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [patch] perf: potential underflow in perf_sample_ustack_size()
  2013-09-20 11:37 [patch] perf: potential underflow in perf_sample_ustack_size() Dan Carpenter
@ 2013-09-21 13:35 ` Jiri Olsa
  0 siblings, 0 replies; 2+ messages in thread
From: Jiri Olsa @ 2013-09-21 13:35 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Peter Zijlstra, Paul Mackerras, Ingo Molnar,
	Arnaldo Carvalho de Melo, linux-kernel, kernel-janitors

On Fri, Sep 20, 2013 at 02:37:36PM +0300, Dan Carpenter wrote:
> The code here is trying to ensure that we don't have a
> "header_size + stack_size" which is more than USHRT_MAX.  I changed
> the overflow check a little to make it more clear.
> 
> My concern here is that if "header_size + sizeof(u64)" is very large
> then we could end up with underflow doing the subtraction and end up
> with a "stack_size" larger than intended.
> 
> I don't know perf well enough to say if this is possible.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index dd236b6..eec9e683 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4217,11 +4217,13 @@ perf_sample_ustack_size(u16 stack_size, u16 header_size,
>  	header_size += 2 * sizeof(u64);
>  
>  	/* Do we fit in with the current stack dump size? */
> -	if ((u16) (header_size + stack_size) < header_size) {
> +	if (header_size > USHRT_MAX - stack_size) {

hum, the original check looks clear enough to me

>  		/*
>  		 * If we overflow the maximum size for the sample,
>  		 * we customize the stack dump size to fit in.
>  		 */
> +		if (header_size + sizeof(u64) > USHRT_MAX)
> +			return 0;

ok, I wonder if we could practically reach header size
this big, but it's safer to check

thanks,
jirka

>  		stack_size = USHRT_MAX - header_size - sizeof(u64);
>  		stack_size = round_up(stack_size, sizeof(u64));
>  	}

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-09-21 13:36 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-20 11:37 [patch] perf: potential underflow in perf_sample_ustack_size() Dan Carpenter
2013-09-21 13:35 ` Jiri Olsa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®