linux-kernel - perf: bug, kernel ignores the buffer size on large read

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]

Date:	Wed, 2 Sep 2015 12:34:41 -0400 (EDT)
From:	Vince Weaver <vincent.weaver@...ne.edu>
To:	linux-kernel@...r.kernel.org
cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: perf: bug, kernel ignores the buffer size on large read

OK, this time I found the actual bug.

event->read_size is declared as a u16 in include/linux/perf_event.h

but it is very easy to get event->read_size larger than 64k
(in my case, create 10000 events in a group).

Because we wrap around the u16, the 
	 if (count < event->read_size) return -ENOSPC;
in perf_read_hw() doesn't trigger reliably and so if you do a read
on a large group event the kernel will quite happily copy_to_user()
beyond the bounds of the value set in the read syscall.  

In my case it completely smashed the stack and caused the program to 
segfault.

I'm not sure what the solution is here.  Change read_size to be larger?
Ban events whose read size would be larger than 64k?  Although that gets 
tricky because the related header_size is also only a u16.

Vince

--
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/