Linux/linux ac9a409drivers/scsi ipr.c st.c, drivers/scsi/qla2xxx qla_tmpl.c

Merge tag 'scsi-fixes' of git://

Pull SCSI fixes from James Bottomley:
 "A couple of minor fixes (st, ses) and some bigger driver fixes for
  qla2xxx (crash triggered by fw dump) and ipr (lockdep problems with

* tag 'scsi-fixes' of git://
  scsi: ses: Fix wrong page error
  scsi: ipr: Fix scsi-mq lockdep issue
  scsi: st: fix blk_get_queue usage
  scsi: qla2xxx: Fix system crash while triggering FW dump

Linux/linux 422ce07kernel audit_watch.c

Merge tag 'audit-pr-20170816' of 

Pull audit fixes from Paul Moore:
 "Two small fixes to the audit code, both explained well in the
  respective patch descriptions, but the quick summary is one
  use-after-free fix, and one silly fanotify notification flag fix"

* tag 'audit-pr-20170816' of git://
  audit: Receive unmount event
  audit: Fix use after free in audit_remove_watch_rule()

Linux/linux 510c8a8drivers/net/ethernet/chelsio/cxgb4 cxgb4_main.c, drivers/pci quirks.c probe.c

Merge git://

Pull networking fixes from David Miller:

 1) Fix TCP checksum offload handling in iwlwifi driver, from Emmanuel

 2) In ksz DSA tagging code, free SKB if skb_put_padto() fails. From
    Vivien Didelot.

 3) Fix two regressions with bonding on wireless, from Andreas Born.

 4) Fix build when busypoll is disabled, from Daniel Borkmann.

 5) Fix copy_linear_skb() wrt. SO_PEEK_OFF, from Eric Dumazet.

 6) Set SKB cached route properly in inet_rtm_getroute(), from Florian

 7) Fix PCI-E relaxed ordering handling in cxgb4 driver, from Ding

 8) Fix module refcnt leak in ULP code, from Sabrina Dubroca.

 9) Fix use of GFP_KERNEL in atomic contexts in AF_KEY code, from Eric

    [30 lines not shown]

Linux/linux 88a5c69kernel/trace bpf_trace.c

bpf: fix bpf_trace_printk on 32 bit archs

James reported that on MIPS32 bpf_trace_printk() is currently
broken while MIPS64 works fine:

  bpf_trace_printk() uses conditional operators to attempt to
  pass different types to __trace_printk() depending on the
  format operators. This doesn't work as intended on 32-bit
  architectures where u32 and long are passed differently to
  u64, since the result of C conditional operators follows the
  "usual arithmetic conversions" rules, such that the values
  passed to __trace_printk() will always be u64 [causing issues
  later in the va_list handling for vscnprintf()].

  For example the samples/bpf/tracex5 test printed lines like
  below on MIPS32, where the fd and buf have come from the u64
  fd argument, and the size from the buf argument:

    [...] 1180.941542: 0x00000001: write(fd=1, buf=  (null), size=6258688)

  Instead of this:

    [...] 1625.616026: 0x00000001: write(fd=1, buf=009e4000, size=512)

One way to get it working is to expand various combinations

    [9 lines not shown]

Linux/linux 0e40523drivers/pci pci.c

PCI: fix oops when try to find Root Port for a PCI device

Eric report a oops when booting the system after applying
the commit a99b646afa8a ("PCI: Disable PCIe Relaxed..."):

[    4.241029] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
[    4.247001] IP: pci_find_pcie_root_port+0x62/0x80
[    4.253011] PGD 0
[    4.253011] P4D 0
[    4.253011]
[    4.258013] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[    4.262015] Modules linked in:
[    4.265005] CPU: 31 PID: 1 Comm: swapper/0 Not tainted 4.13.0-dbx-DEV #316
[    4.271002] Hardware name: Intel RML,PCH/Iota_QC_19, BIOS 2.40.0 06/22/2016
[    4.279002] task: ffffa2ee38cfa040 task.stack: ffffa51ec0004000
[    4.285001] RIP: 0010:pci_find_pcie_root_port+0x62/0x80
[    4.290012] RSP: 0000:ffffa51ec0007ab8 EFLAGS: 00010246
[    4.295003] RAX: 0000000000000000 RBX: ffffa2ee36bae000 RCX: 0000000000000006
[    4.303002] RDX: 000000000000081c RSI: ffffa2ee38cfa8c8 RDI: ffffa2ee36bae000
[    4.310013] RBP: ffffa51ec0007b58 R08: 0000000000000001 R09: 0000000000000000
[    4.317001] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa51ec0007ad0
[    4.324005] R13: ffffa2ee36bae098 R14: 0000000000000002 R15: ffffa2ee37204818
[    4.331002] FS:  0000000000000000(0000) GS:ffffa2ee3fcc0000(0000) 
[    4.339002] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033

    [42 lines not shown]
+4-31 files

Linux/linux 61deee9drivers/net/ethernet/sfc mcdi_port.c

sfc: don't try and read ef10 data on non-ef10 NIC

