Bug 1546440 - Linux kernel 4.15.3-300 failed regression testing during paxtest. Continues through 4.16.14-200
Summary: Linux kernel 4.15.3-300 failed regression testing during paxtest. Continues t...
Status: CLOSED DUPLICATE of bug 1591967
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 27
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 1536864 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-17 14:03 UTC by pmkellly
Modified: 2018-07-23 18:32 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-07-23 18:32:10 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
regression test log (2.59 KB, text/plain)
2018-02-17 14:03 UTC, pmkellly
no flags Details

Description pmkellly 2018-02-17 14:03:30 UTC
Created attachment 1397381 [details]
regression test log

Description of problem:
Failed regression test during paxtest on a Lenovo model H50-55 with AMD A10-7800 processor.

Version-Release number of selected component (if applicable): 4.15.3-300


How reproducible: Run the base regression test {./runtests.sh}


Steps to Reproduce:
1.From command line do the following:
2.CD kernel-tests
3.sudo ./runtests.sh

Actual results: "Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (26)" "Failed Tests: ./default/paxtest"


Expected results: Pass


Additional info: reference bug:1308538

Comment 1 pmkellly 2018-02-20 21:20:35 UTC
As I recall I think I found a request to reference bug:1308538 in the Linux 4.15.3 Test Day pages. Now as I look at this bug, it is not clear how it applies.

Comment 2 pmkellly 2018-02-23 15:45:44 UTC
As I reviewed the Fedora QA group Test Day results for Linux 4.15 I see that several of the entries showing AMD processors show this failure.

Comment 3 pmkellly 2018-02-27 19:16:46 UTC
Sorry, I just read that I should not set the Severity. I apologise for any problem I may have caused. I have set it back to unspecified.

Comment 4 pmkellly 2018-03-02 11:50:21 UTC
This bug is still present in 4.15.6-300.fc27.x86_64 x86_64

Comment 5 pmkellly 2018-03-02 11:54:00 UTC
*** Bug 1536864 has been marked as a duplicate of this bug. ***

Comment 6 pmkellly 2018-03-12 10:52:49 UTC
This bug is still present in 4.15.7-300.fc27.x86_64 x86_64

Comment 7 pmkellly 2018-03-12 17:28:17 UTC
This bug is still present in 4.15.8-300.fc27.x86_64 x86_64

Comment 8 pmkellly 2018-03-17 21:02:34 UTC
This bug is still present in 4.15.9-300.fc27.x86_64 x86_64

Comment 9 pmkellly 2018-03-21 10:04:34 UTC
This bug is still present in 4.15.10-300.fc27.x86_64 x86_64

Comment 10 pmkellly 2018-03-27 20:23:39 UTC
This bug is still present in 4.15.12-301.fc27.x86_64 x86_64

Comment 11 pmkellly 2018-03-28 13:23:32 UTC
This bug is still present in 4.15.13-300.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (25)

Comment 12 pmkellly 2018-03-31 12:12:37 UTC
This bug is still present in 4.15.14-300.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (25)

Comment 13 pmkellly 2018-04-05 18:22:36 UTC
This bug is still present in 4.15.15-300.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (26)

Comment 14 pmkellly 2018-04-14 15:44:27 UTC
This bug is still present in 4.15.16-300.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (25)

Comment 15 pmkellly 2018-04-15 20:55:55 UTC
This bug is still present in 4.15.17-300.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (26)

Comment 16 pmkellly 2018-04-27 13:01:30 UTC
This bug is still present in 4.16.3-200.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (25)

Comment 17 pmkellly 2018-04-29 13:54:11 UTC
This bug is still present in 4.16.4-200.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (26)

Comment 18 pmkellly 2018-05-01 12:52:07 UTC
This bug is still present in 4.16.5-200.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (25)

Comment 19 Shaun Assam 2018-05-06 23:17:37 UTC
paxtest failed on kernel-4.16.6-302.fc28 and kernel-4.16.7-300.fc28 (Lenovo Thinkpads x220 and x240).

Comment 20 pmkellly 2018-05-07 13:09:56 UTC
This bug is still present in 4.16.6-200.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (26)

Comment 21 pmkellly 2018-05-11 11:48:35 UTC
This bug is still present in 4.16.7-200.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (25)

