TOUCHKEY: fix melfas_touchkey driver to operate well

- support regulator control
- change TOUCHKEY_MENU value
- add workaround delay for EXIT_I2C_ACK()
- etc..

Change-Id: Id6b693c2bf9e93fc46df4016410c1671d5293ac2
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS2: update defconfig

remove unused MDNIE/FIMD LITE configuration

Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: Ic92e55d2eb6899491cdb5e96454467b150f057db

perf: Remove the nmi parameter from the swevent and overflow interface

The nmi parameter indicated if we could do wakeups from the current
context, if not, we would set some state and self-IPI and let the
resulting interrupt do the wakeup.

For the various event classes:

  - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
    the PMI-tail (ARM etc.)
  - tracepoint: nmi=0; since tracepoint could be from NMI context.
  - software: nmi=[0,1]; some, like the schedule thing cannot
    perform wakeups, and hence need 0.

As one can see, there is very little nmi=1 usage, and the down-side of
not using it is that on some platforms some software events can have a
jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).

The up-side however is that we can remove the nmi parameter and save a
bunch of conditionals in fast paths.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Michael Cree <mcree@orcon.net.nz>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Eric B Munson <emunson@mgebm.net>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Don Zickus <dzickus@redhat.com>
Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Conflicts:
kernel/events/internal.h
kernel/events/ring_buffer.c
[remove above files and modify kernel/events/core.c]
[Applied patch to resolve tizendev.org issue: TDIS-416]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: Ie253a0f5f4ee46aa12a572097ea3b95345b2dbdb

signal: always clear sa_restorer on execve

When the new signal handlers are set up, the location of sa_restorer is
not cleared, leaking a parent process's address space location to
children.  This allows for a potential bypass of the parent's ASLR by
examining the sa_restorer value returned when calling sigaction().

Based on what should be considered "secret" about addresses, it only
matters across the exec not the fork (since the VMAs haven't changed
until the exec).  But since exec sets SIG_DFL and keeps sa_restorer,
this is where it should be fixed.

Given the few uses of sa_restorer, a "set" function was not written
since this would be the only use.  Instead, we use
__ARCH_HAS_SA_RESTORER, as already done in other places.

Example of the leak before applying this patch:

  $ cat /proc/$$/maps
  ...
  7fb9f3083000-7fb9f3238000 r-xp 00000000 fd:01 404469 .../libc-2.15.so
  ...
  $ ./leak
  ...
  7f278bc74000-7f278be29000 r-xp 00000000 fd:01 404469 .../libc-2.15.so
  ...
  1 0 (nil) 0x7fb9f30b94a0
  2 4000000 (nil) 0x7f278bcaa4a0
  3 4000000 (nil) 0x7f278bcaa4a0
  4 0 (nil) 0x7fb9f30b94a0
  ...

[akpm@linux-foundation.org: use SA_RESTORER for backportability]
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Emese Revfy <re.emese@gmail.com>
Cc: Emese Revfy <re.emese@gmail.com>
Cc: PaX Team <pageexec@freemail.hu>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Serge Hallyn <serge.hallyn@canonical.com>
Cc: Julien Tinnes <jln@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-5373]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: Ibd7b4f8b2032ba3bba86b835f86fed069c3dc38e

keys: fix race with concurrent install_user_keyrings()

This fixes CVE-2013-1792.

There is a race in install_user_keyrings() that can cause a NULL pointer
dereference when called concurrently for the same user if the uid and
uid-session keyrings are not yet created.  It might be possible for an
unprivileged user to trigger this by calling keyctl() from userspace in
parallel immediately after logging in.

Assume that we have two threads both executing lookup_user_key(), both
looking for KEY_SPEC_USER_SESSION_KEYRING.

THREAD A THREAD B
=============================== ===============================
==>call install_user_keyrings();
if (!cred->user->session_keyring)
==>call install_user_keyrings()
...
user->uid_keyring = uid_keyring;
if (user->uid_keyring)
return 0;
<==
key = cred->user->session_keyring [== NULL]
user->session_keyring = session_keyring;
atomic_inc(&key->usage); [oops]

At the point thread A dereferences cred->user->session_keyring, thread B
hasn't updated user->session_keyring yet, but thread A assumes it is
populated because install_user_keyrings() returned ok.

The race window is really small but can be exploited if, for example,
thread B is interrupted or preempted after initializing uid_keyring, but
before doing setting session_keyring.

This couldn't be reproduced on a stock kernel.  However, after placing
systemtap probe on 'user->session_keyring = session_keyring;' that
introduced some delay, the kernel could be crashed reliably.

Fix this by checking both pointers before deciding whether to return.
Alternatively, the test could be done away with entirely as it is checked
inside the mutex - but since the mutex is global, that may not be the best
way.

Signed-off-by: David Howells <dhowells@redhat.com>
Reported-by: Mateusz Guzik <mguzik@redhat.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>
[Patch applied to resolve tizendev.org issue: TDIS-5363]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: I45febf233103400d6656bfad0c198cdc49dbc7f2

net: fix info leak in compat dev_ifconf()

The implementation of dev_ifconf() for the compat ioctl interface uses
an intermediate ifc structure allocated in userland for the duration of
the syscall. Though, it fails to initialize the padding bytes inserted
for alignment and that for leaks four bytes of kernel stack. Add an
explicit memset(0) before filling the structure to avoid the info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Patch applied to resolve tizendev.org issue: TDIS-5319]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: I08398c0457b27dc30696e8a89e31c52cee64a6bb

net/tun: fix ioctl() based info leaks

The tun module leaks up to 36 bytes of memory by not fully initializing
a structure located on the stack that gets copied to user memory by the
TUNGETIFF and SIOCGIFHWADDR ioctl()s.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Conflicts:

drivers/net/tun.c
[Patch applied to resolve tizendev.org issue: TDIS-5290]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: I033af051ba35ec52c91b5c01fa1c9416830e5f02

rtnl: fix info leak on RTM_GETLINK request for VF devices

Initialize the mac address buffer with 0 as the driver specific function
will probably not fill the whole buffer. In fact, all in-kernel drivers
fill only ETH_ALEN of the MAX_ADDR_LEN bytes, i.e. 6 of the 32 possible
bytes. Therefore we currently leak 26 bytes of stack memory to userland
via the netlink interface.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Conflicts:

net/core/rtnetlink.c
[Patch applied to resolve tizendev.org issue: TDIS-5286]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: Icfc79d4465a070e8606319f4e4535de43f98fc44

tmpfs: fix use-after-free of mempolicy object

The tmpfs remount logic preserves filesystem mempolicy if the mpol=M
option is not specified in the remount request.  A new policy can be
specified if mpol=M is given.

Before this patch remounting an mpol bound tmpfs without specifying
mpol= mount option in the remount request would set the filesystem's
mempolicy object to a freed mempolicy object.

To reproduce the problem boot a DEBUG_PAGEALLOC kernel and run:
    # mkdir /tmp/x

    # mount -t tmpfs -o size=100M,mpol=interleave nodev /tmp/x

    # grep /tmp/x /proc/mounts
    nodev /tmp/x tmpfs rw,relatime,size=102400k,mpol=interleave:0-3 0 0

    # mount -o remount,size=200M nodev /tmp/x

    # grep /tmp/x /proc/mounts
    nodev /tmp/x tmpfs rw,relatime,size=204800k,mpol=??? 0 0
        # note ? garbage in mpol=... output above

    # dd if=/dev/zero of=/tmp/x/f count=1
        # panic here

Panic:
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<          (null)>]           (null)
    [...]
    Oops: 0010 [#1] SMP DEBUG_PAGEALLOC
    Call Trace:
      mpol_shared_policy_init+0xa5/0x160
      shmem_get_inode+0x209/0x270
      shmem_mknod+0x3e/0xf0
      shmem_create+0x18/0x20
      vfs_create+0xb5/0x130
      do_last+0x9a1/0xea0
      path_openat+0xb3/0x4d0
      do_filp_open+0x42/0xa0
      do_sys_open+0xfe/0x1e0
      compat_sys_open+0x1b/0x20
      cstar_dispatch+0x7/0x1f

Non-debug kernels will not crash immediately because referencing the
dangling mpol will not cause a fault.  Instead the filesystem will
reference a freed mempolicy object, which will cause unpredictable
behavior.

The problem boils down to a dropped mpol reference below if
shmem_parse_options() does not allocate a new mpol:

    config = *sbinfo
    shmem_parse_options(data, &config, true)
    mpol_put(sbinfo->mpol)
    sbinfo->mpol = config.mpol  /* BUG: saves unreferenced mpol */

This patch avoids the crash by not releasing the mempolicy if
shmem_parse_options() doesn't create a new mpol.

How far back does this issue go? I see it in both 2.6.36 and 3.3.  I did
not look back further.

Signed-off-by: Greg Thelen <gthelen@google.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-4411]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: Ic31ab29e226034529007ec7c7b5748eb0ebe5c8f

