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 stable@xxxxxxxxxxxxxxx, do please let me
know if I am missing any information. I look forward to your ACK/NAK or
any other feedback.
-Kevin Christopher (kevinc@xxxxxxxxxx)
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html