linux-kernel - Fwd: [draft] Tracing multibuffer support concurrency issues

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

Message-ID: <CANiYik6h0_xnUYqCRHZU75az9YS=ySUHaqgMayW-Ffj5Jey6_g@mail.gmail.com>
Date:	Mon, 1 Jul 2013 15:33:58 -0700
From:	Alexander Lam <azl@...gle.com>
To:	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org
Cc:	David Sharp <dhsharp@...gle.com>,
	Vaibhav Nagarnaik <vnagarnaik@...gle.com>,
	Alexander Lam <lambchop468@...il.com>
Subject: Fwd: [draft] Tracing multibuffer support concurrency issues

Hi all,

I noticed that a695cb58 "tracing: Prevent deleting instances when they
are being read" [1] still leaves open the possibility of the
trace_array being deleted before the reference counter is incremented.

Thread A creates a new instance "foo", then tries to open "foo/trace"
for writing, which invokes tracing_open() and __tracing_open()
Thread B removes the "foo" instance. Since Thread A has not
incremented the reference counter for the trace_array representing
"foo," its trace_array and associated structures are freed in
instance_delete().
Thread A now attempts to dereference the trace_cpu pointer it has to
obtain the now deleted trace_array. By now, both the trace_cpu and
trace_array are deleted.

Here's a short bash script to run on a kernel to make it crash like this:
   $ cd /sys/kernel/debug/tracing/instances/
   $ ( while true; do mkdir foo; rmdir foo; done ) &
   $ ( while true; do cat foo/trace &> /dev/null; done) &

To fix this we could go through the ftrace_trace_arrays list and use
addresses to check if a particular pointer to a trace_array is still
valid, but this is vulnerable to the ABA problem if a trace_array is
freed and another is reallocated at the same address. This method is
used by subsystem_open() in trace_events.c

An ugly way to get around the ABA issue is to use a monotonically
increasing ID # for each trace_array instance. Those IDs could be used
instead of pointers when creating debugfs files.

Is there a better way to fix this problem?

Also unaddressed are all of the other files which use a trace_array,
trace_cpu, or ftrace_event_file in their operation - these would need
the same fix.

- Alex

[1] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/kernel/trace/trace.c?id=a695cb5816228f86576f5f5c6809fdf8ed382ece
--
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/