linux-stable.git/include, branch v3.18.46

tcp: fix use after free in tcp_xmit_retransmit_queue()

2016-12-23T14:41:56+00:00

[ Upstream commit bb1fceca22492109be12640d49f5ea5a544c6bb4 ]

When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the
tail of the write queue using tcp_add_write_queue_tail()

Then it attempts to copy user data into this fresh skb.

If the copy fails, we undo the work and remove the fresh skb.

Unfortunately, this undo lacks the change done to tp->highest_sack and
we can leave a dangling pointer (to a freed skb)

Later, tcp_xmit_retransmit_queue() can dereference this pointer and
access freed memory. For regular kernels where memory is not unmapped,
this might cause SACK bugs because tcp_highest_sack_seq() is buggy,
returning garbage instead of tp->snd_nxt, but with various debug
features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel.

This bug was found by Marco Grassi thanks to syzkaller.

Fixes: 6859d49475d4 ("[TCP]: Abstract tp->highest_sack accessing & point to next skb")
Reported-by: Marco Grassi 
Signed-off-by: Eric Dumazet 
Cc: Ilpo Järvinen 
Cc: Yuchung Cheng 
Cc: Neal Cardwell 
Acked-by: Neal Cardwell 
Reviewed-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

can: dev: fix deadlock reported after bus-off

2016-12-23T14:41:16+00:00

[ Upstream commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 ]

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 
Cc: linux-stable 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Sasha Levin

mm: remove gup_flags FOLL_WRITE games from __get_user_pages()

2016-10-22T19:48:09+00:00

[ Upstream commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 ]

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 
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

fix fault_in_multipages_...() on architectures with no-op access_ok()

2016-10-06T02:40:20+00:00

[ Upstream commit e23d4159b109167126e5bcd7f3775c95de7fee47 ]

Switching iov_iter fault-in to multipages variants has exposed an old
bug in underlying fault_in_multipages_...(); they break if the range
passed to them wraps around.  Normally access_ok() done by callers will
prevent such (and it's a guaranteed EFAULT - ERR_PTR() values fall into
such a range and they should not point to any valid objects).

However, on architectures where userland and kernel live in different
MMU contexts (e.g. s390) access_ok() is a no-op and on those a range
with a wraparound can reach fault_in_multipages_...().

Since any wraparound means EFAULT there, the fix is trivial - turn
those

    while (uaddr <= end)
	    ...
into

    if (unlikely(uaddr > end))
	    return -EFAULT;
    do
	    ...
    while (uaddr <= end);

Reported-by: Jan Stancek 
Tested-by: Jan Stancek 
Cc: stable@vger.kernel.org # v3.5+
Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

fanotify: fix list corruption in fanotify_get_response()

2016-10-06T02:40:20+00:00

[ Upstream commit 96d41019e3ac55f6f0115b0ce97e4f24a3d636d2 ]

fanotify_get_response() calls fsnotify_remove_event() when it finds that
group is being released from fanotify_release() (bypass_perm is set).

However the event it removes need not be only in the group's notification
queue but it can have already moved to access_list (userspace read the
event before closing the fanotify instance fd) which is protected by a
different lock.  Thus when fsnotify_remove_event() races with
fanotify_release() operating on access_list, the list can get corrupted.

Fix the problem by moving all the logic removing permission events from
the lists to one place - fanotify_release().

Fixes: 5838d4442bd5 ("fanotify: fix double free of pending permission events")
Link: http://lkml.kernel.org/r/1473797711-14111-3-git-send-email-jack@suse.cz
Signed-off-by: Jan Kara 
Reported-by: Miklos Szeredi 
Tested-by: Miklos Szeredi 
Reviewed-by: Miklos Szeredi 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

fsnotify: add a way to stop queueing events on group shutdown

2016-10-06T02:40:20+00:00

[ Upstream commit 12703dbfeb15402260e7554d32a34ac40c233990 ]

Implement a function that can be called when a group is being shutdown
to stop queueing new events to the group.  Fanotify will use this.

Fixes: 5838d4442bd5 ("fanotify: fix double free of pending permission events")
Link: http://lkml.kernel.org/r/1473797711-14111-2-git-send-email-jack@suse.cz
Signed-off-by: Jan Kara 
Reviewed-by: Miklos Szeredi 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

asm-generic: make get_user() clear the destination on errors

2016-10-06T02:40:20+00:00

[ Upstream commit 9ad18b75c2f6e4a78ce204e79f37781f8815c0fa ]

both for access_ok() failures and for faults halfway through

Cc: stable@vger.kernel.org
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

asm-generic: {get,put}_user ptr argument evaluate only 1 time

2016-10-06T02:40:20+00:00

[ Upstream commit a02613a4ba679eacec8251976d02809d533fa717 ]

Current implemantation ptr argument evaluate 2 times.
It'll be an unexpected result.

Changes v5:
Remove unnecessary const.
Changes v4:
Temporary pointer type change to const void*
Changes v3:
Some build error fix.
Changes v2:
Argument x protect.

Signed-off-by: Yoshinori Sato 
Signed-off-by: Sasha Levin

genirq: Provide irq_gc_{lock_irqsave,unlock_irqrestore}() helpers

2016-10-06T02:40:20+00:00

[ Upstream commit ebf9ff753c041b296241990aef76163bbb2cc9c8 ]

Some irqchip drivers need to take the generic chip lock outside of the
irq context.

Provide the irq_gc_{lock_irqsave,unlock_irqrestore}() helpers to allow
one to disable irqs while entering a critical section protected by
gc->lock.

Note that we do not provide optimized version of these helpers for !SMP,
because they are not called from the hot-path.

[ tglx: Added a comment when these helpers should be [not] used ]

Signed-off-by: Boris Brezillon 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Nicolas Ferre 
Cc: stable@vger.kernel.org
Cc: Alexandre Belloni 
Link: http://lkml.kernel.org/r/1473775109-4192-1-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin

genirq: Generic chip: Change irq_reg_{readl,writel} arguments

2016-10-06T02:40:20+00:00

[ Upstream commit 332fd7c4fef5f3b166e93decb07fd69eb24f7998 ]

Pass in the irq_chip_generic struct so we can use different readl/writel
settings for each irqchip driver, when appropriate.  Compute
(gc->reg_base + reg_offset) in the helper function because this is pretty
much what all callers want to do anyway.

Compile-tested using the following configurations:

    at91_dt_defconfig (CONFIG_ATMEL_AIC_IRQ=y)
    sama5_defconfig (CONFIG_ATMEL_AIC5_IRQ=y)
    sunxi_defconfig (CONFIG_ARCH_SUNXI=y)

tb10x (ARC) is untested.

Signed-off-by: Kevin Cernekee 
Acked-by: Thomas Gleixner 
Acked-by: Acked-by: Arnd Bergmann 
Link: https://lkml.kernel.org/r/1415342669-30640-3-git-send-email-cernekee@gmail.com
Signed-off-by: Jason Cooper 
Signed-off-by: Sasha Levin