mm: thp: fix pmd_present for split_huge_page and PROT_NONE with THP

In many places !pmd_present has been converted to pmd_none.  For pmds
that's equivalent and pmd_none is quicker so using pmd_none is better.

However (unless we delete pmd_present) we should provide an accurate
pmd_present too.  This will avoid the risk of code thinking the pmd is non
present because it's under __split_huge_page_map, see the pmd_mknotpresent
there and the comment above it.

If the page has been mprotected as PROT_NONE, it would also lead to a
pmd_present false negative in the same way as the race with
split_huge_page.

Because the PSE bit stays on at all times (both during split_huge_page and
when the _PAGE_PROTNONE bit get set), we could only check for the PSE bit,
but checking the PROTNONE bit too is still good to remember pmd_present
must always keep PROT_NONE into account.

This explains a not reproducible BUG_ON that was seldom reported on the
lists.

The same issue is in pmd_large, it would go wrong with both PROT_NONE and
if it races with split_huge_page.

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <jweiner@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-4398]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: I58935dfd9769f5bd2704f34de2019f4f249b6dac

kmod: make __request_module() killable

As Tetsuo Handa pointed out, request_module() can stress the system
while the oom-killed caller sleeps in TASK_UNINTERRUPTIBLE.

The task T uses "almost all" memory, then it does something which
triggers request_module().  Say, it can simply call sys_socket().  This
in turn needs more memory and leads to OOM.  oom-killer correctly
chooses T and kills it, but this can't help because it sleeps in
TASK_UNINTERRUPTIBLE and after that oom-killer becomes "disabled" by the
TIF_MEMDIE task T.

Make __request_module() killable.  The only necessary change is that
call_modprobe() should kmalloc argv and module_name, they can't live in
the stack if we use UMH_KILLABLE.  This memory is freed via
call_usermodehelper_freeinfo()->cleanup.

Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Tejun Heo <tj@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Conflicts:

kernel/kmod.c
[Patch applied to resolve tizendev.org issue: TDIS-4397]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: I7ebe9ecd822b81df4514df984a27e071c39b51c7

cipso: don't follow a NULL pointer when setsockopt() is called

As reported by Alan Cox, and verified by Lin Ming, when a user
attempts to add a CIPSO option to a socket using the CIPSO_V4_TAG_LOCAL
tag the kernel dies a terrible death when it attempts to follow a NULL
pointer (the skb argument to cipso_v4_validate() is NULL when called via
the setsockopt() syscall).

This patch fixes this by first checking to ensure that the skb is
non-NULL before using it to find the incoming network interface.  In
the unlikely case where the skb is NULL and the user attempts to add
a CIPSO option with the _TAG_LOCAL tag we return an error as this is
not something we want to allow.

A simple reproducer, kindly supplied by Lin Ming, although you must
have the CIPSO DOI #3 configure on the system first or you will be
caught early in cipso_v4_validate():

#include <sys/types.h>
#include <sys/socket.h>
#include <linux/ip.h>
#include <linux/in.h>
#include <string.h>

struct local_tag {
char type;
char length;
char info[4];
};

struct cipso {
char type;
char length;
char doi[4];
struct local_tag local;
};

int main(int argc, char **argv)
{
int sockfd;
struct cipso cipso = {
.type = IPOPT_CIPSO,
.length = sizeof(struct cipso),
.local = {
.type = 128,
.length = sizeof(struct local_tag),
},
};

memset(cipso.doi, 0, 4);
cipso.doi[3] = 3;

sockfd = socket(AF_INET, SOCK_DGRAM, 0);
#define SOL_IP 0
setsockopt(sockfd, SOL_IP, IP_OPTIONS,
&cipso, sizeof(struct cipso));

return 0;
}

CC: Lin Ming <mlin@ss.pku.edu.cn>
Reported-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Patch applied to resolve tizendev.org issue: TDIS-4394]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: Ifd1ce1d7de09e571dd77ad597b23f82029a89b01

exec: do not leave bprm->interp on stack

If a series of scripts are executed, each triggering module loading via
unprintable bytes in the script header, kernel stack contents can leak
into the command line.

Normally execution of binfmt_script and binfmt_misc happens recursively.
However, when modules are enabled, and unprintable bytes exist in the
bprm->buf, execution will restart after attempting to load matching
binfmt modules.  Unfortunately, the logic in binfmt_script and
binfmt_misc does not expect to get restarted.  They leave bprm->interp
pointing to their local stack.  This means on restart bprm->interp is
left pointing into unused stack memory which can then be copied into the
userspace argv areas.

After additional study, it seems that both recursion and restart remains
the desirable way to handle exec with scripts, misc, and modules.  As
such, we need to protect the changes to interp.

This changes the logic to require allocation for any changes to the
bprm->interp.  To avoid adding a new kmalloc to every exec, the default
value is left as-is.  Only when passing through binfmt_script or
binfmt_misc does an allocation take place.

For a proof of concept, see DoTest.sh from:

   http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: halfdog <me@halfdog.net>
Cc: P J P <ppandit@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-4388]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: I5c9734919a23566bad9da0d638aa292219180bd1

ext4: race-condition protection for ext4_convert_unwritten_extents_endio
We assumed that at the time we call ext4_convert_unwritten_extents_endio()
extent in question is fully inside [map.m_lblk, map->m_len] because
it was already split during submission.  But this may not be true due to
a race between writeback vs fallocate.

If extent in question is larger than requested we will split it again.
Special precautions should being done if zeroout required because
[map.m_lblk, map->m_len] already contains valid data.

Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
[Patch applied to resolve tizendev.org issue: TDIS-3771]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: I6043cf3688eb3406259e2dadcffb2f84787ee486

block: fail SCSI passthrough ioctls on partition devices
Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
will pass the command to the underlying block device.  This is
well-known, but it is also a large security problem when (via Unix
permissions, ACLs, SELinux or a combination thereof) a program or user
needs to be granted access only to part of the disk.

This patch lets partitions forward a small set of harmless ioctls;
others are logged with printk so that we can see which ioctls are
actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
Of course it was being sent to a (partition on a) hard disk, so it would
have failed with ENOTTY and the patch isn't changing anything in
practice.  Still, I'm treating it specially to avoid spamming the logs.

In principle, this restriction should include programs running with
CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
/dev/sdb, it still should not be able to read/write outside the
boundaries of /dev/sda2 independent of the capabilities.  However, for
now programs with CAP_SYS_RAWIO will still be allowed to send the
ioctls.  Their actions will still be logged.

This patch does not affect the non-libata IDE driver.  That driver
however already tests for bd != bd->bd_contains before issuing some
ioctl; it could be restricted further to forbid these ioctls even for
programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>
Cc: James Bottomley <JBottomley@parallels.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[ Make it also print the command name when warning - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-429]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: I8ba707d119db5c8d8a7e807b237d953e5b8b9793

dm: do not forward ioctls from logical volumes to the underlying device

A logical volume can map to just part of underlying physical volume.
In this case, it must be treated like a partition.

Based on a patch from Alasdair G Kergon.

Cc: Alasdair G Kergon <agk@redhat.com>
Cc: dm-devel@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-429]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: Ieae7728bfec8df2ebf001981428b80eb05f7ccbd

printk: fix buffer overflow when calling log_prefix function from call_console_drivers

This patch corrects a buffer overflow in kernels from 3.0 to 3.4 when calling
log_prefix() function from call_console_drivers().

This bug existed in previous releases but has been revealed with commit
162a7e7500f9664636e649ba59defe541b7c2c60 (2.6.39 => 3.0) that made changes
about how to allocate memory for early printk buffer (use of memblock_alloc).
It disappears with commit 7ff9554bb578ba02166071d2d487b7fc7d860d62 (3.4 => 3.5)
that does a refactoring of printk buffer management.

In log_prefix(), the access to "p[0]", "p[1]", "p[2]" or
"simple_strtoul(&p[1], &endp, 10)" may cause a buffer overflow as this
function is called from call_console_drivers by passing "&LOG_BUF(cur_index)"
where the index must be masked to do not exceed the buffer's boundary.

The trick is to prepare in call_console_drivers() a buffer with the necessary
data (PRI field of syslog message) to be safely evaluated in log_prefix().

This patch can be applied to stable kernel branches 3.0.y, 3.2.y and 3.4.y.

Without this patch, one can freeze a server running this loop from shell :
  $ export DUMMY=`cat /dev/urandom | tr -dc '12345AZERTYUIOPQSDFGHJKLMWXCVBNazertyuiopqsdfghjklmwxcvbn' | head -c255`
  $ while true do ; echo $DUMMY > /dev/kmsg ; done

The "server freeze" depends on where memblock_alloc does allocate printk buffer :
if the buffer overflow is inside another kernel allocation the problem may not
be revealed, else the server may hangs up.

