Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address

[Andres Salomon]

On Sat, 14 Jan 2023 16:12:47 +0100 Salvatore Bonaccorso 
 wrote:

> Hi Jakub,
>
> On Thu, Jan 12, 2023 at 01:24:16PM +0100, Jakub Wilk wrote:
> > * Salvatore Bonaccorso , 2022-11-19 11:11:
> > > Given you were able to tackle the issue further, can you report 
the

> > > issue to upstream
> >
> > Don't count on me. Sorry!
>
> Okay thanks for beeing explicit on that. Then I guess it's on our end
> to try to get that upstream.
>
> Regards,
> Salvatore
>
>

This bug seems to also affect 64-bit mmap (though not nearly as badly), 
and is written about here:


https://zolutal.github.io/aslrnt/

Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address

[Salvatore Bonaccorso]

Hi Jakub,

On Thu, Jan 12, 2023 at 01:24:16PM +0100, Jakub Wilk wrote:
> * Salvatore Bonaccorso , 2022-11-19 11:11:
> > Given you were able to tackle the issue further, can you report the
> > issue to upstream
> 
> Don't count on me. Sorry!

Okay thanks for beeing explicit on that. Then I guess it's on our end
to try to get that upstream.

Regards,
Salvatore

Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address

[Jakub Wilk]

* Salvatore Bonaccorso , 2022-11-19 11:11:
Given you were able to tackle the issue further, can you report the 
issue to upstream


Don't count on me. Sorry!

--
Jakub Wilk

Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address

[Salvatore Bonaccorso]

Hello Jakub,

On Fri, Nov 18, 2022 at 09:53:49PM +0100, Jakub Wilk wrote:
> I've bisected this; the first bad commit is 1854bc6e24204726 ("mm/readahead:
> Align file mappings for non-DAX").

Given you were able to tackle the issue further, can you report the
issue to upstream (and keep this bug in the loop), including to the
memory managment maintainers explicitly William Kucharski
 and Matthew Wilcox (Oracle)
 as well?

Regards,
Salvatore

Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address

[Jakub Wilk]

I've bisected this; the first bad commit is 1854bc6e24204726 
("mm/readahead: Align file mappings for non-DAX").


--
Jakub Wilk

Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address

[Jakub Wilk]

Adding forgotten attachment...

--
Jakub Wilk
#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
	struct stat st;
	if (fstat(0, ) < 0)
		abort();
	void *p = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0);
	printf("mmap(NULL, %zd, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = %p\n", (size_t) st.st_size, p);
}

Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address

[Jakub Wilk]

Package: src:linux
Version: 6.0.8-1
Tags: security
Control: affects -1 + libc6

32-bit mmap() puts large (>= 2 MiB) files at the same address every 
time:

$ i686-linux-gnu-gcc -static test-mmap.c -o test-mmap
$ head -c $((2 * 1024 * 1024)) /dev/zero > zeros
$ for i in 1 2 3; do ./test-mmap < zeros; done
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7c0
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7c0
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7c0

In contrast, for smaller files, there's a few bits of entropy in the 
address:

$ head -c $((2 * 1024 * 1024 - 4096)) /dev/zero > zeros
$ for i in 1 2 3; do ./test-mmap < zeros; done
mmap(NULL, 2093056, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7d4a000
mmap(NULL, 2093056, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7db8000
mmap(NULL, 2093056, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7d99000

This weakens ASLR for most(?) programs, because libc.so.6 has recently 
become slightly larger than 2 MiB:

$ wc -c /lib/i386-linux-gnu/libc.so.6
2225200 /lib/i386-linux-gnu/libc.so.6

$ for i in 1 2 3; do cat /proc/self/maps | grep ' r-xp .*/libc'; done
f7c22000-f7d9b000 r-xp 00022000 fd:00 12059068   
/lib/i386-linux-gnu/libc.so.6
f7c22000-f7d9b000 r-xp 00022000 fd:00 12059068   
/lib/i386-linux-gnu/libc.so.6
f7c22000-f7d9b000 r-xp 00022000 fd:00 12059068   
/lib/i386-linux-gnu/libc.so.6

Curiously, not all file systems are affected. I could reproduce the bug 
on ext4, but not on tmpfs or unionfs.


-- Package-specific info:
** Version:
Linux version 6.0.0-4-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 
12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC 
Debian 6.0.8-1 (2022-11-11)


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
Architecture: i386 (x86_64)
Foreign Architectures: amd64

-- 
Jakub Wilk