Where
-Infinity
0

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On Mon, 2024-07-08 at 12:37 -0400, Will Dormann wrote: As reported in the Debian bug, running the program repeatedly with a 2MB file will report the same address every time on a vulnerable system, and will be randomized on a system that is behaving as expected.

In testing some platforms that I had readily available, I've concluded:   - Modern (e.g. 6.x kernel) x86 platforms load a large-enough libc at the same address every time. (i.e. no practical ASLR -- "ASLRn't")   -  Modern (e.g. 6.x kernel and large-enough libc) x8664 platforms running 32-bit code will load a large-enough library at the same address every time.   - Modern x8664 systems with the CVE-2024-26621 patch will randomize the load address of large libraries loaded by 32-bit apps.   - Modern x86 systems with the CVE-2024-26621 patch will NOT ranzomize the load address of large libraries.  (i.e. is still vulnerable to "ASLRn't" despite the patch) Hey,

I'm testing on my Debian sid laptop with Linux kernel 6.9.7-1. This is amd64 but running test-mmap built with -m32, and I get:

for i in {0..10}; do ./test-mmap < zeros; done mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7df3000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7d98000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7d6f000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7de7000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7df6000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7cfd000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7d25000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7d48000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7dad000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7d7b000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7df4000

So it looks to me like it's “properly” randomized (for a 32b process). I don't have a 32b install handy so I can't test but I'd assume the -m32 to exhibit the same behavior? This is with vm.mmaprndcompatbits=8.

Or am I doing something wrong? - -- Yves-Alexis -----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmaO9PsACgkQ3rYcyPpX RFtwbAf/esGTSILYL1Seffq43QtauizeyRAth/3U2o39SbC/KD5Bpx2wwT3+3WX5 ag96yhhBWpf6ef3JgSlblYqCZeFLRFyVYbpLQm4GpfVHDOzvJI1qaF6wPlxyXetn CFy/mQq/CWVNNQ9BH4FvU0SRwaKa7ijszvkDk/RsqS/8e5nR5ufGDyH0LlZU8HJ4 LTLQLLHUA1Xt9xXhBuuNm7iMh0HmesQKOQcPQM0/e6ea7I3enLJNm14gv3eYWUIO RnG+TqwpbGW1E4NlcxZ7qo7sXabmn6tKTg5gQh5X9ADDgW0rvpeKEtYda1rO8M79 /od7a49ITS3XR7tjNswxNBdqelt8Tg== =8zdL -----END PGP SIGNATURE-----

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203