Signed-off-by: Alexandre SIMON <Alexandre.Simon@univ-lorraine.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[To resolve TDIS-5369. 2.1.1 material]
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Change-Id: I23bb8e0e1e203d01bffca58680eabe42b02eaadc

Smack: create a sysfs mount point for smackfs

commit e93072374112db9dc86635934ee761249be28370 upstream

There are a number of "conventions" for where to put LSM filesystems.
Smack adheres to none of them. Create a mount point at /sys/fs/smackfs
for mounting smackfs so that Smack can be conventional.

Targeted for git://git.gitorious.org/smack-next/kernel.git

Change-Id: I453a86a06ef4654c7c90f847968b5c384f7acfef
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>

Smack: use select not depends in Kconfig

commit 111fe8bd65e473d5fc6a0478cf1e2c8c6a77489a upstream

The components NETLABEL and SECURITY_NETWORK are required by
Smack. Using "depends" in Kconfig hides the Smack option
if the user hasn't figured out that they need to be enabled
while using make menuconfig. Using select is a better choice.
Because select is not recursive depends on NET and SECURITY
are added. The reflects similar usage in TOMOYO and AppArmor.

Targeted for git://git.gitorious.org/smack-next/kernel.git

Change-Id: I41ae0b7c53bd1c5840d0d515a232da2c7259cf91
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>

Smack: remove task_wait() hook.

commit c00bedb368ae02a066aed8a888afc286c1df2e60 upstream

On 12/20/2011 11:20 PM, Jarkko Sakkinen wrote:
> Allow SIGCHLD to be passed to child process without
> explicit policy. This will help to keep the access
> control policy simple and easily maintainable with
> complex applications that require use of multiple
> security contexts. It will also help to keep them
> as isolated as possible.
>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com>

I have a slightly different version that applies to the
current smack-next tree.

Allow SIGCHLD to be passed to child process without
explicit policy. This will help to keep the access
control policy simple and easily maintainable with
complex applications that require use of multiple
security contexts. It will also help to keep them
as isolated as possible.

Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
 security/smack/smack_lsm.c |   37 ++++++++-----------------------------
 1 files changed, 8 insertions(+), 29 deletions(-)

Change-Id: I3350432459c46412315dc893915b28f353df5477
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>

Smack: prevent revoke-subject from failing when unseen label is written to it

commit d15d9fad16f6aa459cf4926a1d3aba36b004e9a2 upstream

Special file /smack/revoke-subject will silently accept labels that are not
present on the subject label list. Nothing has to be done for such labels,
as there are no rules for them to revoke.

Targeted for git://git.gitorious.org/smack-next/kernel.git

Change-Id: Ia70c386dfb1aa89ec1dbc641fb28ffc220b0101a
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>

Smack: setprocattr memory leak fix

commit 46a2f3b9e99353cc63e15563e8abee71162330f7 upstream

The data structure allocations being done in prepare_creds
are duplicated in smack_setprocattr. This results in the
structure allocated in prepare_creds being orphaned and
never freed. The duplicate code is removed from
smack_setprocattr.

Targeted for git://git.gitorious.org/smack-next/kernel.git

Change-Id: I9447f387eff166b42453bf46b46815ef16650456
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>

smack: off by one error

commit 3b9fc37280c521b086943f9aedda767f5bf3b2d3 upstream

Consider the input case of a rule that consists entirely of non space
symbols followed by a \0. Say 64 + \0

In this case strlen(data) = 64
kzalloc of subject and object are 64 byte objects
sscanfdata, "%s %s %s", subject, ...)

will put 65 bytes into subject.

Change-Id: Idcdda9bbbdce4e3c5009577bcdde7e153f370264
Signed-off-by: Alan Cox <alan@linux.intel.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Cc: stable@vger.kernel.org
Signed-off-by: James Morris <james.l.morris@oracle.com>

Smack: fix smack_new_inode bogosities

commit eb982cb4cf6405b97ea1f9e1d10864981f269d46 upstream

In January of 2012 Al Viro pointed out three bits of code that
he titled "new_inode_smack bogosities". This patch repairs these
errors.

1. smack_sb_kern_mount() included a NULL check that is impossible.
   The check and NULL case are removed.
2. smack_kb_kern_mount() included pointless locking. The locking is
   removed. Since this is the only place that lock was used the lock
   is removed from the superblock_smack structure.
3. smk_fill_super() incorrectly and unnecessarily set the Smack label
   for the smackfs root inode. The assignment has been removed.

Targeted for git://gitorious.org/smack-next/kernel.git

Change-Id: I0fa5c4b031650b1dd893ab2af5e4ae553d88603c
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>

Smack: add support for modification of existing rules

commit e05b6f982a049113a88a1750e13fdb15298cbed4 upstream

Rule modifications are enabled via /smack/change-rule. Format is as follows:
"Subject Object rwaxt rwaxt"

First two strings are subject and object labels up to 255 characters.
Third string contains permissions to enable.
Fourth string contains permissions to disable.

All unmentioned permissions will be left unchanged.
If no rule previously existed, it will be created.

Targeted for git://git.gitorious.org/smack-next/kernel.git

Change-Id: Iab0ae40a7965e0e440439091785d9c102eed2564
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>

Smack: user access check bounds

commit 3518721a8932b2a243f415c374aef020380efc9d upstream

Some of the bounds checking used on the /smack/access
interface was lost when support for long labels was
added. No kernel access checks are affected, however
this is a case where /smack/access could be used
incorrectly and fail to detect the error. This patch
reintroduces the original checks.

Targeted for git://git.gitorious.org/smack-next/kernel.git

Change-Id: Ia030d2b8fb6cade8a66feda8f1df1da22e133675
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>

Revert "Smack: add support for modification of existing rules"

This reverts commit 4c094866dbb333d769efdb36d780c2bf2237fd1d.

Change-Id: I7301b4fd0c0716ebb3a17741005a22314a5f80fe
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>

Merge "Fix common_audit_data type for smack_inode_unlick() and smack_inode_rmdir()"

Fix common_audit_data type for smack_inode_unlick() and smack_inode_rmdir()

This patch fixes kernel Oops because of wrong common_audit_data type
in smack_inode_unlink() and smack_inode_rmdir().

When SMACK security module is enabled and SMACK logging is on (/smack/logging
is not zero) and you try to delete the file which
1) you cannot delete due to SMACK rules and logging of failures is on
or
2) you can delete and logging of success is on,

you will see following:

Unable to handle kernel NULL pointer dereference at virtual address 000002d7

[<...>] (strlen+0x0/0x28)
[<...>] (audit_log_untrustedstring+0x14/0x28)
[<...>] (common_lsm_audit+0x108/0x6ac)
[<...>] (smack_log+0xc4/0xe4)
[<...>] (smk_curacc+0x80/0x10c)
[<...>] (smack_inode_unlink+0x74/0x80)
[<...>] (security_inode_unlink+0x2c/0x30)
[<...>] (vfs_unlink+0x7c/0x100)
[<...>] (do_unlinkat+0x144/0x16c)

The function smack_inode_unlink() (and smack_inode_rmdir()) need
to log two structures of different types. First of all it does:

smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_DENTRY);
smk_ad_setfield_u_fs_path_dentry(&ad, dentry);

This will set common audit data type to LSM_AUDIT_DATA_DENTRY
and store dentry for auditing (by function smk_curacc(), which in turn calls
dump_common_audit_data(), which is actually uses provided data and logs it).

/*
 * You need write access to the thing you're unlinking
 */
rc = smk_curacc(smk_of_inode(ip), MAY_WRITE, &ad);
if (rc == 0) {
/*
 * You also need write access to the containing directory
 */

Then this function wants to log anoter data:

smk_ad_setfield_u_fs_path_dentry(&ad, NULL);
smk_ad_setfield_u_fs_inode(&ad, dir);

The function sets inode field, but don't change common_audit_data type.

rc = smk_curacc(smk_of_inode(dir), MAY_WRITE, &ad);
}

So the dump_common_audit() function incorrectly interprets inode structure
as dentry, and Oops will happen.

This patch reinitializes common_audit_data structures with correct type.
Also I removed unneeded
smk_ad_setfield_u_fs_path_dentry(&ad, NULL);
initialization, because both dentry and inode pointers are stored
in the same union.

Change-Id: Ica92db5afcd1bdfc7171c40beb2a7131fcd42e9e
Signed-off-by: Igor Zhbanov <i.zhbanov@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

Fix common_audit_data type for smack_inode_unlink() and smack_inode_rmdir()

This patch fixes kernel Oops because of wrong common_audit_data type
in smack_inode_unlink() and smack_inode_rmdir().

When SMACK security module is enabled and SMACK logging is on (/smack/logging
is not zero) and you try to delete the file which
1) you cannot delete due to SMACK rules and logging of failures is on
or
2) you can delete and logging of success is on,

you will see following:

Unable to handle kernel NULL pointer dereference at virtual address 000002d7

