linux-stable.git/include/linux, branch linux-4.7.y

vfs: move permission checking into notify_change() for utimes(NULL)

2016-10-22T10:06:49+00:00

commit f2b20f6ee842313a0d681dbbf7f87b70291a6a3b upstream.

This fixes a bug where the permission was not properly checked in
overlayfs.  The testcase is ltp/utimensat01.

It is also cleaner and safer to do the permission checking in the vfs
helper instead of the caller.

This patch introduces an additional ia_valid flag ATTR_TOUCH (since
touch(1) is the most obvious user of utimes(NULL)) that is passed into
notify_change whenever the conditions for this special permission checking
mode are met.

Reported-by: Aihua Zhang 
Signed-off-by: Miklos Szeredi 
Tested-by: Aihua Zhang 
Signed-off-by: Greg Kroah-Hartman

debugfs: introduce a public file_operations accessor

2016-10-22T10:06:46+00:00

commit 86f0e06767dda7863d6d2a8f0b3b857e6ea876a0 upstream.

This patch introduces an accessor which can be used
by the users of debugfs (drivers, fs, ...) to get the
original file_operations struct. It also removes the
REAL_FOPS_DEREF macro in file.c and converts the code
to use the public version.

Previously, REAL_FOPS_DEREF was only available within
the file.c of debugfs. But having a public getter
available for debugfs users is important as some
drivers (carl9170 and b43) use the pointer of the
original file_operations in conjunction with container_of()
within their debugfs implementations.

Reviewed-by: Nicolai Stange 
Signed-off-by: Christian Lamparter 
Signed-off-by: Greg Kroah-Hartman

mm: remove gup_flags FOLL_WRITE games from __get_user_pages()

2016-10-20T08:02:21+00:00

commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 upstream.

