Hardening Linux /proc map info from potential expoits

https://www.zeroday.cloud/blog/mariadb-cve-2026-32710-deep-dive

Shows access to /proc/self/maps using LOAD DATA INFILE as a mechanism to target memory regions. Without this information may have been harder to obtain.

I can't think of a good use of /proc/self/maps by MariaDB or its users, so we could deny it.

Other maps exist:

$ find /proc/self/ -name \*map\* 

/proc/self/task/94261/maps

/proc/self/task/94261/numa_maps

/proc/self/task/94261/smaps

/proc/self/task/94261/smaps_rollup

/proc/self/task/94261/pagemap

/proc/self/task/94261/uid_map

/proc/self/task/94261/gid_map

/proc/self/task/94261/projid_map

/proc/self/map_files

/proc/self/maps

/proc/self/numa_maps

/proc/self/smaps

/proc/self/smaps_rollup

/proc/self/pagemap

/proc/self/uid_map

/proc/self/gid_map

/proc/self/projid_map

uid/gid/projid aren't maps of memory so they aren't important, at least in any exploint mechanism I currently think of.

Systemd has:

• InaccessiblePaths
• ProcSubSet=ptraceable (for /proc/pid/XX equallants as pids are easier to discover, and a normal Linux setup would eliminate self ptracing - sysctl kernel.yama.ptrace_scope).

MariaDB access some paths:

• InnoDB memory pressure - /proc/self/cgroup - determine cgroup for memory pressure
• /proc/self/exe - message and deprecated names.
• /proc/self/cmd,limits - fatal signal hander information
• /proc/self/status - some mrooonga benchmark thing (hard to make useful to a expoit).