[<...>] (strlen+0x0/0x28)
[<...>] (audit_log_untrustedstring+0x14/0x28)
[<...>] (common_lsm_audit+0x108/0x6ac)
[<...>] (smack_log+0xc4/0xe4)
[<...>] (smk_curacc+0x80/0x10c)
[<...>] (smack_inode_unlink+0x74/0x80)
[<...>] (security_inode_unlink+0x2c/0x30)
[<...>] (vfs_unlink+0x7c/0x100)
[<...>] (do_unlinkat+0x144/0x16c)

The function smack_inode_unlink() (and smack_inode_rmdir()) need
to log two structures of different types. First of all it does:

smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_DENTRY);
smk_ad_setfield_u_fs_path_dentry(&ad, dentry);

This will set common audit data type to LSM_AUDIT_DATA_DENTRY
and store dentry for auditing (by function smk_curacc(), which in turn calls
dump_common_audit_data(), which is actually uses provided data and logs it).

/*
 * You need write access to the thing you're unlinking
 */
rc = smk_curacc(smk_of_inode(ip), MAY_WRITE, &ad);
if (rc == 0) {
/*
 * You also need write access to the containing directory
 */

Then this function wants to log anoter data:

smk_ad_setfield_u_fs_path_dentry(&ad, NULL);
smk_ad_setfield_u_fs_inode(&ad, dir);

The function sets inode field, but don't change common_audit_data type.

rc = smk_curacc(smk_of_inode(dir), MAY_WRITE, &ad);
}

So the dump_common_audit() function incorrectly interprets inode structure
as dentry, and Oops will happen.

This patch reinitializes common_audit_data structures with correct type.
Also I removed unneeded
smk_ad_setfield_u_fs_path_dentry(&ad, NULL);
initialization, because both dentry and inode pointers are stored
in the same union.

Signed-off-by: Igor Zhbanov <i.zhbanov@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Change-Id: Ie549d64f1726c3325a50c8c4dfd1636090e71ec8

TRATS2: fimc: resetting the ctrl->status

resetting the ctrl->status with FIMC_STREAMOFF in an attempt to resolve
a 'fimc is running' issue after finishing the fimc_streamoff_capture
function. There is a case that ctrl->status isn't FIMC_STREAMOFF after
finishing the fimc_streamoff_capture function. Because the checking
available buffer in the fimc_irq_cap function can change ctrl->status
from FIMC_STREAMOFF to FIMC_BUFFER_STOP.

Signed-off-by: HJ.CHOI <hj210.choi@samsung.com>
Change-Id: I230ba88d76994e57279c6d7d19cdf67ece1d410b

[Fix for systemd] Enable autofs support

systemd has a great feature which can automatically mount filesystem on
demand, see systemd.automount(5) for details. This feature depends on
autofs support, so here just enable it.

Currently, only /proc/sys/fs/binfmt_misc leverages this feature, but
there maybe more in future.

Change-Id: I78b76e7070929da301f62c5284bcd4ff4bfc9fb4
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>

