[kernel-sec-discuss] r3454 - active

[Ben Hutchings]

Author: benh
Date: 2014-07-23 00:13:11 +0000 (Wed, 23 Jul 2014)
New Revision: 3454

Modified:
   active/CVE-2014-3534
Log:
Update description of CVE-2014-3534 after re-reading Martin's explanation

This is based on a private mail, so I can't just add a reference. :-(


Modified: active/CVE-2014-3534
===================================================================
--- active/CVE-2014-3534	2014-07-23 00:03:39 UTC (rev 3453)
+++ active/CVE-2014-3534	2014-07-23 00:13:11 UTC (rev 3454)
@@ -2,13 +2,13 @@
 References:
 Notes:
  bwh> Martin Schwidefsky says this was introduced by commit fa968ee215c0
- bwh> ("s390/signal: set correct address space control"), but only if the
- bwh> kernel parameter user_mode=primary is used.  Commit e258d719ff28
- bwh> ("s390/uaccess: always run the kernel in home space") closed the
- bwh> vulnerability in signal handling (the kernel parameter no longer
- bwh> exists) and replaced it with a vulnerability through ptrace.
- bwh> The upstream fix therefore fixes the second vulnerability but 3.2.y
- bwh> suffers from the first (which maybe wants its own CVE ID).
+ bwh> ("s390/signal: set correct address space control").  It added the
+ bwh> ASC (Address Space Control) processor status bits to those that
+ bwh> must be restored on return from signals, but as a result they can
+ bwh> also be set arbitrarily by ptrace.  This opens a vulnerability if
+ bwh> the kernel parameter user_mode=primary is used.  Commit e258d719ff28
+ bwh> ("s390/uaccess: always run the kernel in home space") made that
+ bwh> the default (I think).
 Bugs:
 upstream: pending (3.16-rc7) [dab6cf55f81a6e16b8147aed9a843e1691dcd318]
 2.6.32-upstream-stable: N/A ("vulnerable code not present")