4 years agov4l2-compat-ioctl32: fix alignment for ARM64
Andrzej Hajda [Mon, 31 Aug 2015 11:56:15 +0000 (08:56 -0300)]
v4l2-compat-ioctl32: fix alignment for ARM64

commit 655e9780ab913a3a06d4a164d55e3b755524186d upstream.

Alignment/padding rules on AMD64 and ARM64 differs. To allow properly match
compatible ioctls on ARM64 kernels without breaking AMD64 some fields
should be aligned using compat_s64 type and in one case struct should be

Signed-off-by: Andrzej Hajda <>
[ use compat_u64 instead of compat_s64 in v4l2_input32]
Signed-off-by: Hans Verkuil <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
4 years agoV4L2: fix VIDIOC_CREATE_BUFS 32-bit compatibility mode data copy-back
Guennadi Liakhovetski [Fri, 30 May 2014 23:26:38 +0000 (20:26 -0300)]
V4L2: fix VIDIOC_CREATE_BUFS 32-bit compatibility mode data copy-back

commit 6ed9b28504326f8cf542e6b68245b2f7ce009216 upstream.

Similar to an earlier patch, fixing reading user-space data for the
VIDIOC_CREATE_BUFS ioctl() in 32-bit compatibility mode, this patch fixes
writing back of the possibly modified struct to the user. However, unlike
the former bug, this one is much less harmful, because it only results in
the kernel failing to write the .type field back to the user, but in fact
this is likely unneeded, because the kernel will hardly want to change
that field. Therefore this bug is more of a theoretical nature.

Signed-off-by: Guennadi Liakhovetski <>
Acked-by: Laurent Pinchart <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
4 years agov4l2-compat-ioctl32: fix sparse warnings
Hans Verkuil [Thu, 21 Aug 2014 20:07:21 +0000 (17:07 -0300)]
v4l2-compat-ioctl32: fix sparse warnings

commit 8ae632b11775254c5e555ee8c42b7d19baeb1473 upstream.

A lot of these warnings are caused by the fact that we don't generally use
__user in videodev2.h. Normally the video_usercopy function will copy anything
pointed to by pointers into kernel space, so having __user in the struct will only
cause lots of warnings in the drivers. But the flip side of that is that you
need to add __force casts here.

drivers/media/v4l2-core/v4l2-compat-ioctl32.c:337:26: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:337:30: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:338:31: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:338:49: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:343:21: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:346:21: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:349:35: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:349:46: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:352:35: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:352:54: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:363:26: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:363:32: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:364:31: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:364:51: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:371:35: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:371:56: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:376:35: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:376:48: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:430:30: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:433:48: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:433:56: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:501:24: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:507:48: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:507:56: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:565:18: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:670:22: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:680:29: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:692:55: warning: incorrect type in initializer (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:773:18: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:786:30: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:786:44: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:674:37: warning: dereference of noderef expression
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:718:37: warning: dereference of noderef expression

Signed-off-by: Hans Verkuil <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2:
 - Drop changes in {get,put}_v4l2_edid32()
 - Adjust filename, context]
Signed-off-by: Ben Hutchings <>
4 years agoof: fdt: Fix return with value in void function
Ben Hutchings [Mon, 26 Feb 2018 16:32:31 +0000 (16:32 +0000)]
of: fdt: Fix return with value in void function

Commit 49e67dd17649 "of: fdt: add missing allocation-failure check"
added a "return NULL" statement in __unflatten_device_tree().  When
applied to the 3.2-stable branch, this introduced a compiler warning
(not an error!) because the function returns void here.

Signed-off-by: Ben Hutchings <>
4 years agom32r: fix 'fix breakage from "m32r: use generic ptrace_resume code"' fallout
Geert Uytterhoeven [Tue, 17 Jul 2012 22:48:00 +0000 (15:48 -0700)]
m32r: fix 'fix breakage from "m32r: use generic ptrace_resume code"' fallout

commit a6b202979661eb32646048aeaad7be7b70c2cd22 upstream.