Protect global init (PID#1) from getting killed

OOM killer MUST NOT kill the global init. The same way init is protected
in mm/oom_kill.c.

Change-Id: Ia8d192e26b0fe3262efb18f62ac92fc8ada3f8a3
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>

TRATS1: FIMC: workaround for fimc capture irq handling

workaround for TREL-267

Change-Id: I183bf5981a20b8d75ea74596edf2413605e8ccaa
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS2: slp_s5c73m3: Fix Full HD recording problem
apply variable frame rate for fix full HD recording issue. (2nd patch)
Signed-off-by: HJ.CHOI <hj210.choi@samsung.com>
Change-Id: I08f91ca5276f8907a813898416f1bda824db4bbd

TRATS2: slp_s5c73m3: Fix Full HD recording problem.
apply variable frame rate for fix full HD recording issue.

Change-Id: I12b786e55a66987767f4be1c5911120cf90737a4
Signed-off-by: Hyungjun Choi <hj210.choi@samsung.com>

drivers: misc: fix improper assigning value of old_real_free

This patch changes the unit of old_real_free from the page count to MB.

/* we save the tasks and rss info when free memory size is minimum,
 * which means total used memory is highest at that moment. */
if (check_peak && (old_real_free > real_free)) {
    old_real_free = real_free;

If initial value of the old_real_free is saved in page count, this comparison is
totally wrong. So we need to change the unit of old_real_free.

Please refer this issue in the https://bugs.tizen.org/jira/browse/TDIST-163

Change-Id: Idd8805cb7af83858b5d92ec8d9064ea221e1cb60
Reported-by: Youngsik Yoon<youngsik.yoon@intel.com>
Signed-off-by: Chanho Park <chanho61.park@samsung.com>

TRATS2: fimc: Fix front camera 640x420 capture fail error

Fix padding buffer size error when someone is using it.

Change-Id: Ia84ecd811c23ecea52576e80cf847182d4f57980
Signed-off-by: HJ.CHOI <hj210.choi@samsung.com>

When smk_set_cipso() parsing the CIPSO setting from userspace, the offset of CIPSO level
should be "strlen(label)+1" instead of "strlen(label)"

Change-Id: I7eb62db733895e992765e19e350d254bf06d7123

drm/exynos: fix user interface to g2d driver

64bit data type should be used to transfer user space pointer
into kernel space.

Change-Id: I35590c8d158908e3ac6556495dd30559c4e50b16
Signed-off-by: Inki Dae <inki.dae@samsung.com>

Bluetooth: Add support for 128-bit UUIDs in EIR data

This patch adds the necessary code for encoding a list of 128-bit UUIDs
into the EIR data.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=c7998c8a434d80e5d4d19ed1196ba390fc36a56a

Change-Id: I7a5febd0ec2d96991994b2c9f0e938eda24eda76
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Add support for 32-bit UUIDs in EIR data

This patch adds the necessary code for inserting a list of 32-bit UUIDs
into the EIR data.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=cf4e4acd982b59602b2208bc4ddfb720d30521ea

Change-Id: Ic6d433ed22d9a7b655e9283803fc98c371c833d7
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Refactor UUID-16 list generation into its own function

We will need to create three separate UUID lists in the EIR data (for
16, 32 and 128 bit UUIDs) so the code is easier to follow if each list
is generated in their own function.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=4d071aebc17f788b2fc11041236dd6ca293ef4c6

Change-Id: Ib7a2ed514f7fb72881d088d282297850d2aa6bc3
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Remove useless eir_len variable from EIR creation

The amount of data encoded so far in the create_eir() function can be
calculated simply through the difference between the data and ptr
pointer variables. The eir_len variable then becomes essentially
useless.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=63365177976154ac6455962f45cf003928212d64

Change-Id: Ieeb6c572e07c69ca27ebf7ce5e35a34f754425fd
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Simplify UUID16 list generation for EIR

There's no need to use two separate loops to generate a UUID list for
the EIR data. This patch merges the two loops previously used for the
16-bit UUID list generation into a single loop, thus simplifying the
code a great deal.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=186dc23da07b3fe827343089a5728325da0776bb

Change-Id: Ide1d38477db57fd6e412cc958117fdff36966f19
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Simplify UUID removal code

The UUID removal code can be simplified by using
list_for_each_entry_safe instead of list_for_each_safe.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=1ef2f5a1cb9afcacb5063a96e3401b189d2921ac

Change-Id: I1a8f5c6ee117bab4986aac66bf784c341fb2191d
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <goodguy.lee@samsung.com>

Bluetooth: Keep track of UUID type upon addition

The primary purpose of the UUIDs is to enable generation of EIR and AD
data. In these data formats the UUIDs are split into separate fields
based on whether they're 16, 32 or 128 bit UUIDs. To make the generation
of these data fields simpler this patch adds a type member to the
bt_uuid struct and assigns a value to it as soon as the UUID is added to
the kernel. This way the type doesn't need to be calculated each time
the UUID list is later iterated.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=225ac2c1279f9f33ecce15257692603604cdb467

Change-Id: Ia6d355dee6414b15396ce39abaab662d57374499
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Simplify UUIDs clearing code

The code for clearing the UUIDs list can be simplified by using
list_for_each_entry_safe instead of list_for_each_safe.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=6051357b978e28c461fbbdfa00061466152fd01e

Change-Id: I1ada4bc11a7edcb23d1bbea3232eaeda76c94609
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Store UUIDs in the same order that they were added

We should be encoding UUIDs to the EIR data in the same order that they
were added to the kernel, i.e. each UUID should be added to the end of
the UUIDs list. This patch fixes the issue by using list_add_tail
instead of list_add for storing the UUIDs.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=863d6dff829fbfce7f7b6f3f9a91e09022a00f9e

Change-Id: I3b8624ef6f301b41b008ea390ef6a492506032b8
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

TRATS/TRATS2: enable the IKCONFIG_PROC

Enabled the IKCONFIG_PROC for using /proc/config.gz

Change-Id: I4bdd2f81dfa4bc232e2be4ddf6ca06be9e18579e
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

TRATS: M5MO: revert FACEDETECT configuration by default

By removing flash feature, it is no longer needed FACEDTECT configuration
by default.

Change-Id: Idae74a7e85875c3a74884a007a6897b8e00598d4
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

kernel/sys.c: fix stack memory content leak via UNAME26

Calling uname() with the UNAME26 personality set allows a leak of kernel
stack contents.  This fixes it by defensively calculating the length of
copy_to_user() call, making the len argument unsigned, and initializing
the stack buffer to zero (now technically unneeded, but hey, overkill).

CVE-2012-0957

Reported-by: PaX Team <pageexec@freemail.hu>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: PaX Team <pageexec@freemail.hu>
Cc: Brad Spengler <spender@grsecurity.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Change-Id: I9de2af6803b746650c44de30e22a7ed63a139cfc

TRATS2: S5C73M3: support 3264x2488 and 3264x1836 preview resolution.

support 3264x2488 and 3264x1836 preview resolution(S5C73M3_PREVIEW_HDR)

Change-Id: I34a26b2a625e55ec3478a41d80a3fe452c0b6efe
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS: defconfig: enable BLK_DEV_CRYPTOLOOP

Enabled this config for moving something to the internal storage

Change-Id: I80f44b394bf3e8413dccf483aa97d3dbeb7dfdfe
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

Revert "TRATS: M5MO: ZOOM_LEVEL_MAX changed to 12."

This reverts commit c596d48c84d238fdea7cf1371112b4b185bbd613.

It is decided to remove U1HD-M5MO FLASH function.
Thus, we do not need workarounds for FLASH function anymore.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Change-Id: I4c3243cb9102c0eee12551470f6334856c4f3e75

rtc: max77686: Disable day of week for alram setting.

Change-Id: I05e76ae843161742fea43e58518792cad24bd98f
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>

Sensor: AK8975: reduce delay of magnetic sensor

We have added delay for AK8975 operations; however, the previous
delay value was an overkill and could be reduced.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Change-Id: Ib22548a3db2840d97303f925bbd9771eed22d1d1

TRATS2: fix umts io devices

Apply umts io devices of tizen.

Change-Id: I55165d79aae3da57e60f68b8944177fdee6982a7
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

TRATS2: remove EHCI_REG_DUMP feature

We don't use this.

Change-Id: I929698f33ef9a0edcb5bf0811bde56d1fbe9066d
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

TRATS2: remove modem simdetect polarity feature

We don't use this.

Change-Id: I3f76dc0aae20db32a033781f470349e49ce6d836
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

TRATS2: fix modem gpio configuration

Use s5p_gpio_set_pd_cfg instead of s3c_gpio_slp_cfgpin to set gpio pd
configuation.

Change-Id: Ibd630945142d580e0fbab5bb8012e9a42cc77c62
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

TRATS: M5MO: ZOOM_LEVEL_MAX changed to 12.

Change-Id: I2230bbeca8f2fdf4ad60060f6b91d57dc024efef
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS2: AK8975C Sensor Operation Issue

When two IOCTLS and MODE CHANGES arrive with too short interval,
AK8975C halts operating and provides the same value until a reboot.
This patch gives an unconditional msleep in order to prevent this.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Change-Id: I6d930ccb993871daba94ed3157de192f9f483c1a

BUSFREQ: Disable low freqeuncy; 133Mhz, 100Mhz.

Change-Id: Ib090b43c3eae6924bc1ced3edcff083f9d2225bc
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>

TRATS: m5mo: initiate status of focus mode to select the first auto mode.

to select the fist auto mode, initial status of focus mode was changed
to FOCUS_MODE_DEFAULT.

Change-Id: I3db2bb9550fb435526a11aff8168020b2f9b2f0a
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS2:Sensor:When light sensor is enabled, input event report immediatedly

This patch fixed the bug related with sound volum.

Change-Id: I30f1cb6a8bedb8651065aa44526b4d6bb9a75cdb
Signed-off-by: cs2005.oh <cs2005.oh@samsung.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

SLP: All: Apply tempory fix for screen blinking.

we applied fix for screen blinking issue which revise busfreq.

Change-Id: I44ea734b757b51a90a6fe2308c43f86ffd7cab62
Signed-off-by: dongil01.park <dongil01.park@samsung.com>

BUSFREQ: add bus_dev to get exynos-busfreq device

Change-Id: Iec009c4411aedad88e3ea05e47d9a48cccb74b90
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

SLP:Trats:Sensor:Change the gp2ap020 sensor driver

-When proximity sensor and light sensor is enabled all, proximity raw data is reported wrong
-Change the driver file that is fixed this issue

-Cherry-picked to address TDIS-2945

Change-Id: Ifdea8246ccf7ee3c94bc3a968042b3cc3cb87009
Signed-off-by: cs2005.oh <cs2005.oh@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>

TRATS2: video: fix horizontal porch value

fix horizontal porch values to set mipi dsi timming.
After this patch, unexpected line on display panel was removed.

Change-Id: I248cfb70b9317e14e5d28cc2cfe3ecddb3692502
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS2: video: update mipi dsi platform data

update mipi dsi platform data properly

Change-Id: I9f436397bcd695d029e012b25f74401abfac3c24
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS2 / Move jack event handler to sync charger status.

Move jack event handler to sync charer status in order to
have the event triggered faster, eliminating mismatched
events.

Conflict resolved from the original patch of
dongil01.park <dongil01.park@samsung.com>.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Change-Id: I6f8069c2dae476fc295139a8bd93ba14c516d000

TRATS: WiFi: remove the duplicated define

WRITE_MACADDR is already defined at Makefile.

Change-Id: I340e07c5b0fe3e02643a9e518c7953fcee67d9ea
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

TRATS: WiFi: Fixed kernel panic problem for specific scan

Original author is Byeonghoon Ahn

Change-Id: I50c96a980b58eb5748eb3bb75f13076b80fed290
Signed-off-by: Byeonghoon Ahn <bh87.ahn@samsung.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

TRATS: bluetooth: enable CONFIG_BT_TIZEN

enable CONFIG_BT_TIZEN for TRATS1

Change-Id: Id6fbf7813f30a7ff0c8de84ceadb66f0b85c4882
Signed-off-by: dh09.lee <dh09.lee@samsung.com>

TRATS2: PM: remove the unnecessary code for sleep

When WiFi is entered suspend, didn't power down.

Change-Id: I2002073c00be904b72e5e416105d872ed68e04fd
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

TRATS: M5MO: enable FACE_DETECT_CTL by default

Enable to draw frame on YUV-data and face detect by default.
And change mode to FOCUS_MODE_AUTO when driver receives invalid
value.

Change-Id: I57af8f0428e282c112b8ec73b865ce4d6c1bae1b
Signed-off-by: dh09.lee <dh09.lee@samsung.com>

[PATCH] Bluetooth: Fix to update EIR for uuid16 properly

If we register uuid other than uuid16, especially custom 128 bit uuid
then nothing is updated in the EIR and it was broken.
Currently only uuid16 is only handled in the EIR updation.

After registering a 16 bit uuid. ex: "sdptool add SP" we can see the
uuid in the EIR.
< 0000: 01 52 0c f1 00 08 09 52  65 64 77 6f 6f 64 15 03  .R.....Redwood..
  0010: 01 11 32 11 2f 11 06 11  05 11 0a 11 0e 11 0c 11  ..2./...........
  0020: 1f 11 12 11 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0030: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0040: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0050: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0060: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0070: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0080: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0090: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00a0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00c0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00d0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00e0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00f0: 00 00 00 00 00                                    .....
> 0000: 04 0e 04 01 52 0c 00                              ....R..

After register a user defined 128 bit uuid, nothing is
updated in the EIR.

< 0000: 01 52 0c f1 00 08 09 52  65 64 77 6f 6f 64 00 00  .R.....Redwood..
  0010: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0030: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0040: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0050: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0060: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0070: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0080: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0090: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00a0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00c0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00d0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00e0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00f0: 00 00 00 00 00                                    .....
> 0000: 04 0e 04 01 52 0c 00                              ....R..

Change-Id: I68e4a3ce379157d4f68722d916570a54c4bda136

TRATS: fixed default auto focus mode and wrong fps value

fixed default auto focus mode and print warning message.
And fixed wrong fps value.

Change-Id: I07d12e2ebbb88cbdbfbc6aecc4104f618bc74ed4
Signed-off-by: dh09.lee <dh09.lee@samsung.com>

TRATS/TRATS2: enable the FANOTIFY config for system readahead

Enable the FANOTFY configuration for system readahead.

Change-Id: I5ed4097dc279cf06f24e3d7972905c33163dfa04
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

oom: fix integer overflow of points in oom_badness

An integer overflow will happen on 64bit archs if task's sum of rss,
swapents and nr_ptes exceeds (2^31)/1000 value.  This was introduced by
commit

f755a04 oom: use pte pages in OOM score

where the oom score computation was divided into several steps and it's no
longer computed as one expression in unsigned long(rss, swapents, nr_pte
are unsigned long), where the result value assigned to points(int) is in
range(1..1000).  So there could be an int overflow while computing

176          points *= 1000;

and points may have negative value. Meaning the oom score for a mem hog task
will be one.

196          if (points <= 0)
197                  return 1;

For example:
[ 3366]     0  3366 35390480 24303939   5       0             0 oom01
Out of memory: Kill process 3366 (oom01) score 1 or sacrifice child

Here the oom1 process consumes more than 24303939(rss)*4096~=92GB physical
memory, but it's oom score is one.

In this situation the mem hog task is skipped and oom killer kills another and
most probably innocent task with oom score greater than one.

The points variable should be of type long instead of int to prevent the
int overflow.

Signed-off-by: Frantisek Hrbata <fhrbata@redhat.com>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[Patch applied to resolve tizendev.org issue: TDIS-1691]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Id434f1615af88e5dc9979d4b8c45213875633dbe

rds: set correct msg_namelen

Jay Fenlason (fenlason@redhat.com) found a bug,
that recvfrom() on an RDS socket can return the contents of random kernel
memory to userspace if it was called with a address length larger than
sizeof(struct sockaddr_in).
rds_recvmsg() also fails to set the addr_len paramater properly before
returning, but that's just a bug.
There are also a number of cases wher recvfrom() can return an entirely bogus
address. Anything in rds_recvmsg() that returns a non-negative value but does
not go through the "sin = (struct sockaddr_in *)msg->msg_name;" code path
at the end of the while(1) loop will return up to 128 bytes of kernel memory
to userspace.

And I write two test programs to reproduce this bug, you will see that in
rds_server, fromAddr will be overwritten and the following sock_fd will be
destroyed.
Yes, it is the programmer's fault to set msg_namelen incorrectly, but it is
better to make the kernel copy the real length of address to user space in
such case.

How to run the test programs ?
I test them on 32bit x86 system, 3.5.0-rc7.

1 compile
gcc -o rds_client rds_client.c
gcc -o rds_server rds_server.c

2 run ./rds_server on one console

3 run ./rds_client on another console

4 you will see something like:
server is waiting to receive data...
old socket fd=3
server received data from client:data from client
msg.msg_namelen=32
new socket fd=-1067277685
sendmsg()
: Bad file descriptor

/***************** rds_client.c ********************/

int main(void)
{
int sock_fd;
struct sockaddr_in serverAddr;
struct sockaddr_in toAddr;
char recvBuffer[128] = "data from client";
struct msghdr msg;
struct iovec iov;

sock_fd = socket(AF_RDS, SOCK_SEQPACKET, 0);
if (sock_fd < 0) {
perror("create socket error\n");
exit(1);
}

memset(&serverAddr, 0, sizeof(serverAddr));
serverAddr.sin_family = AF_INET;
serverAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
serverAddr.sin_port = htons(4001);

if (bind(sock_fd, (struct sockaddr*)&serverAddr, sizeof(serverAddr)) < 0) {
perror("bind() error\n");
close(sock_fd);
exit(1);
}

memset(&toAddr, 0, sizeof(toAddr));
toAddr.sin_family = AF_INET;
toAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
toAddr.sin_port = htons(4000);
msg.msg_name = &toAddr;
msg.msg_namelen = sizeof(toAddr);
msg.msg_iov = &iov;
msg.msg_iovlen = 1;
msg.msg_iov->iov_base = recvBuffer;
msg.msg_iov->iov_len = strlen(recvBuffer) + 1;
msg.msg_control = 0;
msg.msg_controllen = 0;
msg.msg_flags = 0;

if (sendmsg(sock_fd, &msg, 0) == -1) {
perror("sendto() error\n");
close(sock_fd);
exit(1);
}

printf("client send data:%s\n", recvBuffer);

memset(recvBuffer, '\0', 128);

msg.msg_name = &toAddr;
msg.msg_namelen = sizeof(toAddr);
msg.msg_iov = &iov;
msg.msg_iovlen = 1;
msg.msg_iov->iov_base = recvBuffer;
msg.msg_iov->iov_len = 128;
msg.msg_control = 0;
msg.msg_controllen = 0;
msg.msg_flags = 0;
if (recvmsg(sock_fd, &msg, 0) == -1) {
perror("recvmsg() error\n");
close(sock_fd);
exit(1);
}

printf("receive data from server:%s\n", recvBuffer);

close(sock_fd);

return 0;
}

/***************** rds_server.c ********************/

int main(void)
{
struct sockaddr_in fromAddr;
int sock_fd;
struct sockaddr_in serverAddr;
unsigned int addrLen;
char recvBuffer[128];
struct msghdr msg;
struct iovec iov;

sock_fd = socket(AF_RDS, SOCK_SEQPACKET, 0);
if(sock_fd < 0) {
perror("create socket error\n");
exit(0);
}

memset(&serverAddr, 0, sizeof(serverAddr));
serverAddr.sin_family = AF_INET;
serverAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
serverAddr.sin_port = htons(4000);
if (bind(sock_fd, (struct sockaddr*)&serverAddr, sizeof(serverAddr)) < 0) {
perror("bind error\n");
close(sock_fd);
exit(1);
}

printf("server is waiting to receive data...\n");
msg.msg_name = &fromAddr;

/*
 * I add 16 to sizeof(fromAddr), ie 32,
 * and pay attention to the definition of fromAddr,
 * recvmsg() will overwrite sock_fd,
 * since kernel will copy 32 bytes to userspace.
 *
 * If you just use sizeof(fromAddr), it works fine.
 * */
msg.msg_namelen = sizeof(fromAddr) + 16;
/* msg.msg_namelen = sizeof(fromAddr); */
msg.msg_iov = &iov;
msg.msg_iovlen = 1;
msg.msg_iov->iov_base = recvBuffer;
msg.msg_iov->iov_len = 128;
msg.msg_control = 0;
msg.msg_controllen = 0;
msg.msg_flags = 0;

while (1) {
printf("old socket fd=%d\n", sock_fd);
if (recvmsg(sock_fd, &msg, 0) == -1) {
perror("recvmsg() error\n");
close(sock_fd);
exit(1);
}
printf("server received data from client:%s\n", recvBuffer);
printf("msg.msg_namelen=%d\n", msg.msg_namelen);
printf("new socket fd=%d\n", sock_fd);
strcat(recvBuffer, "--data from server");
if (sendmsg(sock_fd, &msg, 0) == -1) {
perror("sendmsg()\n");
close(sock_fd);
exit(1);
}
}

close(sock_fd);
return 0;
}

Signed-off-by: Weiping Pan <wpan@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Patch applied to resolve tizendev.org issue: TDIS-1589]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I72b79e8e3f33ff2d6e90ce71a75ca0d3a77bc7ee

mm: Hold a file reference in madvise_remove

Otherwise the code races with munmap (causing a use-after-free
of the vma) or with close (causing a use-after-free of the struct
file).

The bug was introduced by commit 90ed52ebe481 ("[PATCH] holepunch: fix
mmap_sem i_mutex deadlock")

Cc: Hugh Dickins <hugh@veritas.com>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1590]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Iffd4324271a6ac7831b4efea3477995f692c3d30

block: fail SCSI passthrough ioctls on partition devices

Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
will pass the command to the underlying block device.  This is
well-known, but it is also a large security problem when (via Unix
permissions, ACLs, SELinux or a combination thereof) a program or user
needs to be granted access only to part of the disk.

This patch lets partitions forward a small set of harmless ioctls;
others are logged with printk so that we can see which ioctls are
actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
Of course it was being sent to a (partition on a) hard disk, so it would
have failed with ENOTTY and the patch isn't changing anything in
practice.  Still, I'm treating it specially to avoid spamming the logs.

In principle, this restriction should include programs running with
CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
/dev/sdb, it still should not be able to read/write outside the
boundaries of /dev/sda2 independent of the capabilities.  However, for
now programs with CAP_SYS_RAWIO will still be allowed to send the
ioctls.  Their actions will still be logged.

This patch does not affect the non-libata IDE driver.  That driver
however already tests for bd != bd->bd_contains before issuing some
ioctl; it could be restricted further to forbid these ioctls even for
programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>
Cc: James Bottomley <JBottomley@parallels.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[ Make it also print the command name when warning - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1622]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Ib19bb420d7c57358dd7fd00475dcb1f26a57b6ac

xfs: validate acl count

This prevents in-memory corruption and possible panics if the on-disk
ACL is badly corrupted.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
[Patch applied to resolve tizendev.org issue: TDIS-1623]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I473d0982f4b307e9373df9d849b430ec00cc03fe

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.

[mtosatti: cleanup/beautify code]

Signed-off-by: Stephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
[Patch applied to resolve tizendev.org issue: TDIS-1624]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I645b230089f377d3ea1ca1c4970c80553b3ba684

cifs: fix dentry refcount leak when opening a FIFO on lookup

The cifs code will attempt to open files on lookup under certain
circumstances. What happens though if we find that the file we opened
was actually a FIFO or other special file?

Currently, the open filehandle just ends up being leaked leading to
a dentry refcount mismatch and oops on umount. Fix this by having the
code close the filehandle on the server if it turns out not to be a
regular file. While we're at it, change this spaghetti if statement
into a switch too.

Cc: stable@vger.kernel.org
Reported-by: CAI Qian <caiqian@redhat.com>
Tested-by: CAI Qian <caiqian@redhat.com>
Reviewed-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
[Patch applied to resolve tizendev.org issue: TDIS-1626]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Ibafb2fa4656d5decdb8ef4f289f6602bfd10ca88

mm: thp: fix pmd_bad() triggering in code paths holding mmap_sem read…

In some cases it may happen that pmd_none_or_clear_bad() is called with
the mmap_sem hold in read mode.  In those cases the huge page faults can
allocate hugepmds under pmd_none_or_clear_bad() and that can trigger a
false positive from pmd_bad() that will not like to see a pmd
materializing as trans huge.

It's not khugepaged causing the problem, khugepaged holds the mmap_sem
in write mode (and all those sites must hold the mmap_sem in read mode
to prevent pagetables to go away from under them, during code review it
seems vm86 mode on 32bit kernels requires that too unless it's
restricted to 1 thread per process or UP builds).  The race is only with
the huge pagefaults that can convert a pmd_none() into a
pmd_trans_huge().

Effectively all these pmd_none_or_clear_bad() sites running with
mmap_sem in read mode are somewhat speculative with the page faults, and
the result is always undefined when they run simultaneously.  This is
probably why it wasn't common to run into this.  For example if the
madvise(MADV_DONTNEED) runs zap_page_range() shortly before the page
fault, the hugepage will not be zapped, if the page fault runs first it
will be zapped.

Altering pmd_bad() not to error out if it finds hugepmds won't be enough
to fix this, because zap_pmd_range would then proceed to call
zap_pte_range (which would be incorrect if the pmd become a
pmd_trans_huge()).

The simplest way to fix this is to read the pmd in the local stack
(regardless of what we read, no need of actual CPU barriers, only
compiler barrier needed), and be sure it is not changing under the code
that computes its value.  Even if the real pmd is changing under the
value we hold on the stack, we don't care.  If we actually end up in
zap_pte_range it means the pmd was not none already and it was not huge,
and it can't become huge from under us (khugepaged locking explained
above).