This is an ancient bug that was actually attempted to be fixed once
(badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
get_user_pages() race for write access") but that was then undone due to
problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").

In the meantime, the s390 situation has long been fixed, and we can now
fix it by checking the pte_dirty() bit properly (and do it better).  The
s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
software dirty bits") which made it into v3.9.  Earlier kernels will
have to look at the page state itself.

Also, the VM has become more scalable, and what used a purely
theoretical race back then has become easier to trigger.

To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
we already did a COW" rather than play racy games with FOLL_WRITE that
is very fundamental, and then use the pte dirty flag to validate that
the FOLL_COW flag is still valid.

Reported-and-tested-by: Phil "not Paul" Oester 
Acked-by: Hugh Dickins 
Reviewed-by: Michal Hocko 
Cc: Andy Lutomirski 
Cc: Kees Cook 
Cc: Oleg Nesterov 
Cc: Willy Tarreau 
Cc: Nick Piggin 
Cc: Greg Thelen 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mfd: 88pm80x: Double shifting bug in suspend/resume

2016-10-16T15:50:37+00:00

commit 9a6dc644512fd083400a96ac4a035ac154fe6b8d upstream.

set_bit() and clear_bit() take the bit number so this code is really
doing "1 << (1 << irq)" which is a double shift bug.  It's done
consistently so it won't cause a problem unless "irq" is more than 4.

Fixes: 70c6cce04066 ('mfd: Support 88pm80x in 80x driver')
Signed-off-by: Dan Carpenter 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

sysctl: handle error writing UINT_MAX to u32 fields

2016-10-07T13:21:25+00:00

commit e7d316a02f683864a12389f8808570e37fb90aa3 upstream.

We have scripts which write to certain fields on 3.18 kernels but this
seems to be failing on 4.4 kernels.  An entry which we write to here is
xfrm_aevent_rseqth which is u32.

  echo 4294967295  > /proc/sys/net/core/xfrm_aevent_rseqth

Commit 230633d109e3 ("kernel/sysctl.c: detect overflows when converting
to int") prevented writing to sysctl entries when integer overflow
occurs.  However, this does not apply to unsigned integers.

Heinrich suggested that we introduce a new option to handle 64 bit
limits and set min as 0 and max as UINT_MAX.  This might not work as it
leads to issues similar to __do_proc_doulongvec_minmax.  Alternatively,
we would need to change the datatype of the entry to 64 bit.

  static int __do_proc_doulongvec_minmax(void *data, struct ctl_table
  {
      i = (unsigned long *) data;   //This cast is causing to read beyond the size of data (u32)
      vleft = table->maxlen / sizeof(unsigned long); //vleft is 0 because maxlen is sizeof(u32) which is lesser than sizeof(unsigned long) on x86_64.

Introduce a new proc handler proc_douintvec.  Individual proc entries
will need to be updated to use the new handler.

[akpm@linux-foundation.org: coding-style fixes]
Fixes: 230633d109e3 ("kernel/sysctl.c:detect overflows when converting to int")
Link: http://lkml.kernel.org/r/1471479806-5252-1-git-send-email-subashab@codeaurora.org
Signed-off-by: Subash Abhinov Kasiviswanathan 
Cc: Heinrich Schuchardt 
Cc: Kees Cook 
Cc: "David S. Miller" 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm, kasan: account for object redzone in SLUB's nearest_obj()

2016-10-07T13:21:23+00:00

commit c146a2b98eb5898eb0fab15a332257a4102ecae9 upstream.

When looking up the nearest SLUB object for a given address, correctly
calculate its offset if SLAB_RED_ZONE is enabled for that cache.

Previously, when KASAN had detected an error on an object from a cache
with SLAB_RED_ZONE set, the actual start address of the object was
miscalculated, which led to random stacks having been reported.

When looking up the nearest SLUB object for a given address, correctly
calculate its offset if SLAB_RED_ZONE is enabled for that cache.

Fixes: 7ed2f9e663854db ("mm, kasan: SLAB support")
Link: http://lkml.kernel.org/r/1468347165-41906-2-git-send-email-glider@google.com
Signed-off-by: Alexander Potapenko 
Cc: Andrey Konovalov 
Cc: Christoph Lameter 
Cc: Dmitry Vyukov 
Cc: Steven Rostedt (Red Hat) 
Cc: Joonsoo Kim 
Cc: Kostya Serebryany 
Cc: Andrey Ryabinin 
Cc: Kuthonuzo Luruo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

nvmem: Declare nvmem_cell_read() consistently

2016-10-07T13:21:18+00:00

commit a6c50912508d80164a5e607993b617be85a46d73 upstream.

nvmem_cell_read() is declared as void * if CONFIG_NVMEM is enabled, and
as char * otherwise. This can result in a build warning if CONFIG_NVMEM
is not enabled and a caller asigns the result to a type other than char *
without using a typecast. Use a consistent declaration to avoid the
problem.

Fixes: e2a5402ec7c6 ("nvmem: Add nvmem_device based consumer apis.")
Cc: Srinivas Kandagatla 
Signed-off-by: Guenter Roeck 
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: Greg Kroah-Hartman

can: dev: fix deadlock reported after bus-off

2016-10-07T13:21:16+00:00

commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] https://github.com/victronenergy/venus/issues/24

Signed-off-by: Sergei Miroshnichenko 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

ceph: fix symbol versioning for ceph_monc_do_statfs

2016-09-30T08:12:47+00:00

commit a0f2b65275413b3438e9f55b1427273cd893c3b2 upstream.

The genksyms helper in the kernel cannot parse a type definition
like "typeof(((type *)0)->keyfld)" that is used in the DEFINE_RB_FUNCS
helper, causing the following EXPORT_SYMBOL() statement to be ignored
when computing the crcs, and triggering a warning about this:

WARNING: "ceph_monc_do_statfs" [fs/ceph/ceph.ko] has no CRC

To work around the problem, we can rewrite the type to reference
an undefined 'extern' symbol instead of a NULL pointer. This is
evidently ok for genksyms, and it no longer complains about the
line when calling it with 'genksyms -w'.

I've looked briefly into extending genksyms instead, but it seems
really hard to do. Jan Beulich introduced basic support for 'typeof'
a while ago in dc53324060f3 ("genksyms: fix typeof() handling"),
but that is not sufficient for the expression we have here.

Signed-off-by: Arnd Bergmann 
Fixes: fcd00b68bbe2 ("libceph: DEFINE_RB_FUNCS macro")
Cc: Jan Beulich 
Cc: Michal Marek 
Signed-off-by: Ilya Dryomov 
Signed-off-by: Greg Kroah-Hartman

libceph: add an ONSTACK initializer for oids

2016-09-30T08:12:47+00:00

commit 281dbe5db81c6137def9757e07a7aea14b1ed86e upstream.

An on-stack oid in ceph_ioctl_get_dataloc() is not initialized,
resulting in a WARN and a NULL pointer dereference later on.  We will
have more of these on-stack in the future, so fix it with a convenience
macro.

Fixes: d30291b985d1 ("libceph: variable-sized ceph_object_id")
Signed-off-by: Ilya Dryomov 
Signed-off-by: Greg Kroah-Hartman