Skip to content
  1. Nov 19, 2012
  2. Nov 18, 2012
  3. Nov 16, 2012
  4. Nov 15, 2012
  5. Nov 13, 2012
  6. Nov 12, 2012
    • Petr Matousek's avatar
      KVM: x86: invalid opcode oops on SET_SREGS with OSXSAVE bit set (CVE-2012-4461) · 6d1068b3
      Petr Matousek authored
      
      
      On hosts without the XSAVE support unprivileged local user can trigger
      oops similar to the one below by setting X86_CR4_OSXSAVE bit in guest
      cr4 register using KVM_SET_SREGS ioctl and later issuing KVM_RUN
      ioctl.
      
      invalid opcode: 0000 [#2] SMP
      Modules linked in: tun ip6table_filter ip6_tables ebtable_nat ebtables
      ...
      Pid: 24935, comm: zoog_kvm_monito Tainted: G      D      3.2.0-3-686-pae
      EIP: 0060:[<f8b9550c>] EFLAGS: 00210246 CPU: 0
      EIP is at kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm]
      EAX: 00000001 EBX: 000f387e ECX: 00000000 EDX: 00000000
      ESI: 00000000 EDI: 00000000 EBP: ef5a0060 ESP: d7c63e70
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process zoog_kvm_monito (pid: 24935, ti=d7c62000 task=ed84a0c0
      task.ti=d7c62000)
      Stack:
       00000001 f70a1200 f8b940a9 ef5a0060 00000000 00200202 f8769009 00000000
       ef5a0060 000f387e eda5c020 8722f9c8 00015bae 00000000 ed84a0c0 ed84a0c0
       c12bf02d 0000ae80 ef7f8740 fffffffb f359b740 ef5a0060 f8b85dc1 0000ae80
      Call Trace:
       [<f8b940a9>] ? kvm_arch_vcpu_ioctl_set_sregs+0x2fe/0x308 [kvm]
      ...
       [<c12bfb44>] ? syscall_call+0x7/0xb
      Code: 89 e8 e8 14 ee ff ff ba 00 00 04 00 89 e8 e8 98 48 ff ff 85 c0 74
      1e 83 7d 48 00 75 18 8b 85 08 07 00 00 31 c9 8b 95 0c 07 00 00 <0f> 01
      d1 c7 45 48 01 00 00 00 c7 45 1c 01 00 00 00 0f ae f0 89
      EIP: [<f8b9550c>] kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm] SS:ESP
      0068:d7c63e70
      
      QEMU first retrieves the supported features via KVM_GET_SUPPORTED_CPUID
      and then sets them later. So guest's X86_FEATURE_XSAVE should be masked
      out on hosts without X86_FEATURE_XSAVE, making kvm_set_cr4 with
      X86_CR4_OSXSAVE fail. Userspaces that allow specifying guest cpuid with
      X86_FEATURE_XSAVE even on hosts that do not support it, might be
      susceptible to this attack from inside the guest as well.
      
      Allow setting X86_CR4_OSXSAVE bit only if host has XSAVE support.
      
      Signed-off-by: default avatarPetr Matousek <pmatouse@redhat.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      6d1068b3
    • Fabio Estevam's avatar
      ARM: boot: Fix usage of kecho · 2d4d07b9
      Fabio Estevam authored
      
      
      Since commit edc88ceb (ARM: be really quiet when building with 'make -s') the
      following output is generated when building a kernel for ARM:
      
      echo '  Kernel: arch/arm/boot/Image is ready'
        Kernel: arch/arm/boot/Image is ready
        Building modules, stage 2.
      echo '  Kernel: arch/arm/boot/zImage is ready'
        Kernel: arch/arm/boot/zImage is ready
      
      As per Documentation/kbuild/makefiles.txt the correct way of using kecho is
      '@$(kecho)'.
      
      Make this change so no more unwanted 'echo' messages are displayed.
      
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      2d4d07b9
    • Heiko Carstens's avatar
      s390/topology: fix core id vs physical package id mix-up · 658e5ce7
      Heiko Carstens authored
      
      
      The current topology code confuses core id vs physical package id.
      
      In other words /sys/devices/system/cpu/cpuX/topology/core_id
      displays the physical_package_id (aka socket id) instead of the
      core id.
      The physical_package_id sysfs attribute always displays "-1"
      instead of the socket id.
      
      Fix this mix-up with a small patch which defines and initializes
      topology_physical_package_id correctly and fixes the broken
      core id handling.
      
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      658e5ce7
    • Martin Schwidefsky's avatar
      s390/signal: set correct address space control · fa968ee2
      Martin Schwidefsky authored
      
      
      If user space is running in primary mode it can switch to secondary
      or access register mode, this is used e.g. in the clock_gettime code
      of the vdso. If a signal is delivered to the user space process while
      it has been running in access register mode the signal handler is
      executed in access register mode as well which will result in a crash
      most of the time.
      
      Set the address space control bits in the PSW to the default for the
      execution of the signal handler and make sure that the previous
      address space control is restored on signal return. Take care
      that user space can not switch to the kernel address space by
      modifying the registers in the signal frame.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      fa968ee2
  7. Nov 10, 2012
  8. Nov 09, 2012
Loading