kernel/linux.git/scripts/leaking_addresses.pl, branch v6.6.131

leaking_addresses: also skip canonical ftrace path

2023-03-29T10:52:08+00:00

The canonical location for the tracefs filesystem is at /sys/kernel/tracing. But, from Documentation/trace/ftrace.rst: Before 4.1, all ftrace tracing control files were within the debugfs file system, which is typically located at /sys/kernel/debug/tracing. For backward compatibility, when mounting the debugfs file system, the tracefs file system will be automatically mounted at: /sys/kernel/debug/tracing scripts/leaking_addresses.pl only skipped this older debugfs path, so let's add the canonical path as well. Link: https://lkml.kernel.org/r/20230313211746.1541525-2-zwisler@kernel.org Cc: "Tobin C. Harding" Cc: Andrew Morton Cc: Mark Rutland Cc: Masami Hiramatsu Cc: Paolo Bonzini Cc: Shuah Khan Acked-by: Tycho Andersen Reviewed-by: Steven Rostedt (Google) Signed-off-by: Ross Zwisler Signed-off-by: Steven Rostedt (Google)

leaking_addresses: Always print a trailing newline

2021-10-15T09:25:13+00:00

For files that lack trailing newlines and match a leaking address (e.g. wchan[1]), the leaking_addresses.pl report would run together with the next line, making things look corrupted. Unconditionally remove the newline on input, and write it back out on output. [1] https://lore.kernel.org/all/20210103142726.GC30643@xsang-OptiPlex-9020/ Signed-off-by: Kees Cook Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20211008111626.151570317@infradead.org

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 166

2019-05-30T18:26:39+00:00

Based on 1 normalized pattern(s): licensed under the terms of the gnu gpl license version 2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 62 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Allison Randal Reviewed-by: Kate Stewart Reviewed-by: Richard Fontana Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.929121379@linutronix.de Signed-off-by: Greg Kroah-Hartman

leaking_addresses: Completely remove --version flag

2019-03-06T21:53:18+00:00

Recently attempt to remove the '--version' flag was made, badly. We failed to remove mention of it from the help output. And we (me) failed to actually remove the flag from the options list. _Completely_ remove --version flag.

leaking_addresses: Fix calls to dprint

2019-03-06T21:53:18+00:00

Currently calls to function dprint() are non uniform and at times incorrect. Use uniform _correct_ call to function dprint(). Signed-off-by: Tobin C. Harding

leaking_addresses: check if file name contains address

2018-04-06T22:50:34+00:00

Sometimes files may be created by using output from printk. As the scan traverses the directory tree we should parse each path name and check if it is leaking an address. Add check for leaking address on each path name. Suggested-by: Tycho Andersen Acked-by: Tycho Andersen Signed-off-by: Tobin C. Harding

leaking_addresses: explicitly name variable used in regex

2018-04-06T22:50:34+00:00

Currently sub routine may_leak_address() is checking regex against Perl special variable $_ which is _fortunately_ being set correctly in a loop before this sub routine is called. We already have declared a variable to hold this value '$line' we should use it. Use $line in regex match instead of implicit $_ Signed-off-by: Tobin C. Harding

leaking_addresses: remove version number

2018-04-06T22:50:34+00:00

We have git now, we don't need a version number. This was originally added because leaking_addresses.pl shamelessly (and mindlessly) copied checkpatch.pl Remove version number from script. Signed-off-by: Tobin C. Harding

leaking_addresses: skip '/proc/1/syscall'

2018-04-06T22:50:34+00:00

The pointers listed in /proc/1/syscall are user pointers, and negative syscall args will show up like kernel addresses. For example /proc/31808/syscall: 0 0x3 0x55b107a38180 0x2000 0xffffffffffffffb0 \ 0x55b107a302d0 0x55b107a38180 0x7fffa313b8e8 0x7ff098560d11 Skip parsing /proc/1/syscall Suggested-by: Tycho Andersen Signed-off-by: Tobin C. Harding

leaking_addresses: skip all /proc/PID except /proc/1

2018-04-06T22:50:34+00:00

When the system is idle it is likely that most files under /proc/PID will be identical for various processes. Scanning _all_ the PIDs under /proc is unnecessary and implies that we are thoroughly scanning /proc. This is _not_ the case because there may be ways userspace can trigger creation of /proc files that leak addresses but were not present during a scan. For these two reasons we should exclude all PID directories under /proc except '1/' Exclude all /proc/PID except /proc/1. Signed-off-by: Tobin C. Harding