Commit acdc0d5ef9dd ('m32r: fix breakage from "m32r: use generic
ptrace_resume code"') tried to fix a problem in commit e34112e3966fc
("m32r: use generic ptrace_resume code") by returning values in a
function returning void, causing:

  arch/m32r/kernel/ptrace.c: In function 'user_enable_single_step':
  arch/m32r/kernel/ptrace.c:594:3: warning: 'return' with a value, in function returning void [enabled by default]
  arch/m32r/kernel/ptrace.c:598:3: warning: 'return' with a value, in function returning void [enabled by default]
  arch/m32r/kernel/ptrace.c:601:3: warning: 'return' with a value, in function returning void [enabled by default]
  arch/m32r/kernel/ptrace.c:604:2: warning: 'return' with a value, in function returning void [enabled by default]

Remove the unneeded return values.

Signed-off-by: Geert Uytterhoeven <>
Cc: Al Viro <>
Cc: Christoph Hellwig <>
Cc: Hirokazu Takata <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
4 years agohrtimer: Reset hrtimer cpu base proper on CPU hotplug
Thomas Gleixner [Fri, 26 Jan 2018 13:54:32 +0000 (14:54 +0100)]
hrtimer: Reset hrtimer cpu base proper on CPU hotplug

commit d5421ea43d30701e03cadc56a38854c36a8b4433 upstream.

The hrtimer interrupt code contains a hang detection and mitigation
mechanism, which prevents that a long delayed hrtimer interrupt causes a
continous retriggering of interrupts which prevent the system from making
progress. If a hang is detected then the timer hardware is programmed with
a certain delay into the future and a flag is set in the hrtimer cpu base
which prevents newly enqueued timers from reprogramming the timer hardware
prior to the chosen delay. The subsequent hrtimer interrupt after the delay
clears the flag and resumes normal operation.

If such a hang happens in the last hrtimer interrupt before a CPU is
unplugged then the hang_detected flag is set and stays that way when the
CPU is plugged in again. At that point the timer hardware is not armed and
it cannot be armed because the hang_detected flag is still active, so
nothing clears that flag. As a consequence the CPU does not receive hrtimer
interrupts and no timers expire on that CPU which results in RCU stalls and
other malfunctions.

Clear the flag along with some other less critical members of the hrtimer
cpu base to ensure starting from a clean state when a CPU is plugged in.

Thanks to Paul, Sebastian and Anna-Maria for their help to get down to the
root cause of that hard to reproduce heisenbug. Once understood it's
trivial and certainly justifies a brown paperbag.

Fixes: 41d2e4949377 ("hrtimer: Tune hrtimer_interrupt hang logic")
Reported-by: Paul E. McKenney <>
Signed-off-by: Thomas Gleixner <>
Cc: Peter Zijlstra <>
Cc: Sebastian Sewior <>
Cc: Anna-Maria Gleixner <>
[bwh: Backported to 3.2:
 - There's no next_timer field to reset
 - Adjust filename, context]
Signed-off-by: Ben Hutchings <>
4 years agodccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state
Alexey Kodanev [Fri, 26 Jan 2018 12:14:16 +0000 (15:14 +0300)]
dccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state

commit dd5684ecae3bd8e44b644f50e2c12c7e57fdfef5 upstream.

ccid2_hc_tx_rto_expire() timer callback always restarts the timer
again and can run indefinitely (unless it is stopped outside), and after
commit 120e9dabaf55 ("dccp: defer ccid_hc_tx_delete() at dismantle time"),
which moved ccid_hc_tx_delete() (also includes sk_stop_timer()) from
dccp_destroy_sock() to sk_destruct(), this started to happen quite often.
The timer prevents releasing the socket, as a result, sk_destruct() won't
be called.

Found with LTP/dccp_ipsec tests running on the bonding device,
which later couldn't be unloaded after the tests were completed:

  unregister_netdevice: waiting for bond0 to become free. Usage count = 148

Fixes: 2a91aa396739 ("[DCCP] CCID2: Initial CCID2 (TCP-Like) implementation")
Signed-off-by: Alexey Kodanev <>
Reviewed-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
4 years agopppoe: take ->needed_headroom of lower device into account on xmit
Guillaume Nault [Mon, 22 Jan 2018 17:06:37 +0000 (18:06 +0100)]
pppoe: take ->needed_headroom of lower device into account on xmit

commit 02612bb05e51df8489db5e94d0cf8d1c81f87b0c upstream.

In pppoe_sendmsg(), reserving dev->hard_header_len bytes of headroom
was probably fine before the introduction of ->needed_headroom in
commit f5184d267c1a ("net: Allow netdevices to specify needed head/tailroom").

But now, virtual devices typically advertise the size of their overhead
in dev->needed_headroom, so we must also take it into account in
Allocation size of skb is also updated to take dev->needed_tailroom
into account and replace the arbitrary 32 bytes with the real size of
a PPPoE header.

This issue was discovered by syzbot, who connected a pppoe socket to a
gre device which had dev->header_ops->create == ipgre_header and
dev->hard_header_len == 0. Therefore, PPPoE didn't reserve any
headroom, and dev_hard_header() crashed when ipgre_header() tried to
prepend its header to skb->data.

skbuff: skb_under_panic: text:000000001d390b3a len:31 put:24
head:00000000d8ed776f data:000000008150e823 tail:0x7 end:0xc0 dev:gre0
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:104!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
    (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 3670 Comm: syzkaller801466 Not tainted
4.15.0-rc7-next-20180115+ #97
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:skb_panic+0x162/0x1f0 net/core/skbuff.c:100
RSP: 0018:ffff8801d9bd7840 EFLAGS: 00010282
RAX: 0000000000000083 RBX: ffff8801d4f083c0 RCX: 0000000000000000
RDX: 0000000000000083 RSI: 1ffff1003b37ae92 RDI: ffffed003b37aefc
RBP: ffff8801d9bd78a8 R08: 1ffff1003b37ae8a R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff86200de0
R13: ffffffff84a981ad R14: 0000000000000018 R15: ffff8801d2d34180
FS:  00000000019c4880(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000208bc000 CR3: 00000001d9111001 CR4: 00000000001606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
  skb_under_panic net/core/skbuff.c:114 [inline]
  skb_push+0xce/0xf0 net/core/skbuff.c:1714
  ipgre_header+0x6d/0x4e0 net/ipv4/ip_gre.c:879
  dev_hard_header include/linux/netdevice.h:2723 [inline]
  pppoe_sendmsg+0x58e/0x8b0 drivers/net/ppp/pppoe.c:890
  sock_sendmsg_nosec net/socket.c:630 [inline]
  sock_sendmsg+0xca/0x110 net/socket.c:640
  sock_write_iter+0x31a/0x5d0 net/socket.c:909
  call_write_iter include/linux/fs.h:1775 [inline]
  do_iter_readv_writev+0x525/0x7f0 fs/read_write.c:653
  do_iter_write+0x154/0x540 fs/read_write.c:932
  vfs_writev+0x18a/0x340 fs/read_write.c:977
  do_writev+0xfc/0x2a0 fs/read_write.c:1012
  SYSC_writev fs/read_write.c:1085 [inline]
  SyS_writev+0x27/0x30 fs/read_write.c:1082

Admittedly PPPoE shouldn't be allowed to run on non Ethernet-like
interfaces, but reserving space for ->needed_headroom is a more
fundamental issue that needs to be addressed first.

Same problem exists for __pppoe_xmit(), which also needs to take
dev->needed_headroom into account in skb_cow_head().

Fixes: f5184d267c1a ("net: Allow netdevices to specify needed head/tailroom")
Signed-off-by: Guillaume Nault <>
Reviewed-by: Xin Long <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
4 years agoInput: trackpoint - force 3 buttons if 0 button is reported
Aaron Ma [Fri, 19 Jan 2018 17:43:39 +0000 (09:43 -0800)]
Input: trackpoint - force 3 buttons if 0 button is reported

commit f5d07b9e98022d50720e38aa936fc11c67868ece upstream.

Lenovo introduced trackpoint compatible sticks with minimum PS/2 commands.
They supposed to reply with 0x02, 0x03, or 0x04 in response to the
"Read Extended ID" command, so we would know not to try certain extended
commands. Unfortunately even some trackpoints reporting the original IBM
version (0x01 firmware 0x0e) now respond with incorrect data to the "Get
Extended Buttons" command:

 thinkpad_acpi: ThinkPad BIOS R0DET87W (1.87 ), EC unknown
 thinkpad_acpi: Lenovo ThinkPad E470, model 20H1004SGE

 psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 0/0

Since there are no trackpoints without buttons, let's assume the trackpoint
has 3 buttons when we get 0 response to the extended buttons query.

Signed-off-by: Aaron Ma <>
Signed-off-by: Dmitry Torokhov <>
[bwh: Backported to 3.2: use printk() instead of psmouse_warn()]
Signed-off-by: Ben Hutchings <>
4 years agoInput: trackpoint - assume 3 buttons when buttons detection fails
Oscar Campos [Wed, 19 Jul 2017 00:20:36 +0000 (17:20 -0700)]
Input: trackpoint - assume 3 buttons when buttons detection fails

commit 293b915fd9bebf33cdc906516fb28d54649a25ac upstream.

Trackpoint buttons detection fails on ThinkPad 570 and 470 series,
this makes the middle button of the trackpoint to not being recogized.
As I don't believe there is any trackpoint with less than 3 buttons this
patch just assumes three buttons when the extended button information
read fails.

Signed-off-by: Oscar Campos <>
Acked-by: Peter Hutterer <>
Signed-off-by: Dmitry Torokhov <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agonet: igmp: fix source address check for IGMPv3 reports
Felix Fietkau [Fri, 19 Jan 2018 10:50:46 +0000 (11:50 +0100)]
net: igmp: fix source address check for IGMPv3 reports

commit ad23b750933ea7bf962678972a286c78a8fa36aa upstream.

Commit "net: igmp: Use correct source address on IGMPv3 reports"
introduced a check to validate the source address of locally generated
IGMPv3 packets.
Instead of checking the local interface address directly, it uses
inet_ifa_match(fl4->saddr, ifa), which checks if the address is on the
local subnet (or equal to the point-to-point address if used).

This breaks for point-to-point interfaces, so check against
ifa->ifa_local directly.

Cc: Kevin Cernekee <>
Fixes: a46182b00290 ("net: igmp: Use correct source address on IGMPv3 reports")
Reported-by: Sebastian Gottschall <>
Signed-off-by: Felix Fietkau <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
4 years agonet: igmp: Use correct source address on IGMPv3 reports
Kevin Cernekee [Mon, 11 Dec 2017 19:13:45 +0000 (11:13 -0800)]
net: igmp: Use correct source address on IGMPv3 reports

commit a46182b00290839fa3fa159d54fd3237bd8669f0 upstream.

Closing a multicast socket after the final IPv4 address is deleted
from an interface can generate a membership report that uses the
source IP from a different interface.  The following test script, run
from an isolated netns, reproduces the issue:


    ip link add dummy0 type dummy
    ip link add dummy1 type dummy
    ip link set dummy0 up
    ip link set dummy1 up
    ip addr add dev dummy0
    ip addr add dev dummy1

    tcpdump -U -i dummy0 &
    socat EXEC:"sleep 2" \
        UDP4-DATAGRAM:,ip-add-membership= &

    sleep 1
    ip addr del dev dummy0
    sleep 5
    kill %tcpdump

RFC 3376 specifies that the report must be sent with a valid IP source
address from the destination subnet, or from address  Add an
extra check to make sure this is the case.

Signed-off-by: Kevin Cernekee <>
Reviewed-by: Andrew Lunn <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agox86/mce: Make machine check speculation protected
Thomas Gleixner [Thu, 18 Jan 2018 15:28:26 +0000 (16:28 +0100)]
x86/mce: Make machine check speculation protected

commit 6f41c34d69eb005e7848716bbcafc979b35037d5 upstream.

The machine check idtentry uses an indirect branch directly from the low
level code. This evades the speculation protection.

Replace it by a direct call into C code and issue the indirect call there
so the compiler can apply the proper speculation protection.

Signed-off-by: Thomas Gleixner <>
Reviewed-by:Borislav Petkov <>
Reviewed-by: David Woodhouse <>
Niced-by: Peter Zijlstra <>
[bwh: Backported to 3.2:
 - Don't use dotraplinkage
 - Adjust filename, context]
Signed-off-by: Ben Hutchings <>
4 years agocfg80211: fix station info handling bugs
Johannes Berg [Tue, 16 Jan 2018 22:20:22 +0000 (23:20 +0100)]
cfg80211: fix station info handling bugs

commit 5762d7d3eda25c03cc2d9d45227be3f5ab6bec9e upstream.

Fix two places where the structure isn't initialized to zero,
and thus can't be filled properly by the driver.

Fixes: 4a4b8169501b ("cfg80211: Accept multiple RSSI thresholds for CQM")
Fixes: 9930380f0bd8 ("cfg80211: implement IWRATE")
Signed-off-by: Johannes Berg <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Drop change in cfg80211_cqm_rssi_update()
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agocan: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
Marc Kleine-Budde [Tue, 16 Jan 2018 18:30:14 +0000 (19:30 +0100)]
can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once

commit 8cb68751c115d176ec851ca56ecfbb411568c9e8 upstream.

If an invalid CAN frame is received, from a driver or from a tun
interface, a Kernel warning is generated.

This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.

Suggested-by: Dmitry Vyukov <>
Acked-by: Oliver Hartkopp <>
Signed-off-by: Marc Kleine-Budde <>
[bwh: Backported to 3.2:
 - Keep using the 'drop' label, as it has another user
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agonet: fs_enet: do not call phy_stop() in interrupts
Christophe Leroy [Tue, 16 Jan 2018 09:33:05 +0000 (10:33 +0100)]
net: fs_enet: do not call phy_stop() in interrupts

commit f8b39039cbf2a15f2b8c9f081e1cbd5dee00aaf5 upstream.

In case of TX timeout, fs_timeout() calls phy_stop(), which
triggers the following BUG_ON() as we are in interrupt.

[92708.199889] kernel BUG at drivers/net/phy/mdio_bus.c:482!
[92708.204985] Oops: Exception in kernel mode, sig: 5 [#1]
[92708.210119] PREEMPT
[92708.212107] CMPC885
[92708.214216] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G        W       4.9.61 #39
[92708.223227] task: c60f0a40 task.stack: c6104000
[92708.227697] NIP: c02a84bc LR: c02a947c CTR: c02a93d8
[92708.232614] REGS: c6105c70 TRAP: 0700   Tainted: G        W        (4.9.61)
[92708.241193] MSR: 00021032 <ME,IR,DR,RI>[92708.244818]   CR: 24000822  XER: 20000000
GPR00: c02a947c c6105d20 c60f0a40 c62b4c00 00000005 0000001f c069aad8 0001a688
GPR08: 00000007 00000100 c02a93d8 00000000 000005fc 00000000 c6213240 c06338e4
GPR16: 00000001 c06330d4 c0633094 00000000 c0680000 c6104000 c6104000 00000000
GPR24: 00000200 00000000 ffffffff 00000004 00000078 00009032 00000000 c62b4c00
NIP [c02a84bc] mdiobus_read+0x20/0x74
[92708.281517] LR [c02a947c] kszphy_config_intr+0xa4/0xc4
[92708.286547] Call Trace:
[92708.288980] [c6105d20] [c6104000] 0xc6104000 (unreliable)
[92708.294339] [c6105d40] [c02a947c] kszphy_config_intr+0xa4/0xc4
[92708.300098] [c6105d50] [c02a5330] phy_stop+0x60/0x9c
[92708.305007] [c6105d60] [c02c84d0] fs_timeout+0xdc/0x110
[92708.310197] [c6105d80] [c035cd48] dev_watchdog+0x268/0x2a0
[92708.315593] [c6105db0] [c0060288] call_timer_fn+0x34/0x17c
[92708.321014] [c6105dd0] [c00605f0] run_timer_softirq+0x21c/0x2e4
[92708.326887] [c6105e50] [c001e19c] __do_softirq+0xf4/0x2f4
[92708.332207] [c6105eb0] [c001e3c8] run_ksoftirqd+0x2c/0x40
[92708.337560] [c6105ec0] [c003b420] smpboot_thread_fn+0x1f0/0x258
[92708.343405] [c6105ef0] [c003745c] kthread+0xbc/0xd0
[92708.348217] [c6105f40] [c000c400] ret_from_kernel_thread+0x5c/0x64
[92708.354275] Instruction dump:
[92708.357207] 7c0803a6 bbc10018 38210020 4e800020 7c0802a6 9421ffe0 54290024 bfc10018
[92708.364865] 90010024 7c7f1b78 81290008 552902ee <0f0900003bc3002c 7fc3f378 90810008
[92708.372711] ---[ end trace 42b05441616fafd7 ]---

This patch moves fs_timeout() actions into an async worker.

Fixes: commit 48257c4f168e5 ("Add fs_enet ethernet network driver, for several embedded platforms")
Signed-off-by: Christophe Leroy <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoi2c: core-smbus: prevent stack corruption on read I2C_BLOCK_DATA
Jeremy Compostella [Wed, 15 Nov 2017 19:31:44 +0000 (12:31 -0700)]
i2c: core-smbus: prevent stack corruption on read I2C_BLOCK_DATA

commit 89c6efa61f5709327ecfa24bff18e57a4e80c7fa upstream.

On a I2C_SMBUS_I2C_BLOCK_DATA read request, if data->block[0] is
greater than I2C_SMBUS_BLOCK_MAX + 1, the underlying I2C driver writes
data out of the msgbuf1 array boundary.

It is possible from a user application to run into that issue by
calling the I2C_SMBUS ioctl with data.block[0] greater than

This patch makes the code compliant with
Documentation/i2c/dev-interface by raising an error when the requested
size is larger than 32 bytes.

Call Trace:
 [<ffffffff8139f695>] dump_stack+0x67/0x92
 [<ffffffff811802a4>] panic+0xc5/0x1eb
 [<ffffffff810ecb5f>] ? vprintk_default+0x1f/0x30
 [<ffffffff817456d3>] ? i2cdev_ioctl_smbus+0x303/0x320
 [<ffffffff8109a68b>] __stack_chk_fail+0x1b/0x20
 [<ffffffff817456d3>] i2cdev_ioctl_smbus+0x303/0x320
 [<ffffffff81745aed>] i2cdev_ioctl+0x4d/0x1e0
 [<ffffffff811f761a>] do_vfs_ioctl+0x2ba/0x490
 [<ffffffff81336e43>] ? security_file_ioctl+0x43/0x60
 [<ffffffff811f7869>] SyS_ioctl+0x79/0x90
 [<ffffffff81a22e97>] entry_SYSCALL_64_fastpath+0x12/0x6a

Signed-off-by: Jeremy Compostella <>
Signed-off-by: Wolfram Sang <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
4 years agodm btree: fix serious bug in btree_split_beneath()
Joe Thornber [Wed, 20 Dec 2017 09:56:06 +0000 (09:56 +0000)]
dm btree: fix serious bug in btree_split_beneath()

commit bc68d0a43560e950850fc69b58f0f8254b28f6d6 upstream.

When inserting a new key/value pair into a btree we walk down the spine of
btree nodes performing the following 2 operations:

  i) space for a new entry
  ii) adjusting the first key entry if the new key is lower than any in the node.

If the _root_ node is full, the function btree_split_beneath() allocates 2 new
nodes, and redistibutes the root nodes entries between them.  The root node is
left with 2 entries corresponding to the 2 new nodes.

btree_split_beneath() then adjusts the spine to point to one of the two new
children.  This means the first key is never adjusted if the new key was lower,
ie. operation (ii) gets missed out.  This can result in the new key being
'lost' for a period; until another low valued key is inserted that will uncover

This is a serious bug, and quite hard to make trigger in normal use.  A
reproducing test case ("thin create devices-in-reverse-order") is
available as part of the thin-provision-tools project:

Fix the issue by changing btree_split_beneath() so it no longer adjusts
the spine.  Instead it unlocks both the new nodes, and lets the main
loop in btree_insert_raw() relock the appropriate one and make any
neccessary adjustments.

Reported-by: Monty Pavel <>
Signed-off-by: Joe Thornber <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Ben Hutchings <>
4 years agodm thin metadata: THIN_MAX_CONCURRENT_LOCKS should be 6
Dennis Yang [Tue, 12 Dec 2017 10:21:40 +0000 (18:21 +0800)]
dm thin metadata: THIN_MAX_CONCURRENT_LOCKS should be 6

commit 490ae017f54e55bde382d45ea24bddfb6d1a0aaf upstream.

For btree removal, there is a corner case that a single thread
could takes 6 locks which is more than THIN_MAX_CONCURRENT_LOCKS(5)
and leads to deadlock.

A btree removal might eventually call
rebalance_children()->rebalance3() to rebalance entries of three
neighbor child nodes when shadow_spine has already acquired two
write locks. In rebalance3(), it tries to shadow and acquire the
write locks of all three child nodes. However, shadowing a child
node requires acquiring a read lock of the original child node and
a write lock of the new block. Although the read lock will be
released after block shadowing, shadowing the third child node
in rebalance3() could still take the sixth lock.
(2 write locks for shadow_spine +
 2 write locks for the first two child nodes's shadow +
 1 write lock for the last child node's shadow +
 1 read lock for the last child node)

Signed-off-by: Dennis Yang <>
Acked-by: Joe Thornber <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Ben Hutchings <>
4 years agodm thin metadata: introduce THIN_MAX_CONCURRENT_LOCKS
Joe Thornber [Fri, 27 Jul 2012 14:07:58 +0000 (15:07 +0100)]
dm thin metadata: introduce THIN_MAX_CONCURRENT_LOCKS

commit 8c971178a788c70e8d6db5c3a813de1a1f54e5b7 upstream.

Introduce THIN_MAX_CONCURRENT_LOCKS into dm-thin-metadata to
give a name to an otherwise "magic" number.

Signed-off-by: Joe Thornber <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Alasdair G Kergon <>
Signed-off-by: Ben Hutchings <>
4 years agoKVM/x86: Fix wrong macro references of X86_CR0_PG_BIT and X86_CR4_PAE_BIT in kvm_vali...
Tianyu Lan [Tue, 16 Jan 2018 09:34:07 +0000 (17:34 +0800)]
KVM/x86: Fix wrong macro references of X86_CR0_PG_BIT and X86_CR4_PAE_BIT in kvm_valid_sregs()

commit 37b95951c58fdf08dc10afa9d02066ed9f176fb5 upstream.

kvm_valid_sregs() should use X86_CR0_PG and X86_CR4_PAE to check bit
status rather than X86_CR0_PG_BIT and X86_CR4_PAE_BIT. This patch is
to fix it.

Fixes: f29810335965a(KVM/x86: Check input paging mode when cs.l is set)
Reported-by: Jeremi Piotrowski <>
Cc: Paolo Bonzini <>
Cc: Radim Krčmář <>
Signed-off-by: Tianyu Lan <>
Signed-off-by: Radim Krčmář <>
Signed-off-by: Ben Hutchings <>
4 years agoKVM/x86: Check input paging mode when cs.l is set
Lan Tianyu [Thu, 14 Dec 2017 08:01:52 +0000 (03:01 -0500)]
KVM/x86: Check input paging mode when cs.l is set

commit f29810335965ac1f7bcb501ee2af5f039f792416 upstream.

Reported by syzkaller:
    WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 x86_emulate_insn+0x557/0x15f0 [kvm]
    Modules linked in: kvm_intel kvm [last unloaded: kvm]
    CPU: 0 PID: 27962 Comm: syz-executor Tainted: G    B   W        4.15.0-rc2-next-20171208+ #32
    Hardware name: Intel Corporation S1200SP/S1200SP, BIOS S1200SP.86B.01.03.0006.040720161253 04/07/2016
    RIP: 0010:x86_emulate_insn+0x557/0x15f0 [kvm]
    RSP: 0018:ffff8807234476d0 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff88072d0237a0 RCX: ffffffffa0065c4d
    RDX: 1ffff100e5a046f9 RSI: 0000000000000003 RDI: ffff88072d0237c8
    RBP: ffff880723447728 R08: ffff88072d020000 R09: ffffffffa008d240
    R10: 0000000000000002 R11: ffffed00e7d87db3 R12: ffff88072d0237c8
    R13: ffff88072d023870 R14: ffff88072d0238c2 R15: ffffffffa008d080
    FS:  00007f8a68666700(0000) GS:ffff880802200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000002009506c CR3: 000000071fec4005 CR4: 00000000003626f0
    Call Trace:
     x86_emulate_instruction+0x3bc/0xb70 [kvm]
     ? reexecute_instruction.part.162+0x130/0x130 [kvm]
     vmx_handle_exit+0x46d/0x14f0 [kvm_intel]
     ? trace_event_raw_event_kvm_entry+0xe7/0x150 [kvm]
     ? handle_vmfunc+0x2f0/0x2f0 [kvm_intel]
     ? wait_lapic_expire+0x25/0x270 [kvm]
     vcpu_enter_guest+0x720/0x1ef0 [kvm]

When CS.L is set, vcpu should run in the 64 bit paging mode.
Current kvm set_sregs function doesn't have such check when
userspace inputs sreg values. This will lead unexpected behavior.
This patch is to add checks for CS.L, EFER.LME, EFER.LMA and
CR4.PAE when get SREG inputs from userspace in order to avoid
unexpected behavior.

Suggested-by: Paolo Bonzini <>
Reported-by: Dmitry Vyukov <>
Cc: Paolo Bonzini <>
Cc: Radim Krčmář <>
Cc: Dmitry Vyukov <>
Cc: Jim Mattson <>
Signed-off-by: Tianyu Lan <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agosctp: do not allow the v4 socket to bind a v4mapped v6 address
Xin Long [Mon, 15 Jan 2018 09:02:00 +0000 (17:02 +0800)]
sctp: do not allow the v4 socket to bind a v4mapped v6 address

commit c5006b8aa74599ce19104b31d322d2ea9ff887cc upstream.

The check in sctp_sockaddr_af is not robust enough to forbid binding a
v4mapped v6 addr on a v4 socket.

The worse thing is that v4 socket's bind_verify would not convert this
v4mapped v6 addr to a v4 addr. syzbot even reported a crash as the v4
socket bound a v6 addr.

This patch is to fix it by doing the common sa.sa_family check first,
then AF_INET check for v4mapped v6 addrs.

Fixes: 7dab83de50c7 ("sctp: Support ipv6only AF_INET6 sockets.")
Acked-by: Neil Horman <>
Signed-off-by: Xin Long <>
Acked-by: Marcelo Ricardo Leitner <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
4 years agosctp: return error if the asoc has been peeled off in sctp_wait_for_sndbuf
Xin Long [Mon, 15 Jan 2018 09:01:36 +0000 (17:01 +0800)]
sctp: return error if the asoc has been peeled off in sctp_wait_for_sndbuf

commit a0ff660058b88d12625a783ce9e5c1371c87951f upstream.

After commit cea0cc80a677 ("sctp: use the right sk after waking up from
wait_buf sleep"), it may change to lock another sk if the asoc has been
peeled off in sctp_wait_for_sndbuf.

However, the asoc's new sk could be already closed elsewhere, as it's in
the sendmsg context of the old sk that can't avoid the new sk's closing.
If the sk's last one refcnt is held by this asoc, later on after putting
this asoc, the new sk will be freed, while under it's own lock.

This patch is to revert that commit, but fix the old issue by returning
error under the old sk's lock.

Fixes: cea0cc80a677 ("sctp: use the right sk after waking up from wait_buf sleep")
Signed-off-by: Xin Long <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agosctp: use the right sk after waking up from wait_buf sleep
Xin Long [Wed, 15 Nov 2017 08:57:26 +0000 (16:57 +0800)]
sctp: use the right sk after waking up from wait_buf sleep

commit cea0cc80a6777beb6eb643d4ad53690e1ad1d4ff upstream.

Commit dfcb9f4f99f1 ("sctp: deny peeloff operation on asocs with threads
sleeping on it") fixed the race between peeloff and wait sndbuf by
checking waitqueue_active(&asoc->wait) in sctp_do_peeloff().

But it actually doesn't work, as even if waitqueue_active returns false
the waiting sndbuf thread may still not yet hold sk lock. After asoc is
peeled off, sk is not asoc-> any more, then to hold the old sk
lock couldn't make assoc safe to access.

This patch is to fix this by changing to hold the new sk lock if sk is
not asoc->, meanwhile, also set the sk in sctp_sendmsg with the
new sk.

With this fix, there is no more race between peeloff and waitbuf, the
check 'waitqueue_active' in sctp_do_peeloff can be removed.

Thanks Marcelo and Neil for making this clear.

  fix it by changing to lock the new sock instead of adding a flag in asoc.

Suggested-by: Neil Horman <>
Signed-off-by: Xin Long <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agocfg80211: check dev_set_name() return value
Johannes Berg [Mon, 15 Jan 2018 08:58:27 +0000 (09:58 +0100)]
cfg80211: check dev_set_name() return value

commit 59b179b48ce2a6076448a44531242ac2b3f6cef2 upstream.

syzbot reported a warning from rfkill_alloc(), and after a while
I think that the reason is that it was doing fault injection and
the dev_set_name() failed, leaving the name NULL, and we didn't
check the return value and got to rfkill_alloc() with a NULL name.
Since we really don't want a NULL name, we ought to check the
return value.

Fixes: fb28ad35906a ("net: struct device - replace bus_id with dev_name(), dev_set_name()")
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agofutex: Prevent overflow by strengthen input validation
Li Jinyue [Thu, 14 Dec 2017 09:04:54 +0000 (17:04 +0800)]
futex: Prevent overflow by strengthen input validation

commit fbe0e839d1e22d88810f3ee3e2f1479be4c0aa4a upstream.

UBSAN reports signed integer overflow in kernel/futex.c:

 UBSAN: Undefined behaviour in kernel/futex.c:2041:18
 signed integer overflow:
 0 - -2147483648 cannot be represented in type 'int'

Add a sanity check to catch negative values of nr_wake and nr_requeue.

Signed-off-by: Li Jinyue <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoKVM: x86: Add memory barrier on vmcs field lookup
Andrew Honig [Wed, 10 Jan 2018 18:12:03 +0000 (10:12 -0800)]
KVM: x86: Add memory barrier on vmcs field lookup

commit 75f139aaf896d6fdeec2e468ddfa4b2fe469bf40 upstream.

This adds a memory barrier when performing a lookup into
the vmcs_field_to_offset_table.  This is related to

Signed-off-by: Andrew Honig <>
Reviewed-by: Jim Mattson <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoALSA: pcm: Remove yet superfluous WARN_ON()
Takashi Iwai [Wed, 10 Jan 2018 22:48:05 +0000 (23:48 +0100)]
ALSA: pcm: Remove yet superfluous WARN_ON()

commit 23b19b7b50fe1867da8d431eea9cd3e4b6328c2c upstream.

muldiv32() contains a snd_BUG_ON() (which is morphed as WARN_ON() with
debug option) for checking the case of 0 / 0.  This would be helpful
if this happens only as a logical error; however, since the hw refine
is performed with any data set provided by user, the inconsistent
values that can trigger such a condition might be passed easily.
Actually, syzbot caught this by passing some zero'ed old hw_params

So, having snd_BUG_ON() there is simply superfluous and rather
harmful to give unnecessary confusions.  Let's get rid of it.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
4 years ago8021q: fix a memory leak for VLAN 0 device
Cong Wang [Tue, 9 Jan 2018 21:40:41 +0000 (13:40 -0800)]
8021q: fix a memory leak for VLAN 0 device

commit 78bbb15f2239bc8e663aa20bbe1987c91a0b75f6 upstream.

A vlan device with vid 0 is allow to creat by not able to be fully
cleaned up by unregister_vlan_dev() which checks for vlan_id!=0.

Also, VLAN 0 is probably not a valid number and it is kinda
"reserved" for HW accelerating devices, but it is probably too
late to reject it from creation even if makes sense. Instead,
just remove the check in unregister_vlan_dev().

Reported-by: Dmitry Vyukov <>
Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)")
Cc: Vlad Yasevich <>
Cc: Ben Hutchings <>
Signed-off-by: Cong Wang <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: The vlan driver didn't leak memory itself, but might
 cause underlying drivers to leak resources for VID 0.  Keep the check for
 hardware acceleration.]
Signed-off-by: Ben Hutchings <>
4 years agoSolutionEngine771x: add Ether TSU resource
Sergei Shtylyov [Sat, 6 Jan 2018 18:53:27 +0000 (21:53 +0300)]
SolutionEngine771x: add Ether TSU resource

commit f9a531d6731d74f1e24298d9641c2dc1fef2631b upstream.

After the  Ether platform data is fixed, the driver probe() method would
still fail since the 'struct sh_eth_cpu_data' corresponding  to SH771x
indicates the presence of TSU but the memory resource for it is absent.
Add the missing TSU resource  to both Ether devices and fix the harmless
off-by-one error in the main memory resources, while at it...

Fixes: 4986b996882d ("net: sh_eth: remove the SH_TSU_ADDR")
Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
4 years agoSolutionEngine771x: fix Ether platform data
Sergei Shtylyov [Sat, 6 Jan 2018 18:53:26 +0000 (21:53 +0300)]
SolutionEngine771x: fix Ether platform data

commit 195e2addbce09e5afbc766efc1e6567c9ce840d3 upstream.

The 'sh_eth' driver's probe() method would fail  on the SolutionEngine7710
board and crash on SolutionEngine7712 board  as the platform code is
hopelessly behind the driver's platform data --  it passes the PHY address
instead of 'struct sh_eth_plat_data *'; pass the latter to the driver in
order to fix the bug...

Fixes: 71557a37adb5 ("[netdrvr] sh_eth: Add SH7619 support")
Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
4 years agonet: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()
Nicolai Stange [Mon, 8 Jan 2018 14:54:44 +0000 (15:54 +0100)]
net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()

commit 20b50d79974ea3192e8c3ab7faf4e536e5f14d8f upstream.

Commit 8f659a03a0ba ("net: ipv4: fix for a race condition in
raw_sendmsg") fixed the issue of possibly inconsistent ->hdrincl handling
due to concurrent updates by reading this bit-field member into a local
variable and using the thus stabilized value in subsequent tests.

However, aforementioned commit also adds the (correct) comment that

  /* hdrincl should be READ_ONCE(inet->hdrincl)
   * but READ_ONCE() doesn't work with bit fields

because as it stands, the compiler is free to shortcut or even eliminate
the local variable at its will.

Note that I have not seen anything like this happening in reality and thus,
the concern is a theoretical one.

However, in order to be on the safe side, emulate a READ_ONCE() on the
bit-field by doing it on the local 'hdrincl' variable itself:

int hdrincl = inet->hdrincl;
hdrincl = READ_ONCE(hdrincl);

This breaks the chain in the sense that the compiler is not allowed
to replace subsequent reads from hdrincl with reloads from inet->hdrincl.

Fixes: 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg")
Signed-off-by: Nicolai Stange <>
Reviewed-by: Stefano Brivio <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: use ACCESS_ONCE()]
Signed-off-by: Ben Hutchings <>
4 years agoUSB: fix usbmon BUG trigger
Pete Zaitcev [Mon, 8 Jan 2018 21:46:41 +0000 (15:46 -0600)]
USB: fix usbmon BUG trigger

commit 46eb14a6e1585d99c1b9f58d0e7389082a5f466b upstream.

Automated tests triggered this by opening usbmon and accessing the
mmap while simultaneously resizing the buffers. This bug was with
us since 2006, because typically applications only size the buffers
once and thus avoid racing. Reported by Kirill A. Shutemov.

Reported-by: <>
Signed-off-by: Pete Zaitcev <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
4 years agoALSA: pcm: Allow aborting mutex lock at OSS read/write loops
Takashi Iwai [Mon, 8 Jan 2018 13:03:53 +0000 (14:03 +0100)]
ALSA: pcm: Allow aborting mutex lock at OSS read/write loops

commit 900498a34a3ac9c611e9b425094c8106bdd7dc1c upstream.

PCM OSS read/write loops keep taking the mutex lock for the whole
read/write, and this might take very long when the exceptionally high
amount of data is given.  Also, since it invokes with mutex_lock(),
the concurrent read/write becomes unbreakable.

This patch tries to address these issues by replacing mutex_lock()
with mutex_lock_interruptible(), and also splits / re-takes the lock
at each read/write period chunk, so that it can switch the context
more finely if requested.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
4 years agoALSA: pcm: Abort properly at pending signal in OSS read/write loops
Takashi Iwai [Mon, 8 Jan 2018 12:58:31 +0000 (13:58 +0100)]
ALSA: pcm: Abort properly at pending signal in OSS read/write loops

commit 29159a4ed7044c52e3e2cf1a9fb55cec4745c60b upstream.

The loops for read and write in PCM OSS emulation have no proper check
of pending signals, and they keep processing even after user tries to
break.  This results in a very long delay, often seen as RCU stall
when a huge unprocessed bytes remain queued.  The bug could be easily
triggered by syzkaller.

As a simple workaround, this patch adds the proper check of pending
signals and aborts the loop appropriately.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
4 years agoxfrm: Return error on unknown encap_type in init_state
Herbert Xu [Fri, 5 Jan 2018 11:12:32 +0000 (22:12 +1100)]
xfrm: Return error on unknown encap_type in init_state

commit bcfd09f7837f5240c30fd2f52ee7293516641faa upstream.

Currently esp will happily create an xfrm state with an unknown
encap type for IPv4, without setting the necessary state parameters.
This patch fixes it by returning -EINVAL.

There is a similar problem in IPv6 where if the mode is unknown
we will skip initialisation while returning zero.  However, this
is harmless as the mode has already been checked further up the
stack.  This patch removes this anomaly by aligning the IPv6
behaviour with IPv4 and treating unknown modes (which cannot
actually happen) as transport mode.

Fixes: 38320c70d282 ("[IPSEC]: Use crypto_aead and authenc in ESP")
Signed-off-by: Herbert Xu <>
Signed-off-by: Steffen Klassert <>
Signed-off-by: Ben Hutchings <>
4 years agoALSA: aloop: Fix racy hw constraints adjustment
Takashi Iwai [Thu, 4 Jan 2018 16:38:54 +0000 (17:38 +0100)]
ALSA: aloop: Fix racy hw constraints adjustment

commit 898dfe4687f460ba337a01c11549f87269a13fa2 upstream.

The aloop driver tries to update the hw constraints of the connected
target on the cable of the opened PCM substream.  This is done by
adding the extra hw constraints rules referring to the substream
runtime->hw fields, while the other substream may update the runtime
hw of another side on the fly.

This is, however, racy and may result in the inconsistent values when
both PCM streams perform the prepare concurrently.  One of the reason
is that it overwrites the other's runtime->hw field; which is not only
racy but also broken when it's called before the open of another side
finishes.  And, since the reference to runtime->hw isn't protected,
the concurrent write may give the partial value update and become

This patch is an attempt to fix and clean up:
- The prepare doesn't change the runtime->hw of other side any longer,
  but only update the cable->hw that is referred commonly.
- The extra rules refer to the loopback_pcm object instead of the
  runtime->hw.  The actual hw is deduced from cable->hw.
- The extra rules take the cable_lock to protect against the race.

Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
4 years agoALSA: aloop: Fix inconsistent format due to incomplete rule
Takashi Iwai [Fri, 5 Jan 2018 15:15:33 +0000 (16:15 +0100)]
ALSA: aloop: Fix inconsistent format due to incomplete rule

commit b088b53e20c7d09b5ab84c5688e609f478e5c417 upstream.

The extra hw constraint rule for the formats the aloop driver
introduced has a slight flaw, where it doesn't return a positive value
when the mask got changed.  It came from the fact that it's basically
a copy&paste from snd_hw_constraint_mask64().  The original code is
supposed to be a single-shot and it modifies the mask bits only once
and never after, while what we need for aloop is the dynamic hw rule
that limits the mask bits.

This difference results in the inconsistent state, as the hw_refine
doesn't apply the dependencies fully.  The worse and surprisingly
result is that it causes a crash in OSS emulation when multiple
full-duplex reads/writes are performed concurrently (I leave why it
triggers Oops to readers as a homework).

For fixing this, replace a few open-codes with the standard
snd_mask_*() macros.

Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
4 years agoALSA: aloop: Release cable upon open error path
Takashi Iwai [Fri, 5 Jan 2018 15:09:47 +0000 (16:09 +0100)]
ALSA: aloop: Release cable upon open error path

commit 9685347aa0a5c2869058ca6ab79fd8e93084a67f upstream.

The aloop runtime object and its assignment in the cable are left even
when opening a substream fails.  This doesn't mean any memory leak,
but it still keeps the invalid pointer that may be referred by the
another side of the cable spontaneously, which is a potential Oops

Clean up the cable assignment and the empty cable upon the error path

Fixes: 597603d615d2 ("ALSA: introduce the snd-aloop module for the PCM loopback")
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
4 years agoxfrm: Use __skb_queue_tail in xfrm_trans_queue
Herbert Xu [Thu, 4 Jan 2018 11:25:07 +0000 (22:25 +1100)]
xfrm: Use __skb_queue_tail in xfrm_trans_queue

commit d16b46e4fd8bc6063624605f25b8c0835bb1fbe3 upstream.

We do not need locking in xfrm_trans_queue because it is designed
to use per-CPU buffers.  However, the original code incorrectly
used skb_queue_tail which takes the lock.  This patch switches
it to __skb_queue_tail instead.

Reported-and-tested-by: Artem Savkov <>
Fixes: acf568ee859f ("xfrm: Reinject transport-mode packets...")
Signed-off-by: Herbert Xu <>
Signed-off-by: Steffen Klassert <>
Signed-off-by: Ben Hutchings <>
4 years agocrypto: algapi - fix NULL dereference in crypto_remove_spawns()
Eric Biggers [Fri, 29 Dec 2017 20:30:19 +0000 (14:30 -0600)]
crypto: algapi - fix NULL dereference in crypto_remove_spawns()

commit 9a00674213a3f00394f4e3221b88f2d21fc05789 upstream.

syzkaller triggered a NULL pointer dereference in crypto_remove_spawns()
via a program that repeatedly and concurrently requests AEADs
"authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)"
through AF_ALG, where the hashes are requested as "untested"
(CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this
causes the template to be instantiated for every request).

Although AF_ALG users really shouldn't be able to request an "untested"
algorithm, the NULL pointer dereference is actually caused by a
longstanding race condition where crypto_remove_spawns() can encounter
an instance which has had spawn(s) "grabbed" but hasn't yet been
registered, resulting in ->cra_users still being NULL.

We probably should properly initialize ->cra_users earlier, but that
would require updating many templates individually.  For now just fix
the bug in a simple way that can easily be backported: make
crypto_remove_spawns() treat a NULL ->cra_users list as empty.

Reported-by: syzbot <>
Signed-off-by: Eric Biggers <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
4 years agomm/mprotect: add a cond_resched() inside change_pmd_range()
Anshuman Khandual [Fri, 5 Jan 2018 00:17:52 +0000 (16:17 -0800)]
mm/mprotect: add a cond_resched() inside change_pmd_range()

commit 4991c09c7c812dba13ea9be79a68b4565bb1fa4e upstream.

While testing on a large CPU system, detected the following RCU stall
many times over the span of the workload.  This problem is solved by
adding a cond_resched() in the change_pmd_range() function.

  INFO: rcu_sched detected stalls on CPUs/tasks:
   154-....: (670 ticks this GP) idle=022/140000000000000/0 softirq=2825/2825 fqs=612
   (detected by 955, t=6002 jiffies, g=4486, c=4485, q=90864)
  Sending NMI from CPU 955 to CPUs 154:
  NMI backtrace for cpu 154
  CPU: 154 PID: 147071 Comm: workload Not tainted 4.15.0-rc3+ #3
  NIP:  c0000000000b3f64 LR: c0000000000b33d4 CTR: 000000000000aa18
  REGS: 00000000a4b0fb44 TRAP: 0501   Not tainted  (4.15.0-rc3+)
  MSR:  8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 22422082  XER: 00000000
  CFAR: 00000000006cf8f0 SOFTE: 1
  GPR00: 0010000000000000 c00003ef9b1cb8c0 c0000000010cc600 0000000000000000
  GPR04: 8e0000018c32b200 40017b3858fd6e00 8e0000018c32b208 40017b3858fd6e00
  GPR08: 8e0000018c32b210 40017b3858fd6e00 8e0000018c32b218 40017b3858fd6e00
  GPR12: ffffffffffffffff c00000000fb25100
  NIP [c0000000000b3f64] plpar_hcall9+0x44/0x7c
  LR [c0000000000b33d4] pSeries_lpar_flush_hash_range+0x384/0x420
  Call Trace:
  Instruction dump:
  60000000 f8810028 7ca42b78 7cc53378 7ce63b78 7d074378 7d284b78 7d495378
  e9410060 e9610068 e9810070 44000022 <7d806378e9810028 f88c0000 f8ac0008

Signed-off-by: Anshuman Khandual <>
Suggested-by: Nicholas Piggin <>
Acked-by: Michal Hocko <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agousbip: remove kernel addresses from usb device and urb debug msgs
Shuah Khan [Sat, 23 Dec 2017 00:00:06 +0000 (17:00 -0700)]
usbip: remove kernel addresses from usb device and urb debug msgs

commit e1346fd87c71a1f61de1fe476ec8df1425ac931c upstream.

usbip_dump_usb_device() and usbip_dump_urb() print kernel addresses.
Remove kernel addresses from usb device and urb debug msgs and improve
the message content.

Instead of printing parent device and bus addresses, print parent device
and bus names.

Signed-off-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
4 years agoALSA: pcm: Add missing error checks in OSS emulation plugin builder
Takashi Iwai [Thu, 4 Jan 2018 15:39:27 +0000 (16:39 +0100)]
ALSA: pcm: Add missing error checks in OSS emulation plugin builder

commit 6708913750344a900f2e73bfe4a4d6dbbce4fe8d upstream.

In the OSS emulation plugin builder where the frame size is parsed in
the plugin chain, some places miss the possible errors returned from
the plugin src_ or dst_frames callback.

This patch papers over such places.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
4 years agoUSB: serial: cp210x: add new device ID ELV ALC 8xxx
Christian Holl [Wed, 3 Jan 2018 18:53:02 +0000 (19:53 +0100)]
USB: serial: cp210x: add new device ID ELV ALC 8xxx

commit d14ac576d10f865970bb1324d337e5e24d79aaf4 upstream.

This adds the ELV ALC 8xxx Battery Charging device
to the list of USB IDs of drivers/usb/serial/cp210x.c

Signed-off-by: Christian Holl <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
4 years agommc: s3mci: mark debug_regs[] as static
Arnd Bergmann [Wed, 3 Jan 2018 22:49:18 +0000 (23:49 +0100)]
mmc: s3mci: mark debug_regs[] as static

commit 2bd7b4aacdb6efa5ccd4749c365c171b884791d2 upstream.

The global array clashes with a newly added symbol of the same name:

drivers/staging/ccree/cc_debugfs.o:(.data+0x0): multiple definition of `debug_regs'
drivers/mmc/host/s3cmci.o:(.data+0x70): first defined here

We should fix both, this one addresses the s3cmci driver by removing
the symbol from the global namespace. While at it, this separates
the declaration from the type definition and makes the variable const.

Fixes: 9bdd203b4dc8 ("s3cmci: add debugfs support for examining driver and hardware state")
Fixes: b3ec9a6736f2 ("staging: ccree: staging: ccree: replace sysfs by debugfs interface")
Signed-off-by: Arnd Bergmann <>
Signed-off-by: Ulf Hansson <>
Signed-off-by: Ben Hutchings <>
4 years agoe1000e: Fix e1000_check_for_copper_link_ich8lan return value.
Benjamin Poirier [Mon, 11 Dec 2017 07:26:40 +0000 (16:26 +0900)]
e1000e: Fix e1000_check_for_copper_link_ich8lan return value.

commit 4110e02eb45ea447ec6f5459c9934de0a273fb91 upstream.

e1000e_check_for_copper_link() and e1000_check_for_copper_link_ich8lan()
are the two functions that may be assigned to mac.ops.check_for_link when
phy.media_type == e1000_media_type_copper. Commit 19110cfbb34d ("e1000e:
Separate signaling for link check/link up") changed the meaning of the
return value of check_for_link for copper media but only adjusted the first
function. This patch adjusts the second function likewise.

Reported-by: Christian Hesse <>
Reported-by: Gabriel C <>
Fixes: 19110cfbb34d ("e1000e: Separate signaling for link check/link up")
Signed-off-by: Benjamin Poirier <>
Tested-by: Aaron Brown <>
Tested-by: Christian Hesse <>
Signed-off-by: Jeff Kirsher <>
[bwh: Backported to 3.2: e1000_check_for_copper_link() has a single return
 statement for success and error cases, so set ret_val in the link-up
 case instead of changing that statement.]
Signed-off-by: Ben Hutchings <>
4 years agoe1000e: Separate signaling for link check/link up
Benjamin Poirier [Fri, 21 Jul 2017 18:36:26 +0000 (11:36 -0700)]
e1000e: Separate signaling for link check/link up

commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 upstream.

Lennart reported the following race condition:

\ e1000_watchdog_task
    \ e1000e_has_link
        \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link
            /* link is up */
            mac->get_link_status = false;

                            /* interrupt */
                            \ e1000_msix_other
                                hw->mac.get_link_status = true;

        link_active = !hw->mac.get_link_status
        /* link_active is false, wrongly */

This problem arises because the single flag get_link_status is used to
signal two different states: link status needs checking and link status is

Avoid the problem by using the return value of .check_for_link to signal
the link status to e1000e_has_link().

Reported-by: Lennart Sorensen <>
Signed-off-by: Benjamin Poirier <>
Tested-by: Aaron Brown <>
Signed-off-by: Jeff Kirsher <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
4 years agoALSA: pcm: Remove incorrect snd_BUG_ON() usages
Takashi Iwai [Mon, 1 Jan 2018 08:50:50 +0000 (09:50 +0100)]
ALSA: pcm: Remove incorrect snd_BUG_ON() usages

commit fe08f34d066f4404934a509b6806db1a4f700c86 upstream.

syzkaller triggered kernel warnings through PCM OSS emulation at
closing a stream:
  WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635
  snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635
  Call Trace:
   snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457
   snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969
   snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128
   snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638
   snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431
   __fput+0x327/0x7e0 fs/file_table.c:210

This happens while it tries to open and set up the aloop device
concurrently.  The warning above (invoked from snd_BUG_ON() macro) is
to detect the unexpected logical error where snd_pcm_hw_refine() call
shouldn't fail.  The theory is true for the case where the hw_params
config rules are static.  But for an aloop device, the hw_params rule
condition does vary dynamically depending on the connected target;
when another device is opened and changes the parameters, the device
connected in another side is also affected, and it caused the error
from snd_pcm_hw_refine().

That is, the simplest "solution" for this is to remove the incorrect
assumption of static rules, and treat such an error as a normal error
path.  As there are a couple of other places using snd_BUG_ON()
incorrectly, this patch removes these spurious snd_BUG_ON() calls.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
4 years agofscache: Fix the default for fscache_maybe_release_page()
David Howells [Tue, 2 Jan 2018 10:02:19 +0000 (10:02 +0000)]
fscache: Fix the default for fscache_maybe_release_page()

commit 98801506552593c9b8ac11021b0cdad12cab4f6b upstream.

Fix the default for fscache_maybe_release_page() for when the cookie isn't
valid or the page isn't cached.  It mustn't return false as that indicates
the page cannot yet be freed.

The problem with the default is that if, say, there's no cache, but a
network filesystem's pages are using up almost all the available memory, a
system can OOM because the filesystem ->releasepage() op will not allow
them to be released as fscache_maybe_release_page() incorrectly prevents

This can be tested by writing a sequence of 512MiB files to an AFS mount.
It does not affect NFS or CIFS because both of those wrap the call in a
check of PG_fscache and it shouldn't bother Ceph as that only has
PG_private set whilst writeback is in progress.  This might be an issue for
9P, however.

Note that the pages aren't entirely stuck.  Removing a file or unmounting
will clear things because that uses ->invalidatepage() instead.

Fixes: 201a15428bd5 ("FS-Cache: Handle pages pending storage that get evicted under OOM conditions")
Reported-by: Marc Dionne <>
Signed-off-by: David Howells <>
Reviewed-by: Jeff Layton <>
Acked-by: Al Viro <>
Tested-by: Marc Dionne <>
Signed-off-by: Ben Hutchings <>
4 years agoUSB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ
Diego Elio Pettenò [Fri, 29 Dec 2017 09:54:25 +0000 (09:54 +0000)]
USB: serial: cp210x: add IDs for LifeScan OneTouch Verio IQ

commit 4307413256ac1e09b8f53e8715af3df9e49beec3 upstream.

Add IDs for the OneTouch Verio IQ that comes with an embedded
USB-to-serial converter.

Signed-off-by: Diego Elio Pettenò <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
4 years agokbuild: add '-fno-stack-check' to kernel build options
Linus Torvalds [Sat, 30 Dec 2017 01:34:43 +0000 (17:34 -0800)]
kbuild: add '-fno-stack-check' to kernel build options

commit 3ce120b16cc548472f80cf8644f90eda958cf1b6 upstream.

It appears that hardened gentoo enables "-fstack-check" by default for

That doesn't work _at_all_ for the kernel, because the kernel stack
doesn't act like a user stack at all: it's much smaller, and it doesn't
auto-expand on use.  So the extra "probe one page below the stack" code
generated by -fstack-check just breaks the kernel in horrible ways,
causing infinite double faults etc.

[ I have to say, that the particular code gcc generates looks very
  stupid even for user space where it works, but that's a separate
  issue.  ]

Reported-and-tested-by: Alexander Tsoy <>
Reported-and-tested-by: Toralf Förster <>
Cc: Dave Hansen <>
Cc: Jiri Kosina <>
Cc: Andy Lutomirski <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
4 years agoaf_key: fix buffer overread in parse_exthdrs()
Eric Biggers [Sat, 30 Dec 2017 00:15:23 +0000 (18:15 -0600)]
af_key: fix buffer overread in parse_exthdrs()

commit 4e765b4972af7b07adcb1feb16e7a525ce1f6b28 upstream.

If a message sent to a PF_KEY socket ended with an incomplete extension
header (fewer than 4 bytes remaining), then parse_exthdrs() read past
the end of the message, into uninitialized memory.  Fix it by returning
-EINVAL in this case.


#include <linux/pfkeyv2.h>
#include <sys/socket.h>
#include <unistd.h>

int main()
int sock = socket(PF_KEY, SOCK_RAW, PF_KEY_V2);
char buf[17] = { 0 };
struct sadb_msg *msg = (void *)buf;

msg->sadb_msg_version = PF_KEY_V2;
msg->sadb_msg_type = SADB_DELETE;
msg->sadb_msg_len = 2;

write(sock, buf, 17);

Signed-off-by: Eric Biggers <>
Signed-off-by: Steffen Klassert <>
Signed-off-by: Ben Hutchings <>
4 years agoaf_key: fix buffer overread in verify_address_len()
Eric Biggers [Sat, 30 Dec 2017 00:13:05 +0000 (18:13 -0600)]
af_key: fix buffer overread in verify_address_len()

commit 06b335cb51af018d5feeff5dd4fd53847ddb675a upstream.

If a message sent to a PF_KEY socket ended with one of the extensions
that takes a 'struct sadb_address' but there were not enough bytes
remaining in the message for the ->sa_family member of the 'struct
sockaddr' which is supposed to follow, then verify_address_len() read
past the end of the message, into uninitialized memory.  Fix it by
returning -EINVAL in this case.

This bug was found using syzkaller with KMSAN.


#include <linux/pfkeyv2.h>
#include <sys/socket.h>
#include <unistd.h>

int main()
int sock = socket(PF_KEY, SOCK_RAW, PF_KEY_V2);
char buf[24] = { 0 };
struct sadb_msg *msg = (void *)buf;
struct sadb_address *addr = (void *)(msg + 1);

msg->sadb_msg_version = PF_KEY_V2;
msg->sadb_msg_type = SADB_DELETE;
msg->sadb_msg_len = 3;
addr->sadb_address_len = 1;
addr->sadb_address_exttype = SADB_EXT_ADDRESS_SRC;

write(sock, buf, 24);

Reported-by: Alexander Potapenko <>
Signed-off-by: Eric Biggers <>
Signed-off-by: Steffen Klassert <>
Signed-off-by: Ben Hutchings <>
4 years agoinclude/stddef.h: Move offsetofend() from vfio.h to a generic kernel header
Denys Vlasenko [Mon, 9 Mar 2015 14:52:17 +0000 (15:52 +0100)]
include/stddef.h: Move offsetofend() from vfio.h to a generic kernel header

commit 3876488444e71238e287459c39d7692b6f718c3e upstream.

Suggested by Andy.

Suggested-by: Andy Lutomirski <>
Signed-off-by: Denys Vlasenko <>
Acked-by: Linus Torvalds <>
Cc: Alexei Starovoitov <>
Cc: Borislav Petkov <>
Cc: Frederic Weisbecker <>
Cc: H. Peter Anvin <>
Cc: Kees Cook <>
Cc: Oleg Nesterov <>
Cc: Steven Rostedt <>
Cc: Will Drewry <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2:
 - There is no definition in vfio.h to move
 - Put the definition inside the #ifdef __KERNEL__ section]
Signed-off-by: Ben Hutchings <>
4 years agoring-buffer: Mask out the info bits when returning buffer page length
Steven Rostedt (VMware) [Sat, 23 Dec 2017 01:32:35 +0000 (20:32 -0500)]
ring-buffer: Mask out the info bits when returning buffer page length

commit 45d8b80c2ac5d21cd1e2954431fb676bc2b1e099 upstream.

Two info bits were added to the "commit" part of the ring buffer data page
when returned to be consumed. This was to inform the user space readers that
events have been missed, and that the count may be stored at the end of the

What wasn't handled, was the splice code that actually called a function to
return the length of the data in order to zero out the rest of the page
before sending it up to user space. These data bits were returned with the
length making the value negative, and that negative value was not checked.
It was compared to PAGE_SIZE, and only used if the size was less than
PAGE_SIZE. Luckily PAGE_SIZE is unsigned long which made the compare an
unsigned compare, meaning the negative size value did not end up causing a
large portion of memory to be randomly zeroed out.

Fixes: 66a8cb95ed040 ("ring-buffer: Add place holder recording of dropped events")
Signed-off-by: Steven Rostedt (VMware) <>
Signed-off-by: Ben Hutchings <>
4 years agoUSB: serial: ftdi_sio: add id for Airbus DS P8GR
Max Schulze [Wed, 20 Dec 2017 19:47:44 +0000 (20:47 +0100)]
USB: serial: ftdi_sio: add id for Airbus DS P8GR

commit c6a36ad383559a60a249aa6016cebf3cb8b6c485 upstream.

Add AIRBUS_DS_P8GR device IDs to ftdi_sio driver.

Signed-off-by: Max Schulze <>
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agocrypto: n2 - cure use after free
Jan Engelhardt [Tue, 19 Dec 2017 18:09:07 +0000 (19:09 +0100)]
crypto: n2 - cure use after free

commit 203f45003a3d03eea8fa28d74cfc74c354416fdb upstream.

queue_cache_init is first called for the Control Word Queue
(n2_crypto_probe). At that time, queue_cache[0] is NULL and a new
kmem_cache will be allocated. If the subsequent n2_register_algs call
fails, the kmem_cache will be released in queue_cache_destroy, but
queue_cache_init[0] is not set back to NULL.

So when the Module Arithmetic Unit gets probed next (n2_mau_probe),
queue_cache_init will not allocate a kmem_cache again, but leave it
as its bogus value, causing a BUG() to trigger when queue_cache[0] is
eventually passed to kmem_cache_zalloc:

n2_crypto: Found N2CP at /virtual-devices@100/n2cp@7
n2_crypto: Registered NCS HVAPI version 2.0
called queue_cache_init
n2_crypto: md5 alg registration failed
n2cp f028687c: /virtual-devices@100/n2cp@7: Unable to register algorithms.
called queue_cache_destroy
n2cp: probe of f028687c failed with error -22
n2_crypto: Found NCP at /virtual-devices@100/ncp@6
n2_crypto: Registered NCS HVAPI version 2.0
called queue_cache_init
kernel BUG at mm/slab.c:2993!
Call Trace:
 [0000000000604488] kmem_cache_alloc+0x1a8/0x1e0
                  (inlined) kmem_cache_zalloc
                  (inlined) new_queue
                  (inlined) spu_queue_setup
                  (inlined) handle_exec_unit
 [0000000010c61eb4] spu_mdesc_scan+0x1f4/0x460 [n2_crypto]
 [0000000010c62b80] n2_mau_probe+0x100/0x220 [n2_crypto]
 [000000000084b174] platform_drv_probe+0x34/0xc0

Signed-off-by: Jan Engelhardt <>
Acked-by: David S. Miller <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
4 years agoiw_cxgb4: Only validate the MSN for successful completions
Steve Wise [Mon, 18 Dec 2017 21:10:00 +0000 (13:10 -0800)]
iw_cxgb4: Only validate the MSN for successful completions

commit f55688c45442bc863f40ad678c638785b26cdce6 upstream.

If the RECV CQE is in error, ignore the MSN check.  This was causing
recvs that were flushed into the sw cq to be completed with the wrong
status (BAD_MSN instead of FLUSHED).

Signed-off-by: Steve Wise <>
Signed-off-by: Jason Gunthorpe <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agon_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)
Linus Torvalds [Thu, 21 Dec 2017 01:57:06 +0000 (17:57 -0800)]
n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)

commit 966031f340185eddd05affcf72b740549f056348 upstream.

We added support for EXTPROC back in 2010 in commit 26df6d13406d ("tty:
Add EXTPROC support for LINEMODE") and the intent was to allow it to
override some (all?) ICANON behavior.  Quoting from that original commit

         There is a new bit in the termios local flag word, EXTPROC.
         When this bit is set, several aspects of the terminal driver
         are disabled.  Input line editing, character echo, and mapping
         of signals are all disabled.  This allows the telnetd to turn
         off these functions when in linemode, but still keep track of
         what state the user wants the terminal to be in.

but the problem turns out that "several aspects of the terminal driver
are disabled" is a bit ambiguous, and you can really confuse the n_tty
layer by setting EXTPROC and then causing some of the ICANON invariants
to no longer be maintained.

This fixes at least one such case (TIOCINQ) becoming unhappy because of
the confusion over whether ICANON really means ICANON when EXTPROC is set.

This basically makes TIOCINQ match the case of read: if EXTPROC is set,
we ignore ICANON.  Also, make sure to reset the ICANON state ie EXTPROC
changes, not just if ICANON changes.

Fixes: 26df6d13406d ("tty: Add EXTPROC support for LINEMODE")
Reported-by: Tetsuo Handa <>
Reported-by: syzkaller <>
Cc: Jiri Slaby <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agousb: Add device quirk for Logitech HD Pro Webcam C925e
Dmitry Fleytman Dmitry Fleytman [Tue, 19 Dec 2017 04:02:04 +0000 (06:02 +0200)]
usb: Add device quirk for Logitech HD Pro Webcam C925e

commit 7f038d256c723dd390d2fca942919573995f4cfd upstream.

Commit e0429362ab15
("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
introduced quirk to workaround an issue with some Logitech webcams.

There is one more model that has the same issue - C925e, so applying
the same quirk as well.

See aforementioned commit message for detailed explanation of the problem.

Signed-off-by: Dmitry Fleytman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
4 years agousb: add RESET_RESUME for ELSA MicroLink 56K
Oliver Neukum [Tue, 12 Dec 2017 15:11:30 +0000 (16:11 +0100)]
usb: add RESET_RESUME for ELSA MicroLink 56K

commit b9096d9f15c142574ebebe8fbb137012bb9d99c2 upstream.

This modem needs this quirk to operate. It produces timeouts when
resumed without reset.

Signed-off-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
4 years agousbip: fix usbip bind writing random string after command in match_busid
Juan Zea [Fri, 15 Dec 2017 09:21:20 +0000 (10:21 +0100)]
usbip: fix usbip bind writing random string after command in match_busid

commit 544c4605acc5ae4afe7dd5914147947db182f2fb upstream.

usbip bind writes commands followed by random string when writing to
match_busid attribute in sysfs, caused by using full variable size
instead of string length.

Signed-off-by: Juan Zea <>
Acked-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agousbip: prevent leaking socket pointer address in messages
Shuah Khan [Fri, 15 Dec 2017 17:50:09 +0000 (10:50 -0700)]
usbip: prevent leaking socket pointer address in messages

commit 90120d15f4c397272aaf41077960a157fc4212bf upstream.

usbip driver is leaking socket pointer address in messages. Remove
the messages that aren't useful and print sockfd in the ones that
are useful for debugging.

Signed-off-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust filenames, context]
Signed-off-by: Ben Hutchings <>
4 years agousbip: stub: stop printing kernel pointer addresses in messages
Shuah Khan [Tue, 19 Dec 2017 00:23:37 +0000 (17:23 -0700)]
usbip: stub: stop printing kernel pointer addresses in messages

commit 248a22044366f588d46754c54dfe29ffe4f8b4df upstream.

Remove and/or change debug, info. and error messages to not print
kernel pointer addresses.

Signed-off-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Drop change in stub_complete()
 - Adjust filenames, context]
Signed-off-by: Ben Hutchings <>
4 years agousbip: vhci: stop printing kernel pointer addresses in messages
Shuah Khan [Tue, 19 Dec 2017 00:24:22 +0000 (17:24 -0700)]
usbip: vhci: stop printing kernel pointer addresses in messages

commit 8272d099d05f7ab2776cf56a2ab9f9443be18907 upstream.

Remove and/or change debug, info. and error messages to not print
kernel pointer addresses.

Signed-off-by: Shuah Khan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust filenames, context, indentation]
Signed-off-by: Ben Hutchings <>
4 years agostaging: usbip: removed dead code from receive function
Bart Westgeest [Mon, 19 Dec 2011 22:44:11 +0000 (17:44 -0500)]
staging: usbip: removed dead code from receive function

commit 5a08c5267e45fe936452051a8c126e8418984eb7 upstream.

The usbip_xmit function supported sending and receiving data, however
the sending part of the function was never used/executed. Renamed the
function to usbip_recv, and removed the unused code.

Signed-off-by: Bart Westgeest <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
4 years agoUSB: serial: option: adding support for YUGA CLM920-NC5
SZ Lin (林上智) [Tue, 19 Dec 2017 09:40:32 +0000 (17:40 +0800)]
USB: serial: option: adding support for YUGA CLM920-NC5

commit 3920bb713038810f25770e7545b79f204685c8f2 upstream.

This patch adds support for YUGA CLM920-NC5 PID 0x9625 USB modem to option

Interface layout:
1: ADB
3: AT

Signed-off-by: Taiyi Wu <>
Signed-off-by: SZ Lin (林上智) <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
4 years agoxfrm: Reinject transport-mode packets through tasklet
Herbert Xu [Fri, 15 Dec 2017 05:40:44 +0000 (16:40 +1100)]
xfrm: Reinject transport-mode packets through tasklet

commit acf568ee859f098279eadf551612f103afdacb4e upstream.

This is an old bugbear of mine:

By crafting special packets, it is possible to cause recursion
in our kernel when processing transport-mode packets at levels
that are only limited by packet size.

The easiest one is with DNAT, but an even worse one is where
UDP encapsulation is used in which case you just have to insert
an UDP encapsulation header in between each level of recursion.

This patch avoids this problem by reinjecting tranport-mode packets
through a tasklet.

Fixes: b05e106698d9 ("[IPV4/6]: Netfilter IPsec input hooks")
Signed-off-by: Herbert Xu <>
Signed-off-by: Steffen Klassert <>
[bwh: Backported to 3.2:
 - netfilter finish callbacks only receive an sk_buff pointer
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoALSA: usb-audio: Fix the missing ctl name suffix at parsing SU
Takashi Iwai [Mon, 18 Dec 2017 22:36:57 +0000 (23:36 +0100)]
ALSA: usb-audio: Fix the missing ctl name suffix at parsing SU

commit 5a15f289ee87eaf33f13f08a4909ec99d837ec5f upstream.

The commit 89b89d121ffc ("ALSA: usb-audio: Add check return value for
usb_string()") added the check of the return value from
snd_usb_copy_string_desc(), which is correct per se, but it introduced
a regression.  In the original code, either the "Clock Source",
"Playback Source" or "Capture Source" suffix is added after the
terminal string, while the commit changed it to add the suffix only
when get_term_name() is failing.  It ended up with an incorrect ctl
name like "PCM" instead of "PCM Capture Source".

Also, even the original code has a similar bug: when the ctl name is
generated from snd_usb_copy_string_desc() for the given iSelector, it
also doesn't put the suffix.

This patch addresses these issues: the suffix is added always when no
static mapping is found.  Also the patch tries to put more comments
and cleans up the if/else block for better readability in order to
avoid the same pitfall again.

Fixes: 89b89d121ffc ("ALSA: usb-audio: Add check return value for usb_string()")
Reported-and-tested-by: Mauro Santos <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
4 years agonet: bridge: fix early call to br_stp_change_bridge_id and plug newlink leaks
Nikolay Aleksandrov [Mon, 18 Dec 2017 15:35:09 +0000 (17:35 +0200)]
net: bridge: fix early call to br_stp_change_bridge_id and plug newlink leaks

commit 84aeb437ab98a2bce3d4b2111c79723aedfceb33 upstream.

The early call to br_stp_change_bridge_id in bridge's newlink can cause
a memory leak if an error occurs during the newlink because the fdb
entries are not cleaned up if a different lladdr was specified, also
another minor issue is that it generates fdb notifications with
ifindex = 0. Another unrelated memory leak is the bridge sysfs entries
which get added on NETDEV_REGISTER event, but are not cleaned up in the
newlink error path. To remove this special case the call to
br_stp_change_bridge_id is done after netdev register and we cleanup the
bridge on changelink error via br_dev_delete to plug all leaks.

This patch makes netlink bridge destruction on newlink error the same as
dellink and ioctl del which is necessary since at that point we have a
fully initialized bridge device.

To reproduce the issue:
$ ip l add br0 address 00:11:22:33:44:55 type bridge group_fwd_mask 1
RTNETLINK answers: Invalid argument

$ rmmod bridge
[ 1822.142525] =============================================================================
[ 1822.143640] BUG bridge_fdb_cache (Tainted: G           O    ): Objects remaining in bridge_fdb_cache on __kmem_cache_shutdown()
[ 1822.144821] -----------------------------------------------------------------------------

[ 1822.145990] Disabling lock debugging due to kernel taint
[ 1822.146732] INFO: Slab 0x0000000092a844b2 objects=32 used=2 fp=0x00000000fef011b0 flags=0x1ffff8000000100
[ 1822.147700] CPU: 2 PID: 13584 Comm: rmmod Tainted: G    B      O     4.15.0-rc2+ #87
[ 1822.148578] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 1822.150008] Call Trace:
[ 1822.150510]  dump_stack+0x78/0xa9
[ 1822.151156]  slab_err+0xb1/0xd3
[ 1822.151834]  ? __kmalloc+0x1bb/0x1ce
[ 1822.152546]  __kmem_cache_shutdown+0x151/0x28b
[ 1822.153395]  shutdown_cache+0x13/0x144
[ 1822.154126]  kmem_cache_destroy+0x1c0/0x1fb
[ 1822.154669]  SyS_delete_module+0x194/0x244
[ 1822.155199]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 1822.155773]  entry_SYSCALL_64_fastpath+0x23/0x9a
[ 1822.156343] RIP: 0033:0x7f929bd38b17
[ 1822.156859] RSP: 002b:00007ffd160e9a98 EFLAGS: 00000202 ORIG_RAX: 00000000000000b0
[ 1822.157728] RAX: ffffffffffffffda RBX: 00005578316ba090 RCX: 00007f929bd38b17
[ 1822.158422] RDX: 00007f929bd9ec60 RSI: 0000000000000800 RDI: 00005578316ba0f0
[ 1822.159114] RBP: 0000000000000003 R08: 00007f929bff5f20 R09: 00007ffd160e8a11
[ 1822.159808] R10: 00007ffd160e9860 R11: 0000000000000202 R12: 00007ffd160e8a80
[ 1822.160513] R13: 0000000000000000 R14: 0000000000000000 R15: 00005578316ba090
[ 1822.161278] INFO: Object 0x000000007645de29 @offset=0
[ 1822.161666] INFO: Object 0x00000000d5df2ab5 @offset=128

Fixes: 30313a3d5794 ("bridge: Handle IFLA_ADDRESS correctly when creating bridge device")
Fixes: 5b8d5429daa0 ("bridge: netlink: register netdevice before executing changelink")
Signed-off-by: Nikolay Aleksandrov <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: register_netdevice() was the last thing done in
 br_dev_newlink(), so no extra cleanup is needed]
