debug: Improve '%n' fortify detection (BZ 30932)

The 7bb8045ec0 path made the '%n' fortify check ignore EMFILE errors
while trying to open /proc/self/maps, and this added a security
issue where EMFILE can be attacker-controlled thus making it
ineffective for some cases.

The EMFILE failure is reinstated but with a different error
message.  Also, to improve the false positive of the hardening for
the cases where no new files can be opened, the
_dl_readonly_area now uses  _dl_find_object to check if the
memory area is within a writable ELF segment.  The procfs method is
still used as fallback.

Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Arjun Shankar <arjun@redhat.com>

1 files changed, 12 insertions, 11 deletions

diff --git a/debug/readonly-area.c b/debug/readonly-area.c
index 04b437ed8d..4311b8214a 100644
--- a/debug/readonly-area.c
+++ b/debug/readonly-area.c
@@ -16,18 +16,19 @@
    <https://www.gnu.org/licenses/>.  */
 
 #include <stdlib.h>
+#include <ldsodefs.h>
 
-/* Return 1 if the whole area PTR .. PTR+SIZE is not writable.
-   Return -1 if it is writable.  */
-
-int
+enum readonly_error_type
 __readonly_area (const void *ptr, size_t size)
 {
-  /* We cannot determine in general whether memory is writable or not.
-     This must be handled in a system-dependent manner.  to not
-     unconditionally break code we need to return here a positive
-     answer.  This disables this security measure but that is the
-     price people have to pay for using systems without a real
-     implementation of this interface.  */
-  return 1;
+  switch (GLRO(dl_readonly_area (ptr, size)))
+    {
+    case dl_readonly_area_rdonly:
+      return readonly_noerror;
+    case dl_readonly_area_writable:
+      return readonly_area_writable;
+    default:
+      break;
+    }
+  return __readonly_area_fallback (ptr, size);
 }