grsecurity forums

Posted: **Thu Jul 26, 2012 10:39 am**

Hello.

I've downloaded the 2.6.32.59 Kernel from kernel.org and applied the grsecurity patch to it. This was done on a Debian 6.0 32-bit (x86) with a 2.6.32-5-686 Kernel.

Upon booting when the Operating System does its auto-probing, it reports in the console the following:

Code: Select all: b05db000-b05f8000 r-xp 00000000 fe:00 55107 /lib/libgcc_s.so.1: munlock failed: invalid argument

The same is available for other dynamic shared object library files such as:

Code: Select all: /lib/i686/cmov/libc-2.11.3.so /lib/libudev.so.0.9.3 /lib/libdevmapper.so.1.02.1 /lib/ld-2.11.3.so

The machine is running on VMware as a virtual machine and the powerhorse behind this is an AMD 64 DualCore processor.

Any ideas what munlock is all about and how this affects what?

Thank you.

Posted: **Thu Jul 26, 2012 11:39 am**

would it be possible to strace the failing process to see how munlock is being called?

Posted: **Thu Jul 26, 2012 5:16 pm**

PaX Team wrote:would it be possible to strace the failing process to see how munlock is being called?

Strace log is available here:

Code: Select all: http://sprunge.us/BOYT

This was taken after user authentication. If in case you need to put an strace at boot-up as a start-up service to generate log, then let me know with a variant that does it the best way for you.

Thank you.

Addition:

Well, after I took a look at the strace log, some library files are missing so maybe this is the reason why mlock (munlock) says it fails with "Invalid argument".

What are your thoughts on that?

strace.log from above link wrote:[ -->8-- snip -->8-- ]
access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x520fc000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)

[ -->8-- snip -->8-- ]
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
close(3) = 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)

[ -->8-- snip -->8-- ]
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/i686/cmov/libnss_compat.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\16\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=30496, ...}) = 0
mmap2(NULL, 29268, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x51fa7000
mmap2(0x51fad000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0x51fad000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)

[ -->8-- snip -->8-- ]
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/i686/cmov/libnss_nis.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\31\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=38504, ...}) = 0
mmap2(NULL, 37432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x51f86000
mmap2(0x51f8e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8) = 0x51f8e000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)

Not sure about device-mapper libraries and the others mentioned in the picture but not in the log though.

Posted: **Thu Jul 26, 2012 9:13 pm**

sfs6dzs wrote:This was taken after user authentication. If in case you need to put an strace at boot-up as a start-up service to generate log, then let me know with a variant that does it the best way for you.

thanks but i'd need an strace of a failing process that produces the munlock failure above. if it's some service you can restart after boot, then just do it through strace -f.

Posted: **Sat Jul 28, 2012 1:24 pm**

PaX Team wrote:
sfs6dzs wrote:This was taken after user authentication. If in case you need to put an strace at boot-up as a start-up service to generate log, then let me know with a variant that does it the best way for you.
thanks but i'd need an strace of a failing process that produces the munlock failure above. if it's some service you can restart after boot, then just do it through strace -f.

I wish I could help you with this, the problem is that, as the machine is running without an interface and I am only having the virtual consoles available to me, I cannot scroll up or down (from my knowledge) at login time to find which process triggered munlock failures. Any ideas?

Sorry about this

Posted: **Sat Jul 28, 2012 7:04 pm**

what happens if you set activation/use_mlockall=1 in your lvm.conf file? also i think i figured it out, i'll fix it in the next patches.

Posted: **Sun Jul 29, 2012 5:26 pm**

PaX Team wrote:what happens if you set activation/use_mlockall=1 in your lvm.conf file?

The same happens.

PaX Team wrote:also i think i figured it out, i'll fix it in the next patches.

Want to share any of your thoughts?

Thank you!

Posted: **Sun Jul 29, 2012 6:08 pm**

sfs6dzs wrote:
PaX Team wrote:what happens if you set activation/use_mlockall=1 in your lvm.conf file?
The same happens.

by the look of it, you'd probably have to change the lvm.conf used by your initrd.

Want to share any of your thoughts?

under SEGMEXEC (which i believe you use instead of PAGEEXEC) the m(un)lock code was supposed to ignore the vma mirrors (without reporting an error on them) but due to the bug, it didn't. the fix is in the latest grsec now, so you can verify it

.

Posted: **Mon Jul 30, 2012 8:22 am**

PaX Team wrote:under SEGMEXEC (which i believe you use instead of PAGEEXEC) the m(un)lock code was supposed to ignore the vma mirrors (without reporting an error on them) but due to the bug, it didn't.

Since it ignores the vma mirrors, I believe it does not affect any of the functionality of the m(un)lock code that is supposed to be used, since it is used in swap technique, correct?

PaX Team wrote:the fix is in the latest grsec now, so you can verify it .

And so I have tested it and no more errors are displayed upon booting. I have "glued" together several screenshots into a single image just for the sake of it (you will have to zoom and scroll down a bit). The applied patch is grsecurity-2.9.1-2.6.32.59-201207281944.patch.

Thanks for the fix! And I hope I have helped you somewhat back.

Posted: **Mon Jul 30, 2012 7:07 pm**

sfs6dzs wrote:Since it ignores the vma mirrors, I believe it does not affect any of the functionality of the m(un)lock code that is supposed to be used, since it is used in swap technique, correct?

due to the very nature of vma mirroring, it's enough to lock only one of the mirrored pairs, the underlying pages will stay in physical memory for both mappings.

Thanks for the fix! And I hope I have helped you somewhat back.

you're welcome and keep reporting problems you run across, however innocent looking

.

grsecurity forums

/lib/*.so: munlock failed: Invalid argument

/lib/*.so: munlock failed: Invalid argument

Re: /lib/*.so: munlock failed: Invalid argument

Re: /lib/*.so: munlock failed: Invalid argument

Re: /lib/*.so: munlock failed: Invalid argument

Re: /lib/*.so: munlock failed: Invalid argument

Re: /lib/*.so: munlock failed: Invalid argument

Re: /lib/*.so: munlock failed: Invalid argument

Re: /lib/*.so: munlock failed: Invalid argument

Re: /lib/*.so: munlock failed: Invalid argument

Re: /lib/*.so: munlock failed: Invalid argument