Signed-off-by: Ben Hutchings <>
4 years agonet: phy: marvell: Limit 88m1101 autoneg errata to 88E1145 as well.
Zhao Qiang [Mon, 18 Dec 2017 02:26:43 +0000 (10:26 +0800)]
net: phy: marvell: Limit 88m1101 autoneg errata to 88E1145 as well.

commit c505873eaece2b4aefd07d339dc7e1400e0235ac upstream.

88E1145 also need this autoneg errata.

Fixes: f2899788353c ("net: phy: marvell: Limit errata to 88m1101")
Signed-off-by: Zhao Qiang <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
4 years agoACPI: APEI / ERST: Fix missing error handling in erst_reader()
Takashi Iwai [Thu, 14 Dec 2017 12:31:16 +0000 (13:31 +0100)]
ACPI: APEI / ERST: Fix missing error handling in erst_reader()

commit bb82e0b4a7e96494f0c1004ce50cec3d7b5fb3d1 upstream.

The commit f6f828513290 ("pstore: pass allocated memory region back to
caller") changed the check of the return value from erst_read() in
erst_reader() in the following way:

        if (len == -ENOENT)
                goto skip;
-       else if (len < 0) {
-               rc = -1;
+       else if (len < sizeof(*rcd)) {
+               rc = -EIO;
                goto out;

This introduced another bug: since the comparison with sizeof() is
cast to unsigned, a negative len value doesn't hit any longer.
As a result, when an error is returned from erst_read(), the code
falls through, and it may eventually lead to some weird thing like
memory corruption.

This patch adds the negative error value check more explicitly for
addressing the issue.

Fixes: f6f828513290 (pstore: pass allocated memory region back to caller)
Tested-by: Jerry Tang <>
Signed-off-by: Takashi Iwai <>
Acked-by: Kees Cook <>
Reviewed-by: Borislav Petkov <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
4 years agoPCI / PM: Force devices to D0 in pci_pm_thaw_noirq()
Rafael J. Wysocki [Fri, 15 Dec 2017 02:07:18 +0000 (03:07 +0100)]
PCI / PM: Force devices to D0 in pci_pm_thaw_noirq()

commit 5839ee7389e893a31e4e3c9cf17b50d14103c902 upstream.

It is incorrect to call pci_restore_state() for devices in low-power
states (D1-D3), as that involves the restoration of MSI setup which
requires MMIO to be operational and that is only the case in D0.

However, pci_pm_thaw_noirq() may do that if the driver's "freeze"
callbacks put the device into a low-power state, so fix it by making
it force devices into D0 via pci_set_power_state() instead of trying
to "update" their power state which is pointless.

Fixes: e60514bd4485 (PCI/PM: Restore the status of PCI devices across hibernation)
Reported-by: Thomas Gleixner <>
Reported-by: Maarten Lankhorst <>
Tested-by: Thomas Gleixner <>
Tested-by: Maarten Lankhorst <>
Signed-off-by: Rafael J. Wysocki <>
Acked-by: Bjorn Helgaas <>
Signed-off-by: Ben Hutchings <>
4 years agoparisc: Hide Diva-built-in serial aux and graphics card
Helge Deller [Tue, 12 Dec 2017 20:52:26 +0000 (21:52 +0100)]
parisc: Hide Diva-built-in serial aux and graphics card

commit bcf3f1752a622f1372d3252d0fea8855d89812e7 upstream.

Diva GSP card has built-in serial AUX port and ATI graphic card which simply
don't work and which both don't have external connectors.  User Guides even
mention that those devices shouldn't be used.
So, prevent that Linux drivers try to enable those devices.

Signed-off-by: Helge Deller <>
Signed-off-by: Ben Hutchings <>
4 years agoposix-timer: Properly check sigevent->sigev_notify
Thomas Gleixner [Fri, 15 Dec 2017 09:32:03 +0000 (10:32 +0100)]
posix-timer: Properly check sigevent->sigev_notify

commit cef31d9af908243421258f1df35a4a644604efbe upstream.

timer_create() specifies via sigevent->sigev_notify the signal delivery for
the new timer. The valid modes are SIGEV_NONE, SIGEV_SIGNAL, SIGEV_THREAD

The sanity check in good_sigevent() is only checking the valid combination
not set it accepts any random value.

This has no real effects on the posix timer and signal delivery code, but
it affects show_timer() which handles the output of /proc/$PID/timers. That
function uses a string array to pretty print sigev_notify. The access to
that array has no bound checks, so random sigev_notify cause access beyond
the array bounds.

Add proper checks for the valid notify modes and remove the SIGEV_THREAD_ID
masking from various code pathes as SIGEV_NONE can never be set in
combination with SIGEV_THREAD_ID.

Reported-by: Eric Biggers <>
Reported-by: Dmitry Vyukov <>
Reported-by: Alexey Dobriyan <>
Signed-off-by: Thomas Gleixner <>
Cc: John Stultz <>
[bwh: Backported to 3.2:
 - Add sig_none variable in common_timer_get(), added earlier upstream
 - Adjust filename, context]
Signed-off-by: Ben Hutchings <>
4 years agonfsd: auth: Fix gid sorting when rootsquash enabled
Ben Hutchings [Mon, 22 Jan 2018 20:11:06 +0000 (20:11 +0000)]
nfsd: auth: Fix gid sorting when rootsquash enabled

commit 1995266727fa8143897e89b55f5d3c79aa828420 upstream.

Commit bdcf0a423ea1 ("kernel: make groups_sort calling a responsibility
group_info allocators") appears to break nfsd rootsquash in a pretty
major way.

It adds a call to groups_sort() inside the loop that copies/squashes
gids, which means the valid gids are sorted along with the following
garbage.  The net result is that the highest numbered valid gids are
replaced with any lower-valued garbage gids, possibly including 0.

We should sort only once, after filling in all the gids.

Fixes: bdcf0a423ea1 ("kernel: make groups_sort calling a responsibility ...")
Signed-off-by: Ben Hutchings <>
Acked-by: J. Bruce Fields <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
4 years agokernel: make groups_sort calling a responsibility group_info allocators
Thiago Rafael Becker [Thu, 14 Dec 2017 23:33:12 +0000 (15:33 -0800)]
kernel: make groups_sort calling a responsibility group_info allocators

commit bdcf0a423ea1c40bbb40e7ee483b50fc8aa3d758 upstream.

In testing, we found that nfsd threads may call set_groups in parallel
for the same entry cached in auth.unix.gid, racing in the call of
groups_sort, corrupting the groups for that entry and leading to
permission denials for the client.

This patch:
 - Make groups_sort globally visible.
 - Move the call to groups_sort to the modifiers of group_info
 - Remove the call to groups_sort from set_groups

Signed-off-by: Thiago Rafael Becker <>
Reviewed-by: Matthew Wilcox <>
Reviewed-by: NeilBrown <>
Acked-by: "J. Bruce Fields" <>
Cc: Al Viro <>
Cc: Martin Schwidefsky <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2:
 - Drop change in gss_rpc_xdr.c
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoALSA: rawmidi: Avoid racy info ioctl via ctl device
Takashi Iwai [Thu, 14 Dec 2017 15:44:12 +0000 (16:44 +0100)]
ALSA: rawmidi: Avoid racy info ioctl via ctl device

commit c1cfd9025cc394fd137a01159d74335c5ac978ce upstream.

The rawmidi also allows to obtaining the information via ioctl of ctl
API.  It means that user can issue an ioctl to the rawmidi device even
when it's being removed as long as the control device is present.
Although the code has some protection via the global register_mutex,
its range is limited to the search of the corresponding rawmidi
object, and the mutex is already unlocked at accessing the rawmidi
object.  This may lead to a use-after-free.

For avoiding it, this patch widens the application of register_mutex
to the whole snd_rawmidi_info_select() function.  We have another
mutex per rawmidi object, but this operation isn't very hot path, so
it shouldn't matter from the performance POV.

Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoKVM: X86: Fix load RFLAGS w/o the fixed bit
Wanpeng Li [Thu, 7 Dec 2017 08:30:08 +0000 (00:30 -0800)]
KVM: X86: Fix load RFLAGS w/o the fixed bit

commit d73235d17ba63b53dc0e1051dbc10a1f1be91b71 upstream.

 *** Guest State ***
 CR0: actual=0x0000000000000030, shadow=0x0000000060000010, gh_mask=fffffffffffffff7
 CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffe871
 CR3 = 0x00000000fffbc000
 RSP = 0x0000000000000000  RIP = 0x0000000000000000
 RFLAGS=0x00000000         DR7 = 0x0000000000000400

The failed vmentry is triggered by the following testcase when ept=Y:

    #include <unistd.h>
    #include <sys/syscall.h>
    #include <string.h>
    #include <stdint.h>
    #include <linux/kvm.h>
    #include <fcntl.h>
    #include <sys/ioctl.h>

    long r[5];
    int main()
     r[2] = open("/dev/kvm", O_RDONLY);
     r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
     r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7);
     struct kvm_regs regs = {
     .rflags = 0,
     ioctl(r[4], KVM_SET_REGS, &regs);
     ioctl(r[4], KVM_RUN, 0);

X86 RFLAGS bit 1 is fixed set, userspace can simply clearing bit 1
of RFLAGS with KVM_SET_REGS ioctl which results in vmentry fails.
This patch fixes it by oring X86_EFLAGS_FIXED during ioctl.

Suggested-by: Jim Mattson <>
Reviewed-by: David Hildenbrand <>
Reviewed-by: Quan Xu <>
Cc: Paolo Bonzini <>
Cc: Radim Krčmář <>
Cc: Jim Mattson <>
Signed-off-by: Wanpeng Li <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2: use literal integer]
Signed-off-by: Ben Hutchings <>
4 years agotcp md5sig: Use skb's saddr when replying to an incoming segment
Christoph Paasch [Mon, 11 Dec 2017 08:05:46 +0000 (00:05 -0800)]
tcp md5sig: Use skb's saddr when replying to an incoming segment

commit 30791ac41927ebd3e75486f9504b6d2280463bf0 upstream.

The MD5-key that belongs to a connection is identified by the peer's
IP-address. When we are in tcp_v4(6)_reqsk_send_ack(), we are replying
to an incoming segment from tcp_check_req() that failed the seq-number

Thus, to find the correct key, we need to use the skb's saddr and not
the daddr.

This bug seems to have been there since quite a while, but probably got
unnoticed because the consequences are not catastrophic. We will call
tcp_v4_reqsk_send_ack only to send a challenge-ACK back to the peer,
thus the connection doesn't really fail.

Fixes: 9501f9722922 ("tcp md5sig: Let the caller pass appropriate key for tcp_v{4,6}_do_calc_md5_hash().")
Signed-off-by: Christoph Paasch <>
Reviewed-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoext4: fix crash when a directory's i_size is too small
Chandan Rajendra [Mon, 11 Dec 2017 20:00:57 +0000 (15:00 -0500)]
ext4: fix crash when a directory's i_size is too small

commit 9d5afec6b8bd46d6ed821aa1579634437f58ef1f upstream.

On a ppc64 machine, when mounting a fuzzed ext2 image (generated by
fsfuzzer) the following call trace is seen,

VFS: brelse: Trying to free free buffer
WARNING: CPU: 1 PID: 6913 at /root/repos/linux/fs/buffer.c:1165 .__brelse.part.6+0x24/0x40
.__brelse.part.6+0x20/0x40 (unreliable)

This happens because the directory that ext4_find_entry() looks up has
inode->i_size that is less than the block size of the filesystem. This
causes 'nblocks' to have a value of zero. ext4_bread_batch() ends up not
reading any of the directory file's blocks. This renders the entries in
bh_use[] array to continue to have garbage data. buffer_uptodate() on
bh_use[0] can then return a zero value upon which brelse() function is

This commit fixes the bug by returning -ENOENT when the directory file
has no associated blocks.

Reported-by: Abdul Haleem <>
Signed-off-by: Chandan Rajendra <>
Signed-off-by: Ben Hutchings <>
4 years agonet: ipv4: fix for a race condition in raw_sendmsg
Mohamed Ghannam [Sun, 10 Dec 2017 03:50:58 +0000 (03:50 +0000)]
net: ipv4: fix for a race condition in raw_sendmsg

commit 8f659a03a0ba9289b9aeb9b4470e6fb263d6f483 upstream.

inet->hdrincl is racy, and could lead to uninitialized stack pointer
usage, so its value should be read only once.

Fixes: c008ba5bdc9f ("ipv4: Avoid reading user iov twice after raw_probe_proto_opt")
Signed-off-by: Mohamed Ghannam <>
Reviewed-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - flowi4 flags don't depend on hdrincl
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoipv4: Avoid reading user iov twice after raw_probe_proto_opt
Herbert Xu [Fri, 7 Nov 2014 13:27:09 +0000 (21:27 +0800)]
ipv4: Avoid reading user iov twice after raw_probe_proto_opt

commit c008ba5bdc9fa830e1a349b20b0be5a137bdef7a upstream.

Ever since raw_probe_proto_opt was added it had the problem of
causing the user iov to be read twice, once during the probe for
the protocol header and once again in ip_append_data.

This is a potential security problem since it means that whatever
we're probing may be invalid.  This patch plugs the hole by
firstly advancing the iov so we don't read the same spot again,
and secondly saving what we read the first time around for use
by ip_append_data.

Signed-off-by: Herbert Xu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
4 years agoipv4: Use standard iovec primitive in raw_probe_proto_opt
Herbert Xu [Fri, 7 Nov 2014 13:27:08 +0000 (21:27 +0800)]
ipv4: Use standard iovec primitive in raw_probe_proto_opt

commit 32b5913a931fd753faf3d4e1124b2bc2edb364da upstream.

The function raw_probe_proto_opt tries to extract the first two
bytes from the user input in order to seed the IPsec lookup for
ICMP packets.  In doing so it's processing iovec by hand and
overcomplicating things.

This patch replaces the manual iovec processing with a call to

Signed-off-by: Herbert Xu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
4 years agoxhci: Don't add a virt_dev to the devs array before it's fully allocated
Mathias Nyman [Fri, 8 Dec 2017 16:10:05 +0000 (18:10 +0200)]
xhci: Don't add a virt_dev to the devs array before it's fully allocated

commit 5d9b70f7d52eb14bb37861c663bae44de9521c35 upstream.

Avoid null pointer dereference if some function is walking through the
devs array accessing members of a new virt_dev that is mid allocation.

Add the virt_dev to xhci->devs[i] _after_ the virt_device and all its
members are properly allocated.

issue found by KASAN: null-ptr-deref in xhci_find_slot_id_by_port

"Quick analysis suggests that xhci_alloc_virt_device() is not mutex
protected. If so, there is a time frame where xhci->devs[slot_id] is set
but not fully initialized. Specifically, xhci->devs[i]->udev can be NULL."

Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: There is an extra failure path, so we may need to
 free dev->eps[0].ring]
Signed-off-by: Ben Hutchings <>
4 years agoUSB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID
David Kozub [Tue, 5 Dec 2017 21:40:04 +0000 (22:40 +0100)]
USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID

commit 62354454625741f0569c2cbe45b2d192f8fd258e upstream.

There is another JMS567-based USB3 UAS enclosure (152d:0578) that fails
with the following error:

[sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[sda] tag#0 Sense Key : Illegal Request [current]
[sda] tag#0 Add. Sense: Invalid field in cdb

The issue occurs both with UAS (occasionally) and mass storage
(immediately after mounting a FS on a disk in the enclosure).

Enabling US_FL_BROKEN_FUA quirk solves this issue.

This patch adds an UNUSUAL_DEV with US_FL_BROKEN_FUA for the enclosure
for both UAS and mass storage.

Signed-off-by: David Kozub <>
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Drop uas change
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agocan: esd_usb2: cancel urb on -EPIPE and -EPROTO
Martin Kelly [Tue, 5 Dec 2017 19:15:48 +0000 (11:15 -0800)]
can: esd_usb2: cancel urb on -EPIPE and -EPROTO

commit 7a31ced3de06e9878e4f9c3abe8f87d9344d8144 upstream.

In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect

This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.

Signed-off-by: Martin Kelly <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Ben Hutchings <>
4 years agocan: ems_usb: cancel urb on -EPIPE and -EPROTO
Martin Kelly [Tue, 5 Dec 2017 19:15:47 +0000 (11:15 -0800)]
can: ems_usb: cancel urb on -EPIPE and -EPROTO

commit bd352e1adfe0d02d3ea7c8e3fb19183dc317e679 upstream.

In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect

This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.

Signed-off-by: Martin Kelly <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Ben Hutchings <>
4 years agobtrfs: Fix possible off-by-one in btrfs_search_path_in_tree
Nikolay Borisov [Fri, 1 Dec 2017 09:19:42 +0000 (11:19 +0200)]
btrfs: Fix possible off-by-one in btrfs_search_path_in_tree

commit c8bcbfbd239ed60a6562964b58034ac8a25f4c31 upstream.

The name char array passed to btrfs_search_path_in_tree is of size
BTRFS_INO_LOOKUP_PATH_MAX (4080). So the actual accessible char indexes
are in the range of [0, 4079]. Currently the code uses the define but this
represents an off-by-one.


Size of btrfs_ioctl_ino_lookup_args is 4096, so the new byte will be
written to extra space, not some padding that could be provided by the

btrfs-progs store the arguments on stack, but kernel does own copy of
the ioctl buffer and the off-by-one overwrite does not affect userspace,
but the ending 0 might be lost.

Kernel ioctl buffer is allocated dynamically so we're overwriting
somebody else's memory, and the ioctl is privileged if args.objectid is
not 256. Which is in most cases, but resolving a subvolume stored in
another directory will trigger that path.

Before this patch the buffer was one byte larger, but then the -1 was
not added.

Fixes: ac8e9819d71f907 ("Btrfs: add search and inode lookup ioctls")
Signed-off-by: Nikolay Borisov <>
Reviewed-by: David Sterba <>
[ added implications ]
Signed-off-by: David Sterba <>
Signed-off-by: Ben Hutchings <>
4 years agokdb: Fix handling of kallsyms_symbol_next() return value
Daniel Thompson [Mon, 2 Mar 2015 14:13:36 +0000 (14:13 +0000)]
kdb: Fix handling of kallsyms_symbol_next() return value

commit c07d35338081d107e57cf37572d8cc931a8e32e2 upstream.

kallsyms_symbol_next() returns a boolean (true on success). Currently
kdb_read() tests the return value with an inequality that
unconditionally evaluates to true.

This is fixed in the obvious way and, since the conditional branch is
supposed to be unreachable, we also add a WARN_ON().

Reported-by: Dan Carpenter <>
Signed-off-by: Daniel Thompson <>
Signed-off-by: Jason Wessel <>
Signed-off-by: Ben Hutchings <>
4 years agoALSA: pcm: prevent UAF in snd_pcm_info
Robb Glasser [Tue, 5 Dec 2017 17:16:55 +0000 (09:16 -0800)]
ALSA: pcm: prevent UAF in snd_pcm_info

commit 362bca57f5d78220f8b5907b875961af9436e229 upstream.

When the device descriptor is closed, the `substream->runtime` pointer
is freed. But another thread may be in the ioctl handler, case
SNDRV_CTL_IOCTL_PCM_INFO. This case calls snd_pcm_info_user() which
calls snd_pcm_info() which accesses the now freed `substream->runtime`.

Note: this fixes CVE-2017-0861

Signed-off-by: Robb Glasser <>
Signed-off-by: Nick Desaulniers <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
4 years agonet_sched: red: Avoid illegal values
Nogah Frankel [Mon, 4 Dec 2017 11:31:11 +0000 (13:31 +0200)]
net_sched: red: Avoid illegal values

commit 8afa10cbe281b10371fee5a87ab266e48d71a7f9 upstream.

Check the qmin & qmax values doesn't overflow for the given Wlog value.
Check that qmin <= qmax.

Fixes: a783474591f2 ("[PKT_SCHED]: Generic RED layer")
Signed-off-by: Nogah Frankel <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Drop changes in sch_sfq
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agos390: always save and restore all registers on context switch
Heiko Carstens [Mon, 20 Nov 2017 11:38:44 +0000 (12:38 +0100)]
s390: always save and restore all registers on context switch

commit fbbd7f1a51965b50dd12924841da0d478f3da71b upstream.

The switch_to() macro has an optimization to avoid saving and
restoring register contents that aren't needed for kernel threads.

There is however the possibility that a kernel thread execve's a user
space program. In such a case the execve'd process can partially see
the contents of the previous process, which shouldn't be allowed.

To avoid this, simply always save and restore register contents on
context switch.

Fixes: fdb6d070effba ("switch_to: dont restore/save access & fpu regs for kernel threads")
Signed-off-by: Heiko Carstens <>
Signed-off-by: Martin Schwidefsky <>
[bwh: Backported to 3.2:
 - The save/restore functions are different here
 - FP restore is non-lazy, so drop the comment about it being lazy
 - Adjust filename]
Signed-off-by: Ben Hutchings <>
4 years agodm: fix various targets to dm_register_target after module __init resources created [Fri, 24 Nov 2017 17:43:50 +0000 (01:43 +0800)]
dm: fix various targets to dm_register_target after module __init resources created

commit 7e6358d244e4706fe612a77b9c36519a33600ac0 upstream.

A NULL pointer is seen if two concurrent "vgchange -ay -K <vg name>"
processes race to load the dm-thin-pool module:

 PID: 25992 TASK: ffff883cd7d23500 CPU: 4 COMMAND: "vgchange"
  #0 [ffff883cd743d600] machine_kexec at ffffffff81038fa9
  0000001 [ffff883cd743d660] crash_kexec at ffffffff810c5992
  0000002 [ffff883cd743d730] oops_end at ffffffff81515c90
  0000003 [ffff883cd743d760] no_context at ffffffff81049f1b
  0000004 [ffff883cd743d7b0] __bad_area_nosemaphore at ffffffff8104a1a5
  0000005 [ffff883cd743d800] bad_area at ffffffff8104a2ce
  0000006 [ffff883cd743d830] __do_page_fault at ffffffff8104aa6f
  0000007 [ffff883cd743d950] do_page_fault at ffffffff81517bae
  0000008 [ffff883cd743d980] page_fault at ffffffff81514f95
     [exception RIP: kmem_cache_alloc+108]
     RIP: ffffffff8116ef3c RSP: ffff883cd743da38 RFLAGS: 00010046
     RAX: 0000000000000004 RBX: ffffffff81121b90 RCX: ffff881bf1e78cc0
     RDX: 0000000000000000 RSI: 00000000000000d0 RDI: 0000000000000000
     RBP: ffff883cd743da68 R8: ffff881bf1a4eb00 R9: 0000000080042000
     R10: 0000000000002000 R11: 0000000000000000 R12: 00000000000000d0
     R13: 0000000000000000 R14: 00000000000000d0 R15: 0000000000000246
     ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
  0000009 [ffff883cd743da70] mempool_alloc_slab at ffffffff81121ba5
 0000010 [ffff883cd743da80] mempool_create_node at ffffffff81122083
 0000011 [ffff883cd743dad0] mempool_create at ffffffff811220f4
 0000012 [ffff883cd743dae0] pool_ctr at ffffffffa08de049 [dm_thin_pool]
 0000013 [ffff883cd743dbd0] dm_table_add_target at ffffffffa0005f2f [dm_mod]
 0000014 [ffff883cd743dc30] table_load at ffffffffa0008ba9 [dm_mod]
 0000015 [ffff883cd743dc90] ctl_ioctl at ffffffffa0009dc4 [dm_mod]

The race results in a NULL pointer because:

Process A (vgchange -ay -K):
  a. send DM_LIST_VERSIONS_CMD ioctl;
  b. pool_target not registered;
  c. modprobe dm_thin_pool and wait until end.

Process B (vgchange -ay -K):
  a. send DM_LIST_VERSIONS_CMD ioctl;
  b. pool_target registered;
  c. table_load->dm_table_add_target->pool_ctr;
  d. _new_mapping_cache is NULL and panic.
  1. process A and process B are two concurrent processes.
  2. pool_target can be detected by process B but
  _new_mapping_cache initialization has not ended.

To fix dm-thin-pool, and other targets (cache, multipath, and snapshot)
with the same problem, simply dm_register_target() after all resources
created during module init (as labelled with __init) are finished.

Signed-off-by: monty <>
Signed-off-by: Mike Snitzer <>
[bwh: Backported to 3.2:
 - Drop changes in dm-cache (non-existent) and dm-thin (doesn't have this bug)
 - In dm-snap, reorder cleanup of tracked_chunk_cache too
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agodm mpath: simplify failure path of dm_multipath_init()
Johannes Thumshirn [Sun, 11 Jan 2015 11:45:23 +0000 (12:45 +0100)]
dm mpath: simplify failure path of dm_multipath_init()

commit ff658e9c1aae9a84dd06d46f847dc0cd2bf0dd11 upstream.

Currently the cleanup of all error cases are open-coded.  Introduce a
common exit path and labels.

Signed-off-by: Johannes Thumshirn <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Ben Hutchings <>
4 years agobatman-adv: Fix lock for ogm cnt access in batadv_iv_ogm_calc_tq
Sven Eckelmann [Sun, 3 Dec 2017 10:26:45 +0000 (11:26 +0100)]
batman-adv: Fix lock for ogm cnt access in batadv_iv_ogm_calc_tq

commit 5ba7dcfe77037b67016263ea597a8b431692ecab upstream.

The originator node object orig_neigh_node is used to when accessing the
bcast_own(_sum) and real_packet_count information. The access to them has
to be protected with the spinlock in orig_neigh_node.

But the function uses the lock in orig_node instead. This is incorrect
because they could be two different originator node objects.

Fixes: 0ede9f41b217 ("batman-adv: protect bit operations to count OGMs with spinlock")
Signed-off-by: Sven Eckelmann <>
Signed-off-by: Simon Wunderlich <>
[bwh: Backported to 3.2:
 - s/bat_iv\.ogm_cnt_lock/ogm_cnt_lock/
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoALSA: usb-audio: Add check return value for usb_string()
Jaejoong Kim [Mon, 4 Dec 2017 06:31:49 +0000 (15:31 +0900)]
ALSA: usb-audio: Add check return value for usb_string()

commit 89b89d121ffcf8d9546633b98ded9d18b8f75891 upstream.

snd_usb_copy_string_desc() returns zero if usb_string() fails.
In case of failure, we need to check the snd_usb_copy_string_desc()'s
return value and add an exception case

Signed-off-by: Jaejoong Kim <>
Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoALSA: usb-audio: Fix out-of-bound error
Jaejoong Kim [Mon, 4 Dec 2017 06:31:48 +0000 (15:31 +0900)]
ALSA: usb-audio: Fix out-of-bound error

commit 251552a2b0d454badc8f486e6d79100970c744b0 upstream.

The snd_usb_copy_string_desc() retrieves the usb string corresponding to
the index number through the usb_string(). The problem is that the
usb_string() returns the length of the string (>= 0) when successful, but
it can also return a negative value about the error case or status of

If iClockSource is '0' as shown below, usb_string() will returns -EINVAL.
This will result in '0' being inserted into buf[-22], and the following
KASAN out-of-bound error message will be output.

AudioControl Interface Descriptor:
  bLength                 8
  bDescriptorType        36
  bDescriptorSubtype     10 (CLOCK_SOURCE)
  bClockID                1
  bmAttributes         0x07 Internal programmable Clock (synced to SOF)
  bmControls           0x07
  Clock Frequency Control (read/write)
  Clock Validity Control (read-only)
  bAssocTerminal          0
  iClockSource            0

To fix it, check usb_string()'return value and bail out.

BUG: KASAN: stack-out-of-bounds in parse_audio_unit+0x1327/0x1960 [snd_usb_audio]
Write of size 1 at addr ffff88007e66735a by task systemd-udevd/18376

CPU: 0 PID: 18376 Comm: systemd-udevd Not tainted 4.13.0+ #3
Hardware name: LG Electronics                   15N540-RFLGL/White Tip Mountain, BIOS 15N5
Call Trace:
? parse_audio_unit+0x1327/0x1960 [snd_usb_audio]
parse_audio_unit+0x1327/0x1960 [snd_usb_audio]
? save_stack+0xb5/0xd0
? save_stack_trace+0x1b/0x20
? save_stack+0x46/0xd0
? kasan_kmalloc+0xad/0xe0
? kmem_cache_alloc_trace+0xff/0x230
? snd_usb_create_mixer+0xb0/0x4b0 [snd_usb_audio]
? usb_audio_probe+0x4de/0xf40 [snd_usb_audio]
? usb_probe_interface+0x1f5/0x440
? driver_probe_device+0x3ed/0x660
? build_feature_ctl+0xb10/0xb10 [snd_usb_audio]
? save_stack_trace+0x1b/0x20
? init_object+0x69/0xa0
? snd_usb_find_csint_desc+0xa8/0xf0 [snd_usb_audio]
snd_usb_mixer_controls+0x1dc/0x370 [snd_usb_audio]
? build_audio_procunit+0x890/0x890 [snd_usb_audio]
? snd_usb_create_mixer+0xb0/0x4b0 [snd_usb_audio]
? kmem_cache_alloc_trace+0xff/0x230
? usb_ifnum_to_if+0xbd/0xf0
snd_usb_create_mixer+0x25b/0x4b0 [snd_usb_audio]
? snd_usb_create_stream+0x255/0x2c0 [snd_usb_audio]
usb_audio_probe+0x4de/0xf40 [snd_usb_audio]
? snd_usb_autosuspend.part.7+0x30/0x30 [snd_usb_audio]
? __pm_runtime_idle+0x90/0x90
? kernfs_activate+0xa6/0xc0
? usb_match_one_id_intf+0xdc/0x130
? __pm_runtime_set_status+0x2d4/0x450

Signed-off-by: Jaejoong Kim <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>