default mmap_min_addr breaks dosemu

[pivo]

Default value of mmap_min_addr is set to 64kb, which breaks many different userland applications, including dosemu, wine and hardware virtualisation.

Should be set to zero, as recommended by LKML when feature was introduced.

As originally reported by pivo:

"""
When I start dosemu, I get the following, only:

$ dosemu
LOWRAM mmap: Invalid argument
Segmentation fault (core dumped)

I use latest hardy on 3 different machines (both ix32 and amd64), tried the console as well as X11, with the same result. The last time I'm certain it worked was 2008-03-26. Some dependency must have borked dosemu. Google didn't help.
"""

***WORKAROUND**************
To fix it temporarily run from console (needed everytime you reboot):
$ sudo sysctl vm.mmap_min_addr=0

To fix it permanently:
As root ("sudo -s"), add this line to /etc/sysctl.d/90-low-memory-access.conf (Intrepid) or /etc/sysctl.conf (Hardy):
   vm.mmap_min_addr=0
and then run: invoke-rc.d procps start
***END WORKAROUND*********

[pivo (pivo-pobox)]

A (temporary ?) workaround is to be found at http://marc.info/?l=linux-msdos&m=120802271919730&w=2

[obnibolongo (obnibolongo)]

Also here.

The fix suggested above works.

dosemu.bin[4032]: segfault at 000f0000 eip b7e019b5 esp bfb4908c error 6

$ cat /proc/version_signature
Ubuntu 2.6.24-16.30-generic

$ uname -a
Linux my_hostname 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

[The Punisher (melprinsi)]

same here
The fix suggested doesn't work on Kubuntu 8.04

max@zarquon:~$ sudo echo 0 > /proc/sys/vm/mmap_min_addr
bash: /proc/sys/vm/mmap_min_addr: Permesso negato

[pivo (pivo-pobox)]

need to learn to use sudo.

echo 0 | sudo tee /proc/sys/vm/mmap_min_addr

[The Punisher (melprinsi)]

shame on me

