The ECRYPTFS_NEW_FILE crypt_stat flag is set upon creation of a new
eCryptfs file. When the flag is set, eCryptfs reads directly from the
lower filesystem when bringing a page up to date. This means that no
offset translation (for the eCryptfs file metadata in the lower file)
and no decryption is performed. The flag is cleared just before the
first write is completed (at the beginning of ecryptfs_write_begin()).
It was discovered that if a new file was created and then extended with
truncate, the ECRYPTFS_NEW_FILE flag was not cleared. If pages
corresponding to this file are ever reclaimed, any subsequent reads
would result in userspace seeing eCryptfs file metadata and encrypted
file contents instead of the expected decrypted file contents.
Data corruption is possible if the file is written to before the
eCryptfs directory is unmounted. The data written will be copied into
pages which have been read directly from the lower file rather than
zeroed pages, as would be expected after extending the file with
truncate.
This flag, and the functionality that used it, was removed in upstream
kernels in 2.6.39 with the following commits:
Signed-off-by: Tyler Hicks <email address hidden>
Signed-off-by: Colin Ian King <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Herton Krzesinski <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
5547ada...
by
=?utf-8?q?Stephan_B=C3=A4rwolf?= <email address hidden>
KVM: x86: fix missing checks in syscall emulation
On hosts without this patch, 32bit guests will crash (and 64bit guests
may behave in a wrong way) for example by simply executing following
nasm-demo-application:
[bits 32]
global _start
SECTION .text
_start: syscall
(I tested it with winxp and linux - both always crashed)
Disassembly of section .text:
00000000 <_start>:
0: 0f 05 syscall
The reason seems a missing "invalid opcode"-trap (int6) for the
syscall opcode "0f05", which is not available on Intel CPUs
within non-longmodes, as also on some AMD CPUs within legacy-mode.
(depending on CPU vendor, MSR_EFER and cpuid)
Because previous mentioned OSs may not engage corresponding
syscall target-registers (STAR, LSTAR, CSTAR), they remain
NULL and (non trapping) syscalls are leading to multiple
faults and finally crashs.
Depending on the architecture (AMD or Intel) pretended by
guests, various checks according to vendor's documentation
are implemented to overcome the current issue and behave
like the CPUs physical counterparts.
CVE-2012-0045
BugLink: http://bugs.launchpad.net/bugs/917842
(backported from commit c2226fc9e87ba3da060e47333657cd6616652b84 upstream)
Signed-off-by: Stefan Bader <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Herton Krzesinski <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
013f2cc...
by
=?utf-8?q?Stephan_B=C3=A4rwolf?= <email address hidden>
KVM: x86: extend "struct x86_emulate_ops" with "get_cpuid"
In order to be able to proceed checks on CPU-specific properties
within the emulator, function "get_cpuid" is introduced.
With "get_cpuid" it is possible to virtually call the guests
"cpuid"-opcode without changing the VM's context.
CVE-2012-0045
BugLink: http://bugs.launchpad.net/bugs/917842
(backported from commit bdb42f5afebe208eae90406959383856ae2caf2b upstream)
Signed-off-by: Stefan Bader <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Herton Krzesinski <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
4ad254a...
by
Alex Williamson <email address hidden>
KVM: Remove ability to assign a device without iommu support
This option has no users and it exposes a security hole that we
can allow devices to be assigned without iommu protection. Make
KVM_DEV_ASSIGN_ENABLE_IOMMU a mandatory option.
mm: memcg: Correct unregistring of events attached to the same eventfd
There is an issue when memcg unregisters events that were attached to
the same eventfd:
- On the first call mem_cgroup_usage_unregister_event() removes all
events attached to a given eventfd, and if there were no events left,
thresholds->primary would become NULL;
- Since there were several events registered, cgroups core will call
mem_cgroup_usage_unregister_event() again, but now kernel will oops,
as the function doesn't expect that threshold->primary may be NULL.
That's a good question whether mem_cgroup_usage_unregister_event()
should actually remove all events in one go, but nowadays it can't
do any better as cftype->unregister_event callback doesn't pass
any private event-associated cookie. So, let's fix the issue by
simply checking for threshold->primary.
FWIW, w/o the patch the following oops may be observed:
There is only one error code to return for a bad user-space buffer
pointer passed to a system call in the same address space as the
system call is executed, and that is EFAULT. Furthermore, the
low-level access routines, which catch most of the faults, return
EFAULT already.
Signed-off-by: H. Peter Anvin <email address hidden>
Reviewed-by: Oleg Nesterov <email address hidden>
Acked-by: Roland McGrath <email address hidden>
Cc: <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
(cherry picked from commit 5189fa19a4b2b4c3bec37c3a019d446148827717)
CVE-2012-1097
Acked-by: Seth Forshee <email address hidden>
Acked-by: Colin King <email address hidden>
Signed-off-by: Andy Whitcroft <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
The regset common infrastructure assumed that regsets would always
have .get and .set methods, but not necessarily .active methods.
Unfortunately people have since written regsets without .set methods.
Rather than putting in stub functions everywhere, handle regsets with
null .get or .set methods explicitly.
Signed-off-by: H. Peter Anvin <email address hidden>
Reviewed-by: Oleg Nesterov <email address hidden>
Acked-by: Roland McGrath <email address hidden>
Cc: <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
(cherry picked from commit c8e252586f8d5de906385d8cf6385fee289a825e)
CVE-2012-1097
Acked-by: Seth Forshee <email address hidden>
Acked-by: Colin King <email address hidden>
Signed-off-by: Andy Whitcroft <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