All we need is to enforce that there is no way anymore that in a code
path like below, pmd_trans_huge can be false, but pmd_none_or_clear_bad
can run into a hugepmd.  The overhead of a barrier() is just a compiler
tweak and should not be measurable (I only added it for THP builds).  I
don't exclude different compiler versions may have prevented the race
too by caching the value of *pmd on the stack (that hasn't been
verified, but it wouldn't be impossible considering
pmd_none_or_clear_bad, pmd_bad, pmd_trans_huge, pmd_none are all inlines
and there's no external function called in between pmd_trans_huge and
pmd_none_or_clear_bad).

if (pmd_trans_huge(*pmd)) {
if (next-addr != HPAGE_PMD_SIZE) {
VM_BUG_ON(!rwsem_is_locked(&tlb->mm->mmap_sem));
split_huge_page_pmd(vma->vm_mm, pmd);
} else if (zap_huge_pmd(tlb, vma, pmd, addr))
continue;
/* fall through */
}
if (pmd_none_or_clear_bad(pmd))

Because this race condition could be exercised without special
privileges this was reported in CVE-2012-1179.

The race was identified and fully explained by Ulrich who debugged it.
I'm quoting his accurate explanation below, for reference.

====== start quote =======
      mapcount 0 page_mapcount 1
      kernel BUG at mm/huge_memory.c:1384!

    At some point prior to the panic, a "bad pmd ..." message similar to the
    following is logged on the console:

      mm/memory.c:145: bad pmd ffff8800376e1f98(80000000314000e7).

    The "bad pmd ..." message is logged by pmd_clear_bad() before it clears
    the page's PMD table entry.

        143 void pmd_clear_bad(pmd_t *pmd)
        144 {
    ->  145         pmd_ERROR(*pmd);
        146         pmd_clear(pmd);
        147 }

    After the PMD table entry has been cleared, there is an inconsistency
    between the actual number of PMD table entries that are mapping the page
    and the page's map count (_mapcount field in struct page). When the page
    is subsequently reclaimed, __split_huge_page() detects this inconsistency.

       1381         if (mapcount != page_mapcount(page))
       1382                 printk(KERN_ERR "mapcount %d page_mapcount %d\n",
       1383                        mapcount, page_mapcount(page));
    -> 1384         BUG_ON(mapcount != page_mapcount(page));

    The root cause of the problem is a race of two threads in a multithreaded
    process. Thread B incurs a page fault on a virtual address that has never
    been accessed (PMD entry is zero) while Thread A is executing an madvise()
    system call on a virtual address within the same 2 MB (huge page) range.

               virtual address space
              .---------------------.
              |                     |
              |                     |
            .-|---------------------|
            | |                     |
            | |                     |<-- B(fault)
            | |                     |
      2 MB  | |/////////////////////|-.
      huge <  |/////////////////////|  > A(range)
      page  | |/////////////////////|-'
            | |                     |
            | |                     |
            '-|---------------------|
              |                     |
              |                     |
              '---------------------'

    - Thread A is executing an madvise(..., MADV_DONTNEED) system call
      on the virtual address range "A(range)" shown in the picture.

    sys_madvise
      // Acquire the semaphore in shared mode.
      down_read(&current->mm->mmap_sem)
      ...
      madvise_vma
        switch (behavior)
        case MADV_DONTNEED:
             madvise_dontneed
               zap_page_range
                 unmap_vmas
                   unmap_page_range
                     zap_pud_range
                       zap_pmd_range
                         //
                         // Assume that this huge page has never been accessed.
                         // I.e. content of the PMD entry is zero (not mapped).
                         //
                         if (pmd_trans_huge(*pmd)) {
                             // We don't get here due to the above assumption.
                         }
                         //
                         // Assume that Thread B incurred a page fault and
             .---------> // sneaks in here as shown below.
             |           //
             |           if (pmd_none_or_clear_bad(pmd))
             |               {
             |                 if (unlikely(pmd_bad(*pmd)))
             |                     pmd_clear_bad
             |                     {
             |                       pmd_ERROR
             |                         // Log "bad pmd ..." message here.
             |                       pmd_clear
             |                         // Clear the page's PMD entry.
             |                         // Thread B incremented the map count
             |                         // in page_add_new_anon_rmap(), but
             |                         // now the page is no longer mapped
             |                         // by a PMD entry (-> inconsistency).
             |                     }
             |               }
             |
             v
    - Thread B is handling a page fault on virtual address "B(fault)" shown
      in the picture.

    ...
    do_page_fault
      __do_page_fault
        // Acquire the semaphore in shared mode.
        down_read_trylock(&mm->mmap_sem)
        ...
        handle_mm_fault
          if (pmd_none(*pmd) && transparent_hugepage_enabled(vma))
              // We get here due to the above assumption (PMD entry is zero).
              do_huge_pmd_anonymous_page
                alloc_hugepage_vma
                  // Allocate a new transparent huge page here.
                ...
                __do_huge_pmd_anonymous_page
                  ...
                  spin_lock(&mm->page_table_lock)
                  ...
                  page_add_new_anon_rmap
                    // Here we increment the page's map count (starts at -1).
                    atomic_set(&page->_mapcount, 0)
                  set_pmd_at
                    // Here we set the page's PMD entry which will be cleared
                    // when Thread A calls pmd_clear_bad().
                  ...
                  spin_unlock(&mm->page_table_lock)

    The mmap_sem does not prevent the race because both threads are acquiring
    it in shared mode (down_read).  Thread B holds the page_table_lock while
    the page's map count and PMD table entry are updated.  However, Thread A
    does not synchronize on that lock.

