linux-kernel - Re: [PATCH 0/7] tracing: instance_rmdir() leaks ftrace_event

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]

Date:	Mon, 14 Jul 2014 22:54:56 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Tom Zanussi <tom.zanussi@...ux.intel.com>,
	"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] tracing: instance_rmdir() leaks
 ftrace_event_file->filter

Hi Oleg,

2014-07-11 (금), 21:06 +0200, Oleg Nesterov:
> Hello,
> 
> Sorry for delay, I was distracted by other problems.
> 
> To remind, we discussed the potential uprobes "mix perf/ftrace" changes and
> found some off-topic problems. Lets start with ->filter fixes/cleanups.
> 
> So far I didn't even try to test this series, although it looks simple except
> perhaps the last patch. I'll try to somehow test this tomorrow, but I do not
> really now how.
> 
> So please review, these patches need acks anyway.
> 
> As for 1/7, I added BUG_ON(file->filter) into remove_event_file_dir() before
> kmem_cache_free() to verify that yes, the leak does exist. Perhaps this patch
> should go to stable, or at least to v3.16.
> 
> --------------------------------------------------------------------------------
> And could someone explain me why apply_subsystem_event_filter("0") clears
> ->filter_string first, then the whole ->filter? It seems that the only
> thing filter_free_subsystem_preds() should do is filter_disable(), no?
> IOW, why the patch below (on top of this series) is wrong?

I also think that the original code is bit strange.  I agree with your
change and name of the function should be changed to something like
'filter_disable_subsystem_filters' IMHO (it does nothing with preds).
With this change, the apply_subsystem_event_filter can simply do below:

	if (!strcmp(strstrip(filter_string), "0")) {
		filter_disable_subsystem_filters(system, tr);
		/* Ensure all filters are no longer used */
		synchronize_sched();
		filter_free_subsystem_filters(system, tr);
		__free_filter(system->filter);
		system->filter = NULL;
		goto out_unlock;
	}

Thanks,
Namhyung


> 
> Oleg.
> 
> --- x/kernel/trace/trace_events_filter.c
> +++ x/kernel/trace/trace_events_filter.c
> @@ -831,17 +831,6 @@ static int __alloc_preds(struct event_filter *filter, int n_preds)
>  	return 0;
>  }
>  
> -static inline void __remove_filter(struct ftrace_event_file *file)
> -{
> -	struct ftrace_event_call *call = file->event_call;
> -
> -	filter_disable(file);
> -	if (call->flags & TRACE_EVENT_FL_USE_CALL_FILTER)
> -		remove_filter_string(call->filter);
> -	else
> -		remove_filter_string(file->filter);
> -}
> -
>  static void filter_free_subsystem_preds(struct event_subsystem *system,
>  					struct trace_array *tr)
>  {
> @@ -850,7 +839,7 @@ static void filter_free_subsystem_preds(struct event_subsystem *system,
>  	list_for_each_entry(file, &tr->events, list) {
>  		if (file->system->subsystem != system)
>  			continue;
> -		__remove_filter(file);
> +		filter_disable(file);
>  	}
>  }
>  
> 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/