;-(

[George Ganoe (george-ganoe)]

I can confirm this bug, and also that the suggested fix permits dosemu to
work again.

dosemu has worked on Hardy for me since i originally installed it at beta5.
However, it quit working when the kernel update to

   kernel 2.6.24-16-generic

occurred. I really need to have dosemu working properly before putting
Hardy on my production system. It is a good thing I found the problem
before upgrading that system. Please release a supported fix for this
problem.

               George

[Stephan Wijering (stephan-wijering)]

Dosemu does start after aplying the workaround but my dos program doesnt, it worked in 7.10

[dpecile (dpecile)]

anyone have problems with keyboard layout too ? only under root see the right layout.
may be related ?
Thanks

[Nagy Tamás (nattomi)]

Have anyone found a permanent solution yet?
echo 0 | sudo tee /proc/sys/vm/mmap_min_addr must be rewrote after each restart of the computer.

[Edward Mendelson (emendelson)]

Permanent fix:

with root privileges edit /etc/sysctl.conf file; find the line that reads

    vm.mmap_min_addr = 65536

and change the number from 65536 to 0 (zero). Save and restart.

[Edward Mendelson (emendelson)]

Permanent fix:

with root privleges edit /etc/sysctl.conf file; find the line that reads

    vm.mmap_min_addr = 65536

and change the number from 65536 to 0 (zero). Save and restart.

[Louis-Dominique Dubeau (ldd)]

On Sun, 2008-04-27 at 13:50 +0000, Nagy Tamás wrote:
> Have anyone found a permanent solution yet?
> echo 0 | sudo tee /proc/sys/vm/mmap_min_addr must be rewrote after each restart of the computer.

Manipulations of /proc/sys can be done through sysctl and can be made to
be automatically applied at every boot by editing /etc/sysctl.conf In
this case, the following command performs the same as the above:

$ sudo sysctl vm.mmap_min_addr=0

So adding the line:

vm.mmap_min_addr=0

to /etc/sysctl.conf will make that change automatically with each boot.
I have not tested running the system with this change so I do not know
if making it the default on your system will cause some other unintended
consequences.

Hmm... actually, I looked at my sysctl.conf file and found this:

# protect bottom 64k of memory from mmap to prevent NULL-dereference
# attacks against potential future kernel security vulnerabilities.
# (Added in kernel 2.6.23.)
vm.mmap_min_addr = 65536

So it seems that the current value was set this way on purpose, for
security reasons. This probably should be investigated further.

[John Catt (john-catt)]

Thanks Edward.

Did this and now Dosemu boots OK. However when I try to run an exe
program it say that it can't access the temp directory.

Again works OK if I launch using sudo.

Regards,

John Catt.

Edward Mendelson wrote:
> Permanent fix:
>
> with root privleges edit /etc/sysctl.conf file; find the line that reads
>
> vm.mmap_min_addr = 65536
>
> and change the number from 65536 to 0 (zero). Save and restart.
>

[exactt (giesbert)]

i confirm this bug as well as the workaround setting "sudo sysctl -w vm.mmap_min_addr=0". this seems to be related to https://bugs.launchpad.net/ubuntu/+source/wine/+bug/114025/ .

[drink (martin-espinoza)]

not like it's needed, but I confirm as well. I mostly use dosemu to run populous 2, which works fine for me once I set mmap_min_addr to 0.

[Ricardo Pérez López (ricardo)]

I can confirm this bug and it's workaround on Hardy.

[Stephan Wijering (stephan-wijering)]

@Stephan Wijering wrote on 2008-04-25:

I solved this problem, i was running the program on a samba server and the old method of smbfs doesnt work anymore, i needed to mount using cifs, but it was nessecary tot add the line unix extensions = no in the global section of the smb.conf on the server.

Everyting works reasonbly well now.

[Josh Leahy (jleahy)]

Change was in 2.6.23 kernel update, lines 18-21 of /etc/sysctl.conf.

Suggested vm.mmap_min_addr be changed back to zero for Intrepid, as functionality for non-technical users should be more important the protecting the lower 64kb of memory. The linux kernel has a good track record for security vulnerabilities and vulnerabilities exploiting a dereferenced NULL pointer are rare. This also affects hardware virtualisation.

This was discussed in the LKML (https://kerneltrap.org/mailarchive/linux-kernel/2007/6/5/100078) and it was decided that min_addr=0 should be the default behavior so as not to break user-land by default.

Excerpt from /etc/sysctl.conf below:

# protect bottom 64k of memory from mmap to prevent NULL-dereference
# attacks against potential future kernel security vulnerabilities.
# (Added in kernel 2.6.23.)
vm.mmap_min_addr = 65536

Suggested change to:

# If enabled (set to 65536) will prevent userland from allocating
# more memory, which is more secure. However some features will
# break including dosemu, wine and hardware virtualisation.
vm.mmap_min_addr = 0

Finally I request this bug be moved to the ubuntu kernel, as it affects not only dosemu, but also wine, hardware virtualisation and an unknown number of other userland programs.

[Pablo Castellano (pablocastellano)]

It's present in intrepid.
Someone with rights should triage it.

[Pablo Castellano (pablocastellano)]

Here is the debdiff made from the patch of Josh Leahy

[Pablo Castellano (pablocastellano)]

Forgot to add the reference to LP.
Here is the good one:

[Bryce Harrington (bryce)]

Kees, there are some security implications to this - would you review this sponsorship item?

[Kees Cook (kees)]

procps should not be reverted. The correct fix is to handle this how it was done with wine: add a file to /etc/sysctl.d/ that resets the mmap_min to 0 when you have installed applications that require it (i.e. wine, dosemu). The vast majority of Ubuntu users do no use those applications, so the system default should stay at 64k.

[Kees Cook (kees)]

e.g.:

sudo -s
(echo "# Allow dosemu and Wine to access lower memory" ; echo "vm.mmap_min_addr = 0") > /etc/sysctrl.d/90-low-memory-access.conf
invoke-rc.d procps start

[Pablo Castellano (pablocastellano)]

I already have a fixed deb built.
What format should I provide the patch? I'm new... I had thought debdiff but it doesn't include changes in debian/patches nor Makefiles.

[Pablo Castellano (pablocastellano)]

Here is the patch.
Anyways this package should be revised because when you run 'debuild clean', files are not unpatched which adds difficulty to the task of creating a patch.

Another thing:
the sysctl file would need to be removed without need of --purge in apt-get but I don't know how to do that
wine also needs to do it

[Kees Cook (kees)]

The sysctl file will be removed with --purge. It should not be removed
before then -- packaging policy is that conffiles (stuff in /etc) remain
until the package is purged.

[Launchpad Janitor (janitor)]

This bug was fixed in the package dosemu - 1.4.0+svn.1828-2ubuntu2

---------------
dosemu (1.4.0+svn.1828-2ubuntu2) jaunty; urgency=low

  * debian/{90-dosemu.conf,postinst,install}: handle low memory sysctl,
    thanks to Pablo Castellano (debian bug 505247, LP: #216398).

 -- Kees Cook <email address hidden> Mon, 10 Nov 2008 16:29:02 -0800

[Pablo Castellano (pablocastellano)]

SRU: minimal patch for intrepid is attached.

[Pablo Castellano (pablocastellano)]

SRU: minimal patch for intrepid is attached.

[Kees Cook (kees)]

Pablo, please change the debdiff to use your own email address (since your patch isn't one I directly created), and then adjust the version (1.4.0+svn.1828-2ubuntu1.1) and the pocket (intrepid-proposed) so you can follow the SRU process: https://wiki.ubuntu.com/StableReleaseUpdates (you'll need to subscribe motu-sru, etc).

[Pablo Castellano (pablocastellano)]

Hello Kees, I did what you told me.
I hope I don't miss anything this time.

Here I attach the patch for SRU.

[Malte S. Stretz (mss)]

A small nitpick: As /etc/sysctl.d/README states, the shipped file should be in the 30-* range, not 90-*.

[Pablo Castellano (pablocastellano)]

Hello Malte.
The problem is that in Jaunty it has been already commited the patch with 90-*.
But renaming it to 30-* sounds very logical (reading sysctl.d/README). It was firstly named 90-* to be one of the last configurations executed.
I don't know what to do :?

[Malte S. Stretz (mss)]

It shouldn't be a problem to update the jaunty package, just a small version bump (but don't ask me which part of the version) and everything should be fine. But I'm not the package maintainer, not my decision :) I guess its up to Kees to tell which way to go...

[Kees Cook (kees)]

I'm okay with 90-* for now. Originally I wanted to move it as late in the sysctl settings as possible.

[Pablo Castellano (pablocastellano)]

Hello Kees.
What about it? Is my patch finally going to be applied?

[Kees Cook (kees)]

I've uploaded it to -proposed, so we're now waiting on the SRU team to accept it.

[Jonathan Riddell (jr)]

The diff on the upload is very long, in configure.lineno and config.log and other files. Can that not be avoided?

[Jonathan Riddell (jr)]

Accepted into intrepid-proposed, please test.

[Pablo Castellano (pablocastellano)]

Tested and it works as expected!

[Launchpad Janitor (janitor)]

This bug was fixed in the package dosemu - 1.4.0+svn.1828-2ubuntu1.1

---------------
dosemu (1.4.0+svn.1828-2ubuntu1.1) intrepid-proposed; urgency=low

  * debian/{90-dosemu.conf,postinst,install}: handle low memory sysctl,
    (LP: #216398)

 -- Pablo Castellano <email address hidden> Wed, 19 Nov 2008 18:50:17 +0100

[Norberto Bensa (nbensa)]

Hello everyone. What about Hardy? Are we going to have a proper fix or should we change /etc/sysclt.conf?

Many thanks in advance,
Norberto

[Søren Holm (sgh)]

Hmmm karmic has simmilar problem. mmap_min_addr is set to 0 but dosemu still fails _except_ when running it as root.

[Peter Gervai (grin)]

You people should consider the security background as well. Some info (pro and con as well :)): http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html

[John Dong (jdong)]

Peter has a point here -- mmap_min_addr is a security feature and now, installing dosemu disables it system-wide without any indication to the user that this action is taken.

[Josh Leahy (jleahy)]

This bug is old, it's also resolved. If you believe the fix now poses a security issue I recommend you start a second bug specifying this. However the debate has already been held when this bug was put forward and it was decided that usability is one of the key concerns of Ubuntu and as such the fix was released.

[John Dong (jdong)]

Umm, as a member of motu-sru, I'd hardly call it resolved. This bug was handled with no regard to the Stable Release Updates procedure. I do not see an ACK from someone on the team. My issue is with the handling of THIS bug, not with the security issue itself.

[Kees Cook (kees)]

Re: comment 45> this was fixed prior to karmic releasing.