The MAC stats command takes a port ID, which doesn't exist on
pre-ef10 NICs (5000- and 6000- series). This is extracted from the
NIC specific data; we misinterpret this as the ef10 data structure,
causing us to read potentially unallocated data. With a KASAN kernel
this can cause errors with:
   BUG: KASAN: slab-out-of-bounds in efx_mcdi_mac_stats

Fixes: 0a2ab4d988d7 ("sfc: set the port-id when calling MC_CMD_MAC_STATS")
Reported-by: Stefano Brivio <sbrivio at>
Tested-by: Stefano Brivio <sbrivio at>
Signed-off-by: Bert Kenward <bkenward at>
Signed-off-by: David S. Miller <davem at>

Linux/linux 325d5dcnet/sched sch_sfq.c

net_sched/sfq: update hierarchical backlog when drop packet

When sfq_enqueue() drops head packet or packet from another queue it
have to update backlog at upper qdiscs too.

Fixes: 2ccccf5fb43f ("net_sched: update hierarchical backlog too")
Signed-off-by: Konstantin Khlebnikov <khlebnikov at>
Acked-by: Eric Dumazet <edumazet at>
Signed-off-by: David S. Miller <davem at>

Linux/linux c90e951net/sched sch_api.c

net_sched: remove warning from qdisc_hash_add

