0.74-3 - Heap corruption when CPU core set to auto

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

0.74-3 - Heap corruption when CPU core set to auto

Postby Kahenraz » 2019-9-01 @ 18:45

I'm running Spelling Jungle / Yobi's Basic Spelling Tricks in DOSBox and it's crashing when CPU core is set to "auto" when using the -forcescaler option. Manually setting the core to either "normal" or "dynamic" does not cause a crash. However, this may not be consistent. I believe it was still crashing with "normal" until I rebooted-- I'm not entirely sure.

https://en.wikipedia.org/wiki/Spelling_Jungle

Code: Select all
$ dosbox -forcescaler advmame2x -noconsole -exit -conf config -c exit
DOSBox version 0.74-3
Copyright 2002-2019 DOSBox Team, published under GNU GPL.
---
CONFIG:Loading primary settings from config file config
MIXER:Got different values from SDL: freq 44100, blocksize 512
ALSA:Can't subscribe to MIDI port (65:0) nor (17:0)
MIDI:Opened device:none
Setting excute permission on the code cache has failed
Segmentation fault (core dumped)


This makes SELinux very unhappy:

Code: Select all
SELinux is preventing dosbox from using the execheap access on a process.

*****  Plugin allow_execheap (53.1 confidence) suggests   ********************

If you do not think dosbox should need to map heap memory that is both writable and executable.
Then you need to report a bug. This is a potentially dangerous access.
Do
contact your security administrator and report this issue.

*****  Plugin catchall_boolean (42.6 confidence) suggests   ******************

If you want to allow selinuxuser to execheap
Then you must tell SELinux about this by enabling the 'selinuxuser_execheap' boolean.

Do
setsebool -P selinuxuser_execheap 1

*****  Plugin catchall (5.76 confidence) suggests   **************************

If you believe that dosbox should be allowed execheap access on processes labeled unconfined_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'dosbox' --raw | audit2allow -M my-dosbox
# semodule -X 300 -i my-dosbox.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Objects                Unknown [ process ]
Source                        dosbox
Source Path                   dosbox
Port                          <Unknown>
Host                          hpenvy13m
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.14.3-43.fc30.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     hpenvy13m
Platform                      Linux hpenvy13m 5.2.9-200.fc30.x86_64 #1 SMP Fri
                              Aug 16 21:37:45 UTC 2019 x86_64 x86_64
Alert Count                   11
First Seen                    2019-09-01 13:30:01 EDT
Last Seen                     2019-09-01 14:13:35 EDT
Local ID                      6127a617-2a1d-4794-9c8d-e669685983ed

Raw Audit Messages
type=AVC msg=audit(1567361615.991:767): avc:  denied  { execheap } for  pid=14106 comm="dosbox" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0


Hash: dosbox,unconfined_t,unconfined_t,process,execheap


Out of curiosity, I ran it as root to bypass the policy and my system immediately locked up after displaying the game splash screen. On the plus side, it scaled correctly for the first frame.

This affects my Ryzen 7 2700U laptop running Fedora 30 x86_64. The exact same options work on my other laptop running an old Intel netbook processor and Fedora i686.

Running this game is a little bit more complicated as it has to first load Windows 3.1 and then launch the game.

The game requires 8-bit color mode, if that makes a difference.
User avatar
Kahenraz
Oldbie
 
Posts: 565
Joined: 2004-1-22 @ 04:57

Re: 0.74-3 - Heap corruption when CPU core set to auto

Postby jmarsh » 2019-9-01 @ 19:54

That error would happen for either core=auto or core=dynamic regardless of any other settings. It's not heap corruption, it is the OS not allowing the dynamic core to map memory as both writable and executable.
jmarsh
Member
 
Posts: 241
Joined: 2014-1-04 @ 09:17


Re: 0.74-3 - Heap corruption when CPU core set to auto

Postby Kahenraz » 2019-9-01 @ 22:20

I can confirm that DOSBox runs fine with core=dynamic. Auto only becomes a problem when mixed with the -forcescaler option.

Because it's dynamic, will I instead encounter a problem at runtime?
User avatar
Kahenraz
Oldbie
 
Posts: 565
Joined: 2004-1-22 @ 04:57

Re: 0.74-3 - Heap corruption when CPU core set to auto

Postby jmarsh » 2019-9-02 @ 04:01

You will encounter the same problem you posted above ("Setting excute permission on the code cache has failed"). The scaler has nothing to do with it.
jmarsh
Member
 
Posts: 241
Joined: 2014-1-04 @ 09:17

Re: 0.74-3 - Heap corruption when CPU core set to auto

Postby Kahenraz » 2019-9-02 @ 09:54

I can confirm that disabling SELinux stops the crash. I don't understand why setting CPU to dynamic instead of auto allows me to use the scaler without crashing or setting it to auto with the scaler off also allows it to run without crashing.

In my case I need core=dynamic and -forcescaler to cause the crash.
User avatar
Kahenraz
Oldbie
 
Posts: 565
Joined: 2004-1-22 @ 04:57


Return to DOSBox Development

Who is online

Users browsing this forum: INT1, krcroft and 2 guests