Bug 1102001 - (CVE-2018-9422) VUL-0: CVE-2018-9422: kernel: Elevation of Privilege in futex
(CVE-2018-9422)
VUL-0: CVE-2018-9422: kernel: Elevation of Privilege in futex
Status: RESOLVED WONTFIX
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: E-mail List
Security Team bot
https://smash.suse.de/issue/211175/
CVSSv3:RedHat:CVE-2018-9422:4.5:(AV:L...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-07-20 07:22 UTC by Johannes Segitz
Modified: 2018-10-02 13:33 UTC (History)
5 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Segitz 2018-07-20 07:22:04 UTC
rh#1604217

A flaw was found in the way futex deals with the key handling for shared futexes. This allows a rare race condition that requires the page lock in the slow path when examining the swapcache.

Upstream Patch:
https://github.com/torvalds/linux/commit/65d8fc777f6dcfee12785c057a6b57f679641c90

References:
https://source.android.com/security/bulletin/2018-07-01
https://bugzilla.redhat.com/show_bug.cgi?id=1604217
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-9422
Comment 2 Michal Hocko 2018-07-23 09:30:04 UTC
Let's involve Mel. I thought that this is more of an optimization than anything else. How can anybody gain privileges? Mel, do you have an idea?
Comment 3 Mel Gorman 2018-07-23 10:21:45 UTC
(In reply to Michal Hocko from comment #2)
> Let's involve Mel. I thought that this is more of an optimization than
> anything else. How can anybody gain privileges? Mel, do you have an idea?

I admit I'm confused and it does not help that neither the CVE link nor the bulletin includes information about how privileges can be escalated. At minimum, the attacker would need access to the same shmem data holding the shared mutex so the attacker has at least similar privilege already. I do not see how this translates into privilege escalation.

The intent of that patch was to address real-time users concerns about unbounded contention time due to the page lock. I wonder if the CVE is based on confusion about the changelog -- particularly the first paragraph? Before the patch, the page lock was a heavy unnecessary lock for the futex path that protected too much. After the patch, the page lock is only required in a specific corner case. No race was being addressed but the changelog could be interpreted as fixing a race related to shmem pages and swapcache.

If this patch is backported then commit 48fb6f4db940e92cfb16cd878cddd59ea6120d06 should be included. That fixes a case whereby an application bug can trigger a kernel warning (harmless but annoying).
Comment 4 Michal Hocko 2018-07-23 10:27:53 UTC
(In reply to Mel Gorman from comment #3)
> (In reply to Michal Hocko from comment #2)
> > Let's involve Mel. I thought that this is more of an optimization than
> > anything else. How can anybody gain privileges? Mel, do you have an idea?
> 
> I admit I'm confused and it does not help that neither the CVE link nor the
> bulletin includes information about how privileges can be escalated. At
> minimum, the attacker would need access to the same shmem data holding the
> shared mutex so the attacker has at least similar privilege already. I do
> not see how this translates into privilege escalation.
> 
> The intent of that patch was to address real-time users concerns about
> unbounded contention time due to the page lock. I wonder if the CVE is based
> on confusion about the changelog -- particularly the first paragraph? Before
> the patch, the page lock was a heavy unnecessary lock for the futex path
> that protected too much. After the patch, the page lock is only required in
> a specific corner case. No race was being addressed but the changelog could
> be interpreted as fixing a race related to shmem pages and swapcache.

Thanks Mel! This matches my understanding. Can somebody who is in touch with people requesting this CVE can double check please?
Comment 5 Johannes Segitz 2018-07-26 08:42:41 UTC
(In reply to Michal Hocko from comment #4)
I tried to find a contact for android security, but they hide it well. I'll contact MITRE to find out who requested the CVE
Comment 6 Johannes Segitz 2018-07-27 08:47:05 UTC
(In reply to Johannes Segitz from comment #5)
MITRE doesn't give out this information.

If we're confident that this is not an issue we can wait until MITRE publishes more details and then contact the people who reequested the CVE
Comment 7 Borislav Petkov 2018-09-28 13:37:15 UTC
In the meantime, RH bz was closed with:

https://bugzilla.redhat.com/show_bug.cgi?id=1604217#c3
Comment 8 Michal Hocko 2018-10-01 07:43:00 UTC
(In reply to Borislav Petkov from comment #7)
> In the meantime, RH bz was closed with:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1604217#c3

This matches our understanding as well. I am not a security expert so I might be missing something but I would tend to suspect this is either something Android specific or a confusion from the change. So I would tend to make it WONTFIX.
Comment 9 Marcus Meissner 2018-10-02 13:33:49 UTC
This flaw currently does not seem to be exploitable and we are not considering fixing it.