It was added in commit e57a784d8cae ("pkt_sched: set root qdisc
before change() in attach_default_qdiscs()") to hide duplicates
from "tc qdisc show" for incative deivices.

After 59cc1f61f ("net: sched: convert qdisc linked list to hashtable")
it triggered when classful qdisc is added to inactive device because
default qdiscs are added before switching root qdisc.

Anyway after commit ea3274695353 ("net: sched: avoid duplicates in
qdisc dump") duplicates are filtered right in dumper.

Signed-off-by: Konstantin Khlebnikov <khlebnikov at>
Signed-off-by: David S. Miller <davem at>

Linux/linux 8989042net/sched sch_htb.c sch_hfsc.c

net_sched: reset pointers to tcf blocks in classful qdiscs' destructors

Traffic filters could keep direct pointers to classes in classful qdisc,
thus qdisc destruction first removes all filters before freeing classes.
Class destruction methods also tries to free attached filters but now
this isn't safe because tcf_block_put() unlike to tcf_destroy_chain()
cannot be called second time.

This patch set class->block to NULL after first tcf_block_put() and
turn second call into no-op.

Fixes: 6529eaba33f0 ("net: sched: introduce tcf block infractructure")
Signed-off-by: Konstantin Khlebnikov <khlebnikov at>
Acked-by: Jiri Pirko <jiri at>
Signed-off-by: David S. Miller <davem at>

Linux/linux 187e5b3net/ipv4 fib_semantics.c

ipv4: fix NULL dereference in free_fib_info_rcu()

If fi->fib_metrics could not be allocated in fib_create_info()
we attempt to dereference a NULL pointer in free_fib_info_rcu() :

    m = fi->fib_metrics;
    if (m != &dst_default_metrics && atomic_dec_and_test(&m->refcnt))

Before my recent patch, we used to call kfree(NULL) and nothing wrong

Instead of using RCU to defer freeing while we are under memory stress,
it seems better to take immediate action.

This was reported by syzkaller team.

Fixes: 3fb07daff8e9 ("ipv4: add reference counting to metrics")
Signed-off-by: Eric Dumazet <edumazet at>
Reported-by: Dmitry Vyukov <dvyukov at>
Signed-off-by: David S. Miller <davem at>

Linux/linux b3dc8f7include/linux net.h

net: Fix a typo in comment about sock flags.

Signed-off-by: Tonghao Zhang <xiangxia.m.yue at>
Signed-off-by: David S. Miller <davem at>

Linux/linux 12d94a8include/net addrconf.h, net/ipv6 route.c

ipv6: fix NULL dereference in ip6_route_dev_notify()

Based on a syzkaller report [1], I found that a per cpu allocation
failure in snmp6_alloc_dev() would then lead to NULL dereference in

It seems this is a very old bug, thus no Fixes tag in this submission.

Let's add in6_dev_put_clear() helper, as we will probably use
it elsewhere (once available/present in net-next)

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 17294 Comm: syz-executor6 Not tainted 4.13.0-rc2+ #10
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
task: ffff88019f456680 task.stack: ffff8801c6e58000
RIP: 0010:__read_once_size include/linux/compiler.h:250 [inline]
RIP: 0010:atomic_read arch/x86/include/asm/atomic.h:26 [inline]
RIP: 0010:refcount_sub_and_test+0x7d/0x1b0 lib/refcount.c:178
RSP: 0018:ffff8801c6e5f1b0 EFLAGS: 00010202

    [53 lines not shown]

Linux/linux b5fed47kernel audit_watch.c

audit: Receive unmount event

Although audit_watch_handle_event() can handle FS_UNMOUNT event, it is
not part of AUDIT_FS_WATCH mask and thus such event never gets to
audit_watch_handle_event(). Thus fsnotify marks are deleted by fsnotify
subsystem on unmount without audit being notified about that which leads
to a strange state of existing audit rules with dead fsnotify marks.

Add FS_UNMOUNT to the mask of events to be received so that audit can
clean up its state accordingly.

Signed-off-by: Jan Kara <jack at>
Signed-off-by: Paul Moore <paul at>

Linux/linux d76036akernel audit_watch.c

audit: Fix use after free in audit_remove_watch_rule()

audit_remove_watch_rule() drops watch's reference to parent but then
continues to work with it. That is not safe as parent can get freed once
we drop our reference. The following is a trivial reproducer:

mount -o loop image /mnt
touch /mnt/file
auditctl -w /mnt/file -p wax
umount /mnt
auditctl -D
<crash in fsnotify_destroy_mark()>

Grab our own reference in audit_remove_watch_rule() earlier to make sure
mark does not get freed under us.

CC: stable at
Reported-by: Tony Jones <tonyj at>
Signed-off-by: Jan Kara <jack at>
Tested-by: Tony Jones <tonyj at>
Signed-off-by: Paul Moore <paul at>

Linux/linux 40c6d1btools/testing/selftests/futex Makefile, tools/testing/selftests/kmod

Merge tag 'linux-kselftest-4.13-rc6-fixes' of 

Pull kselftest fixes from Shuah Khan:
 "This update consists of important compile and run-time error fixes to
  timers/freq-step, kmod, and sysctl tests"

* tag 'linux-kselftest-4.13-rc6-fixes' of 
  selftests: timers: freq-step: fix compile error
  selftests: futex: fix run_tests target
  test_sysctl: fix by making it executable
  test_kmod: fix by making it executable

Linux/linux 0a6f041drivers/net/wireless/intel/iwlwifi iwl-nvm-parse.c, drivers/net/wireless/intel/iwlwifi/cfg 9000.c

Merge tag 'wireless-drivers-for-davem-2017-08-15' of 

Kalle Valo says:

wireless-drivers fixes for 4.13

This time quite a few fixes for iwlwifi and one major regression fix
for brcmfmac. For the iwlwifi aggregation bug a small change was
needed for mac80211, but as Johannes is still away the mac80211 patch
is taken via wireless-drivers tree.


* fix firmware crash (a recent regression in bcm4343{0,1,8}


* Some simple PCI HW ID fix-ups and additions for family 9000

* Remove a bogus warning message with new FWs (bug #196915)

* Don't allow illegal channel options to be used (bug #195299)

    [18 lines not shown]

Linux/linux d624d27net/ipv4 tcp_ipv4.c, net/ipv6 tcp_ipv6.c

tcp: fix possible deadlock in TCP stack vs BPF filter

Filtering the ACK packet was not put at the right place.

At this place, we already allocated a child and put it
into accept queue.

We absolutely need to call tcp_child_process() to release
its spinlock, or we will deadlock at accept() or close() time.

Found by syzkaller team (Thanks a lot !)

Fixes: 8fac365f63c8 ("tcp: Add a tcp_filter hook before handle ack packet")
Signed-off-by: Eric Dumazet <edumazet at>
Reported-by: Dmitry Vyukov <dvyukov at>
Cc: Chenbo Feng <fengc at>
Signed-off-by: David S. Miller <davem at>

Linux/linux 7749d4fnet/dccp proto.c

dccp: purge write queue in dccp_destroy_sock()

syzkaller reported that DCCP could have a non empty
write queue at dismantle time.

WARNING: CPU: 1 PID: 2953 at net/core/stream.c:199 sk_stream_kill_queues+0x3ce/0x520 
Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 2953 Comm: syz-executor0 Not tainted 4.13.0-rc4+ #2
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x194/0x257 lib/dump_stack.c:52
 panic+0x1e4/0x417 kernel/panic.c:180
 __warn+0x1c4/0x1d9 kernel/panic.c:541
 report_bug+0x211/0x2d0 lib/bug.c:183
 fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:190
 do_trap_no_signal arch/x86/kernel/traps.c:224 [inline]
 do_trap+0x260/0x390 arch/x86/kernel/traps.c:273
 do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:310
 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:323
 invalid_op+0x1e/0x30 arch/x86/entry/entry_64.S:846
RIP: 0010:sk_stream_kill_queues+0x3ce/0x520 net/core/stream.c:199
RSP: 0018:ffff8801d182f108 EFLAGS: 00010297

    [25 lines not shown]
+1-41 files

Linux/linux 42b7305include/net udp.h

udp: fix linear skb reception with PEEK_OFF

copy_linear_skb() is broken; both of its callers actually
expect 'len' to be the amount we are trying to copy,
not the offset of the end.
Fix it keeping the meanings of arguments in sync with what the
callers (both of them) expect.
Also restore a saner behavior on EFAULT (i.e. preserving
the iov_iter position in case of failure):

The commit fd851ba9caa9 ("udp: harden copy_linear_skb()")
avoids the more destructive effect of the buggy
copy_linear_skb(), e.g. no more invalid memory access, but
said function still behaves incorrectly: when peeking with
offset it can fail with EINVAL instead of copying the
appropriate amount of memory.

Reported-by: Sasha Levin <alexander.levin at>
Fixes: b65ac44674dd ("udp: try to avoid 2 cache miss on dequeue")
Fixes: fd851ba9caa9 ("udp: harden copy_linear_skb()")
Signed-off-by: Al Viro <viro at>
Acked-by: Paolo Abeni <pabeni at>
Tested-by: Sasha Levin <alexander.levin at>
Acked-by: Eric Dumazet <edumazet at>
Signed-off-by: David S. Miller <davem at>
+4-51 files

Linux/linux e5645f5net/ipv6 route.c

ipv6: release rt6->rt6i_idev properly during ifdown

When a dst is created by addrconf_dst_alloc() for a host route or an
anycast route, dst->dev points to loopback dev while rt6->rt6i_idev
points to a real device.
When the real device goes down, the current cleanup code only checks for
dst->dev and assumes rt6->rt6i_idev->dev is the same. This causes the
refcount leak on the real device in the above situation.
This patch makes sure to always release the refcount taken on
rt6->rt6i_idev during dst_dev_put().

Fixes: 587fea741134 ("ipv6: mark DST_NOGC and remove the operation of
Reported-by: John Stultz <john.stultz at>
Tested-by: John Stultz <john.stultz at>
Tested-by: Martin KaFai Lau <kafai at>
Signed-off-by: Wei Wang <weiwan at>
Signed-off-by: Martin KaFai Lau <kafai at>
Acked-by: David Ahern <dsahern at>
Signed-off-by: David S. Miller <davem at>
+5-81 files

Linux/linux 36f41f8net/key af_key.c

af_key: do not use GFP_KERNEL in atomic contexts

pfkey_broadcast() might be called from non process contexts,
we can not use GFP_KERNEL in these cases [1].

This patch partially reverts commit ba51b6be38c1 ("net: Fix RCU splat in
af_key"), only keeping the GFP_ATOMIC forcing under rcu_read_lock()

[1] : syzkaller reported :

in_atomic(): 1, irqs_disabled(): 0, pid: 2932, name: syzkaller183439
3 locks held by syzkaller183439/2932:
 #0:  (&net->xfrm.xfrm_cfg_mutex){+.+.+.}, at: [<ffffffff83b43888>] 
pfkey_sendmsg+0x4c8/0x9f0 net/key/af_key.c:3649
 #1:  (&pfk->dump_lock){+.+.+.}, at: [<ffffffff83b467f6>] pfkey_do_dump+0x76/0x3f0 
 #2:  (&(&net->xfrm.xfrm_policy_lock)->rlock){+...+.}, at: [<ffffffff83957632>] 
spin_lock_bh include/linux/spinlock.h:304 [inline]
 #2:  (&(&net->xfrm.xfrm_policy_lock)->rlock){+...+.}, at: [<ffffffff83957632>] 
xfrm_policy_walk+0x192/0xa30 net/xfrm/xfrm_policy.c:1028
CPU: 0 PID: 2932 Comm: syzkaller183439 Not tainted 4.13.0-rc4+ #24
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]

    [37 lines not shown]
+26-221 files

Linux/linux 539a06bnet/ipv4 tcp_ulp.c

tcp: ulp: avoid module refcnt leak in tcp_set_ulp

__tcp_ulp_find_autoload returns tcp_ulp_ops after taking a reference on
the module. Then, if ->init fails, tcp_set_ulp propagates the error but
nothing releases that reference.

Fixes: 734942cc4ea6 ("tcp: ULP infrastructure")
Signed-off-by: Sabrina Dubroca <sd at>
Signed-off-by: David S. Miller <davem at>
+7-71 files

Linux/linux b0ba9d5drivers/net/ethernet/chelsio/cxgb4 cxgb4_main.c sge.c


cxgb4 Ethernet driver now queries PCIe configuration space to determine
if it can send TLPs to it with the Relaxed Ordering Attribute set.

Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability
Device Control[Relaxed Ordering Enable] at probe routine, to make sure
the driver will not send the Relaxed Ordering TLPs to the Root Complex which
could not deal the Relaxed Ordering TLPs.

Signed-off-by: Casey Leedom <leedom at>
Signed-off-by: Ding Tianhong <dingtianhong at>
Reviewed-by: Casey Leedom <leedom at>
Signed-off-by: David S. Miller <davem at>

Linux/linux b629276drivers/net/ethernet/chelsio/cxgb4vf cxgb4vf_main.c sge.c

net/cxgb4vf: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

cxgb4vf Ethernet driver now queries PCIe configuration space to
determine if it can send TLPs to it with the Relaxed Ordering
Attribute set, just like the pf did.

Signed-off-by: Casey Leedom <leedom at>
Signed-off-by: Ding Tianhong <dingtianhong at>
Reviewed-by: Casey Leedom <leedom at>
Signed-off-by: David S. Miller <davem at>

Linux/linux bae514adrivers/net/ethernet/chelsio/cxgb4 cxgb4_main.c sge.c, drivers/net/ethernet/chelsio/cxgb4vf cxgb4vf_main.c

Merge branch 'Add-new-PCI_DEV_FLAGS_NO_RELAXED_ORDERING-flag'

Ding Tianhong says:


Some devices have problems with Transaction Layer Packets with the Relaxed
Ordering Attribute set.  This patch set adds a new PCIe Device Flag,
PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known
devices with Relaxed Ordering issues, and a use of this new flag by the
cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex

It's been years since I've submitted patches, I appolgise for the
almost certain submission errors.

v2: Alexander point out that the v1 was only a part of the whole solution,
    some platform which has some issues could use the new flag to indicate
    that it is not safe to enable relaxed ordering attribute, then we need
    to clear the relaxed ordering enable bits in the PCI configuration when
    initializing the device. So add a new second patch to modify the PCI
    initialization code to clear the relaxed ordering enable bit in the
    event that the root complex doesn't want relaxed ordering enabled.

    [70 lines not shown]

Linux/linux 87e09cddrivers/pci quirks.c

PCI: Disable Relaxed Ordering for some Intel processors

According to the Intel spec section 3.9.1 said:

    3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory
          and Toward MMIO Regions (P2P)

    In order to maximize performance for PCIe devices in the processors
    listed in Table 3-6 below, the soft- ware should determine whether the
    accesses are toward coherent memory (system memory) or toward MMIO
    regions (P2P access to other devices). If the access is toward MMIO
    region, then software can command HW to set the RO bit in the TLP
    header, as this would allow hardware to achieve maximum throughput for
    these types of accesses. For accesses toward coherent memory, software
    can command HW to clear the RO bit in the TLP header (no RO), as this
    would allow hardware to achieve maximum throughput for these types of

    Table 3-6. Intel Processor CPU RP Device IDs for Processors Optimizing
               PCIe Performance

    Processor                            CPU RP Device IDs

    Intel Xeon processors based on       6F01H-6F0EH
    Broadwell microarchitecture

    [12 lines not shown]
+62-01 files

Linux/linux 077fa19drivers/pci quirks.c

PCI: Disable Relaxed Ordering Attributes for AMD A1100

Casey reported that the AMD ARM A1100 SoC has a bug in its PCIe
Root Port where Upstream Transaction Layer Packets with the Relaxed
Ordering Attribute clear are allowed to bypass earlier TLPs with
Relaxed Ordering set, it would cause Data Corruption, so we need
to disable Relaxed Ordering Attribute when Upstream TLPs to the
Root Port.

Reported-and-suggested-by: Casey Leedom <leedom at>
Signed-off-by: Casey Leedom <leedom at>
Signed-off-by: Ding Tianhong <dingtianhong at>
Acked-by: Casey Leedom <leedom at>
Signed-off-by: David S. Miller <davem at>
+16-01 files

Linux/linux a99b646drivers/pci probe.c quirks.c, include/linux pci.h

PCI: Disable PCIe Relaxed Ordering if unsupported

When bit4 is set in the PCIe Device Control register, it indicates
whether the device is permitted to use relaxed ordering.
On some platforms using relaxed ordering can have performance issues or
due to erratum can cause data-corruption. In such cases devices must avoid
using relaxed ordering.

The patch adds a new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING to indicate that
Relaxed Ordering (RO) attribute should not be used for Transaction Layer
Packets (TLP) targeted towards these affected root complexes.

This patch checks if there is any node in the hierarchy that indicates that
using relaxed ordering is not safe. In such cases the patch turns off the
relaxed ordering by clearing the capability for this device.

Signed-off-by: Casey Leedom <leedom at>
Signed-off-by: Ding Tianhong <dingtianhong at>
Acked-by: Ashok Raj <ashok.raj at>
Acked-by: Alexander Duyck <alexander.h.duyck at>
Acked-by: Casey Leedom <leedom at>
Signed-off-by: David S. Miller <davem at>

Linux/linux fcd0735drivers/md raid5-cache.c md.c

Merge tag 'md/4.13-rc5' of git://

Pull MD fixes from Shaohua Li:
 "Fix several bugs:

   - fix a rcu stall issue introduced in 4.12 (Neil Brown)

   - fix two raid5 cache race conditions (Song Liu)"

* tag 'md/4.13-rc5' of git://
  MD: not clear ->safemode for external metadata array
  md/r5cache: fix io_unit handling in r5l_log_endio()
  md/r5cache: call mddev_lock/unlock() in r5c_journal_mode_set
  md: fix test in md_write_start()
  md: always clear ->safemode when md_check_recovery gets the mddev lock.

Linux/linux 6b9d1c2arch/x86/crypto sha1_avx2_x86_64_asm.S sha1_ssse3_glue.c, drivers/crypto ixp4xx_crypto.c

Merge branch 'linus' of git://

Pull crypto fixes from Herbert Xu:
 "Fix an error path bug in ixp4xx as well as a read overrun in

* 'linus' of git://
  crypto: x86/sha1 - Fix reads beyond the number of blocks passed
  crypto: ixp4xx - Fix error handling path in 'aead_perform()'

Linux/linux 59a361bnet/tipc msg.c

tipc: avoid inheriting msg_non_seq flag when message is returned

In the function msg_reverse(), we reverse the header while trying to
reuse the original buffer whenever possible. Those rejected/returned
messages are always transmitted as unicast, but the msg_non_seq field
is not explicitly set to zero as it should be.

We have seen cases where multicast senders set the message type to
"NOT dest_droppable", meaning that a multicast message shorter than
one MTU will be returned, e.g., during receive buffer overflow, by
reusing the original buffer. This has the effect that even the
'msg_non_seq' field is inadvertently inherited by the rejected message,
although it is now sent as a unicast message. This again leads the
receiving unicast link endpoint to steer the packet toward the broadcast
link receive function, where it is dropped. The affected unicast link is
thereafter (after 100 failed retransmissions) declared 'stale' and

We fix this by unconditionally setting the 'msg_non_seq' flag to zero
for all rejected/returned messages.

Reported-by: Canh Duc Luu <canh.d.luu at>
Signed-off-by: Jon Maloy <jon.maloy at>
Signed-off-by: David S. Miller <davem at>
+1-01 files

Linux/linux fed5f57net/tipc bearer.c

tipc: accept PACKET_MULTICAST packets

On L2 bearers, the TIPC broadcast function is sending out packets using
the corresponding L2 broadcast address. At reception, we filter such
packets under the assumption that they will also be delivered as
broadcast packets.

This assumption doesn't always hold true. Under high load, we have seen
that a switch may convert the destination address and deliver the packet
as a PACKET_MULTICAST, something leading to inadvertently dropped
packets and a stale and reset broadcast link.

We fix this by extending the reception filtering to accept packets of

Signed-off-by: Jon Maloy <jon.maloy at>
Signed-off-by: David S. Miller <davem at>
+1-11 files

Linux/linux 2c87d63net/ipv4 route.c

ipv4: route: fix inet_rtm_getroute induced crash

"ip route get $daddr iif eth0 from $saddr" causes:
 BUG: KASAN: use-after-free in ip_route_input_rcu+0x1535/0x1b50
 Call Trace:

Problem is that inet_rtm_getroute calls either ip_route_input_rcu (if an
iif was provided) or ip_route_output_key_hash_rcu.

But ip_route_input_rcu, unlike ip_route_output_key_hash_rcu, already
associates the dst_entry with the skb.  This clears the SKB_DST_NOREF
bit (i.e. skb_dst_drop will release/free the entry while it should not).

Thus only set the dst if we called ip_route_output_key_hash_rcu().

I tested this patch by running:
 while true;do ip r get;done > /dev/null &
 while true;do ip r get iif eth0  from;done > /dev/null &
... and saw no crash or memory leak.

    [7 lines not shown]
+2-11 files

Linux/linux e9bf53adrivers/net/wireless/broadcom/brcm80211/brcmfmac feature.c

brcmfmac: feature check for multi-scheduled scan fails on bcm4343x devices

The firmware feature check introduced for multi-scheduled scan turned out
to be failing for bcm4343{0,1,8} devices resulting in a firmware crash.
The reason for this crash has not yet been root cause so this patch avoids
the feature check for those device as a short-term fix.

Reported-by: Stefan Wahren <stefan.wahren at>
Reported-by: Ian Molton <ian at>
Fixes: 9fe929aaace6 ("brcmfmac: add firmware feature detection for gscan feature")
Signed-off-by: Arend van Spriel <arend.vanspriel at>
Signed-off-by: Kalle Valo <kvalo at>

Linux/linux 11e9d78drivers/net/bonding bond_main.c

bonding: ratelimit failed speed/duplex update warning

bond_miimon_commit() handles the UP transition for each slave of a bond
in the case of MII. It is triggered 10 times per second for the default
MII Polling interval of 100ms. For device drivers that do not implement
__ethtool_get_link_ksettings() the call to bond_update_speed_duplex()
fails persistently while the MII status could remain UP. That is, in
this and other cases where the speed/duplex update keeps failing over a
longer period of time while the MII state is UP, a warning is printed
every MII polling interval.

To address these excessive warnings net_ratelimit() should be used.
Printing a warning once would not be sufficient since the call to
bond_update_speed_duplex() could recover to succeed and fail again
later. In that case there would be no new indication what went wrong.

Fixes: b5bf0f5b16b9c (bonding: correctly update link status during mii-commit phase)
Signed-off-by: Andreas Born <futur.andy at>
Signed-off-by: David S. Miller <davem at>

Linux/linux ef95484. Makefile

Linux 4.13-rc5
+1-11 files

Linux/linux b2298fcarch/mips Makefile, arch/mips/dec int-handler.S

Merge branch 'upstream' of git://

Pull MIPS fixes from Ralf Baechle:
 "Another round of MIPS fixes:

   - compressed boot: Ignore a generated .c file

   - VDSO: Fix a register clobber list

   - DECstation: Fix an int-handler.S CPU_DADDI_WORKAROUNDS regression

   - Octeon: Fix recent cleanups that cleaned away a bit too much thus
     breaking the arch side of the EDAC and USB drivers.

   - uasm: Fix duplicate const in "const struct foo const bar[]" which
     GCC 7.1 no longer accepts.

   - Fix race on setting and getting cpu_online_mask

   - Fix preemption issue. To do so cleanly introduce macro to get the
     size of L3 cache line.

   - Revert include cleanup that sometimes results in build error

   - MicroMIPS uses bit 0 of the PC to indicate microMIPS mode. Make

    [24 lines not shown]

Linux/linux c9dc281drivers/base firmware_class.c

Merge tag 'driver-core-4.13-rc5' of 

Pull driver core fixes from Greg KH:
 "Here are three firmware core fixes for 4.13-rc5.

  All three of these fix reported issues and have been floating around
  for a few weeks. They have been in linux-next with no reported

* tag 'driver-core-4.13-rc5' of 
  firmware: avoid invalid fallback aborts by using killable wait
  firmware: fix batched requests - send wake up on failure on direct lookups
  firmware: fix batched requests - wake all waiters

Linux/linux ce7ba95drivers/misc/mei pci-me.c pci-txe.c, drivers/thunderbolt eeprom.c

Merge tag 'char-misc-4.13-rc5' of 

Pull char/misc fixes from Greg KH:
 "Here are two patches for 4.13-rc5.

  One is a fix for a reported thunderbolt issue, and the other a fix for
  an MEI driver issue. Both have been in linux-next with no reported

* tag 'char-misc-4.13-rc5' of 
  thunderbolt: Do not enumerate more ports from DROM than the controller has
  mei: exclude device from suspend direct complete optimization

Linux/linux 438630edrivers/acpi spcr.c, drivers/tty/serial amba-pl011.c

Merge tag 'tty-4.13-rc5' of git://

Pull tty/serial fixes from Greg KH:
 "Here are two tty serial driver fixes for 4.13-rc5. One is a revert of
  a -rc1 patch that turned out to not be a good idea, and the other is a
  fix for the pl011 serial driver.

  Both have been in linux-next with no reported issues"

* tag 'tty-4.13-rc5' of git://
  Revert "serial: Delete dead code for CIR serial ports"
  tty: pl011: fix initialization order of QDF2400 E44

Linux/linux dd95f18drivers/iio/accel st_accel_core.c bmc150-accel-core.c, drivers/iio/adc axp288_adc.c aspeed_adc.c

Merge tag 'staging-4.13-rc5' of 

Pull staging/iio fixes from Greg KH:
 "Here are some Staging and IIO driver fixes for 4.13-rc5.

  Nothing major, just a number of small fixes for reported issues. All
  of these have been in linux-next for a while now with no reported
  issues. Full details are in the shortlog"

* tag 'staging-4.13-rc5' of git://
  staging: comedi: comedi_fops: do not call blocking ops when !TASK_RUNNING
  iio: aspeed-adc: wait for initial sequence.
  iio: accel: bmc150: Always restore device to normal mode after suspend-resume
  staging:iio:resolver:ad2s1210 fix negative IIO_ANGL_VEL read
  iio: adc: axp288: Fix the GPADC pin reading often wrongly returning 0
  iio: adc: vf610_adc: Fix VALT selection value for REFSEL bits
  iio: accel: st_accel: add SPI-3wire support
  iio: adc: Revert "axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications"
  iio: adc: sun4i-gpadc-iio: fix unbalanced irq enable/disable
  iio: pressure: st_pressure_core: disable multiread by default for LPS22HB
  iio: light: tsl2563: use correct event code

Linux/linux 10cec91drivers/usb/core hub.c, drivers/usb/dwc3 gadget.c

Merge tag 'usb-4.13-rc5' of git://

Pull USB fixes from Greg KH:
 "Here are a number of small USB driver fixes and new device ids for
  4.13-rc5. There is the usual gadget driver fixes, some new quirks for
  "messy" hardware, and some new device ids.

  All have been in linux-next with no reported issues"

* tag 'usb-4.13-rc5' of git://
  USB: serial: pl2303: add new ATEN device id
  usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter
  USB: Check for dropped connection before switching to full speed
  usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume
  usb: renesas_usbhs: gadget: fix unused-but-set-variable warning
  usb: renesas_usbhs: Fix UGCTRL2 value for R-Car Gen3
  usb: phy: phy-msm-usb: Fix usage of devm_regulator_bulk_get()
  usb: gadget: udc: renesas_usb3: Fix usb_gadget_giveback_request() calling
  usb: dwc3: gadget: Correct ISOC DATA PIDs for short packets
  USB: serial: option: add D-Link DWM-222 device ID
  usb: musb: fix tx fifo flush handling again
  usb: core: unlink urbs from the tail of the endpoint's urb_list
  usb-storage: fix deadlock involving host lock and scsi_done
  uas: Add US_FL_IGNORE_RESIDUE for Initio Corporation INIC-3069
  USB: hcd: Mark secondary HCD as dead if the primary one died
  USB: serial: cp210x: add support for Qivicon USB ZigBee dongle

Linux/linux 89a5527drivers/mtd mtd_blkdevs.c

Merge tag 'for-linus-20170812' of git://

Pull another MTD fix from Brian Norris:
 "An mtdblock regression occurred in -rc1 (all writes were broken!), in
  the process of some block subsystem refactoring. Noticed and fixed
  last week, but I'm a little slow on the uptake"

* tag 'for-linus-20170812' of git://
  mtd: blkdevs: Fix mtd block write failure

Linux/linux 9a51544drivers/mtd mtd_blkdevs.c

mtd: blkdevs: Fix mtd block write failure

All the MTD block write requests are failing with
following error messages

    mkfs.ext4  /dev/mtdblock0

    print_req_error: I/O error, dev mtdblock0, sector 0
    Buffer I/O error on dev mtdblock0, logical block 0,
    lost async page write

The control is going to default case after block write request
because of missing return.

Fixes: commit 2a842acab109 ("block: introduce new block status code type")
Signed-off-by: Abhishek Sahu <absahu at>
Signed-off-by: Brian Norris <computersforpeace at>

Linux/linux a99bcdcdrivers/scsi/qla2xxx tcm_qla2xxx.c, drivers/target target_core_user.c

Merge git://

Pull SCSI target fixes from Nicholas Bellinger:
 "The highlights include:

   - Fix iscsi-target payload memory leak during

   - Fix tcm_qla2xxx incorrect use of tcm_qla2xxx_free_cmd during ABORT
     (Pascal de Bruijn + Himanshu Madhani + nab)

   - Fix iscsi-target long-standing issue with parallel delete of a
     single network portal across multiple target instances (Gary Guo +

   - Fix target dynamic se_node GPF during uncached shutdown regression
     (Justin Maggard + nab)"

* git://
  target: Fix node_acl demo-mode + uncached dynamic shutdown regression
  iscsi-target: Fix iscsi_np reset hung task during parallel delete
  qla2xxx: Fix incorrect tcm_qla2xxx_free_cmd use during TMR ABORT (v2)
  cxgbit: fix sg_nents calculation
  iscsi-target: fix invalid flags in text response
  iscsi-target: fix memory leak in iscsit_setup_text_cmd()

    [3 lines not shown]

Linux/linux 043cd07arch/x86/include/asm hypervisor.h, arch/x86/mm init.c

Merge tag 'for-linus-4.13b-rc5-tag' of 

Pull xen fixes from Juergen Gross:
 "Some fixes for Xen:

   - a fix for a regression introduced in 4.13 for a Xen HVM-guest
     configured with KASLR

   - a fix for a possible deadlock in the xenbus driver when booting the

   - a fix for lost interrupts in Xen guests"

* tag 'for-linus-4.13b-rc5-tag' of git://
  xen/events: Fix interrupt lost during irq_disable and irq_enable
  xen: avoid deadlock in xenbus
  xen: fix hvm guest with kaslr enabled
  xen: split up xen_hvm_init_shared_info()
  x86: provide an init_mem_mapping hypervisor hook

Linux/linux afc1f55drivers/md md.c

MD: not clear ->safemode for external metadata array

->safemode should be triggered by mdadm for external metadaa array, otherwise
array's state confuses mdadm.

Fixes: 33182d15c6bf(md: always clear ->safemode when md_check_recovery gets the mddev 
Cc: NeilBrown <neilb at>
Signed-off-by: Shaohua Li <shli at>
+1-11 files

Linux/linux fd851bainclude/net udp.h

udp: harden copy_linear_skb()

syzkaller got crashes with CONFIG_HARDENED_USERCOPY=y configs.

Issue here is that recvfrom() can be used with user buffer of Z bytes,
and SO_PEEK_OFF of X bytes, from a skb with Y bytes, and following
condition :

Z < X < Y

kernel BUG at mm/usercopy.c:72!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 2917 Comm: syzkaller842281 Not tainted 4.13.0-rc3+ #16
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
task: ffff8801d2fa40c0 task.stack: ffff8801d1fe8000
RIP: 0010:report_usercopy mm/usercopy.c:64 [inline]
RIP: 0010:__check_object_size+0x3ad/0x500 mm/usercopy.c:264
RSP: 0018:ffff8801d1fef8a8 EFLAGS: 00010286
RAX: 0000000000000078 RBX: ffffffff847102c0 RCX: 0000000000000000
RDX: 0000000000000078 RSI: 1ffff1003a3fded5 RDI: ffffed003a3fdf09
RBP: ffff8801d1fef998 R08: 0000000000000001 R09: 0000000000000000

    [25 lines not shown]
+2-01 files

Linux/linux 6401f37include/net busy_poll.h, net/core filter.c

Merge branch 'bpf-Minor-fix-in-bpf_convert_ctx_access'

Daniel Borkmann says:

bpf: Minor fix in bpf_convert_ctx_access

First one was found while trying to compile the kernel

Signed-off-by: David S. Miller <davem at>

Linux/linux 2ed46cenet/core filter.c

bpf: fix two missing target_size settings in bpf_convert_ctx_access

we try a narrow __sk_buff load of tc_index or napi_id, respectively,
then verifier rightfully complains that it's misconfigured, because
we need to set target_size in each of the two cases. The rewrite
for the ctx access is just a dummy op, but needs to pass, so fix
this up.

Fixes: f96da09473b5 ("bpf: simplify narrower ctx access")
Reported-by: Shubham Bansal <illusionist.neo at>
Signed-off-by: Daniel Borkmann <daniel at>
Signed-off-by: David S. Miller <davem at>
+2-01 files