我正在debuggingLinux DNS服务器的问题。 奇怪的是，当我查看DNS服务器进程的/proc/PID/maps ，这是我得到的：
00000000-00000000 r-xp 00000000 00:0e 2344 /usr/sbin/unbound 00000000-00000000 rw-p 00000000 00:0e 2344 /usr/sbin/unbound 00000000-00000000 ---p 00000000 00:00 0 00000000-00000000 rw-p 00000000 00:00 0 [heap] 00000000-00000000 rw-p 00000000 00:00 0 [heap] 00000000-00000000 r-xp 00000000 00:0e 2009 /usr/lib/engines/libgost.so (deleted) 00000000-00000000 ---p 00000000 00:00 0 00000000-00000000 rw-p 00000000 00:0e 2009 /usr/lib/engines/libgost.so (deleted) 00000000-00000000 r-xp 00000000 00:0e 2016 /usr/lib/engines/libpadlock.so (deleted) 00000000-00000000 ---p 00000000 00:00 0 00000000-00000000 rw-p 00000000 00:0e 2016 /usr/lib/engines/libpadlock.so (deleted) 00000000-00000000 r-xp 00000000 00:0e 2333 /lib/libz.so.1.2.8 00000000-00000000 ---p 00000000 00:00 0 00000000-00000000 rw-p 00000000 00:0e 2333 /lib/libz.so.1.2.8 00000000-00000000 r-xp 00000000 00:0e 1760 /lib/libdl-0.9.33.2.so 00000000-00000000 ---p 00000000 00:00 0 00000000-00000000 r--p 00000000 00:0e 1760 /lib/libdl-0.9.33.2.so 00000000-00000000 rw-p 00000000 00:0e 1760 /lib/libdl-0.9.33.2.so 00000000-00000000 r-xp 00000000 00:0e 3083 /usr/lib/libgcc_s.so.1 00000000-00000000 ---p 00000000 00:00 0 00000000-00000000 rw-p 00000000 00:0e 3083 /usr/lib/libgcc_s.so.1 00000000-00000000 r-xp 00000000 00:0e 1761 /lib/libuClibc-0.9.33.2.so 00000000-00000000 ---p 00000000 00:00 0 00000000-00000000 r--p 00000000 00:0e 1761 /lib/libuClibc-0.9.33.2.so 00000000-00000000 rw-p 00000000 00:0e 1761 /lib/libuClibc-0.9.33.2.so 00000000-00000000 rw-p 00000000 00:00 0 00000000-00000000 r-xp 00000000 00:0e 3085 /lib/libpthread-0.9.33.2.so 00000000-00000000 ---p 00000000 00:00 0 00000000-00000000 r--p 00000000 00:0e 3085 /lib/libpthread-0.9.33.2.so 00000000-00000000 rw-p 00000000 00:0e 3085 /lib/libpthread-0.9.33.2.so 00000000-00000000 rw-p 00000000 00:00 0 00000000-00000000 r-xp 00000000 00:0e 2002 /lib/libcrypto.so.1.0.0 (deleted) 00000000-00000000 ---p 00000000 00:00 0 00000000-00000000 rw-p 00000000 00:0e 2002 /lib/libcrypto.so.1.0.0 (deleted) 00000000-00000000 rw-p 00000000 00:00 0 00000000-00000000 r-xp 00000000 00:0e 3181 /usr/lib/libevent-2.0.so.5.1.9 00000000-00000000 ---p 00000000 00:00 0 00000000-00000000 rw-p 00000000 00:0e 3181 /usr/lib/libevent-2.0.so.5.1.9 00000000-00000000 r-xp 00000000 00:0e 3189 /usr/lib/libldns.so.1.6.17 00000000-00000000 ---p 00000000 00:00 0 00000000-00000000 rw-p 00000000 00:0e 3189 /usr/lib/libldns.so.1.6.17 00000000-00000000 r-xp 00000000 00:0e 2335 /lib/libssl.so.1.0.0 (deleted) 00000000-00000000 ---p 00000000 00:00 0 00000000-00000000 rw-p 00000000 00:0e 2335 /lib/libssl.so.1.0.0 (deleted) 00000000-00000000 r-xp 00000000 00:0e 1755 /lib/ld64-uClibc-0.9.33.2.so 00000000-00000000 rw-p 00000000 00:00 0 00000000-00000000 rw-p 00000000 00:00 0 00000000-00000000 r-xp 00000000 00:00 0 [vdso] 00000000-00000000 r--p 00000000 00:0e 1755 /lib/ld64-uClibc-0.9.33.2.so 00000000-00000000 rw-p 00000000 00:0e 1755 /lib/ld64-uClibc-0.9.33.2.so 00000000-00000000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 r--p 00000000 00:00 0 [vsyscall]
我从来没有见过这样的事情。 所有的地址，除了vsyscall页面，都是零！ 你知道那是什么意思吗？
当有人遇到同样的问题时，我在Valgrind邮件列表中发现了这个讨论 。 问题在于内核已经被修补了PaX补丁，其中一个不允许查看/proc/pid/maps 。
关于来自维基百科的补丁的报价
如果攻击者需要先进的地址空间布局知识，并且可以通过读取攻击任务的地址空间来获得这些知识，那么第二类和第三类攻击也可能具有100％的可靠性。 如果目标有泄漏信息的bug，例如攻击者可以访问/ proc /（pid）/ maps，则这是可能的。 有一个obscurity补丁，它可以将每个信息源的地址范围和信息节点的值清空，从而可以从用户空间访问这些信息源来关闭大部分这些空洞。 但是，目前尚未包含在PaX中。
尽管目前还没有包含该补丁，但邮件列表中的问题是通过PaX实用程序解决的。 也就是说，它可以用chpax实用程序进行更改， chpax实用程序在每个二进制文件上进行权限修改，从而允许禁用特定二进制文件的限制。