summaryrefslogtreecommitdiffstats
path: root/MAINTAINERS
diff options
context:
space:
mode:
authorTobin C. Harding <me@tobin.cc>2017-11-06 16:19:27 +1100
committerLinus Torvalds <torvalds@linux-foundation.org>2017-11-06 11:46:42 -0800
commit136fc5c41f349296db1910677bb7402b0eeff376 (patch)
treeeb9005942d3ac0327edb58b6bdc2bcbad5915f3d /MAINTAINERS
parentaf903dcd31e1b345d858ca2af9a84ed61c960b57 (diff)
downloadlinux-stable-136fc5c41f349296db1910677bb7402b0eeff376.tar.gz
linux-stable-136fc5c41f349296db1910677bb7402b0eeff376.tar.bz2
linux-stable-136fc5c41f349296db1910677bb7402b0eeff376.zip
scripts: add leaking_addresses.pl
Currently we are leaking addresses from the kernel to user space. This script is an attempt to find some of those leakages. Script parses `dmesg` output and /proc and /sys files for hex strings that look like kernel addresses. Only works for 64 bit kernels, the reason being that kernel addresses on 64 bit kernels have 'ffff' as the leading bit pattern making greping possible. On 32 kernels we don't have this luxury. Scripts is _slightly_ smarter than a straight grep, we check for false positives (all 0's or all 1's, and vsyscall start/finish addresses). [ I think there is a lot of room for improvement here, but it's already useful, so I'm merging it as-is. The whole "hash %p format" series is expected to go into 4.15, but will not fix %x users, and will not incentivize people to look at what they are leaking. - Linus ] Signed-off-by: Tobin C. Harding <me@tobin.cc> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'MAINTAINERS')
-rw-r--r--MAINTAINERS5
1 files changed, 5 insertions, 0 deletions
diff --git a/MAINTAINERS b/MAINTAINERS
index 2f4e462aa4a2..a7995c737728 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7745,6 +7745,11 @@ S: Maintained
F: Documentation/scsi/53c700.txt
F: drivers/scsi/53c700*
+LEAKING_ADDRESSES
+M: Tobin C. Harding <me@tobin.cc>
+S: Maintained
+F: scripts/leaking_addresses.pl
+
LED SUBSYSTEM
M: Richard Purdie <rpurdie@rpsys.net>
M: Jacek Anaszewski <jacek.anaszewski@gmail.com>