Comment 22 pmkellly 2018-05-23 11:47:47 UTC
This bug is still present in 4.16.9-200.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (25)

Comment 23 Shaun Assam 2018-05-25 20:26:40 UTC
@pmkellly,

Can you please try the following command and run the kernel regression test to confirm if paxtest passes:

sudo setsebool -P selinuxuser_execheap 0

It appears this is an issue with SELinux and not the kernel. I can confirm this was the solution for me.


The following is the SELinux alert message:

----
SELinux is preventing mprotheap from using the execheap access on a process.

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

If you do not think mprotheap 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 mprotheap 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 'mprotheap' --raw | audit2allow -M my-mprotheap
# semodule -X 300 -i my-mprotheap.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                        mprotheap
Source Path                   mprotheap
Port                          <Unknown>
Host                          orion
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-283.34.fc27.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     orion
Platform                      Linux orion 4.16.11-200.fc27.x86_64 #1 SMP Tue May
                              22 18:36:25 UTC 2018 x86_64 x86_64
Alert Count                   4
First Seen                    2018-05-24 10:13:36 EDT
Last Seen                     2018-05-25 16:07:50 EDT
Local ID                      7b010961-5955-4153-b408-c85ffa87daf4

Raw Audit Messages
type=AVC msg=audit(1527278870.584:443): avc:  denied  { execheap } for  pid=7083 comm="mprotheap" 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: mprotheap,unconfined_t,unconfined_t,process,execheap
----

Comment 24 pmkellly 2018-05-26 13:06:43 UTC
In this PC, that boolean was not set to true, but I did the command as suggested and it made no difference in the paxtest result.

Here is the text from the terminal screen:

[table1pc2@localhost ~]$ getsebool selinuxuser_execheap
selinuxuser_execheap --> off
[table1pc2@localhost ~]$ sudo setsebool -P selinuxuser_execheap 0
[table1pc2@localhost ~]$ getsebool selinuxuser_execheap
selinuxuser_execheap --> off
[table1pc2@localhost ~]$ cd kernel-tests
[table1pc2@localhost kernel-tests]$ sudo ./runtests.sh
Test suite called with default
./default/sysfs-perms                                            PASS    
./default/cachedrop                                              PASS    
./default/selinux-dac-controls                                   PASS    
./default/mq-memory-corruption                                   PASS    
./default/timer-overhead                                         PASS    
./default/modsign                                                SKIP    
./default/insert_leap_second                                     PASS    
./default/paxtest                                                FAIL    
./default/posix_timers                                           PASS    
./default/libhugetlbfs                                           SKIP    
./default/stack-randomness                                       PASS    
./default/memfd                                                  PASS    

Test suite complete                                              FAIL    

Your log file is being submitted
FAS password: 
Upload successful!

Comment 25 pmkellly 2018-05-26 13:11:22 UTC
This bug is still present in 4.16.11-200.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (26)

Comment 26 pmkellly 2018-05-30 11:46:53 UTC
This bug is still present in 4.16.12-200.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (26)

Comment 27 pmkellly 2018-06-05 22:10:46 UTC
This bug is still present in 4.16.13-200.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (25)

Comment 28 pmkellly 2018-06-13 20:26:37 UTC
This bug is still present in 4.16.14-200.fc27.x86_64 x86_64

Starting test ./default/paxtest
Main executable randomisation (PIE) randomness is less than 28 bits (25)

Comment 29 Justin M. Forbes 2018-07-23 15:07:09 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.

Fedora 27 has now been rebased to 4.17.7-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28.

If you experience different issues, please open a new bug report for those.

Comment 30 pmkellly 2018-07-23 18:01:09 UTC
In regard to request for info.

I no longer have any machines running F27. They are all on F28 now. This bug continues to exist in F28. I didn't know the protocol, but it seemed best to file a new bug report for that. Please see Bug 1591967.

Okay I see now that I should have changed the version in the bug to F28. Sorry for the inconvenience.

Comment 31 Justin M. Forbes 2018-07-23 18:32:10 UTC

*** This bug has been marked as a duplicate of bug 1591967 ***


Note You need to log in before you can comment on or make changes to this bug.