user/sven/linux.git/tools, branch v3.2.45

tools: hv: Netlink source address validation allows DoS

2013-03-27T02:41:03Z

commit 95a69adab9acfc3981c504737a2b6578e4d846ef upstream. The source code without this patch caused hypervkvpd to exit when it processed a spoofed Netlink packet which has been sent from an untrusted local user. Now Netlink messages with a non-zero nl_pid source address are ignored and a warning is printed into the syslog. Signed-off-by: Tomas Hozza Acked-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

perf: Revert duplicated commit

2013-03-27T02:41:00Z

This reverts commit 923415295307845e614589c1cce62abedd4d1731 'perf: Fix parsing of __print_flags() in TP_printk()'. The same change was already included in 3.2 as commit d06c27b22aa66e48e32f03f9387328a9af9b0625 but in 3.2.1 this change was wrongly applied to similar code in a different function. Thanks to Jiri for pointing this out in 3.0.y. Signed-off-by: Ben Hutchings Cc: Jiri Slaby Cc: Andrew Vagin Cc: Steven Rostedt

kbuild: Fix gcc -x syntax

2012-10-17T02:49:27Z

commit b1e0d8b70fa31821ebca3965f2ef8619d7c5e316 upstream. The correct syntax for gcc -x is "gcc -x assembler", not "gcc -xassembler". Even though the latter happens to work, the former is what is documented in the manual page and thus what gcc wrappers such as icecream do expect. This isn't a cosmetic change. The missing space prevents icecream from recognizing compilation tasks it can't handle, leading to silent kernel miscompilations. Besides me, credits go to Michael Matz and Dirk Mueller for investigating the miscompilation issue and tracking it down to this incorrect -x parameter syntax. Signed-off-by: Jean Delvare Acked-by: Ingo Molnar Cc: Bernhard Walle Cc: Michal Marek Cc: Ralf Baechle Signed-off-by: Michal Marek [bwh: Backported to 3.2: drop unneeded change to arch/x86/Makefile] Signed-off-by: Ben Hutchings

tools/hv: Fix exit() error code

2012-10-17T02:48:21Z

commit 6bb22fea25624ab593eee376fa5fb82d1b13f45a upstream. Linux native exit codes are 8-bit unsigned values. exit(-1) results in an exit code of 255, which is usually reserved for shells reporting 'command not found'. Use the portable value EXIT_FAILURE. (Not that this matters much for a daemon.) Signed-off-by: Ben Hutchings Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: drop changes to exit() calls not in this version]

Tools: hv: verify origin of netlink connector message

2012-07-04T04:44:05Z

commit bcc2c9c3fff859e0eb019fe6fec26f9b8eba795c upstream. The SuSE security team suggested to use recvfrom instead of recv to be certain that the connector message is originated from kernel. CVE-2012-2669 Signed-off-by: Olaf Hering Signed-off-by: Marcus Meissner Signed-off-by: Sebastian Krahmer Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

USB: ffs-test: fix length argument of out function call

2012-05-30T23:43:38Z

commit eb9c5836384cd2a276254df6254ed71117983626 upstream. The out functions should only handle actual available data instead of the complete buffer. Otherwise for example the ep0_consume function will report ghost events since it tries to decode the complete buffer - which may contain partly invalid data. Signed-off-by: Matthias Fend Acked-by: Michal Nazarewicz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

Perf: fix build breakage

2012-05-11T12:13:48Z

[Patch not needed upstream as this is a backport build bugfix - gregkh gcc correctly complains: util/hist.c: In function ‘__hists__add_entry’: util/hist.c:240:27: error: invalid type argument of ‘->’ (have ‘struct hist_entry’) util/hist.c:241:23: error: invalid type argument of ‘->’ (have ‘struct hist_entry’) for this new code: + if (he->ms.map != entry->ms.map) { + he->ms.map = entry->ms.map; + if (he->ms.map) + he->ms.map->referenced = true; + } because "entry" is a "struct hist_entry", not a pointer to a struct. In mainline, "entry" is a pointer to struct passed as argument to the function. So this is broken during backporting. But obviously not compile tested. Signed-off-by: Zeev Tarantov Cc: Signed-off-by: David S. Miller Cc: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

perf hists: Catch and handle out-of-date hist entry maps.

2012-04-22T22:31:00Z

commit 63fa471dd49e9c9ce029d910d1024330d9b1b145 upstream. When a process exec()'s, all the maps are retired, but we keep the hist entries around which hold references to those outdated maps. If the same library gets mapped in for which we have hist entries, a new map will be created. But when we take a perf entry hit within that map, we'll find the existing hist entry with the older map. This causes symbol translations to be done incorrectly. For example, the perf entry processing will lookup the correct uptodate map entry and use that to calculate the symbol and DSO relative address. But later when we update the histogram we'll translate the address using the outdated map file instead leading to conditions such as out-of-range offsets in symbol__inc_addr_samples(). Therefore, update the map of the hist_entry dynamically at lookup/ creation time. Signed-off-by: David S. Miller Link: http://lkml.kernel.org/r/20120327.031418.1220315351537060808.davem@davemloft.net Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

perf tools: Use scnprintf where applicable

2012-03-23T18:21:22Z

commit e7f01d1e3d8d501deb8abeaa269d5d48a703b8b0 upstream. Several places were expecting that the value returned was the number of characters printed, not what would be printed if there was space. Fix it by using the scnprintf and vscnprintf variants we inherited from the kernel sources. Some corner cases where the number of printed characters were not accounted were fixed too. Reported-by: Anton Blanchard Cc: Anton Blanchard Cc: Eric B Munson Cc: David Ahern Cc: Frederic Weisbecker Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Yanmin Zhang Link: http://lkml.kernel.org/n/tip-kwxo2eh29cxmd8ilixi2005x@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

perf tools: Incorrect use of snprintf results in SEGV

2012-03-23T18:21:22Z

commit b832796caa1fda8516464a003c8c7cc547bc20c2 upstream. I have a workload where perf top scribbles over the stack and we SEGV. What makes it interesting is that an snprintf is causing this. The workload is a c++ gem that has method names over 3000 characters long, but snprintf is designed to avoid overrunning buffers. So what went wrong? The problem is we assume snprintf returns the number of characters written: ret += repsep_snprintf(bf + ret, size - ret, "[%c] ", self->level); ... ret += repsep_snprintf(bf + ret, size - ret, "%s", self->ms.sym->name); Unfortunately this is not how snprintf works. snprintf returns the number of characters that would have been written if there was enough space. In the above case, if the first snprintf returns a value larger than size, we pass a negative size into the second snprintf and happily scribble over the stack. If you have 3000 character c++ methods thats a lot of stack to trample. This patch fixes repsep_snprintf by clamping the value at size - 1 which is the maximum snprintf can write before adding the NULL terminator. I get the sinking feeling that there are a lot of other uses of snprintf that have this same bug, we should audit them all. Cc: David Ahern Cc: Eric B Munson Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Yanmin Zhang Link: http://lkml.kernel.org/r/20120307114249.44275ca3@kryten Signed-off-by: Anton Blanchard Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman