Revert "SMACK: netework label match fix"

This reverts commit 1b2029c38121a0c7f208df9774ed997a3af2efda.

Change-Id: I3696bf55ff92cee1e2b73ad6827f71c67f828781

Revert "smack: fix memleak in smk_write_rules_list()"

This reverts commit d74328fb7f8e333bff0718d3f6bffc3cf8398431.

Change-Id: I0cadaa20c8ca152c26ef733416ddaf20ec87e243

Revert "SMACK: support the smack 'L' mode for smack permission"

This reverts commit 6ae6d1852ee602c22d337aacd004f1c0fecb323d.

Change-Id: Iff1d280eed361aa04fee9f37a6d87aa5c4b17597

Revert "Smack: parse multiple rules per write to load2, up to PAGE_SIZE-1 bytes"

This reverts commit cfb2f358b42f6990b93ee157d8f5afaded9e20dd.

Change-Id: I2e0e3be306a7927bd303fd62539b322fd4ec6370

Merge "Smack: parse multiple rules per write to load2, up to PAGE_SIZE-1 bytes"

Smack: parse multiple rules per write to load2, up to PAGE_SIZE-1 bytes

Smack interface for loading rules has always parsed only single rule from
data written to it. This requires user program to call one write() per
each rule it wants to load.
This change makes it possible to write multiple rules, separated by new
line character. Smack will load at most PAGE_SIZE-1 characters and properly
return number of processed bytes. In case when user buffer is larger, it
will be additionally truncated. All characters after last \n will not get
parsed to avoid partial rule near input buffer boundary.

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

Bluetooth: Migrated to the latest bluetooth.git code (2012-10-12)

This code is taken from the 3.0 repo, where its is sync
with latest bluetooth.git.

With this patch we are migrating the linux bluetooth module
based on the bluetooth.git dated on 2012-10-12. This is required
to get the support for the latest Bluetooth fixes.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth.git;
a=commit;h=065a13e2cc665f6547dc7e8a9d6b6565badf940a

Change-Id: I0cd8e3f3b65d982fe371b445658a5870979bcd52
Signed-off-by: DoHyun Pyun <dh79.pyun@samsung.com>
Reviewed-on: https://review.tizendev.org/gerrit/#/c/89424/
Reviewed-on: Taesoo Jun <steve.jun@samsung.com>
Tested-by: DoHyun Pyun <dh79.pyun@samsung.com>

ida: simplified functions for id allocation

The current hyper-optimized functions are overkill if you simply want to
allocate an id for a device.  Create versions which use an internal
lock.

In followup patches, numerous drivers are converted to use this
interface.

Thanks to Tejun for feedback.

Change-Id: I980c6feb8e88014e09d73a902a522e99fcac18b5
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: DoHyun Pyun <dh79.pyun@samsung.com>

module.h: split out the EXPORT_SYMBOL into export.h

A lot of files pull in module.h when all they are really
looking for is the basic EXPORT_SYMBOL functionality. The
recent data from Ingo[1] shows that this is one of several
instances that has a significant impact on compile times,
and it should be targeted for factoring out (as done here).

Note that several commonly used header files in include/*
directly include <linux/module.h> themselves (some 34 of them!)
The most commonly used ones of these will have to be made
independent of module.h before the full benefit of this change
can be realized.

We also transition THIS_MODULE from module.h to export.h,
since there are lots of files with subsystem structs that
in turn will have a struct module *owner and only be doing:

.owner = THIS_MODULE;

and absolutely nothing else modular. So, we also want to have
the THIS_MODULE definition present in the lightweight header.

[1] https://lkml.org/lkml/2011/5/23/76

Change-Id: I57b65ffab7ef89a35180cbfe841a848017fcb648
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: DoHyun Pyun <dh79.pyun@samsung.com>

video: mipi dsi: rearrange initial delay and remove useless code

rearrange initial delay for mipi dsi core and s6e8aa0 panel and
remove useless code.

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

SMACK: support the smack 'L' mode for smack permission

To consider the security issue, added the smack 'L'mode for smack
permission.
('w' smack rule is replaced the 'L' mode)

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

smack: fix memleak in smk_write_rules_list()

The smack_parsed_rule structure is allocated.  If a rule is successfully
installed then the last reference to the object is lost.  This patch fixes this
leak. Moreover smack_parsed_rule is allocated on stack because it no longer
needed ofter smk_write_rules_list() is finished.

Change-Id: Icd5120bc398af14d9d198e799afcf131d50c0200
Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com>
Signed-off-by: Sangjung Woo <sangjung.woo@samsung.com>

ARM: 7169/1: topdown mmap support

Similar to other architectures, this adds topdown mmap support in user
process address space allocation policy. This allows mmap sizes greater
than 2GB. This support is largely copied from MIPS and the generic
implementations.

The address space randomization is moved into arch_pick_mmap_layout.

Tested on V-Express with ubuntu and a mmap test from here:
https://bugs.launchpad.net/bugs/861296

Change-Id: If1224a16aee3dc330fcf432f04be5d5d29a7128b
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7168/1: use cache type functions for arch_get_unmapped_area

There are already cache type decoding functions, so use those instead
of custom decode code which only works for ARMv6.

Change-Id: Ibe7d0934e407117e93e0a82dbb00d94c7490f9da
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

power: samsung_battery: Use system time for alarm timer not real time.

Fix to use ktimer_get() not alarm_elasped_realtime().

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

SMACK: netework label match fix

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

oprofile: Remove useless parameter from op_overflow_handler().

Since perf removed nmi parameter from the swevent and overflow
interface, (commit id : 28830d2562a42) oprofile's overflow handler
also needs to fix to fit.

Change-Id: If128e552a58eba961fa04bdd4fd4e530c5584bde
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
Reviewed-by : Chanho Park <chanho61.park@samsung.com>
Reviewed-by : Myungjoo Ham <myungjoo.ham@samsung.com>

net: fix incorrect credentials passing

[ Upstream commit 83f1b4ba917db5dc5a061a44b3403ddb6e783494 ]

Commit 257b5358b32f ("scm: Capture the full credentials of the scm
sender") changed the credentials passing code to pass in the effective
uid/gid instead of the real uid/gid.

Obviously this doesn't matter most of the time (since normally they are
the same), but it results in differences for suid binaries when the wrong
uid/gid ends up being used.

This just undoes that (presumably unintentional) part of the commit.

Reported-by: Andy Lutomirski <luto@amacapital.net>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Serge E. Hallyn <serge@hallyn.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-5988]
Signed-off-by: Hyung-won Hwang <human.hwang@samsung.com>
Change-Id: I2486e0635400ef5b2547d0f405061996cc99bed9

crypto: algif - suppress sending source address information in recvmsg

The current code does not set the msg_namelen member to 0 and therefore
makes net/socket.c leak the local sockaddr_storage variable to userland
-- 128 bytes of kernel stack memory. Fix that.

Cc: <stable@vger.kernel.org> # 2.6.38
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[Patch applied to resolve tizendev.org issue: TDIS-5675]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: Ifa5e4c8e1497964ba3731af1c4f165877e5f97c7

llc: Fix missing msg_namelen update in llc_ui_recvmsg()

For stream sockets the code misses to update the msg_namelen member
to 0 and therefore makes net/socket.c leak the local, uninitialized
sockaddr_storage variable to userland -- 128 bytes of kernel stack
memory. The msg_namelen update is also missing for datagram sockets
in case the socket is shutting down during receive.

Fix both issues by setting msg_namelen to 0 early. It will be
updated later if we're going to fill the msg_name member.

Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
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-5674]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: Ic8320df2c7d689a32b62a86e57f00fbd9934c21f

Bluetooth: fix possible info leak in bt_sock_recvmsg()

In case the socket is already shutting down, bt_sock_recvmsg() returns
with 0 without updating msg_namelen leading to net/socket.c leaking the
local, uninitialized sockaddr_storage variable to userland -- 128 bytes
of kernel stack memory.

Fix this by moving the msg_namelen assignment in front of the shutdown
test.

Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
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-5673]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: I3c47fa6366e50252d9a6cca6816429414a4877da

atm: update msg_namelen in vcc_recvmsg()

The current code does not fill the msg_name member in case it is set.
It also does not set the msg_namelen member to 0 and therefore makes
net/socket.c leak the local, uninitialized sockaddr_storage variable
to userland -- 128 bytes of kernel stack memory.

Fix that by simply setting msg_namelen to 0 as obviously nobody cared
about vcc_recvmsg() not filling the msg_name in case it was set.

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-5672]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: I8c9c6a0de3a5704587c5df45a0594832001667e2

TRATS2: sensor: disable lps331 barometer into redwood

- lps331 barometer do not exist into redwood.

Change-Id: I91d602337c8600b3f82a96803fcb0bd21c33e9d8
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>

TRATS2: sensor support gp2ap light/proximity sensor for redwood board

Change-Id: I225eba71e3301ee631a41605c78b9f29d22bf120
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>

TRATS2: sensor: support ak8963 magnetic sensor for redwood board

-Add position information each board correctly

Merge conflict resolve by MyungJoo Ham <myungjoo.ham@samsung.com>

Change-Id: I3ecc4ea03fcac20228e345a06a2b810678acb5d6
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>

TRATS2: sensor: add ak8963 prefix at IOCTL command

Change-Id: I1fc36c6202434cdf897e2069b6a2f96915527405
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Reviewed-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS2: REDWOOD: support redwood input device

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

TRATS2: remove repeated code for input device configuration

- remove repeated code in the check_hw_revision() function.

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

TRATS2: re-define REDWOOD and M0 board check

- use REDWOOD prefix which it take over from u-boot.
- remove check_board_type() function.
- define hwrevision() function newly.

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

TRATS2: video: support s6d6aa1 panel for redwood board

Checkpatched & cleand by MyungJoo Ham <myungjoo.ham@samsung.com>

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

TRATS2: support redwood board

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

perf: Treat attr.config as u64 in perf_swevent_init()

Trinity discovered that we fail to check all 64 bits of
attr.config passed by user space, resulting to out-of-bounds
access of the perf_swevent_enabled array in
sw_perf_event_destroy().

Introduced in commit b0a873ebb ("perf: Register PMU
implementations").

Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: davej@redhat.com
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Link: http://lkml.kernel.org/r/1365882554-30259-1-git-send-email-tt.rantala@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[Patch applied to resolve tizendev.org issue: TDIS-5991]
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Change-Id: Iaf7e4179f9ffe1bcf519c4bc1fbf1b01b271daef

modify spec file for build error

modify specfile for build error

TRATS2: sensor: Fix ak8975 magnetic sensor position issue

- Output value of magnetic sensor not showing correct direction.
- Output value depend on position of sensor.
- Add position information correctly.
- Add magnnetic_get_position function into board-trats2.c

Change-Id: I51e86b0878b231bf3e2ba7833d833db4ac8c6fbb
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>

TRATS2: modify linux.spec file to support kernel-header pakage

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

2-TOUCHKEY: add workaround delay to sync I2C SCL signal

add delay to sync I2C SCL signal of EXT_I2C_ACK()

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

TRATS2: update defconfig

- add melfas_touchkey configuration

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

TRATS2: support melfas_touchkey device

- support melfas_touchkey device for TRATS2

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

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>