3 years agopowerpc/pseries: Add empty update_numa_cpu_lookup_table() for NUMA=n
Corentin Labbe [Wed, 14 Feb 2018 12:17:47 +0000 (12:17 +0000)]
powerpc/pseries: Add empty update_numa_cpu_lookup_table() for NUMA=n

commit c1e150ceb61e4a585bad156da15c33bfe89f5858 upstream.

When CONFIG_NUMA is not set, the build fails with:

  error: déclaration implicite de la fonction « update_numa_cpu_lookup_table »

So we have to add update_numa_cpu_lookup_table() as an empty function
when CONFIG_NUMA is not set.

Fixes: 1d9a090783be ("powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove")
Signed-off-by: Corentin Labbe <>
Signed-off-by: Michael Ellerman <>
Signed-off-by: Ben Hutchings <>
3 years agonetfilter: nat: cope with negative port range
Paolo Abeni [Wed, 14 Feb 2018 16:21:19 +0000 (17:21 +0100)]
netfilter: nat: cope with negative port range

commit db57ccf0f2f4624b4c4758379f8165277504fbd7 upstream.

syzbot reported a division by 0 bug in the netfilter nat code:

divide error: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
    (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 4168 Comm: syzkaller034710 Not tainted 4.16.0-rc1+ #309
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:nf_nat_l4proto_unique_tuple+0x291/0x530
RSP: 0018:ffff8801b2466778 EFLAGS: 00010246
RAX: 000000000000f153 RBX: ffff8801b2466dd8 RCX: ffff8801b2466c7c
RDX: 0000000000000000 RSI: ffff8801b2466c58 RDI: ffff8801db5293ac
RBP: ffff8801b24667d8 R08: ffff8801b8ba6dc0 R09: ffffffff88af5900
R10: ffff8801b24666f0 R11: 0000000000000000 R12: 000000002990f153
R13: 0000000000000001 R14: 0000000000000000 R15: ffff8801b2466c7c
FS:  00000000017e3880(0000) GS:ffff8801db500000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000208fdfe4 CR3: 00000001b5340002 CR4: 00000000001606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
  dccp_unique_tuple+0x40/0x50 net/netfilter/nf_nat_proto_dccp.c:30
  get_unique_tuple+0xc28/0x1c10 net/netfilter/nf_nat_core.c:362
  nf_nat_setup_info+0x1c2/0xe00 net/netfilter/nf_nat_core.c:406
  nf_nat_redirect_ipv6+0x306/0x730 net/netfilter/nf_nat_redirect.c:124
  redirect_tg6+0x7f/0xb0 net/netfilter/xt_REDIRECT.c:34
  ip6t_do_table+0xc2a/0x1a30 net/ipv6/netfilter/ip6_tables.c:365
  ip6table_nat_do_chain+0x65/0x80 net/ipv6/netfilter/ip6table_nat.c:41
  nf_nat_ipv6_fn+0x594/0xa80 net/ipv6/netfilter/nf_nat_l3proto_ipv6.c:302
  ip6table_nat_local_fn+0x2c/0x40 net/ipv6/netfilter/ip6table_nat.c:69
  nf_hook_entry_hookfn include/linux/netfilter.h:120 [inline]
  nf_hook_slow+0xba/0x1a0 net/netfilter/core.c:483
  nf_hook include/linux/netfilter.h:243 [inline]
  NF_HOOK include/linux/netfilter.h:286 [inline]
  ip6_xmit+0x10ec/0x2260 net/ipv6/ip6_output.c:277
  inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
  dccp_transmit_skb+0x9ac/0x10f0 net/dccp/output.c:142
  dccp_connect+0x369/0x670 net/dccp/output.c:564
  dccp_v6_connect+0xe17/0x1bf0 net/dccp/ipv6.c:946
  __inet_stream_connect+0x2d4/0xf00 net/ipv4/af_inet.c:620
  inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:684
  SYSC_connect+0x213/0x4a0 net/socket.c:1639
  SyS_connect+0x24/0x30 net/socket.c:1620
  do_syscall_64+0x282/0x940 arch/x86/entry/common.c:287
RIP: 0033:0x441c69
RSP: 002b:00007ffe50cc0be8 EFLAGS: 00000217 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: ffffffffffffffff RCX: 0000000000441c69
RDX: 000000000000001c RSI: 00000000208fdfe4 RDI: 0000000000000003
RBP: 00000000006cc018 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000538 R11: 0000000000000217 R12: 0000000000403590
R13: 0000000000403620 R14: 0000000000000000 R15: 0000000000000000
Code: 48 89 f0 83 e0 07 83 c0 01 38 d0 7c 08 84 d2 0f 85 46 02 00 00 48 8b
45 c8 44 0f b7 20 e8 88 97 04 fd 31 d2 41 0f b7 c4 4c 89 f9 <41> f7 f6 48
c1 e9 03 48 b8 00 00 00 00 00 fc ff df 0f b6 0c 01
RIP: nf_nat_l4proto_unique_tuple+0x291/0x530
net/netfilter/nf_nat_proto_common.c:88 RSP: ffff8801b2466778

The problem is that currently we don't have any check on the
configured port range. A port range == -1 triggers the bug, while
other negative values may require a very long time to complete the
following loop.

This commit addresses the issue swapping the two ends on negative
ranges. The check is performed in nf_nat_l4proto_unique_tuple() since
the nft nat loads the port values from nft registers at runtime.

v1 -> v2: use the correct 'Fixes' tag
v2 -> v3: update commit message, drop unneeded READ_ONCE()

Fixes: 5b1158e909ec ("[NETFILTER]: Add NAT support for nf_conntrack")
Signed-off-by: Paolo Abeni <>
Signed-off-by: Pablo Neira Ayuso <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
3 years agonetfilter: x_tables: fix missing timer initialization in xt_LED
Paolo Abeni [Mon, 12 Feb 2018 17:49:39 +0000 (18:49 +0100)]
netfilter: x_tables: fix missing timer initialization in xt_LED

commit 10414014bc085aac9f787a5890b33b5605fbcfc4 upstream.

syzbot reported that xt_LED may try to use the ledinternal->timer
without previously initializing it:

------------[ cut here ]------------
kernel BUG at kernel/time/timer.c:958!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
    (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 1826 Comm: kworker/1:2 Not tainted 4.15.0+ #306
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:__mod_timer kernel/time/timer.c:958 [inline]
RIP: 0010:mod_timer+0x7d6/0x13c0 kernel/time/timer.c:1102
RSP: 0018:ffff8801d24fe9f8 EFLAGS: 00010293
RAX: ffff8801d25246c0 RBX: ffff8801aec6cb50 RCX: ffffffff816052c6
RDX: 0000000000000000 RSI: 00000000fffbd14b RDI: ffff8801aec6cb68
RBP: ffff8801d24fec98 R08: 0000000000000000 R09: 1ffff1003a49fd6c
R10: ffff8801d24feb28 R11: 0000000000000005 R12: dffffc0000000000
R13: ffff8801d24fec70 R14: 00000000fffbd14b R15: ffff8801af608f90
FS:  0000000000000000(0000) GS:ffff8801db500000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000206d6fd0 CR3: 0000000006a22001 CR4: 00000000001606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
  led_tg+0x1db/0x2e0 net/netfilter/xt_LED.c:75
  ip6t_do_table+0xc2a/0x1a30 net/ipv6/netfilter/ip6_tables.c:365
  ip6table_raw_hook+0x65/0x80 net/ipv6/netfilter/ip6table_raw.c:42
  nf_hook_entry_hookfn include/linux/netfilter.h:120 [inline]
  nf_hook_slow+0xba/0x1a0 net/netfilter/core.c:483
  nf_hook.constprop.27+0x3f6/0x830 include/linux/netfilter.h:243
  NF_HOOK include/linux/netfilter.h:286 [inline]
  ndisc_send_skb+0xa51/0x1370 net/ipv6/ndisc.c:491
  ndisc_send_ns+0x38a/0x870 net/ipv6/ndisc.c:633
  addrconf_dad_work+0xb9e/0x1320 net/ipv6/addrconf.c:4008
  process_one_work+0xbbf/0x1af0 kernel/workqueue.c:2113
  worker_thread+0x223/0x1990 kernel/workqueue.c:2247
  kthread+0x33c/0x400 kernel/kthread.c:238
  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:429
Code: 85 2a 0b 00 00 4d 8b 3c 24 4d 85 ff 75 9f 4c 8b bd 60 fd ff ff e8 bb
57 10 00 65 ff 0d 94 9a a1 7e e9 d9 fc ff ff e8 aa 57 10 00 <0f> 0b e8 a3
57 10 00 e9 14 fb ff ff e8 99 57 10 00 4c 89 bd 70
RIP: __mod_timer kernel/time/timer.c:958 [inline] RSP: ffff8801d24fe9f8
RIP: mod_timer+0x7d6/0x13c0 kernel/time/timer.c:1102 RSP: ffff8801d24fe9f8
---[ end trace f661ab06f5dd8b3d ]---

The ledinternal struct can be shared between several different
xt_LED targets, but the related timer is currently initialized only
if the first target requires it. Fix it by unconditionally
initializing the timer struct.

v1 -> v2: call del_timer_sync() unconditionally, too.

Fixes: 268cb38e1802 ("netfilter: x_tables: add LED trigger target")
Signed-off-by: Paolo Abeni <>
Signed-off-by: Pablo Neira Ayuso <>
[bwh: Backported to 3.2: Keep using setup_timer()]
Signed-off-by: Ben Hutchings <>
3 years agonetfilter: ipt_CLUSTERIP: fix a refcount bug in clusterip_config_find_get()
Cong Wang [Thu, 8 Feb 2018 21:53:52 +0000 (13:53 -0800)]
netfilter: ipt_CLUSTERIP: fix a refcount bug in clusterip_config_find_get()

commit db93a3632b0f8773a3899e04a3a3e0aa7a26eb46 upstream.

In clusterip_config_find_get() we hold RCU read lock so it could
run concurrently with clusterip_config_entry_put(), as a result,
the refcnt could go back to 1 from 0, which leads to a double
list_del()... Just replace refcount_inc() with
refcount_inc_not_zero(), as for c->refcount.

Fixes: d73f33b16883 ("netfilter: CLUSTERIP: RCU conversion")
Cc: Eric Dumazet <>
Cc: Pablo Neira Ayuso <>
Cc: Florian Westphal <>
Signed-off-by: Cong Wang <>
Reviewed-by: Florian Westphal <>
Signed-off-by: Pablo Neira Ayuso <>
[bwh: Backported to 3.2: s/refcount/atomic/]
Signed-off-by: Ben Hutchings <>
3 years agonetfilter: drop outermost socket lock in getsockopt()
Paolo Abeni [Thu, 8 Feb 2018 11:19:00 +0000 (12:19 +0100)]
netfilter: drop outermost socket lock in getsockopt()

commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.

The Syzbot reported a possible deadlock in the netfilter area caused by
rtnl lock, xt lock and socket lock being acquired with a different order
on different code paths, leading to the following backtrace:
Reviewed-by: Xin Long <>
WARNING: possible circular locking dependency detected
4.15.0+ #301 Not tainted
syzkaller233489/4179 is trying to acquire lock:
  (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20

but task is already holding lock:
  (&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041

which lock already depends on the new lock.

Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
only in the required scope"), we already acquire the socket lock in
the innermost scope, where needed. In such commit I forgot to remove
the outer-most socket lock from the getsockopt() path, this commit
addresses the issues dropping it now.

v1 -> v2: fix bad subj, added relavant 'fixes' tag

Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
Suggested-by: Florian Westphal <>
Signed-off-by: Paolo Abeni <>
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>
3 years agonet: fix race on decreasing number of TX queues
Jakub Kicinski [Tue, 13 Feb 2018 05:35:31 +0000 (21:35 -0800)]
net: fix race on decreasing number of TX queues

commit ac5b70198adc25c73fba28de4f78adcee8f6be0b upstream.

netif_set_real_num_tx_queues() can be called when netdev is up.
That usually happens when user requests change of number of
channels/rings with ethtool -L.  The procedure for changing
the number of queues involves resetting the qdiscs and setting
dev->num_tx_queues to the new value.  When the new value is
lower than the old one, extra care has to be taken to ensure
ordering of accesses to the number of queues vs qdisc reset.

Currently the queues are reset before new dev->num_tx_queues
is assigned, leaving a window of time where packets can be
enqueued onto the queues going down, leading to a likely
crash in the drivers, since most drivers don't check if TX
skbs are assigned to an active queue.

Fixes: e6484930d7c7 ("net: allocate tx queues in register_netdevice")
Signed-off-by: Jakub Kicinski <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoxfrm_user: uncoditionally validate esn replay attribute struct
Florian Westphal [Mon, 12 Feb 2018 13:42:01 +0000 (14:42 +0100)]
xfrm_user: uncoditionally validate esn replay attribute struct

commit d97ca5d714a5334aecadadf696875da40f1fbf3e upstream.

The sanity test added in ecd7918745234 can be bypassed, validation
only occurs if XFRM_STATE_ESN flag is set, but rest of code doesn't care
and just checks if the attribute itself is present.

So always validate.  Alternative is to reject if we have the attribute
without the flag but that would change abi.

Cc: Mathias Krause <>
Fixes: ecd7918745234 ("xfrm_user: ensure user supplied esn replay window is valid")
Fixes: d8647b79c3b7e ("xfrm: Add user interface for esn and big anti-replay windows")
Signed-off-by: Florian Westphal <>
Signed-off-by: Steffen Klassert <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agolibata: remove WARN() for DMA or PIO command without data
Eric Biggers [Sun, 4 Feb 2018 04:33:27 +0000 (20:33 -0800)]
libata: remove WARN() for DMA or PIO command without data

commit 9173e5e80729c8434b8d27531527c5245f4a5594 upstream.

syzkaller hit a WARN() in ata_qc_issue() when writing to /dev/sg0.  This
happened because it issued a READ_6 command with no data buffer.

Just remove the WARN(), as it doesn't appear indicate a kernel bug.  The
expected behavior is to fail the command, which the code does.

Here's a reproducer that works in QEMU when /dev/sg0 refers to a disk of
the default type ("82371SB PIIX3 IDE"):

    #include <fcntl.h>
    #include <unistd.h>

    int main()
            char buf[42] = { [36] = 0x8 /* READ_6 */ };

            write(open("/dev/sg0", O_RDWR), buf, sizeof(buf));

Fixes: f92a26365a72 ("libata: change ATA_QCFLAG_DMAMAP semantics")
Signed-off-by: Eric Biggers <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
3 years agolibata: fix length validation of ATAPI-relayed SCSI commands
Eric Biggers [Sun, 4 Feb 2018 04:30:56 +0000 (20:30 -0800)]
libata: fix length validation of ATAPI-relayed SCSI commands

commit 058f58e235cbe03e923b30ea7c49995a46a8725f upstream.

syzkaller reported a crash in ata_bmdma_fill_sg() when writing to
/dev/sg1.  The immediate cause was that the ATA command's scatterlist
was not DMA-mapped, which causes 'pi - 1' to underflow, resulting in a
write to 'qc->ap->bmdma_prd[0xffffffff]'.

Strangely though, the flag ATA_QCFLAG_DMAMAP was set in qc->flags.  The
root cause is that when __ata_scsi_queuecmd() is preparing to relay a
SCSI command to an ATAPI device, it doesn't correctly validate the CDB
length before copying it into the 16-byte buffer 'cdb' in 'struct
ata_queued_cmd'.  Namely, it validates the fixed CDB length expected
based on the SCSI opcode but not the actual CDB length, which can be
larger due to the use of the SG_NEXT_CMD_LEN ioctl.  Since 'flags' is
the next member in ata_queued_cmd, a buffer overflow corrupts it.

Fix it by requiring that the actual CDB length be <= 16 (ATAPI_CDB_LEN).

[Really it seems the length should be required to be <= dev->cdb_len,
but the current behavior seems to have been intentionally introduced by
commit 607126c2a21c ("libata-scsi: be tolerant of 12-byte ATAPI commands
in 16-byte CDBs") to work around a userspace bug in mplayer.  Probably
the workaround is no longer needed (mplayer was fixed in 2007), but
continuing to allow lengths to up 16 appears harmless for now.]

Here's a reproducer that works in QEMU when /dev/sg1 refers to the
CD-ROM drive that qemu-system-x86_64 creates by default:

    #include <fcntl.h>
    #include <sys/ioctl.h>
    #include <unistd.h>

    #define SG_NEXT_CMD_LEN 0x2283

    int main()
    char buf[53] = { [36] = 0x7e, [52] = 0x02 };
    int fd = open("/dev/sg1", O_RDWR);
    ioctl(fd, SG_NEXT_CMD_LEN, &(int){ 17 });
    write(fd, buf, sizeof(buf));

The crash was:

    BUG: unable to handle kernel paging request at ffff8cb97db37ffc
    IP: ata_bmdma_fill_sg drivers/ata/libata-sff.c:2623 [inline]
    IP: ata_bmdma_qc_prep+0xa4/0xc0 drivers/ata/libata-sff.c:2727
    PGD fb6c067 P4D fb6c067 PUD 0
    Oops: 0002 [#1] SMP
    CPU: 1 PID: 150 Comm: syz_ata_bmdma_q Not tainted 4.15.0-next-20180202 #99
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
    Call Trace:
     ata_qc_issue+0x100/0x1d0 drivers/ata/libata-core.c:5421
     ata_scsi_translate+0xc9/0x1a0 drivers/ata/libata-scsi.c:2024
     __ata_scsi_queuecmd drivers/ata/libata-scsi.c:4326 [inline]
     ata_scsi_queuecmd+0x8c/0x210 drivers/ata/libata-scsi.c:4375
     scsi_dispatch_cmd+0xa2/0xe0 drivers/scsi/scsi_lib.c:1727
     scsi_request_fn+0x24c/0x530 drivers/scsi/scsi_lib.c:1865
     __blk_run_queue_uncond block/blk-core.c:412 [inline]
     __blk_run_queue+0x3a/0x60 block/blk-core.c:432
     blk_execute_rq_nowait+0x93/0xc0 block/blk-exec.c:78
     sg_common_write.isra.7+0x272/0x5a0 drivers/scsi/sg.c:806
     sg_write+0x1ef/0x340 drivers/scsi/sg.c:677
     __vfs_write+0x31/0x160 fs/read_write.c:480
     vfs_write+0xa7/0x160 fs/read_write.c:544
     SYSC_write fs/read_write.c:589 [inline]
     SyS_write+0x4d/0xc0 fs/read_write.c:581
     do_syscall_64+0x5e/0x110 arch/x86/entry/common.c:287

Fixes: 607126c2a21c ("libata-scsi: be tolerant of 12-byte ATAPI commands in 16-byte CDBs")
Signed-off-by: Eric Biggers <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
3 years agobridge: check brport attr show in brport_show
Xin Long [Mon, 12 Feb 2018 09:15:40 +0000 (17:15 +0800)]
bridge: check brport attr show in brport_show

commit 1b12580af1d0677c3c3a19e35bfe5d59b03f737f upstream.

Now br_sysfs_if file flush doesn't have attr show. To read it will
cause kernel panic after users chmod u+r this file.

Xiong found this issue when running the commands:

  ip link add br0 type bridge
  ip link add type veth
  ip link set veth0 master br0
  chmod u+r /sys/devices/virtual/net/veth0/brport/flush
  timeout 3 cat /sys/devices/virtual/net/veth0/brport/flush

kernel crashed with NULL a pointer dereference call trace.

This patch is to fix it by return -EINVAL when brport_attr->show
is null, just the same as the check for brport_attr->store in

Fixes: 9cf637473c85 ("bridge: add sysfs hook to flush forwarding table")
Reported-by: Xiong Zhou <>
Signed-off-by: Xin Long <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
3 years agousb: dwc3: gadget: Set maxpacket size for ep0 IN
Thinh Nguyen [Sat, 13 Jan 2018 02:18:05 +0000 (18:18 -0800)]
usb: dwc3: gadget: Set maxpacket size for ep0 IN

commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream.

There are 2 control endpoint structures for DWC3. However, the driver
only updates the OUT direction control endpoint structure during
ConnectDone event. DWC3 driver needs to update the endpoint max packet
size for control IN endpoint as well. If the max packet size is not
properly set, then the driver will incorrectly calculate the data
transfer size and fail to send ZLP for HS/FS 3-stage control read

The fix is simply to update the max packet size for the ep0 IN direction
during ConnectDone event.

Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: Thinh Nguyen <>
Signed-off-by: Felipe Balbi <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoInput: matrix_keypad - fix race when disabling interrupts
Zhang Bo [Mon, 5 Feb 2018 22:56:21 +0000 (14:56 -0800)]
Input: matrix_keypad - fix race when disabling interrupts

commit ea4f7bd2aca9f68470e9aac0fc9432fd180b1fe7 upstream.

If matrix_keypad_stop() is executing and the keypad interrupt is triggered,
disable_row_irqs() may be called by both matrix_keypad_interrupt() and
matrix_keypad_stop() at the same time, causing interrupts to be disabled
twice and the keypad being "stuck" after resuming.

Take lock when setting keypad->stopped to ensure that ISR will not race
with matrix_keypad_stop() disabling interrupts.

Signed-off-by: Zhang Bo <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
3 years agos390/qeth: fix SETIP command handling
Julian Wiedmann [Fri, 9 Feb 2018 10:03:50 +0000 (11:03 +0100)]
s390/qeth: fix SETIP command handling

commit 1c5b2216fbb973a9410e0b06389740b5c1289171 upstream.

send_control_data() applies some special handling to SETIP v4 IPA
commands. But current code parses *all* command types for the SETIP
command code. Limit the command code check to IPA commands.

Fixes: 5b54e16f1a54 ("qeth: do not spin for SETIP ip assist command")
Signed-off-by: Julian Wiedmann <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
3 years ago9p/trans_virtio: discard zero-length reply
Greg Kurz [Mon, 22 Jan 2018 21:02:05 +0000 (22:02 +0100)]
9p/trans_virtio: discard zero-length reply

commit 26d99834f89e76514076d9cd06f61e56e6a509b8 upstream.

When a 9p request is successfully flushed, the server is expected to just
mark it as used without sending a 9p reply (ie, without writing data into
the buffer). In this case, virtqueue_get_buf() will return len == 0 and
we must not report a REQ_STATUS_RCVD status to the client, otherwise the
client will erroneously assume the request has not been flushed.

Signed-off-by: Greg Kurz <>
Signed-off-by: Michael S. Tsirkin <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agonetlink: avoid a double skb free in genlmsg_mcast()
Nicolas Dichtel [Wed, 14 Mar 2018 20:10:23 +0000 (21:10 +0100)]
netlink: avoid a double skb free in genlmsg_mcast()

commit 02a2385f37a7c6594c9d89b64c4a1451276f08eb upstream.

nlmsg_multicast() consumes always the skb, thus the original skb must be
freed only when this function is called with a clone.

Fixes: cb9f7a9a5c96 ("netlink: ensure to loop over all netns in genlmsg_multicast_allns()")
Reported-by: Ben Hutchings <>
Signed-off-by: Nicolas Dichtel <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
3 years agonetlink: ensure to loop over all netns in genlmsg_multicast_allns()
Nicolas Dichtel [Tue, 6 Feb 2018 13:48:32 +0000 (14:48 +0100)]
netlink: ensure to loop over all netns in genlmsg_multicast_allns()

commit cb9f7a9a5c96a773bbc9c70660dc600cfff82f82 upstream.

Nowadays, nlmsg_multicast() returns only 0 or -ESRCH but this was not the
case when commit 134e63756d5f was pushed.
However, there was no reason to stop the loop if a netns does not have
Returns -ESRCH only if there was no listeners in all netns.

To avoid having the same problem in the future, I didn't take the
assumption that nlmsg_multicast() returns only 0 or -ESRCH.

Fixes: 134e63756d5f ("genetlink: make netns aware")
CC: Johannes Berg <>
Signed-off-by: Nicolas Dichtel <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: s/portid/pid/]
Signed-off-by: Ben Hutchings <>
3 years agopowerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove
Nathan Fontenot [Fri, 26 Jan 2018 19:41:59 +0000 (13:41 -0600)]
powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove

commit 1d9a090783bef19fe8cdec878620d22f05191316 upstream.

When DLPAR removing a CPU, the unmapping of the cpu from a node in
unmap_cpu_from_node() should also invalidate the CPUs entry in the
numa_cpu_lookup_table. There is not a guarantee that on a subsequent
DLPAR add of the CPU the associativity will be the same and thus
could be in a different node. Invalidating the entry in the
numa_cpu_lookup_table causes the associativity to be read from the
device tree at the time of the add.

The current behavior of not invalidating the CPUs entry in the
numa_cpu_lookup_table can result in scenarios where the the topology
layout of CPUs in the partition does not match the device tree
or the topology reported by the HMC.

This bug looks like it was introduced in 2004 in the commit titled
"ppc64: cpu hotplug notifier for numa", which is 6b15e4e87e32 in the
linux-fullhist tree. Hence tag it for all stable releases.

Signed-off-by: Nathan Fontenot <>
Reviewed-by: Tyrel Datwyler <>
Signed-off-by: Michael Ellerman <>
[bwh: Backported to 3.2:
 - update_numa_cpu_lookup_table() wasn't defined anywhere before
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agonetfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
Cong Wang [Mon, 5 Feb 2018 22:41:45 +0000 (14:41 -0800)]
netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert

commit 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 upstream.

rateest_hash is supposed to be protected by xt_rateest_mutex,
and, as suggested by Eric, lookup and insert should be atomic,
so we should acquire the xt_rateest_mutex once for both.

So introduce a non-locking helper for internal use and keep the
locking one for external.

Reported-by: <>
Fixes: 5859034d7eb8 ("[NETFILTER]: x_tables: add RATEEST target")
Signed-off-by: Cong Wang <>
Reviewed-by: Florian Westphal <>
Reviewed-by: Eric Dumazet <>
Signed-off-by: Pablo Neira Ayuso <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoMIPS: TXx9: use IS_BUILTIN() for CONFIG_LEDS_CLASS
Matt Redfearn [Mon, 29 Jan 2018 11:26:45 +0000 (11:26 +0000)]

commit 0cde5b44a30f1daaef1c34e08191239dc63271c4 upstream.

When commit b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support")
added board support for the RBTX4939, it added a call to
led_classdev_register even if the LED class is built as a module.
Built-in arch code cannot call module code directly like this. Commit
b33b44073734 ("MIPS: TXX9: use IS_ENABLED() macro") subsequently
changed the inclusion of this code to a single check that
CONFIG_LEDS_CLASS is either builtin or a module, but the same issue

This leads to MIPS allmodconfig builds failing when CONFIG_MACH_TX49XX=y
is set:

arch/mips/txx9/rbtx4939/setup.o: In function `rbtx4939_led_probe':
setup.c:(.init.text+0xc0): undefined reference to `of_led_classdev_register'
make: *** [Makefile:999: vmlinux] Error 1

Fix this by using the IS_BUILTIN() macro instead.

Fixes: b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support")
Signed-off-by: Matt Redfearn <>
Reviewed-by: James Hogan <>
Cc: Ralf Baechle <>
Signed-off-by: James Hogan <>
Signed-off-by: Ben Hutchings <>
3 years agoMIPS: TXX9: use IS_ENABLED() macro
Florian Fainelli [Tue, 31 Jan 2012 17:19:05 +0000 (18:19 +0100)]
MIPS: TXX9: use IS_ENABLED() macro

commit b33b44073734842ec0c75d376c40d0471d6113ff upstream.

Signed-off-by: Florian Fainelli <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
3 years agofirmware: dmi_scan: Fix handling of empty DMI strings
Jean Delvare [Sat, 3 Feb 2018 10:25:20 +0000 (11:25 +0100)]
firmware: dmi_scan: Fix handling of empty DMI strings

commit a7770ae194569e96a93c48aceb304edded9cc648 upstream.

The handling of empty DMI strings looks quite broken to me:
* Strings from 1 to 7 spaces are not considered empty.
* True empty DMI strings (string index set to 0) are not considered
  empty, and result in allocating a 0-char string.
* Strings with invalid index also result in allocating a 0-char
* Strings starting with 8 spaces are all considered empty, even if
  non-space characters follow (sounds like a weird thing to do, but
  I have actually seen occurrences of this in DMI tables before.)
* Strings which are considered empty are reported as 8 spaces,
  instead of being actually empty.

Some of these issues are the result of an off-by-one error in memcmp,
the rest is incorrect by design.

So let's get it square: missing strings and strings made of only
spaces, regardless of their length, should be treated as empty and
no memory should be allocated for them. All other strings are
non-empty and should be allocated.

Signed-off-by: Jean Delvare <>
Fixes: 79da4721117f ("x86: fix DMI out of memory problems")
Cc: Parag Warudkar <>
Cc: Ingo Molnar <>
Cc: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
3 years agofirmware/dmi_scan: constify strings
Jean Delvare [Wed, 11 Sep 2013 21:24:09 +0000 (14:24 -0700)]
firmware/dmi_scan: constify strings

commit ffbbb96dd7570b9aafd426cd77a7ee03d224cabf upstream.

Add const to all DMI string pointers where this is possible.  This fixes a
checkpatch warning.

Signed-off-by: Jean Delvare <>
Cc: Joe Perches <>
Cc: Ben Hutchings <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoBtrfs: fix extent state leak from tree log
Liu Bo [Thu, 25 Jan 2018 18:02:52 +0000 (11:02 -0700)]
Btrfs: fix extent state leak from tree log

commit 55237a5f2431a72435e3ed39e4306e973c0446b7 upstream.

It's possible that btrfs_sync_log() bails out after one of the two
btrfs_write_marked_extents() which convert extent state's state bit into
and EXTENT_NEW are searched by free_log_tree() so that those extent states
with EXTENT_NEED_WAIT lead to memory leak.

Signed-off-by: Liu Bo <>
Reviewed-by: Josef Bacik <>
Signed-off-by: David Sterba <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agonet: igmp: add a missing rcu locking section
Eric Dumazet [Thu, 1 Feb 2018 18:26:57 +0000 (10:26 -0800)]
net: igmp: add a missing rcu locking section

commit e7aadb27a5415e8125834b84a74477bfbee4eff5 upstream.

Newly added igmpv3_get_srcaddr() needs to be called under rcu lock.

Timer callbacks do not ensure this locking.

WARNING: suspicious RCU usage
4.15.0+ #200 Not tainted
./include/linux/inetdevice.h:216 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
3 locks held by syzkaller616973/4074:
 #0:  (&mm->mmap_sem){++++}, at: [<00000000bfce669e>] __do_page_fault+0x32d/0xc90 arch/x86/mm/fault.c:1355
 #1:  ((&im->timer)){+.-.}, at: [<00000000619d2f71>] lockdep_copy_map include/linux/lockdep.h:178 [inline]
 #1:  ((&im->timer)){+.-.}, at: [<00000000619d2f71>] call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1316
 #2:  (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] spin_lock_bh include/linux/spinlock.h:315 [inline]
 #2:  (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] igmpv3_send_report+0x98/0x5b0 net/ipv4/igmp.c:600

stack backtrace:
CPU: 0 PID: 4074 Comm: syzkaller616973 Not tainted 4.15.0+ #200
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x194/0x257 lib/dump_stack.c:53
 lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592
 __in_dev_get_rcu include/linux/inetdevice.h:216 [inline]
 igmpv3_get_srcaddr net/ipv4/igmp.c:329 [inline]
 igmpv3_newpack+0xeef/0x12e0 net/ipv4/igmp.c:389
 add_grhead.isra.27+0x235/0x300 net/ipv4/igmp.c:432
 add_grec+0xbd3/0x1170 net/ipv4/igmp.c:565
 igmpv3_send_report+0xd5/0x5b0 net/ipv4/igmp.c:605
 igmp_send_report+0xc43/0x1050 net/ipv4/igmp.c:722
 igmp_timer_expire+0x322/0x5c0 net/ipv4/igmp.c:831
 call_timer_fn+0x228/0x820 kernel/time/timer.c:1326
 expire_timers kernel/time/timer.c:1363 [inline]
 __run_timers+0x7ee/0xb70 kernel/time/timer.c:1666
 run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
 invoke_softirq kernel/softirq.c:365 [inline]
 irq_exit+0x1cc/0x200 kernel/softirq.c:405
 exiting_irq arch/x86/include/asm/apic.h:541 [inline]
 smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052
 apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:938

Fixes: a46182b00290 ("net: igmp: Use correct source address on IGMPv3 reports")
Signed-off-by: Eric Dumazet <>
Reported-by: syzbot <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
3 years agomm: pin address_space before dereferencing it while isolating an LRU page
Mel Gorman [Thu, 1 Feb 2018 00:19:52 +0000 (16:19 -0800)]
mm: pin address_space before dereferencing it while isolating an LRU page

commit 69d763fc6d3aee787a3e8c8c35092b4f4960fa5d upstream.

Minchan Kim asked the following question -- what locks protects
address_space destroying when race happens between inode trauncation and
__isolate_lru_page? Jan Kara clarified by describing the race as follows

CPU1                                            CPU2

truncate(inode)                                 __isolate_lru_page()
  truncate_inode_page(mapping, page);
      spin_lock_irqsave(&mapping->tree_lock, flags);
        __delete_from_page_cache(page, NULL)
            ...                                   mapping = page_mapping(page);
            page->mapping = NULL;
      spin_unlock_irqrestore(&mapping->tree_lock, flags);
      page_cache_free_page(mapping, page)
          if (put_page_testzero(page)) -> false
- inode now has no pages and can be freed including embedded address_space

                                                  if (mapping && !mapping->a_ops->migratepage)
- we've dereferenced mapping which is potentially already free.

The race is theoretically possible but unlikely.  Before the
delete_from_page_cache, truncate_cleanup_page is called so the page is
likely to be !PageDirty or PageWriteback which gets skipped by the only
caller that checks the mappping in __isolate_lru_page.  Even if the race
occurs, a substantial amount of work has to happen during a tiny window
with no preemption but it could potentially be done using a virtual
machine to artifically slow one CPU or halt it during the critical

This patch should eliminate the race with truncation by try-locking the
page before derefencing mapping and aborting if the lock was not
acquired.  There was a suggestion from Huang Ying to use RCU as a
side-effect to prevent mapping being freed.  However, I do not like the
solution as it's an unconventional means of preserving a mapping and
it's not a context where rcu_read_lock is obviously protecting rcu data.

Fixes: c82449352854 ("mm: compaction: make isolate_lru_page() filter-aware again")
Signed-off-by: Mel Gorman <>
Acked-by: Minchan Kim <>
Cc: "Huang, Ying" <>
Cc: Jan Kara <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agonetfilter: on sockopt() acquire sock lock only in the required scope
Paolo Abeni [Tue, 30 Jan 2018 18:01:40 +0000 (19:01 +0100)]
netfilter: on sockopt() acquire sock lock only in the required scope

commit 3f34cfae1238848fd53f25e5c8fd59da57901f4b upstream.

Syzbot reported several deadlocks in the netfilter area caused by
rtnl lock and socket lock being acquired with a different order on
different code paths, leading to backtraces like the following one:

WARNING: possible circular locking dependency detected
4.15.0-rc9+ #212 Not tainted
syzkaller041579/3682 is trying to acquire lock:
  (sk_lock-AF_INET6){+.+.}, at: [<000000008775e4dd>] lock_sock
include/net/sock.h:1463 [inline]
  (sk_lock-AF_INET6){+.+.}, at: [<000000008775e4dd>]
do_ipv6_setsockopt.isra.8+0x3c5/0x39d0 net/ipv6/ipv6_sockglue.c:167

but task is already holding lock:
  (rtnl_mutex){+.+.}, at: [<000000004342eaa9>] rtnl_lock+0x17/0x20

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (rtnl_mutex){+.+.}:
        __mutex_lock_common kernel/locking/mutex.c:756 [inline]
        __mutex_lock+0x16f/0x1a80 kernel/locking/mutex.c:893
        mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
        rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
        register_netdevice_notifier+0xad/0x860 net/core/dev.c:1607
        tee_tg_check+0x1a0/0x280 net/netfilter/xt_TEE.c:106
        xt_check_target+0x22c/0x7d0 net/netfilter/x_tables.c:845
        check_target net/ipv6/netfilter/ip6_tables.c:538 [inline]
        translate_table+0xf52/0x1690 net/ipv6/netfilter/ip6_tables.c:749
        do_replace net/ipv6/netfilter/ip6_tables.c:1165 [inline]
        do_ip6t_set_ctl+0x370/0x5f0 net/ipv6/netfilter/ip6_tables.c:1691
        nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
        nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115
        ipv6_setsockopt+0x115/0x150 net/ipv6/ipv6_sockglue.c:928
        udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1422
        sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978
        SYSC_setsockopt net/socket.c:1849 [inline]
        SyS_setsockopt+0x189/0x360 net/socket.c:1828

-> #0 (sk_lock-AF_INET6){+.+.}:
        lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3914
        lock_sock_nested+0xc2/0x110 net/core/sock.c:2780
        lock_sock include/net/sock.h:1463 [inline]
        do_ipv6_setsockopt.isra.8+0x3c5/0x39d0 net/ipv6/ipv6_sockglue.c:167
        ipv6_setsockopt+0xd7/0x150 net/ipv6/ipv6_sockglue.c:922
        udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1422
        sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978
        SYSC_setsockopt net/socket.c:1849 [inline]
        SyS_setsockopt+0x189/0x360 net/socket.c:1828

other info that might help us debug this:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----

  *** DEADLOCK ***

1 lock held by syzkaller041579/3682:
  #0:  (rtnl_mutex){+.+.}, at: [<000000004342eaa9>] rtnl_lock+0x17/0x20

The problem, as Florian noted, is that nf_setsockopt() is always
called with the socket held, even if the lock itself is required only
for very tight scopes and only for some operation.

This patch addresses the issues moving the lock_sock() call only
where really needed, namely in ipv*_getorigdst(), so that nf_setsockopt()
does not need anymore to acquire both locks.

Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
Suggested-by: Florian Westphal <>
Signed-off-by: Paolo Abeni <>
Signed-off-by: Pablo Neira Ayuso <>
[bwh: Backported to 3.2: Drop changes to ipv6_getorigdst()]
Signed-off-by: Ben Hutchings <>
3 years agonetfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
Dmitry Vyukov [Tue, 30 Jan 2018 14:21:34 +0000 (15:21 +0100)]
netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()

commit 1a38956cce5eabd7b74f94bab70265e4df83165e upstream.

Commit 136e92bbec0a switched local_nodes from an array to a bitmask
but did not add proper bounds checks. As the result
clusterip_config_init_nodelist() can both over-read
ipt_clusterip_tgt_info.local_nodes and over-write

Add bounds checks for both.

Fixes: 136e92bbec0a ("[NETFILTER] CLUSTERIP: use a bitmap to store node responsibility data")
Signed-off-by: Dmitry Vyukov <>
Reported-by: syzbot <>
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>
3 years agoscsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
Tyrel Datwyler [Wed, 24 Jan 2018 02:11:32 +0000 (20:11 -0600)]
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info

commit c39813652700f3df552b6557530f1e5f782dbe2f upstream.

The fcp_rsp_info structure as defined in the FC spec has an initial 3
bytes reserved field. The ibmvfc driver mistakenly defined this field as
4 bytes resulting in the rsp_code field being defined in what should be
the start of the second reserved field and thus always being reported as
zero by the driver.

Ideally, we should wire ibmvfc up with libfc for the sake of code
deduplication, and ease of maintaining standardized structures in a
single place. However, for now simply fixup the definition in ibmvfc for
backporting to distros on older kernels. Wiring up with libfc will be
done in a followup patch.

Reported-by: Hannes Reinecke <>
Signed-off-by: Tyrel Datwyler <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agomedia: cxusb, dib0700: ignore XC2028_I2C_FLUSH
Mauro Carvalho Chehab [Wed, 24 Jan 2018 11:01:57 +0000 (06:01 -0500)]
media: cxusb, dib0700: ignore XC2028_I2C_FLUSH

commit 9893b905e743ded332575ca04486bd586c0772f7 upstream.

The XC2028_I2C_FLUSH only needs to be implemented on a few
devices. Others can safely ignore it.

That prevents filling the dmesg with lots of messages like:

dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0

Fixes: 4d37ece757a8 ("[media] tuner/xc2028: Add I2C flush callback")
Reported-by: Enrico Mioso <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filenames]
Signed-off-by: Ben Hutchings <>
3 years agojffs2: Fix use-after-free bug in jffs2_iget()'s error handling path
Jake Daryll Obina [Thu, 21 Sep 2017 16:00:14 +0000 (00:00 +0800)]
jffs2: Fix use-after-free bug in jffs2_iget()'s error handling path

commit 5bdd0c6f89fba430e18d636493398389dadc3b17 upstream.

If jffs2_iget() fails for a newly-allocated inode, jffs2_do_clear_inode()
can get called twice in the error handling path, the first call in
jffs2_iget() itself and the second through iget_failed(). This can result
to a use-after-free error in the second jffs2_do_clear_inode() call, such
as shown by the oops below wherein the second jffs2_do_clear_inode() call
was trying to free node fragments that were already freed in the first
jffs2_do_clear_inode() call.

[   78.178860] jffs2: error: (1904) jffs2_do_read_inode_internal: CRC failed for read_inode of inode 24 at physical location 0x1fc00c
[   78.178914] Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b7b
[   78.185871] pgd = ffffffc03a567000
[   78.188794] [6b6b6b6b6b6b6b7b] *pgd=0000000000000000, *pud=0000000000000000
[   78.194968] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[   78.513147] PC is at rb_first_postorder+0xc/0x28
[   78.516503] LR is at jffs2_kill_fragtree+0x28/0x90 [jffs2]
[   78.520672] pc : [<ffffff8008323d28>] lr : [<ffffff8000eb1cc8>] pstate: 60000105
[   78.526757] sp : ffffff800cea38f0
[   78.528753] x29: ffffff800cea38f0 x28: ffffffc01f3f8e80
[   78.532754] x27: 0000000000000000 x26: ffffff800cea3c70
[   78.536756] x25: 00000000dc67c8ae x24: ffffffc033d6945d
[   78.540759] x23: ffffffc036811740 x22: ffffff800891a5b8
[   78.544760] x21: 0000000000000000 x20: 0000000000000000
[   78.548762] x19: ffffffc037d48910 x18: ffffff800891a588
[   78.552764] x17: 0000000000000800 x16: 0000000000000c00
[   78.556766] x15: 0000000000000010 x14: 6f2065646f6e695f
[   78.560767] x13: 6461657220726f66 x12: 2064656c69616620
[   78.564769] x11: 435243203a6c616e x10: 7265746e695f6564
[   78.568771] x9 : 6f6e695f64616572 x8 : ffffffc037974038
[   78.572774] x7 : bbbbbbbbbbbbbbbb x6 : 0000000000000008
[   78.576775] x5 : 002f91d85bd44a2f x4 : 0000000000000000
[   78.580777] x3 : 0000000000000000 x2 : 000000403755e000
[   78.584779] x1 : 6b6b6b6b6b6b6b6b x0 : 6b6b6b6b6b6b6b6b
[   79.038551] [<ffffff8008323d28>] rb_first_postorder+0xc/0x28
[   79.042962] [<ffffff8000eb5578>] jffs2_do_clear_inode+0x88/0x100 [jffs2]
[   79.048395] [<ffffff8000eb9ddc>] jffs2_evict_inode+0x3c/0x48 [jffs2]
[   79.053443] [<ffffff8008201ca8>] evict+0xb0/0x168
[   79.056835] [<ffffff8008202650>] iput+0x1c0/0x200
[   79.060228] [<ffffff800820408c>] iget_failed+0x30/0x3c
[   79.064097] [<ffffff8000eba0c0>] jffs2_iget+0x2d8/0x360 [jffs2]
[   79.068740] [<ffffff8000eb0a60>] jffs2_lookup+0xe8/0x130 [jffs2]
[   79.073434] [<ffffff80081f1a28>] lookup_slow+0x118/0x190
[   79.077435] [<ffffff80081f4708>] walk_component+0xfc/0x28c
[   79.081610] [<ffffff80081f4dd0>] path_lookupat+0x84/0x108
[   79.085699] [<ffffff80081f5578>] filename_lookup+0x88/0x100
[   79.089960] [<ffffff80081f572c>] user_path_at_empty+0x58/0x6c
[   79.094396] [<ffffff80081ebe14>] vfs_statx+0xa4/0x114
[   79.098138] [<ffffff80081ec44c>] SyS_newfstatat+0x58/0x98
[   79.102227] [<ffffff800808354c>] __sys_trace_return+0x0/0x4
[   79.106489] Code: d65f03c0 f9400001 b40000e1 aa0103e0 (f9400821)

The jffs2_do_clear_inode() call in jffs2_iget() is unnecessary since
iget_failed() will eventually call jffs2_do_clear_inode() if needed, so
just remove it.

Fixes: 5451f79f5f81 ("iget: stop JFFS2 from using iget() and read_inode()")
Reviewed-by: Richard Weinberger <>
Signed-off-by: Jake Daryll Obina <>
Signed-off-by: Al Viro <>
Signed-off-by: Ben Hutchings <>
3 years agoUSB: serial: pl2303: new device id for Chilitag
Greg Kroah-Hartman [Thu, 25 Jan 2018 08:48:55 +0000 (09:48 +0100)]
USB: serial: pl2303: new device id for Chilitag

commit d08dd3f3dd2ae351b793fc5b76abdbf0fd317b12 upstream.

This adds a new device id for Chilitag devices to the pl2303 driver.

Reported-by: "Chu.Mike [朱堅宜]" <>
Acked-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
3 years agocifs: Fix missing put_xid in cifs_file_strict_mmap
Matthew Wilcox [Fri, 15 Dec 2017 20:48:32 +0000 (12:48 -0800)]
cifs: Fix missing put_xid in cifs_file_strict_mmap

commit f04a703c3d613845ae3141bfaf223489de8ab3eb upstream.

If cifs_zap_mapping() returned an error, we would return without putting
the xid that we got earlier.  Restructure cifs_file_strict_mmap() and
cifs_file_mmap() to be more similar to each other and have a single
point of return that always puts the xid.

Signed-off-by: Matthew Wilcox <>
Signed-off-by: Steve French <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoHID: roccat: prevent an out of bounds read in kovaplus_profile_activated()
Dan Carpenter [Wed, 10 Jan 2018 09:39:03 +0000 (12:39 +0300)]
HID: roccat: prevent an out of bounds read in kovaplus_profile_activated()

commit 7ad81482cad67cbe1ec808490d1ddfc420c42008 upstream.

We get the "new_profile_index" value from the mouse device when we're
handling raw events.  Smatch taints it as untrusted data and complains
that we need a bounds check.  This seems like a reasonable warning
otherwise there is a small read beyond the end of the array.

Fixes: 0e70f97f257e ("HID: roccat: Add support for Kova[+] mouse")
Signed-off-by: Dan Carpenter <>
Acked-by: Silvan Jegen <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Ben Hutchings <>
3 years agos390: fix handling of -1 in set{,fs}[gu]id16 syscalls
Eugene Syromiatnikov [Mon, 15 Jan 2018 19:38:17 +0000 (20:38 +0100)]
s390: fix handling of -1 in set{,fs}[gu]id16 syscalls

commit 6dd0d2d22aa363fec075cb2577ba273ac8462e94 upstream.

For some reason, the implementation of some 16-bit ID system calls
(namely, setuid16/setgid16 and setfsuid16/setfsgid16) used type cast
instead of low2highgid/low2highuid macros for converting [GU]IDs, which
led to incorrect handling of value of -1 (which ought to be considered

Discovered by strace test suite.

Signed-off-by: Eugene Syromiatnikov <>
Signed-off-by: Heiko Carstens <>
Signed-off-by: Martin Schwidefsky <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoscsi: fas216: fix sense buffer initialization
Arnd Bergmann [Thu, 18 Jan 2018 13:16:38 +0000 (14:16 +0100)]
scsi: fas216: fix sense buffer initialization

commit 96d5eaa9bb74d299508d811d865c2c41b38b0301 upstream.

While testing with the ARM specific memset() macro removed, I ran into a
compiler warning that shows an old bug:

drivers/scsi/arm/fas216.c: In function 'fas216_rq_sns_done':
drivers/scsi/arm/fas216.c:2014:40: error: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to provide an explicit length? [-Werror=sizeof-pointer-memaccess]

It turns out that the definition of the scsi_cmd structure changed back
in linux-2.6.25, so now we clear only four bytes (sizeof(pointer))
instead of 96 (SCSI_SENSE_BUFFERSIZE). I did not check whether we
actually need to initialize the buffer here, but it's clear that if we
do it, we should use the correct size.

Fixes: de25deb18016 ("[SCSI] use dynamically allocated sense buffer")
Signed-off-by: Arnd Bergmann <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
3 years agoCDC-ACM: apply quirk for card reader
Oliver Neukum [Thu, 18 Jan 2018 11:13:45 +0000 (12:13 +0100)]
CDC-ACM: apply quirk for card reader

commit df1cc78a52491f71d8170d513d0f6f114faa1bda upstream.

This devices drops random bytes from messages if you talk to it
too fast.

Signed-off-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
3 years agoalpha: fix crash if pthread_create races with signal delivery
Mikulas Patocka [Tue, 2 Jan 2018 19:01:34 +0000 (14:01 -0500)]
alpha: fix crash if pthread_create races with signal delivery

commit 21ffceda1c8b3807615c40d440d7815e0c85d366 upstream.

On alpha, a process will crash if it attempts to start a thread and a
signal is delivered at the same time. The crash can be reproduced with
this program:

The reason for the crash is this:
* we call the clone syscall
* we go to the function copy_process
* copy process calls copy_thread_tls, it is a wrapper around copy_thread
* copy_thread sets the tls pointer: childti->pcb.unique = regs->r20
* copy_thread sets regs->r20 to zero
* we go back to copy_process
* copy process checks "if (signal_pending(current))" and returns
* the clone syscall is restarted, but this time, regs->r20 is zero, so
  the new thread is created with zero tls pointer
* the new thread crashes in start_thread when attempting to access tls

The comment in the code says that setting the register r20 is some
compatibility with OSF/1. But OSF/1 doesn't use the CLONE_SETTLS flag, so
we don't have to zero r20 if CLONE_SETTLS is set. This patch fixes the bug
by zeroing regs->r20 only if CLONE_SETTLS is not set.

Signed-off-by: Mikulas Patocka <>
Signed-off-by: Matt Turner <>
[bwh: Backported to 3.2:
 - Remove the settls variable, which was done upstream in commit 25906730ec01
   "alpha: reorganize copy_process(), prepare to saner fork_idle()"]
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoalpha: fix reboot on Avanti platform
Mikulas Patocka [Tue, 2 Jan 2018 18:59:54 +0000 (13:59 -0500)]
alpha: fix reboot on Avanti platform

commit 55fc633c41a08ce9244ff5f528f420b16b1e04d6 upstream.

We need to define NEED_SRM_SAVE_RESTORE on the Avanti, otherwise we get
machine check exception when attempting to reboot the machine.

Signed-off-by: Mikulas Patocka <>
Signed-off-by: Matt Turner <>
Signed-off-by: Ben Hutchings <>
3 years agoMIPS: Fix clean of vmlinuz.{32,ecoff,bin,srec}
James Hogan [Tue, 16 Jan 2018 21:38:24 +0000 (21:38 +0000)]
MIPS: Fix clean of vmlinuz.{32,ecoff,bin,srec}

commit 5f2483eb2423152445b39f2db59d372f523e664e upstream.

Make doesn't expand shell style "vmlinuz.{32,ecoff,bin,srec}" to the 4
separate files, so none of these files get cleaned up by make clean.
List the files separately instead.

Fixes: ec3352925b74 ("MIPS: Remove all generated vmlinuz* files on "make clean"")
Signed-off-by: James Hogan <>
Cc: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
3 years agodrm/ttm: Don't add swapped BOs to swap-LRU list
Felix Kuehling [Thu, 18 Jan 2018 04:52:03 +0000 (23:52 -0500)]
drm/ttm: Don't add swapped BOs to swap-LRU list

commit fd5002d6a3c602664b07668a24df4ef7a43bf078 upstream.

A BO that's already swapped would be added back to the swap-LRU list
for example if its validation failed under high memory pressure. This
could later lead to swapping it out again and leaking previous swap

This commit adds a condition to prevent that from happening.

v2: Check page_flags instead of swap_storage

Signed-off-by: Felix Kuehling <>
Reviewed-by: Christian König <>
Signed-off-by: Alex Deucher <>
[bwh: Backported to 3.2: We aren't checking for TTM_PAGE_FLAG_SG here as that's
 not defined]
Signed-off-by: Ben Hutchings <>
3 years agoubi: Fix race condition between ubi volume creation and udev
Clay McClure [Fri, 22 Sep 2017 02:01:34 +0000 (19:01 -0700)]
ubi: Fix race condition between ubi volume creation and udev

commit a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 upstream.

Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi
device creation and udev"), we should make the volume active before
registering it.

Signed-off-by: Clay McClure <>
Signed-off-by: Richard Weinberger <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agodm thin: fix documentation relative to low water mark threshold
mulhern [Mon, 27 Nov 2017 15:02:39 +0000 (10:02 -0500)]
dm thin: fix documentation relative to low water mark threshold

commit 9b28a1102efc75d81298198166ead87d643a29ce upstream.

1. The use of "exceeds" when the opposite of exceeds, falls below,
was meant.
2. Properly speaking, a table can not exceed a threshold.

It emphasizes the important point, which is that it is the userspace
daemon's responsibility to check for low free space when a device
is resumed, since it won't get a special event indicating low free
space in that situation.

Signed-off-by: mulhern <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Ben Hutchings <>
3 years agoUSB: cdc-acm: Do not log urb submission errors on disconnect
Hans de Goede [Sun, 14 Jan 2018 15:09:00 +0000 (16:09 +0100)]
USB: cdc-acm: Do not log urb submission errors on disconnect

commit f0386c083c2ce85284dc0b419d7b89c8e567c09f upstream.

When disconnected sometimes the cdc-acm driver logs errors like these:

[20278.039417] cdc_acm 2-2:2.1: urb 9 failed submission with -19
[20278.042924] cdc_acm 2-2:2.1: urb 10 failed submission with -19
[20278.046449] cdc_acm 2-2:2.1: urb 11 failed submission with -19
[20278.049920] cdc_acm 2-2:2.1: urb 12 failed submission with -19
[20278.053442] cdc_acm 2-2:2.1: urb 13 failed submission with -19
[20278.056915] cdc_acm 2-2:2.1: urb 14 failed submission with -19
[20278.060418] cdc_acm 2-2:2.1: urb 15 failed submission with -19

Silence these by not logging errors when the result is -ENODEV.

Signed-off-by: Hans de Goede <>
Acked-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
3 years agohrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
Anna-Maria Gleixner [Thu, 21 Dec 2017 10:41:35 +0000 (11:41 +0100)]
hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)

commit 48d0c9becc7f3c66874c100c126459a9da0fdced upstream.

The POSIX specification defines that relative CLOCK_REALTIME timers are not
affected by clock modifications. Those timers have to use CLOCK_MONOTONIC
to ensure POSIX compliance.

The introduction of the additional HRTIMER_MODE_PINNED mode broke this
requirement for pinned timers.

There is no user space visible impact because user space timers are not
using pinned mode, but for consistency reasons this needs to be fixed.

Check whether the mode has the HRTIMER_MODE_REL bit set instead of
comparing with HRTIMER_MODE_ABS.

Signed-off-by: Anna-Maria Gleixner <>
Cc: Christoph Hellwig <>
Cc: John Stultz <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Fixes: 597d0275736d ("timers: Framework for identifying pinned timers")
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
3 years agoASoC: au1x: Fix timeout tests in au1xac97c_ac97_read()
Dan Carpenter [Mon, 15 Jan 2018 08:08:38 +0000 (11:08 +0300)]
ASoC: au1x: Fix timeout tests in au1xac97c_ac97_read()

commit 123af9043e93cb6f235207d260d50f832cdb5439 upstream.

The loop timeout doesn't work because it's a post op and ends with "tmo"
set to -1.  I changed it from a post-op to a pre-op and I changed the
initial the starting value from 5 to 6 so we still iterate 5 times.  I
left the other as it was because it's a large number.

Fixes: b3c70c9ea62a ("ASoC: Alchemy AC97C/I2SC audio support")
Signed-off-by: Dan Carpenter <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
3 years agoconsole/dummy: leave .con_font_get set to NULL
Nicolas Pitre [Mon, 15 Jan 2018 16:04:22 +0000 (17:04 +0100)]
console/dummy: leave .con_font_get set to NULL

commit 724ba8b30b044aa0d94b1cd374fc15806cdd6f18 upstream.

When this method is set, the caller expects struct console_font fields
to be properly initialized when it returns. Leave it unset otherwise
nonsensical (leaked kernel stack) values are returned to user space.

Signed-off-by: Nicolas Pitre <>
Signed-off-by: Bartlomiej Zolnierkiewicz <>
Signed-off-by: Ben Hutchings <>
3 years agomn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
Eric W. Biederman [Tue, 1 Aug 2017 10:02:38 +0000 (05:02 -0500)]
mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy

commit 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd upstream.

Setting si_code to 0 is the same a setting si_code to SI_USER which is definitely
not correct.  With si_code set to SI_USER si_pid and si_uid will be copied to
userspace instead of si_addr.  Which is very wrong.

So fix this by using a sensible si_code (SEGV_MAPERR) for this failure.

Fixes: b920de1b77b7 ("mn10300: add the MN10300/AM33 architecture to the kernel")
Cc: David Howells <>
Cc: Masakazu Urade <>
Cc: Koichi Yasutake <>
Signed-off-by: "Eric W. Biederman" <>
Signed-off-by: Ben Hutchings <>
3 years agosignal/openrisc: Fix do_unaligned_access to send the proper signal
Eric W. Biederman [Tue, 1 Aug 2017 09:16:47 +0000 (04:16 -0500)]
signal/openrisc: Fix do_unaligned_access to send the proper signal

commit 500d58300571b6602341b041f97c082a461ef994 upstream.

While reviewing the signal sending on openrisc the do_unaligned_access
function stood out because it is obviously wrong.  A comment about an
si_code set above when actually si_code is never set.  Leading to a
random si_code being sent to userspace in the event of an unaligned

Looking further SIGBUS BUS_ADRALN is the proper pair of signal and
si_code to send for an unaligned access. That is what other
architectures do and what is required by posix.

Given that do_unaligned_access is broken in a way that no one can be
relying on it on openrisc fix the code to just do the right thing.

Fixes: 769a8a96229e ("OpenRISC: Traps")
Cc: Jonas Bonn <>
Cc: Stefan Kristiansson <>
Cc: Stafford Horne <>
Cc: Arnd Bergmann <>
Acked-by: Stafford Horne <>
Signed-off-by: "Eric W. Biederman" <>
Signed-off-by: Ben Hutchings <>
3 years agocrypto: hash - prevent using keyed hashes without setting key
Eric Biggers [Wed, 3 Jan 2018 19:16:27 +0000 (11:16 -0800)]
crypto: hash - prevent using keyed hashes without setting key

commit 9fa68f620041be04720d0cbfb1bd3ddfc6310b24 upstream.

Currently, almost none of the keyed hash algorithms check whether a key
has been set before proceeding.  Some algorithms are okay with this and
will effectively just use a key of all 0's or some other bogus default.
However, others will severely break, as demonstrated using
"hmac(sha3-512-generic)", the unkeyed use of which causes a kernel crash
via a (potentially exploitable) stack buffer overflow.

A while ago, this problem was solved for AF_ALG by pairing each hash
transform with a 'has_key' bool.  However, there are still other places
in the kernel where userspace can specify an arbitrary hash algorithm by
name, and the kernel uses it as unkeyed hash without checking whether it
is really unkeyed.  Examples of this include:

    - KEYCTL_DH_COMPUTE, via the KDF extension
    - dm-verity
    - dm-crypt, via the ESSIV support
    - dm-integrity, via the "internal hash" mode with no key given
    - drbd (Distributed Replicated Block Device)

This bug is especially bad for KEYCTL_DH_COMPUTE as that requires no
privileges to call.

Fix the bug for all users by adding a flag CRYPTO_TFM_NEED_KEY to the
->crt_flags of each hash transform that indicates whether the transform
still needs to be keyed or not.  Then, make the hash init, import, and
digest functions return -ENOKEY if the key is still needed.

The new flag also replaces the 'has_key' bool which algif_hash was
previously using, thereby simplifying the algif_hash implementation.

Reported-by: syzbot <>
Signed-off-by: Eric Biggers <>
Signed-off-by: Herbert Xu <>
[bwh: Backported to 3.2:
 - In hash_accept_parent_nokey(), update initialisation of ds to use tfm
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agocrypto: hash - annotate algorithms taking optional key
Eric Biggers [Wed, 3 Jan 2018 19:16:26 +0000 (11:16 -0800)]
crypto: hash - annotate algorithms taking optional key

commit a208fa8f33031b9e0aba44c7d1b7e68eb0cbd29e upstream.

We need to consistently enforce that keyed hashes cannot be used without
setting the key.  To do this we need a reliable way to determine whether
a given hash algorithm is keyed or not.  AF_ALG currently does this by
checking for the presence of a ->setkey() method.  However, this is
actually slightly broken because the CRC-32 algorithms implement
->setkey() but can also be used without a key.  (The CRC-32 "key" is not
actually a cryptographic key but rather represents the initial state.
If not overridden, then a default initial state is used.)

Prepare to fix this by introducing a flag CRYPTO_ALG_OPTIONAL_KEY which
indicates that the algorithm has a ->setkey() method, but it is not
required to be called.  Then set it on all the CRC-32 algorithms.

The same also applies to the Adler-32 implementation in Lustre.

Also, the cryptd and mcryptd templates have to pass through the flag
from their underlying algorithm.

Signed-off-by: Eric Biggers <>
Signed-off-by: Herbert Xu <>
[bwh: Backported to 3.2:
 - Drop changes to nonexistent drivers
 - There's no CRYPTO_ALG_INTERNAL flag
 - Adjust filenames]
Signed-off-by: Ben Hutchings <>
3 years agocrypto: cryptd - pass through absence of ->setkey()
Eric Biggers [Wed, 3 Jan 2018 19:16:23 +0000 (11:16 -0800)]
crypto: cryptd - pass through absence of ->setkey()

commit 841a3ff329713f796a63356fef6e2f72e4a3f6a3 upstream.

When the cryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the cryptd instance.  This change
is necessary for cryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.

Signed-off-by: Eric Biggers <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
3 years agocrypto: hash - introduce crypto_hash_alg_has_setkey()
Eric Biggers [Wed, 3 Jan 2018 19:16:22 +0000 (11:16 -0800)]
crypto: hash - introduce crypto_hash_alg_has_setkey()

commit cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba upstream.

Templates that use an shash spawn can use crypto_shash_alg_has_setkey()
to determine whether the underlying algorithm requires a key or not.
But there was no corresponding function for ahash spawns.  Add it.

Note that the new function actually has to support both shash and ahash
algorithms, since the ahash API can be used with either.

Signed-off-by: Eric Biggers <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
3 years agocrypto: af_alg - whitelist mask and type
Stephan Mueller [Tue, 2 Jan 2018 07:55:25 +0000 (08:55 +0100)]
crypto: af_alg - whitelist mask and type

commit bb30b8848c85e18ca7e371d0a869e94b3e383bdf upstream.

The user space interface allows specifying the type and mask field used
to allocate the cipher. Only a subset of the possible flags are intended
for user space. Therefore, white-list the allowed flags.

In case the user space caller uses at least one non-allowed flag, EINVAL
is returned.

Reported-by: syzbot <>
Signed-off-by: Stephan Mueller <>
Signed-off-by: Herbert Xu <>
[bwh: Backported to 3.2: The CRYPTO_ALG_KERN_DRIVER_ONLY flag is not supported,
 so set allowed to 0]
Signed-off-by: Ben Hutchings <>
3 years agoext4: correct documentation for grpid mount option
Ernesto A. Fernández [Thu, 11 Jan 2018 18:43:33 +0000 (13:43 -0500)]
ext4: correct documentation for grpid mount option

commit 9f0372488cc9243018a812e8cfbf27de650b187b upstream.

The grpid option is currently described as being the same as nogrpid.

Signed-off-by: Ernesto A. Fernández <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
3 years agoext4: save error to disk in __ext4_grp_locked_error()
Zhouyi Zhou [Wed, 10 Jan 2018 05:34:19 +0000 (00:34 -0500)]
ext4: save error to disk in __ext4_grp_locked_error()

commit 06f29cc81f0350261f59643a505010531130eea0 upstream.

In the function __ext4_grp_locked_error(), __save_error_info()
is called to save error info in super block block, but does not sync
that information to disk to info the subsequence fsck after reboot.

This patch writes the error information to disk.  After this patch,
I think there is no obvious EXT4 error handle branches which leads to
"Remounting filesystem read-only" will leave the disk partition miss
the subsequence fsck.

Signed-off-by: Zhouyi Zhou <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
3 years agoscsi: aacraid: remove redundant setting of variable c
Colin Ian King [Fri, 5 Jan 2018 15:31:06 +0000 (15:31 +0000)]
scsi: aacraid: remove redundant setting of variable c

commit 91814744646351a470f256fbcb853fb5a7229a9f upstream.

A previous commit no longer stores the contents of c, so we now have a
situation where c is being updated but the value is never read. Clean up
the code by removing the now redundant setting of variable c.

Cleans up clang warning:
drivers/scsi/aacraid/aachba.c:943:3: warning: Value stored to 'c' is
never read

Fixes: f4e8708d3104 ("scsi: aacraid: Fix udev inquiry race condition")
Signed-off-by: Colin Ian King <>
Reviewed-by: Raghava Aditya Renukunta <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
3 years agoscsi: libsas: fix error when getting phy events
Jason Yan [Thu, 4 Jan 2018 13:04:32 +0000 (21:04 +0800)]
scsi: libsas: fix error when getting phy events

commit 2b23d9509fd7174b362482cf5f3b5f9a2265bc33 upstream.

The intend purpose here was to goto out if smp_execute_task() returned
error. Obviously something got screwed up. We will never get these link
error statistics below:

~:/sys/class/sas_phy/phy-1:0:12 # cat invalid_dword_count
~:/sys/class/sas_phy/phy-1:0:12 # cat running_disparity_error_count
~:/sys/class/sas_phy/phy-1:0:12 # cat loss_of_dword_sync_count
~:/sys/class/sas_phy/phy-1:0:12 # cat phy_reset_problem_count

Obviously we should goto error handler if smp_execute_task() returns

Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
Signed-off-by: Jason Yan <>
CC: John Garry <>
CC: chenqilin <>
CC: chenxiang <>
Reviewed-by: Hannes Reinecke <>
Reviewed-by: Christoph Hellwig <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
3 years agosignal/sh: Ensure si_signo is initialized in do_divide_error
Eric W. Biederman [Mon, 24 Jul 2017 22:30:30 +0000 (17:30 -0500)]
signal/sh: Ensure si_signo is initialized in do_divide_error

commit 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 upstream.

Set si_signo.

Cc: Yoshinori Sato <>
Cc: Rich Felker <>
Cc: Paul Mundt <>
Fixes: 0983b31849bb ("sh: Wire up division and address error exceptions on SH-2A.")
Signed-off-by: "Eric W. Biederman" <>
Signed-off-by: Ben Hutchings <>
3 years agopktcdvd: Fix pkt_setup_dev() error path
Bart Van Assche [Tue, 2 Jan 2018 19:39:47 +0000 (11:39 -0800)]
pktcdvd: Fix pkt_setup_dev() error path

commit 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd upstream.

Commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
modified add_disk() and disk_release() but did not update any of the
error paths that trigger a put_disk() call after disk->queue has been
assigned. That introduced the following behavior in the pktcdvd driver
if pkt_new_dev() fails:

Kernel BUG at 00000000e98fd882 [verbose debug info unavailable]

Since disk_release() calls blk_put_queue() anyway if disk->queue != NULL,
fix this by removing the blk_cleanup_queue() call from the pkt_setup_dev()
error path.

Fixes: commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
Signed-off-by: Bart Van Assche <>
Cc: Tejun Heo <>
Cc: Maciej S. Szmigiero <>
Signed-off-by: Jens Axboe <>
Signed-off-by: Ben Hutchings <>
3 years agoscsi: aacraid: Fix udev inquiry race condition
Raghava Aditya Renukunta [Wed, 27 Dec 2017 04:34:22 +0000 (20:34 -0800)]
scsi: aacraid: Fix udev inquiry race condition

commit f4e8708d3104437fd7716e957f38c265b0c509ef upstream.

When udev requests for a devices inquiry string, it might create multiple
threads causing a race condition on the shared inquiry resource string.

Created a buffer with the string for each thread.

Fixes: 3bc8070fb75b3315 ([SCSI] aacraid: SMC vendor identification)
Signed-off-by: Raghava Aditya Renukunta <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2:
 - s/sup_adap_info->adapter_type_text/dev->supplement_adapter_info.AdapterTypeText/
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agol2tp: fix missing print session offset info
Hangbin Liu [Fri, 22 Dec 2017 14:10:17 +0000 (15:10 +0100)]
l2tp: fix missing print session offset info

commit 820da5357572715c6235ba3b3daa2d5b43a1198f upstream.

Report offset parameter in L2TP_CMD_SESSION_GET command if
it has been configured by userspace

Fixes: 309795f4bec ("l2tp: Add netlink control API for L2TP")
Reported-by: Jianlin Shi <>
Signed-off-by: Hangbin Liu <>
Signed-off-by: Lorenzo Bianconi <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Use NLA_PUT_U16, consistent with the rest of the function
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoath9k_htc: Add a sanity check in ath9k_htc_ampdu_action()
Dan Carpenter [Tue, 5 Dec 2017 14:35:08 +0000 (17:35 +0300)]
ath9k_htc: Add a sanity check in ath9k_htc_ampdu_action()

commit 413fd2f5c0233d3cde391679b967c1f14cd2cb27 upstream.

Smatch generates a warning here:

    drivers/net/wireless/ath/ath9k/htc_drv_main.c:1688 ath9k_htc_ampdu_action()
    error: buffer overflow 'ista->tid_state' 8 <= 15

I don't know if it's a real bug or not but the other paths through this
function all ensure that "tid" is less than ATH9K_HTC_MAX_TID (8) so
checking here makes things more consistent.

Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.")
Signed-off-by: Dan Carpenter <>
Signed-off-by: Kalle Valo <>
Signed-off-by: Ben Hutchings <>
3 years agomedia: bt8xx: Fix err 'bt878_probe()'
Christophe JAILLET [Thu, 21 Sep 2017 23:23:56 +0000 (19:23 -0400)]
media: bt8xx: Fix err 'bt878_probe()'

commit 45392ff6881dbe56d41ef0b17c2e576065f8ffa1 upstream.

This is odd to call 'pci_disable_device()' in an error path before a
coresponding successful 'pci_enable_device()'.

Return directly instead.

Fixes: 77e0be12100a ("V4L/DVB (4176): Bug-fix: Fix memory overflow")

Signed-off-by: Christophe JAILLET <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
3 years agoUSB: serial: io_edgeport: fix possible sleep-in-atomic
Jia-Ju Bai [Wed, 13 Dec 2017 12:34:36 +0000 (20:34 +0800)]
USB: serial: io_edgeport: fix possible sleep-in-atomic

commit c7b8f77872c73f69a16528a9eb87afefcccdc18b upstream.

According to drivers/usb/serial/io_edgeport.c, the driver may sleep
under a spinlock.
The function call path is:
edge_bulk_in_callback (acquire the spinlock)
             usb_kill_urb --> may sleep

To fix it, the redundant usb_kill_urb() is removed from the error path
after usb_submit_urb() fails.

This possible bug is found by my static analysis tool (DSAC) and checked
by my code review.

Signed-off-by: Jia-Ju Bai <>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoASoC: nuc900: Fix a loop timeout test
Dan Carpenter [Sat, 9 Dec 2017 11:52:28 +0000 (14:52 +0300)]
ASoC: nuc900: Fix a loop timeout test

commit 65a12b3aafed5fc59f4ce41b22b752b1729e6701 upstream.

We should be finishing the loop with timeout set to zero but because
this is a post-op we finish with timeout == -1.

Fixes: 1082e2703a2d ("ASoC: NUC900/audio: add nuc900 audio driver support")
Signed-off-by: Dan Carpenter <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
3 years agoslip: sl_alloc(): remove unused parameter "dev_t line"
Marc Kleine-Budde [Fri, 8 Dec 2017 11:18:59 +0000 (12:18 +0100)]
slip: sl_alloc(): remove unused parameter "dev_t line"

commit 936e5d8bdfa72577e28ea671d9e2ee4fef0d6b3e upstream.

The first and only parameter of sl_alloc() is unused, so remove it.

Fixes: 5342b77c4123 slip: ("Clean up create and destroy")
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
3 years agomedia: cpia2: Fix a couple off by one bugs
Dan Carpenter [Thu, 9 Nov 2017 21:28:14 +0000 (16:28 -0500)]
media: cpia2: Fix a couple off by one bugs

commit d5ac225c7d64c9c3ef821239edc035634e594ec9 upstream.

The cam->buffers[] array has cam->num_frames elements so the > needs to
be changed to >= to avoid going beyond the end of the array.  The
->buffers[] array is allocated in cpia2_allocate_buffers() if you want
to confirm.

Fixes: ab33d5071de7 ("V4L/DVB (3376): Add cpia2 camera support")

Signed-off-by: Dan Carpenter <>
Signed-off-by: Hans Verkuil <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
3 years agoperf/hwbp: Simplify the perf-hwbp code, fix documentation
Linus Torvalds [Tue, 27 Mar 2018 01:39:07 +0000 (15:39 -1000)]
perf/hwbp: Simplify the perf-hwbp code, fix documentation

commit f67b15037a7a50c57f72e69a6d59941ad90a0f0f upstream.

Annoyingly, modify_user_hw_breakpoint() unnecessarily complicates the
modification of a breakpoint - simplify it and remove the pointless
local variables.

Also update the stale Docbook while at it.

Signed-off-by: Linus Torvalds <>
Acked-by: Thomas Gleixner <>
Cc: Alexander Shishkin <>
Cc: Andy Lutomirski <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Frederic Weisbecker <>
Cc: Jiri Olsa <>
Cc: Peter Zijlstra <>
Cc: Stephane Eranian <>
Cc: Vince Weaver <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
3 years agoperf/hwpb: Invoke __perf_event_disable() if interrupts are already disabled
K.Prasad [Thu, 2 Aug 2012 08:16:35 +0000 (13:46 +0530)]
perf/hwpb: Invoke __perf_event_disable() if interrupts are already disabled

commit 500ad2d8b01390c98bc6dce068bccfa9534b8212 upstream.

While debugging a warning message on PowerPC while using hardware
breakpoints, it was discovered that when perf_event_disable is invoked
through hw_breakpoint_handler function with interrupts disabled, a
subsequent IPI in the code path would trigger a WARN_ON_ONCE message in
smp_call_function_single function.

This patch calls __perf_event_disable() when interrupts are already
disabled, instead of perf_event_disable().

Reported-by: Edjunior Barbosa Machado <>
Signed-off-by: K.Prasad <>
[ v3: Check to make sure we target current task]
Signed-off-by: Naveen N. Rao <>
Acked-by: Frederic Weisbecker <>
Signed-off-by: Peter Zijlstra <>
[ Fixed build error on MIPS. ]
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
3 years agocdrom: information leak in cdrom_ioctl_media_changed()
Dan Carpenter [Wed, 18 Apr 2018 09:51:31 +0000 (12:51 +0300)]
cdrom: information leak in cdrom_ioctl_media_changed()

commit 9de4ee40547fd315d4a0ed1dd15a2fa3559ad707 upstream.

This cast is wrong.  "cdi->capacity" is an int and "arg" is an unsigned
long.  The way the check is written now, if one of the high 32 bits is
set then we could read outside the info->slots[] array.

This bug is pretty old and it predates git.

Reviewed-by: Christoph Hellwig <>
Signed-off-by: Dan Carpenter <>
Signed-off-by: Jens Axboe <>
Signed-off-by: Ben Hutchings <>
3 years agox86/entry/64: Don't use IST entry for #BP stack
Andy Lutomirski [Thu, 23 Jul 2015 22:37:48 +0000 (15:37 -0700)]
x86/entry/64: Don't use IST entry for #BP stack

commit d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9 upstream.

There's nothing IST-worthy about #BP/int3.  We don't allow kprobes
in the small handful of places in the kernel that run at CPL0 with
an invalid stack, and 32-bit kernels have used normal interrupt
gates for #BP forever.

Furthermore, we don't allow kprobes in places that have usergs while
in kernel mode, so "paranoid" is also unnecessary.

Signed-off-by: Andy Lutomirski <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Thomas Gleixner <>
[carnil: Backport to 3.16:
 - Adjust finename change: arch/x86/kernel/entry_64.S
 - Context changes
[bwh: Rebase on top of "x86/traps: Enable DEBUG_STACK after cpu_init() for
 TRAP_DB/BP", and restore change in trap_init() instead of early_trap_init().
 Backport to 3.2:
 - Use zeroentry macro in entry_64.S
 - Drop changes related to breakpoint-in-NMI support
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agox86/traps: Enable DEBUG_STACK after cpu_init() for TRAP_DB/BP
Wang Nan [Thu, 26 Feb 2015 05:49:39 +0000 (13:49 +0800)]
x86/traps: Enable DEBUG_STACK after cpu_init() for TRAP_DB/BP

commit b4d8327024637cb2a1f7910dcb5d0ad7a096f473 upstream.

Before this patch early_trap_init() installs DEBUG_STACK for
X86_TRAP_BP and X86_TRAP_DB. However, DEBUG_STACK doesn't work
correctly until cpu_init() <-- trap_init().

This patch passes 0 to set_intr_gate_ist() and
set_system_intr_gate_ist() instead of DEBUG_STACK to let it use
same stack as kernel, and installs DEBUG_STACK for them in

As core runs at ring 0 between early_trap_init() and
trap_init(), there is no chance to get a bad stack before

As NMI is also enabled in trap_init(), we don't need to care
about is_debug_stack() and related things used in

Signed-off-by: Wang Nan <>
Reviewed-by: Masami Hiramatsu <>
Acked-by: Steven Rostedt <>
Cc: <>
Cc: <>
Cc: <>
Cc: <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agostaging: ncpfs: memory corruption in ncp_read_kernel()
Dan Carpenter [Mon, 19 Mar 2018 11:07:45 +0000 (14:07 +0300)]
staging: ncpfs: memory corruption in ncp_read_kernel()

commit 4c41aa24baa4ed338241d05494f2c595c885af8f upstream.

If the server is malicious then *bytes_read could be larger than the
size of the "target" buffer.  It would lead to memory corruption when we
do the memcpy().

Reported-by: Dr Silvio Cesare of InfoSect <Silvio Cesare <>
Signed-off-by: Dan Carpenter <>
Signed-off-by: Greg Kroah-Hartman <>
[carnil: backport to 4.9: Files renamed from drivers/staging/ncpfs/ncplib_kernel.c
 to fs/ncpfs/ncplib_kernel.c]
Signed-off-by: Ben Hutchings <>
3 years agox86/MCE: Serialize sysfs changes
Seunghun Han [Tue, 6 Mar 2018 14:21:43 +0000 (15:21 +0100)]
x86/MCE: Serialize sysfs changes

commit b3b7c4795ccab5be71f080774c45bbbcc75c2aaf upstream.

The check_interval file in

  /sys/devices/system/machinecheck/machinecheck<cpu number>

directory is a global timer value for MCE polling. If it is changed by one
CPU, mce_restart() broadcasts the event to other CPUs to delete and restart
the MCE polling timer and __mcheck_cpu_init_timer() reinitializes the
mce_timer variable.

If more than one CPU writes a specific value to the check_interval file
concurrently, mce_timer is not protected from such concurrent accesses and
all kinds of explosions happen. Since only root can write to those sysfs
variables, the issue is not a big deal security-wise.

However, concurrent writes to these configuration variables is void of
reason so the proper thing to do is to serialize the access with a mutex.


 - Make store_int_with_restart() use device_store_ulong() to filter out
   negative intervals
 - Limit min interval to 1 second
 - Correct locking
 - Massage commit message

Signed-off-by: Seunghun Han <>
Signed-off-by: Borislav Petkov <>
Signed-off-by: Thomas Gleixner <>
Cc: Greg Kroah-Hartman <>
Cc: Tony Luck <>
Cc: linux-edac <>
[bwh: Backported to 3.2:
 - MCE device is a sysdev here
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoscsi: libsas: fix memory leak in sas_smp_get_phy_events()
Jason Yan [Thu, 4 Jan 2018 13:04:31 +0000 (21:04 +0800)]
scsi: libsas: fix memory leak in sas_smp_get_phy_events()

commit 4a491b1ab11ca0556d2fda1ff1301e862a2d44c4 upstream.

We've got a memory leak with the following producer:

while true;
do cat /sys/class/sas_phy/phy-1:0:12/invalid_dword_count >/dev/null;

The buffer req is allocated and not freed after we return. Fix it.

Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
Signed-off-by: Jason Yan <>
CC: John Garry <>
CC: chenqilin <>
CC: chenxiang <>
Reviewed-by: Christoph Hellwig <>
Reviewed-by: Hannes Reinecke <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
3 years agohugetlbfs: check for pgoff value overflow
Mike Kravetz [Thu, 22 Mar 2018 23:17:13 +0000 (16:17 -0700)]
hugetlbfs: check for pgoff value overflow

commit 63489f8e821144000e0bdca7e65a8d1cc23a7ee7 upstream.

A vma with vm_pgoff large enough to overflow a loff_t type when
converted to a byte offset can be passed via the remap_file_pages system
call.  The hugetlbfs mmap routine uses the byte offset to calculate
reservations and file size.

A sequence such as:

  mmap(0x20a00000, 0x600000, 0, 0x66033, -1, 0);
  remap_file_pages(0x20a00000, 0x600000, 0, 0x20000000000000, 0);

will result in the following when task exits/file closed,

  kernel BUG at mm/hugetlb.c:749!
  Call Trace:

The overflowed pgoff value causes hugetlbfs to try to set up a mapping
with a negative range (end < start) that leaves invalid state which
causes the BUG.

The previous overflow fix to this code was incomplete and did not take
the remap_file_pages system call into account.

[ v3]
[ include mmdebug.h]
[ fix -ve left shift count on sh]
Fixes: 045c7a3f53d9 ("hugetlbfs: fix offset overflow in hugetlbfs mmap")
Signed-off-by: Mike Kravetz <>
Reported-by: Nic Losby <>
Acked-by: Michal Hocko <>
Cc: "Kirill A . Shutemov" <>
Cc: Yisheng Xie <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2:
 - Use a conditional WARN() instead of VM_WARN()
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agohugetlbfs: fix offset overflow in hugetlbfs mmap
Mike Kravetz [Thu, 13 Apr 2017 21:56:32 +0000 (14:56 -0700)]
hugetlbfs: fix offset overflow in hugetlbfs mmap

commit 045c7a3f53d9403b62d396b6d051c4be5044cdb4 upstream.

If mmap() maps a file, it can be passed an offset into the file at which
the mapping is to start.  Offset could be a negative value when
represented as a loff_t.  The offset plus length will be used to update
the file size (i_size) which is also a loff_t.

Validate the value of offset and offset + length to make sure they do
not overflow and appear as negative.

Found by syzcaller with commit ff8c0c53c475 ("mm/hugetlb.c: don't call
region_abort if region_chg fails") applied.  Prior to this commit, the
overflow would still occur but we would luckily return ENOMEM.

To reproduce:

   mmap(0, 0x2000, 0, 0x40021, 0xffffffffffffffffULL, 0x8000000000000000ULL);

Resulted in,

  kernel BUG at mm/hugetlb.c:742!
  Call Trace:

Fixes: ff8c0c53c475 ("mm/hugetlb.c: don't call region_abort if region_chg fails")
Reported-by: Vegard Nossum <>
Signed-off-by: Mike Kravetz <>
Acked-by: Hillf Danton <>
Cc: Dmitry Vyukov <>
Cc: Michal Hocko <>
Cc: "Kirill A . Shutemov" <>
Cc: Andrey Ryabinin <>
Cc: Naoya Horiguchi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoALSA: seq: More protection for concurrent write and ioctl races
Takashi Iwai [Mon, 5 Mar 2018 21:06:09 +0000 (22:06 +0100)]
ALSA: seq: More protection for concurrent write and ioctl races

commit 7bd80091567789f1c0cb70eb4737aac8bcd2b6b9 upstream.

This patch is an attempt for further hardening against races between
the concurrent write and ioctls.  The previous fix d15d662e89fc
("ALSA: seq: Fix racy pool initializations") covered the race of the
pool initialization at writer and the pool resize ioctl by the
client->ioctl_mutex (CVE-2018-1000004).  However, basically this mutex
should be applied more widely to the whole write operation for
avoiding the unexpected pool operations by another thread.

The only change outside snd_seq_write() is the additional mutex
argument to helper functions, so that we can unlock / relock the given
mutex temporarily during schedule() call for blocking write.

Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations")
Reported-by: 范龙飞 <>
Reported-by: Nicolai Stange <>
Reviewed-and-tested-by: Nicolai Stange <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
3 years agoALSA: seq: correctly detect input buffer overflow
Adam Goode [Wed, 4 Jun 2014 05:02:51 +0000 (01:02 -0400)]
ALSA: seq: correctly detect input buffer overflow

commit 21fd3e956ee8a307a06bc6e095f5767a00eb2a7e upstream.

snd_seq_event_dup returns -ENOMEM in some buffer-full conditions,
but usually returns -EAGAIN. Make -EAGAIN trigger the overflow
condition in snd_seq_fifo_event_in so that the fifo is cleared
and -ENOSPC is returned to userspace as stated in the alsa-lib docs.

Signed-off-by: Adam Goode <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
3 years agoALSA: seq: Don't allow resizing pool in use
Takashi Iwai [Mon, 5 Mar 2018 21:00:55 +0000 (22:00 +0100)]
ALSA: seq: Don't allow resizing pool in use

commit d85739367c6d56e475c281945c68fdb05ca74b4c upstream.

This is a fix for a (sort of) fallout in the recent commit
d15d662e89fc ("ALSA: seq: Fix racy pool initializations") for
As the pool resize deletes the existing cells, it may lead to a race
when another thread is writing concurrently, eventually resulting a

A simple workaround is not to allow the pool resizing when the pool is
in use.  It's an invalid behavior in anyway.

Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations")
Reported-by: 范龙飞 <>
Reported-by: Nicolai Stange <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
3 years agoALSA: seq: Fix racy pool initializations
Takashi Iwai [Mon, 12 Feb 2018 14:20:51 +0000 (15:20 +0100)]
ALSA: seq: Fix racy pool initializations

commit d15d662e89fc667b90cd294b0eb45694e33144da upstream.

ALSA sequencer core initializes the event pool on demand by invoking
snd_seq_pool_init() when the first write happens and the pool is
empty.  Meanwhile user can reset the pool size manually via ioctl
concurrently, and this may lead to UAF or out-of-bound accesses since
the function tries to vmalloc / vfree the buffer.

A simple fix is to just wrap the snd_seq_pool_init() call with the
recently introduced client->ioctl_mutex; as the calls for
snd_seq_pool_init() from other side are always protected with this
mutex, we can avoid the race.

Reported-by: 范龙飞 <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
3 years agofbdev: Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper().
Peter Malone [Wed, 7 Mar 2018 13:00:34 +0000 (14:00 +0100)]
fbdev: Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper().

commit 250c6c49e3b68756b14983c076183568636e2bde upstream.

Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in

'index' is defined as an int in sbusfb_ioctl_helper().
We retrieve this from the user:
if (get_user(index, &c->index) ||
    __get_user(count, &c->count) ||
    __get_user(ured, &c->red) ||
    __get_user(ugreen, &c->green) ||
    __get_user(ublue, &c->blue))
       return -EFAULT;

and then we use 'index' in the following way:
red = cmap->red[index + i] >> 8;
green = cmap->green[index + i] >> 8;
blue = cmap->blue[index + i] >> 8;

This is a classic information leak vulnerability. 'index' should be
an unsigned int, given its usage above.

This patch is straight-forward; it changes 'index' to unsigned int

This patch fixes CVE-2018-6412.

Signed-off-by: Peter Malone <>
Acked-by: Mathieu Malaterre <>
Signed-off-by: Bartlomiej Zolnierkiewicz <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
3 years agosctp: verify size of a new chunk in _sctp_make_chunk()
Alexey Kodanev [Fri, 9 Feb 2018 14:35:23 +0000 (17:35 +0300)]
sctp: verify size of a new chunk in _sctp_make_chunk()

commit 07f2c7ab6f8d0a7e7c5764c4e6cc9c52951b9d9c upstream.

When SCTP makes INIT or INIT_ACK packet the total chunk length
can exceed SCTP_MAX_CHUNK_LEN which leads to kernel panic when
transmitting these packets, e.g. the crash on sending INIT_ACK:

[  597.804948] skbuff: skb_over_panic: text:00000000ffae06e4 len:120168
               put:120156 head:000000007aa47635 data:00000000d991c2de
               tail:0x1d640 end:0xfec0 dev:<NULL>
[  597.976970] ------------[ cut here ]------------
[  598.033408] kernel BUG at net/core/skbuff.c:104!
[  600.314841] Call Trace:
[  600.345829]  <IRQ>
[  600.371639]  ? sctp_packet_transmit+0x2095/0x26d0 [sctp]
[  600.436934]  skb_put+0x16c/0x200
[  600.477295]  sctp_packet_transmit+0x2095/0x26d0 [sctp]
[  600.540630]  ? sctp_packet_config+0x890/0x890 [sctp]
[  600.601781]  ? __sctp_packet_append_chunk+0x3b4/0xd00 [sctp]
[  600.671356]  ? sctp_cmp_addr_exact+0x3f/0x90 [sctp]
[  600.731482]  sctp_outq_flush+0x663/0x30d0 [sctp]
[  600.788565]  ? sctp_make_init+0xbf0/0xbf0 [sctp]
[  600.845555]  ? sctp_check_transmitted+0x18f0/0x18f0 [sctp]
[  600.912945]  ? sctp_outq_tail+0x631/0x9d0 [sctp]
[  600.969936]  sctp_cmd_interpreter.isra.22+0x3be1/0x5cb0 [sctp]
[  601.041593]  ? sctp_sf_do_5_1B_init+0x85f/0xc30 [sctp]
[  601.104837]  ? sctp_generate_t1_cookie_event+0x20/0x20 [sctp]
[  601.175436]  ? sctp_eat_data+0x1710/0x1710 [sctp]
[  601.233575]  sctp_do_sm+0x182/0x560 [sctp]
[  601.284328]  ? sctp_has_association+0x70/0x70 [sctp]
[  601.345586]  ? sctp_rcv+0xef4/0x32f0 [sctp]
[  601.397478]  ? sctp6_rcv+0xa/0x20 [sctp]

Here the chunk size for INIT_ACK packet becomes too big, mostly
because of the state cookie (INIT packet has large size with
many address parameters), plus additional server parameters.

Later this chunk causes the panic in skb_put_data():

          skb_put_data(nskb, chunk->skb->data, chunk->skb->len);

'nskb' (head skb) was previously allocated with packet->size
from u16 'chunk->chunk_hdr->length'.

As suggested by Marcelo we should check the chunk's length in
_sctp_make_chunk() before trying to allocate skb for it and
discard a chunk if its size bigger than SCTP_MAX_CHUNK_LEN.

Signed-off-by: Alexey Kodanev <>
Acked-by: Marcelo Ricardo Leitner <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Keep using WORD_ROUND() instead of SCTP_PAD4()
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agodccp: check sk for closed state in dccp_sendmsg()
Alexey Kodanev [Tue, 6 Mar 2018 19:57:01 +0000 (22:57 +0300)]
dccp: check sk for closed state in dccp_sendmsg()

commit 67f93df79aeefc3add4e4b31a752600f834236e2 upstream.

dccp_disconnect() sets 'dp->dccps_hc_tx_ccid' tx handler to NULL,
therefore if DCCP socket is disconnected and dccp_sendmsg() is
called after it, it will cause a NULL pointer dereference in

This crash and the reproducer was reported by syzbot. Looks like
it is reproduced if commit 69c64866ce07 ("dccp: CVE-2017-8824:
use-after-free in DCCP code") is applied.

Signed-off-by: Alexey Kodanev <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
3 years agoext4: fix bitmap position validation
Lukas Czerner [Tue, 24 Apr 2018 15:31:44 +0000 (11:31 -0400)]
ext4: fix bitmap position validation

commit 22be37acce25d66ecf6403fc8f44df9c5ded2372 upstream.

Currently in ext4_valid_block_bitmap() we expect the bitmap to be
positioned anywhere between 0 and s_blocksize clusters, but that's
wrong because the bitmap can be placed anywhere in the block group. This
causes false positives when validating bitmaps on perfectly valid file
system layouts. Fix it by checking whether the bitmap is within the group

The problem can be reproduced using the following

mkfs -t ext3 -E stride=256 /dev/vdb1
mount /dev/vdb1 /mnt/test
cd /mnt/test
tar xf linux-4.16.3.tar.xz

This will result in the warnings in the logs

EXT4-fs error (device vdb1): ext4_validate_block_bitmap:399: comm tar: bg 84: block 2774529: invalid block bitmap

[ Changed slightly for clarity and to not drop a overflow test -- TYT ]

Signed-off-by: Lukas Czerner <>
Signed-off-by: Theodore Ts'o <>
Reported-by: Ilya Dryomov <>
Fixes: 7dac4a1726a9 ("ext4: add validity checks for bitmap block numbers")
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoext4: add validity checks for bitmap block numbers
Theodore Ts'o [Tue, 27 Mar 2018 03:54:10 +0000 (23:54 -0400)]
ext4: add validity checks for bitmap block numbers

commit 7dac4a1726a9c64a517d595c40e95e2d0d135f6f upstream.

An privileged attacker can cause a crash by mounting a crafted ext4
image which triggers a out-of-bounds read in the function
ext4_valid_block_bitmap() in fs/ext4/balloc.c.

This issue has been assigned CVE-2018-1093.

Reported-by: Wen Xu <>
Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2:
 - In ext4_valid_block_bitmap(), goto err_out on error
 - In ext4_read_{block,inode}_bitmap(), return NULL on error
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoext4: fix block bitmap validation when bigalloc, ^flex_bg
Darrick J. Wong [Mon, 12 May 2014 14:17:55 +0000 (10:17 -0400)]
ext4: fix block bitmap validation when bigalloc, ^flex_bg

commit e674e5cbd0942b42a12106ac0be8330f4301bef4 upstream.

On a bigalloc,^flex_bg filesystem, the ext4_valid_block_bitmap
function fails to convert from blocks to clusters when spot-checking
the validity of the bitmap block that we've just read from disk.  This
causes ext4 to think that the bitmap is garbage, which results in the
block group being taken offline when it's not necessary.  Add in the
necessary EXT4_B2C() calls to perform the conversions.

Signed-off-by: Darrick J. Wong <>
Signed-off-by: "Theodore Ts'o" <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agoext4: fail ext4_iget for root directory if unallocated
Theodore Ts'o [Fri, 30 Mar 2018 01:56:09 +0000 (21:56 -0400)]
ext4: fail ext4_iget for root directory if unallocated

commit 8e4b5eae5decd9dfe5a4ee369c22028f90ab4c44 upstream.

If the root directory has an i_links_count of zero, then when the file
system is mounted, then when ext4_fill_super() notices the problem and
tries to call iput() the root directory in the error return path,
ext4_evict_inode() will try to free the inode on disk, before all of
the file system structures are set up, and this will result in an OOPS
caused by a NULL pointer dereference.

This issue has been assigned CVE-2018-1092.

Reported-by: Wen Xu <>
Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2:
 - Use EIO instead of EFSCORRUPTED
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agonetfilter: ebtables: fix erroneous reject of last rule
Florian Westphal [Thu, 8 Mar 2018 11:54:19 +0000 (12:54 +0100)]
netfilter: ebtables: fix erroneous reject of last rule

commit 932909d9b28d27e807ff8eecb68c7748f6701628 upstream.

The last rule in the blob has next_entry offset that is same as total size.
This made "ebtables32 -A OUTPUT -d de:ad:be:ef:01:02" fail on 64 bit kernel.

Fixes: b71812168571fa ("netfilter: ebtables: CONFIG_COMPAT: don't trust userland offsets")
Signed-off-by: Florian Westphal <>
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>
3 years agonetfilter: ebtables: CONFIG_COMPAT: don't trust userland offsets
Florian Westphal [Mon, 19 Feb 2018 00:24:15 +0000 (01:24 +0100)]
netfilter: ebtables: CONFIG_COMPAT: don't trust userland offsets

commit b71812168571fa55e44cdd0254471331b9c4c4c6 upstream.

We need to make sure the offsets are not out of range of the
total size.
Also check that they are in ascending order.

The WARN_ON triggered by syzkaller (it sets panic_on_warn) is
changed to also bail out, no point in continuing parsing.

Briefly tested with simple ruleset of
-A INPUT --limit 1/s' --log
plus jump to custom chains using 32bit ebtables binary.

Reported-by: <>
Signed-off-by: Florian Westphal <>
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>
3 years agoocfs2: subsystem.su_mutex is required while accessing the item->ci_parent
alex chen [Thu, 16 Nov 2017 01:31:48 +0000 (17:31 -0800)]
ocfs2: subsystem.su_mutex is required while accessing the item->ci_parent

commit 853bc26a7ea39e354b9f8889ae7ad1492ffa28d2 upstream.

The subsystem.su_mutex is required while accessing the item->ci_parent,
otherwise, NULL pointer dereference to the item->ci_parent will be
triggered in the following situation:

add node                     delete node
                                 item->ci_group = NULL;
                                 item->ci_parent = NULL;
  BUG since of NULL pointer dereference to nd_item.ci_parent

Moreover, the o2nm_cluster also should be protected by the

[ v2]
Signed-off-by: Alex Chen <>
Reviewed-by: Jun Piao <>
Reviewed-by: Joseph Qi <>
Cc: Mark Fasheh <>
Cc: Joel Becker <>
Cc: Junxiao Bi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agomm/madvise.c: fix madvise() infinite loop under special circumstances
chenjie [Thu, 30 Nov 2017 00:10:54 +0000 (16:10 -0800)]
mm/madvise.c: fix madvise() infinite loop under special circumstances

commit 6ea8d958a2c95a1d514015d4e29ba21a8c0a1a91 upstream.

MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings.
Unfortunately madvise_willneed() doesn't communicate this information
properly to the generic madvise syscall implementation.  The calling
convention is quite subtle there.  madvise_vma() is supposed to either
return an error or update &prev otherwise the main loop will never
advance to the next vma and it will keep looping for ever without a way
to get out of the kernel.

It seems this has been broken since introduction.  Nobody has noticed
because nobody seems to be using MADVISE_WILLNEED on these DAX mappings.

[ rewrite changelog]
Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place")
Signed-off-by: chenjie <>
Signed-off-by: guoxuenan <>
Acked-by: Michal Hocko <>
Cc: Minchan Kim <>
Cc: zhangyi (F) <>
Cc: Miao Xie <>
Cc: Mike Rapoport <>
Cc: Shaohua Li <>
Cc: Andrea Arcangeli <>
Cc: Mel Gorman <>
Cc: Kirill A. Shutemov <>
Cc: David Rientjes <>
Cc: Anshuman Khandual <>
Cc: Rik van Riel <>
Cc: Carsten Otte <>
Cc: Dan Williams <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
3 years agosctp: Fix mangled IPv4 addresses on a IPv6 listening socket
Jason Gunthorpe [Tue, 26 May 2015 23:30:17 +0000 (17:30 -0600)]
sctp: Fix mangled IPv4 addresses on a IPv6 listening socket

commit 9302d7bb0c5cd46be5706859301f18c137b2439f upstream.

sctp_v4_map_v6 was subtly writing and reading from members
of a union in a way the clobbered data it needed to read before
it read it.

Zeroing the v6 flowinfo overwrites the v4 sin_addr with 0, meaning
that every place that calls sctp_v4_map_v6 gets ::ffff: as the

Reorder things to guarantee correct behaviour no matter what the
union layout is.

This impacts user space clients that open an IPv6 SCTP socket and
receive IPv4 connections. Prior to 299ee user space would see a
sockaddr with AF_INET and a correct address, after 299ee the sockaddr
is AF_INET6, but the address is wrong.

Fixes: 299ee123e198 (sctp: Fixup v4mapped behaviour to comply with Sock API)
Signed-off-by: Jason Gunthorpe <>
Acked-by: Daniel Borkmann <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
3 years agoLinux 3.2.101
Ben Hutchings [Mon, 19 Mar 2018 18:58:41 +0000 (18:58 +0000)]
Linux 3.2.101

3 years agocris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Paul Gortmaker [Wed, 18 Apr 2012 19:58:43 +0000 (21:58 +0200)]
cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile

commit 7b91747d42a1012e3781dd09fa638d113809e3fd upstream.

Most of these have been purged years ago.  This one silently lived
on until commit 69349c2dc01c489eccaa4c472542c08e370c6d7e

    "kconfig: fix IS_ENABLED to not require all options to be defined"

In the above, we use some macro trickery to create a conditional that
is valid in CPP and in C usage.  However that trickery doesn't sit
well if you have the legacy "-traditional" flag enabled.  You'll get:

  AS      arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:
include/linux/kconfig.h:23:0: error: syntax error in macro parameter list
make[2]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1

Everything builds fine w/o "-traditional" so simply drop it from this
location as well.

Signed-off-by: Paul Gortmaker <>
Signed-off-by: Jesper Nilsson <>
Signed-off-by: Ben Hutchings <>
3 years agox86: fix build warnign with 32-bit PAE
Arnd Bergmann [Thu, 15 Feb 2018 15:16:57 +0000 (16:16 +0100)]
x86: fix build warnign with 32-bit PAE

I ran into a 4.9 build warning in randconfig testing, starting with the
KAISER patches:

arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct':
arch/x86/include/asm/pgtable_types.h:208:24: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
arch/x86/kernel/ldt.c:81:6: note: in expansion of macro '__PAGE_KERNEL'

I originally ran into this last year when the patches were part of linux-next,
and tried to work around it by using the proper 'pteval_t' types consistently,
but that caused additional problems.

This takes a much simpler approach, and makes the argument type of the dummy
helper always 64-bit, which is wide enough for any page table layout and
won't hurt since this call is just an empty stub anyway.

Fixes: 8f0baadf2bea ("kaiser: merged update")
Signed-off-by: Arnd Bergmann <>
Acked-by: Kees Cook <>
Acked-by: Hugh Dickins <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
3 years agox86/uaccess: Use __uaccess_begin_nospec() and uaccess_try_nospec
Dan Williams [Tue, 30 Jan 2018 01:02:49 +0000 (17:02 -0800)]
x86/uaccess: Use __uaccess_begin_nospec() and uaccess_try_nospec

commit 304ec1b050310548db33063e567123fae8fd0301 upstream.

Quoting Linus:

    I do think that it would be a good idea to very expressly document
    the fact that it's not that the user access itself is unsafe. I do
    agree that things like "get_user()" want to be protected, but not
    because of any direct bugs or problems with get_user() and friends,
    but simply because get_user() is an excellent source of a pointer
    that is obviously controlled from a potentially attacking user
    space. So it's a prime candidate for then finding _subsequent_
    accesses that can then be used to perturb the cache.

__uaccess_begin_nospec() covers __get_user() and copy_from_iter() where the
limit check is far away from the user pointer de-reference. In those cases
a barrier_nospec() prevents speculation with a potential pointer to
privileged memory. uaccess_try_nospec covers get_user_try.

Suggested-by: Linus Torvalds <>
Suggested-by: Andi Kleen <>
Signed-off-by: Dan Williams <>
Signed-off-by: Thomas Gleixner <>
Cc: Kees Cook <>
Cc: Al Viro <>
[bwh: Backported to 3.2:
 - There's no SMAP support, so use barrier_nospec() directly instead of
 - Convert several more functions to use barrier_nospec(), that are just
   wrappers in mainline
 - There's no 'case 8' in __copy_to_user_inatomic()
 - Adjust context]
Signed-off-by: Ben Hutchings <>
3 years agox86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
Dan Williams [Tue, 30 Jan 2018 01:02:39 +0000 (17:02 -0800)]
x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec

commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd upstream.

For __get_user() paths, do not allow the kernel to speculate on the value
of a user controlled pointer. In addition to the 'stac' instruction for
Supervisor Mode Access Protection (SMAP), a barrier_nospec() causes the
access_ok() result to resolve in the pipeline before the CPU might take any
speculative action on the pointer value. Given the cost of 'stac' the
speculation barrier is placed after 'stac' to hopefully overlap the cost of
disabling SMAP with the cost of flushing the instruction pipeline.

Since __get_user is a major kernel interface that deals with user
controlled pointers, the __uaccess_begin_nospec() mechanism will prevent
speculative execution past an access_ok() permission check. While
speculative execution past access_ok() is not enough to lead to a kernel
memory leak, it is a necessary precondition.

To be clear, __uaccess_begin_nospec() is addressing a class of potential
problems near __get_user() usages.

Note, that while the barrier_nospec() in __uaccess_begin_nospec() is used
to protect __get_user(), pointer masking similar to array_index_nospec()
will be used for get_user() since it incorporates a bounds check near the

uaccess_try_nospec provides the same mechanism for get_user_try.

No functional changes.

Suggested-by: Linus Torvalds <>
Suggested-by: Andi Kleen <>
Suggested-by: Ingo Molnar <>
Signed-off-by: Dan Williams <>
Signed-off-by: Thomas Gleixner <>
Cc: Tom Lendacky <>
Cc: Kees Cook <>
Cc: Al Viro <>
[bwh: Backported to 3.2:
 - There's no SMAP support, so only add uaccess_try_nospec()
 - Use current_thread_info() and save the previous error state, matching
Signed-off-by: Ben Hutchings <>
3 years agonospec: Include <asm/barrier.h> dependency
Dan Williams [Fri, 16 Feb 2018 21:20:54 +0000 (13:20 -0800)]
nospec: Include <asm/barrier.h> dependency

commit eb6174f6d1be16b19cfa43dac296bfed003ce1a6 upstream.

The nospec.h header expects the per-architecture header file
<asm/barrier.h> to optionally define array_index_mask_nospec(). Include
that dependency to prevent inadvertent fallback to the default
array_index_mask_nospec() implementation.

The default implementation may not provide a full mitigation
on architectures that perform data value speculation.

Reported-by: Christian Borntraeger <>
Signed-off-by: Dan Williams <>
Cc: Andy Lutomirski <>
Cc: Arjan van de Ven <>
Cc: Borislav Petkov <>
Cc: Dave Hansen <>
Cc: David Woodhouse <>
Cc: Greg Kroah-Hartman <>
Cc: Josh Poimboeuf <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Cc: Will Deacon <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: include <asm/system.h> instead]
Signed-off-by: Ben Hutchings <>
3 years agonospec: Kill array_index_nospec_mask_check()
Dan Williams [Fri, 16 Feb 2018 21:20:42 +0000 (13:20 -0800)]
nospec: Kill array_index_nospec_mask_check()

commit 1d91c1d2c80cb70e2e553845e278b87a960c04da upstream.

There are multiple problems with the dynamic sanity checking in

* It causes unnecessary overhead in the 32-bit case since integer sized
  @index values will no longer cause the check to be compiled away like
  in the 64-bit case.

* In the 32-bit case it may trigger with user controllable input when
  the expectation is that should only trigger during development of new
  kernel enabling.

* The macro reuses the input parameter in multiple locations which is
  broken if someone passes an expression like 'index++' to

Reported-by: Linus Torvalds <>
Signed-off-by: Dan Williams <>
Cc: Andy Lutomirski <>
Cc: Arjan van de Ven <>
Cc: Borislav Petkov <>
Cc: Dave Hansen <>
Cc: David Woodhouse <>
Cc: Greg Kroah-Hartman <>
Cc: Josh Poimboeuf <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Cc: Will Deacon <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>