Request security fix in -stable (upstream 2c33645d366d)
Stable maintainers -
Have a request to merge an upstream security fix into stable branches. The change avoids a userlevel-induceable kernel #GP in perf/x86 when a hypervisor emulates older perfmon. The issue was originally seen and accepted as an upstream patch proposed by Amazon in 2015; the security implication when on a VMware hypervisor was recently reported.
Upstream commit:
(commit) 2c33645d366d13b969d936b68b9f4875b1fdddea
(subject) perf/x86: Honor the architectural performance monitoring version
A second commit fixes a trivial build issue introduced by the above commit:
(commit) 6d6f2833bfbf296101f9f085e10488aef2601ba5
(subject) perf/x86: Fix undefined shift on 32-bit kernels
The 1st commit was released in 4.2 kernels and should cleanly backport quite far (at least 3.10). I have verified a 3.10 kernel is subject to the issue and a 4.4 kernel is not subject to the issue. The second commit was CCed to stable when committed, though would not be needed before 4.2. The second commit is not needed for the security fix, but I feel the maintainer should have the option to include a build fix introduced by the security fix.
VMware viewed the reported security issue as a likely Linux bug and requested communication with Linux maintainers to confirm; the reporter disagreed with that assessment and disclosed unilaterally. We subsequently identified the Linux upstream fix mentioned above, which tends to confirm it is a Linux bug. VMware also has an option to mitigate with a workaround, though we consider the workaround "risky" and prefer to only pursue that path if Linux -stable is unable to accept the upstream fix. VMware would view mitigation as a "low" severity issue which would go out in a "next available" release (commensurate with a Linux "next -stable release" cycle). The issue is only believed to impact Linux running on a VMware hypervisor.
Versions:
Here I am not sure, based on unfamiliarity with Linux kernel
stability lifecycles. I defer to stable maintainer's judgement based on the security implication. Possible candidates:
linux-4.1.y
linux-3.18.y
linux-3.16.y
linux-3.14.y
linux-3.12.y
linux-3.10.y
The 1st commit should apply cleanly to those kernel versions; if it does not, I am available to create a backport. The 2nd commit will not apply cleanly due to file movement on mainline (arch/x86/kernel/cpu/perf_event_intel.c to arch/x86/events/intel/core.c); however, it is trivial (<const>UL -> <const>ULL).
Background:
(external disclosure): https://cyseclabs.com/blog/vmware-linux-poc
(LKML discussion of upstream change in 2015):
http://comments.gmane.org/gmane.linux.kernel/1968211
The reporter suggested there could be a higher-severity privilege escalation on the path as well; our analysis found the evidence of privilege escalation to be an artifact of pvops patching interacting poorly with debug symbols and thus be a non-issue.
As this is my first report to [email protected], do please let me know if I am missing any information. I look forward to your ACK/NAK or any other feedback.
-Kevin Christopher ([email protected])
Hi Kevin,
Quoted 16 lines · Kevin Christopher
Stable maintainers -
Have a request to merge an upstream security fix into stable branches. The change avoids a userlevel-induceable kernel #GP in perf/x86 when a hypervisor emulates older perfmon. The issue was originally seen and accepted as an upstream patch proposed by Amazon in 2015; the security implication when on a VMware hypervisor was recently reported.
Upstream commit:
(commit)2c33645d366d13b969d936b68b9f4875b1fdddea
(subject) perf/x86: Honor the architectural performance monitoring versionA second commit fixes a trivial build issue introduced by the above commit:
(commit)6d6f2833bfbf296101f9f085e10488aef2601ba5
(subject) perf/x86: Fix undefined shift on 32-bit kernels
Quoted 6 lines
The 1st commit was released in 4.2 kernels and should cleanly backport quite far (at least 3.10). I have verified a 3.10 kernel is subject to the issue and a 4.4 kernel is not subject to the issue. The second commit was CCed to stable when committed, though would not be needed before 4.2. The second commit is not needed for the security fix, but I feel the maintainer should have the option to include a build fix introduced by the security fix.
The second indeed is a fix for the first one, so both should be taken together.
Quoted 10 lines
VMware viewed the reported security issue as a likely Linux bug and requested communication with Linux maintainers to confirm; the reporter disagreed with that assessment and disclosed unilaterally. We subsequently identified the Linux upstream fix mentioned above, which tends to confirm it is a Linux bug. VMware also has an option to mitigate with a workaround, though we consider the workaround "risky" and prefer to only pursue that path if Linux -stable is unable to accept the upstream fix. VMware would view mitigation as a "low" severity issue which would go out in a "next available" release (commensurate with a Linux "next -stable release" cycle). The issue is only believed to impact Linux running on a VMware hypervisor.
Even once merged into -stable, it doesn't guarantee that all Linux distros will have it, some of them maintain their own kernels and do not necessarily follow the stable ones (and may even already have picked this fix). Thus it would seem safer to me if the hypervisor would also have a fix or at least a workaround for this (even one with a small performance impact if it's only to protect unfixed kernels, that's always better than nothing).
Quoted 21 lines
Versions:
Here I am not sure, based on unfamiliarity with Linux kernel stability
lifecycles. I defer to stable maintainer's judgement based on the security implication. Possible candidates:
linux-4.1.y
linux-3.18.y
linux-3.16.y
linux-3.14.y
linux-3.12.y
linux-3.10.y
The 1st commit should apply cleanly to those kernel versions; if it does not, I am available to create a backport. The 2nd commit will not apply cleanly due to file movement on mainline (arch/x86/kernel/cpu/perf_event_intel.ctoarch/x86/events/intel/core.c); however, it is trivial (<const>UL -> <const>ULL).Background:
(external disclosure): https://cyseclabs.com/blog/vmware-linux-poc
(LKML discussion of upstream change in 2015):http://comments.gmane.org/gmane.linux.kernel/1968211
Quoted 8 lines
The reporter suggested there could be a higher-severity privilege escalation on the path as well; our analysis found the evidence of privilege escalation to be an artifact of pvops patching interacting poorly with debug symbols and thus be a non-issue.
As this is my first report to [email protected], do please let me know if I am missing any information. I look forward to your ACK/NAK or any other feedback.
Usually it is recommended to CC the patch's author and maintainers of the code in question because they help with backports of fixes, and they are the ones who know best if there's a risk of regression or if a fix is incomplete for certain versions, so they definitely have their word to say. I'm CCing Imre and Peter who were involved in this fix.
Also we're usually careful about not backporting to older kernels something which is not yet in more recent ones. Greg is traveling with limited connectivity this week, so we may have to wait for him to come back. The bug is not urgent anyway since it was fixed one year ago :-)
Quoted 1 line
-Kevin Christopher ([email protected])
Regards,
Willy
Quoted 14 lines · Willy Tarreau
Quoted 7 lines
Upstream commit:
(commit)2c33645d366d13b969d936b68b9f4875b1fdddea
(subject) perf/x86: Honor the architectural performance monitoring versionA second commit fixes a trivial build issue introduced by the above commit:
(commit)6d6f2833bfbf296101f9f085e10488aef2601ba5
(subject) perf/x86: Fix undefined shift on 32-bit kernelsUsually it is recommended to CC the patch's author and maintainers of the code in question because they help with backports of fixes, and they are the ones who know best if there's a risk of regression or if a fix is incomplete for certain versions, so they definitely have their word to say. I'm CCing Imre and Peter who were involved in this fix.
Quoted 4 lines
Also we're usually careful about not backporting to older kernels something which is not yet in more recent ones. Greg is traveling with limited connectivity this week, so we may have to wait for him to come back. The bug is not urgent anyway since it was fixed one year ago :-)
No objections from my pov. they're fairly simple patches, therefore I would not suspect any trouble backporting this, but if there is, do holler.
Quoted 15 lines · Peter Zijlstra
Quoted 14 lines · Willy Tarreau
Quoted 7 lines
Upstream commit:
(commit)2c33645d366d13b969d936b68b9f4875b1fdddea
(subject) perf/x86: Honor the architectural performance monitoring versionA second commit fixes a trivial build issue introduced by the above commit:
(commit)6d6f2833bfbf296101f9f085e10488aef2601ba5
(subject) perf/x86: Fix undefined shift on 32-bit kernelsUsually it is recommended to CC the patch's author and maintainers of the code in question because they help with backports of fixes, and they are the ones who know best if there's a risk of regression or if a fix is incomplete for certain versions, so they definitely have their word to say. I'm CCing Imre and Peter who were involved in this fix.
Quoted 8 lines
Quoted 4 lines
Also we're usually careful about not backporting to older kernels something which is not yet in more recent ones. Greg is traveling with limited connectivity this week, so we may have to wait for him to come back. The bug is not urgent anyway since it was fixed one year ago :-)
No objections from my pov. they're fairly simple patches, therefore I would not suspect any trouble backporting this, but if there is, do holler.
OK, thank you Peter!
Willy
Quoted 8 lines · Kevin Christopher
Stable maintainers -
Have a request to merge an upstream security fix into stable branches. The change avoids a userlevel-induceable kernel #GP in perf/x86 when a hypervisor emulates older perfmon. The issue was originally seen and accepted as an upstream patch proposed by Amazon in 2015; the security implication when on a VMware hypervisor was recently reported.
Quoted 7 lines
Upstream commit:
(commit)2c33645d366d13b969d936b68b9f4875b1fdddea
(subject) perf/x86: Honor the architectural performance monitoring versionA second commit fixes a trivial build issue introduced by the above commit:
(commit)6d6f2833bfbf296101f9f085e10488aef2601ba5
(subject) perf/x86: Fix undefined shift on 32-bit kernels
[...]
Belatedly queued these up for 3.16.
Ben.
Signature · 2 lines
Ben Hutchings compatible: Gracefully accepts erroneous data from any source