====== end quote =======

[akpm@linux-foundation.org: checkpatch fixes]
Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Dave Jones <davej@redhat.com>
Acked-by: Larry Woodman <lwoodman@redhat.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Mark Salter <msalter@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1629]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I9f91598c091fa80dfc3aa5506d7d0f595d7642ca

KVM: Ensure all vcpus are consistent with in-kernel irqchip settings

If some vcpus are created before KVM_CREATE_IRQCHIP, then
irqchip_in_kernel() and vcpu->arch.apic will be inconsistent, leading
to potential NULL pointer dereferences.

Fix by:
- ensuring that no vcpus are installed when KVM_CREATE_IRQCHIP is called
- ensuring that a vcpu has an apic if it is installed after KVM_CREATE_IRQCHIP

This is somewhat long winded because vcpu->arch.apic is created without
kvm->lock held.

Based on earlier patch by Michael Ellerman.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Avi Kivity <avi@redhat.com>
[Patch applied to resolve tizendev.org issue: TDIS-1630]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I33b128c1762ead12a12ef13df8d1a1bfedc798ff

KVM: unmap pages from the iommu when slots are removed

commit 32f6daa upstream.

We've been adding new mappings, but not destroying old mappings.
This can lead to a page leak as pages are pinned using
get_user_pages, but only unpinned with put_page if they still
exist in the memslots list on vm shutdown.  A memslot that is
destroyed while an iommu domain is enabled for the guest will
therefore result in an elevated page reference count that is
never cleared.

