linux-kernel - Re: 2.6.28.4 regression: mmap fails if mlockall used

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0902081802480.14394@blonde.anvils>
Date:	Sun, 8 Feb 2009 18:25:45 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	Sami Farin <safari-kernel@...ari.iki.fi>
cc:	Linux kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.28.4 regression: mmap fails if mlockall used

On Sun, 8 Feb 2009, Sami Farin wrote:

> 2.6.28.2 + gcc-4.3.2-7 works.
> 2.6.28.4 + gcc-4.4.0-0.16 does not work.
> I run x86_64 SMP kernel.

If it's really a bug, in kernel or gcc, then it will help to know
how 2.6.28.4 + gcc-4.3.2-7 behaves.  And are you using the respective
version of gcc to build both the kernel and the a.out?

> 
> # strace ./a.out ntp
> 12:10:14.780726 mmap(NULL, 2147624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = -1 EFAULT (Bad address) <0.000038>

I wonder where that 2147624 originates from.  Because EFAULT is exactly
what you get on an mmap of a file, following an mlockall(MCL_FUTURE),
if the file is actually a page or more shorter than the size given:
the mlocking tries to fault in a non-existent page of the file, if
in userspace you'd get SIGBUS, but within the kernel it's EFAULT
returned from the mmap.

My suspicion is that the 2147624 is just wrong: is it a filesize,
but the file gets truncated before the mmap? or is it the size given
in an ELF section perhaps, but the file actually not that big?
Any ENOSPC in that filesystem recently?

> 12:10:14.780809 close(3)                = 0 <0.000012>
> 12:10:14.780856 munmap(0x7f3476e0d000, 421232) = 0 <0.000145>
> 12:10:14.781054 write(2, "./a.out: getpwnam failed: Success\n"..., 34./a.out: getpwnam failed: Success
> ) = 34 <0.000015>
> 
> I can do malloc(3000000), then mmap call is
> 12:50:20.694207 mmap(NULL, 3002368, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8a8d16b000 <0.003078>

Whereas in the case of anonymous, we don't have an underlying object
to fault in (or create the object in response to the mmap), so no
such problem.

I didn't manage to reproduce this here, but I wasn't using the same
version of gcc nor (I'd guess!) your kernel config nor your a.out.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/