Additionally, without this fix, the iommu is only programmed
with the first translation for a gpa.  This can result in
peer-to-peer errors if a mapping is destroyed and replaced by a
new mapping at the same gpa as the iommu will still be pointing
to the original, pinned memory address.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1632]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Ie349c15d2597a1726a23a84c8cdfdd0adacdd05e

hugepages: fix use after free bug in "quota" handling

hugetlbfs_{get,put}_quota() are badly named.  They don't interact with the
general quota handling code, and they don't much resemble its behaviour.
Rather than being about maintaining limits on on-disk block usage by
particular users, they are instead about maintaining limits on in-memory
page usage (including anonymous MAP_PRIVATE copied-on-write pages)
associated with a particular hugetlbfs filesystem instance.

Worse, they work by having callbacks to the hugetlbfs filesystem code from
the low-level page handling code, in particular from free_huge_page().
This is a layering violation of itself, but more importantly, if the
kernel does a get_user_pages() on hugepages (which can happen from KVM
amongst others), then the free_huge_page() can be delayed until after the
associated inode has already been freed.  If an unmount occurs at the
wrong time, even the hugetlbfs superblock where the "quota" limits are
stored may have been freed.

Andrew Barry proposed a patch to fix this by having hugepages, instead of
storing a pointer to their address_space and reaching the superblock from
there, had the hugepages store pointers directly to the superblock,
bumping the reference count as appropriate to avoid it being freed.
Andrew Morton rejected that version, however, on the grounds that it made
the existing layering violation worse.

This is a reworked version of Andrew's patch, which removes the extra, and
some of the existing, layering violation.  It works by introducing the
concept of a hugepage "subpool" at the lower hugepage mm layer - that is a
finite logical pool of hugepages to allocate from.  hugetlbfs now creates
a subpool for each filesystem instance with a page limit set, and a
pointer to the subpool gets added to each allocated hugepage, instead of
the address_space pointer used now.  The subpool has its own lifetime and
is only freed once all pages in it _and_ all other references to it (i.e.
superblocks) are gone.

subpools are optional - a NULL subpool pointer is taken by the code to
mean that no subpool limits are in effect.

Previous discussion of this bug found in:  "Fix refcounting in hugetlbfs
quota handling.". See:  https://lkml.org/lkml/2011/8/11/28 or
http://marc.info/?l=linux-mm&m=126928970510627&w=1

v2: Fixed a bug spotted by Hillf Danton, and removed the extra parameter to
alloc_huge_page() - since it already takes the vma, it is not necessary.

Signed-off-by: Andrew Barry <abarry@cray.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Cc: Hugh Dickins <hughd@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Hillf Danton <dhillf@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1635]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I63783f5ab9494acdf243cb80a47668ee1933a3d4

hugetlb: fix resv_map leak in error path

Memory leak in mm/hugetlb.c in the Linux kernel before 3.4.2
allows local users to cause a denial of service (memory
consumption or system crash) via invalid MAP_HUGETLB mmap
operations.

Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>
Acked-by: Mel Gorman <mel@csn.ul.ie>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reported-by: Christoph Lameter <cl@linux.com>
Tested-by: Christoph Lameter <cl@linux.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: <stable@vger.kernel.org> [2.6.32+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1642]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I7e1039d435b22261fa68ad5b5da121b2baa62daa

TRATS: fixed compiler errors

Change-Id: I0f8f2a23cc9a13baae30323aca924753d9121722
Signed-off-by: dh09.lee <dh09.lee@samsung.com>

igmp: Avoid zero delay when receiving odd mixture of IGMP queries

Commit 5b7c84066733c5dfb0e4016d939757b38de189e4 ('ipv4: correct IGMP
behavior on v3 query during v2-compatibility mode') added yet another
case for query parsing, which can result in max_delay = 0.  Substitute
a value of 1, as in the usual v3 case.

Reported-by: Simon McVittie <smcv@debian.org>
References: http://bugs.debian.org/654876
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Patch applied to resolve tizendev.org issue: TDIS-1625]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I867c7e918c38a1fa52dc82373ef720a8effbf97c

regset: Prevent null pointer reference on readonly regsets

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 <hpa@zytor.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Roland McGrath <roland@hack.frob.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1627]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I48c4948b8c8f064513c350ca48ab1b9945419852

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:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
 IP: [<ffffffff810be32c>] mem_cgroup_usage_unregister_event+0x9c/0x1f0
 Pid: 574, comm: kworker/0:2 Not tainted 3.3.0-rc4+ #9 Bochs Bochs
 RIP: 0010:[<ffffffff810be32c>]  [<ffffffff810be32c>] mem_cgroup_usage_unregister_event+0x9c/0x1f0
 RSP: 0018:ffff88001d0b9d60  EFLAGS: 00010246
 Process kworker/0:2 (pid: 574, threadinfo ffff88001d0b8000, task ffff88001de91cc0)
 Call Trace:
  [<ffffffff8107092b>] cgroup_event_remove+0x2b/0x60
  [<ffffffff8103db94>] process_one_work+0x174/0x450
  [<ffffffff8103e413>] worker_thread+0x123/0x2d0

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Cc: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1628]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I2bbbe2b43478599f373afb5a9fcdd980d16a9e05

ext4: fix undefined behavior in ext4_fill_flex_info()

Commit 503358ae01b70ce6909d19dd01287093f6b6271c ("ext4: avoid divide by
zero when trying to mount a corrupted file system") fixes CVE-2009-4307
by performing a sanity check on s_log_groups_per_flex, since it can be
set to a bogus value by an attacker.

sbi->s_log_groups_per_flex = sbi->s_es->s_log_groups_per_flex;
groups_per_flex = 1 << sbi->s_log_groups_per_flex;

if (groups_per_flex < 2) { ... }

This patch fixes two potential issues in the previous commit.

1) The sanity check might only work on architectures like PowerPC.
On x86, 5 bits are used for the shifting amount.  That means, given a
large s_log_groups_per_flex value like 36, groups_per_flex = 1 << 36
is essentially 1 << 4 = 16, rather than 0.  This will bypass the check,
leaving s_log_groups_per_flex and groups_per_flex inconsistent.

2) The sanity check relies on undefined behavior, i.e., oversized shift.
A standard-confirming C compiler could rewrite the check in unexpected
ways.  Consider the following equivalent form, assuming groups_per_flex
is unsigned for simplicity.

groups_per_flex = 1 << sbi->s_log_groups_per_flex;
if (groups_per_flex == 0 || groups_per_flex == 1) {

We compile the code snippet using Clang 3.0 and GCC 4.6.  Clang will
completely optimize away the check groups_per_flex == 0, leaving the
patched code as vulnerable as the original.  GCC keeps the check, but
there is no guarantee that future versions will do the same.

Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
[Patch applied to resolve tizendev.org issue: TDIS-1631]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Ib3f81dbcc385e11d999c4d2b3ecc834f5ff3f311

fcaps: clear the same personality flags as suid when fcaps are used

If a process increases permissions using fcaps all of the dangerous
personality flags which are cleared for suid apps should also be cleared.
Thus programs given priviledge with fcaps will continue to have address space
randomization enabled even if the parent tried to disable it to make it
easier to attack.

Signed-off-by: Eric Paris <eparis@redhat.com>
Reviewed-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
[Patch applied to resolve tizendev.org issue: TDIS-1633]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Icf697a5a7336f310ddcd40a7379af22e7d9872d5

procfs: fix a vfsmount longterm reference leak

kern_mount() doesn't pair with plain mntput()...
fs/proc/root.c in the procfs implementation in the Linux kernel before
3.2 does not properly interact with CLONE_NEWPID clone system calls,
which allows remote attackers to cause a denial of service (reference
leak and memory consumption) by making many connections to a daemon
that uses PID namespaces to isolate clients, as demonstrated by vsftpd."

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[Patch applied to resolve tizendev.org issue: TDIS-1634]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Ib98fb053aced04adbb733357d35fa1705b556618

net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()

We need to validate the number of pages consumed by data_len, otherwise frags
array could be overflowed by userspace. So this patch validate data_len and
return -EMSGSIZE when data_len may occupies more frags than MAX_SKB_FRAGS.

Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Patch applied to resolve tizendev.org issue: TDIS-1636]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I23ff1dd134498bde200ee71b4e4813baf0e5dd4a