{"push_id":2692618391,"size":106,"distinct_size":0,"ref":"refs/heads/aosp/upstream-linux-4.4.y","head":"16af098616e73b39c4d98b0d4358cc29a9539c98","before":"0bd2bedb3501db249b347e5acbfd3415bd7667a5","commits":[{"sha":"5a38892dccc571c8ff386a6df243b744fc6110e2","author":{"name":"Eric Dumazet","email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com"},"message":"xfrm6: avoid potential infinite loop in _decode_session6()\n\n[ Upstream commit d9f92772e8ec388d070752ee8f187ef8fa18621f ]\n\nsyzbot found a way to trigger an infinitie loop by overflowing\n@offset variable that has been forced to use u16 for some very\nobscure reason in the past.\n\nWe probably want to look at NEXTHDR_FRAGMENT handling which looks\nwrong, in a separate patch.\n\nIn net-next, we shall try to use skb_header_pointer() instead of\npskb_may_pull().\n\nwatchdog: BUG: soft lockup - CPU#1 stuck for 134s! [syz-executor738:4553]\nModules linked in:\nirq event stamp: 13885653\nhardirqs last  enabled at (13885652): [<ffffffff878009d5>] restore_regs_and_return_to_kernel+0x0/0x2b\nhardirqs last disabled at (13885653): [<ffffffff87800905>] interrupt_entry+0xb5/0xf0 arch/x86/entry/entry_64.S:625\nsoftirqs last  enabled at (13614028): [<ffffffff84df0809>] tun_napi_alloc_frags drivers/net/tun.c:1478 [inline]\nsoftirqs last  enabled at (13614028): [<ffffffff84df0809>] tun_get_user+0x1dd9/0x4290 drivers/net/tun.c:1825\nsoftirqs last disabled at (13614032): [<ffffffff84df1b6f>] tun_get_user+0x313f/0x4290 drivers/net/tun.c:1942\nCPU: 1 PID: 4553 Comm: syz-executor738 Not tainted 4.17.0-rc3+ #40\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:check_kcov_mode kernel/kcov.c:67 [inline]\nRIP: 0010:__sanitizer_cov_trace_pc+0x20/0x50 kernel/kcov.c:101\nRSP: 0018:ffff8801d8cfe250 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13\nRAX: ffff8801d88a8080 RBX: ffff8801d7389e40 RCX: 0000000000000006\nRDX: 0000000000000000 RSI: ffffffff868da4ad RDI: ffff8801c8a53277\nRBP: ffff8801d8cfe250 R08: ffff8801d88a8080 R09: ffff8801d8cfe3e8\nR10: ffffed003b19fc87 R11: ffff8801d8cfe43f R12: ffff8801c8a5327f\nR13: 0000000000000000 R14: ffff8801c8a4e5fe R15: ffff8801d8cfe3e8\nFS:  0000000000d88940(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffffff600400 CR3: 00000001acab3000 CR4: 00000000001406e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n _decode_session6+0xc1d/0x14f0 net/ipv6/xfrm6_policy.c:150\n __xfrm_decode_session+0x71/0x140 net/xfrm/xfrm_policy.c:2368\n xfrm_decode_session_reverse include/net/xfrm.h:1213 [inline]\n icmpv6_route_lookup+0x395/0x6e0 net/ipv6/icmp.c:372\n icmp6_send+0x1982/0x2da0 net/ipv6/icmp.c:551\n icmpv6_send+0x17a/0x300 net/ipv6/ip6_icmp.c:43\n ip6_input_finish+0x14e1/0x1a30 net/ipv6/ip6_input.c:305\n NF_HOOK include/linux/netfilter.h:288 [inline]\n ip6_input+0xe1/0x5e0 net/ipv6/ip6_input.c:327\n dst_input include/net/dst.h:450 [inline]\n ip6_rcv_finish+0x29c/0xa10 net/ipv6/ip6_input.c:71\n NF_HOOK include/linux/netfilter.h:288 [inline]\n ipv6_rcv+0xeb8/0x2040 net/ipv6/ip6_input.c:208\n __netif_receive_skb_core+0x2468/0x3650 net/core/dev.c:4646\n __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4711\n netif_receive_skb_internal+0x126/0x7b0 net/core/dev.c:4785\n napi_frags_finish net/core/dev.c:5226 [inline]\n napi_gro_frags+0x631/0xc40 net/core/dev.c:5299\n tun_get_user+0x3168/0x4290 drivers/net/tun.c:1951\n tun_chr_write_iter+0xb9/0x154 drivers/net/tun.c:1996\n call_write_iter include/linux/fs.h:1784 [inline]\n do_iter_readv_writev+0x859/0xa50 fs/read_write.c:680\n do_iter_write+0x185/0x5f0 fs/read_write.c:959\n vfs_writev+0x1c7/0x330 fs/read_write.c:1004\n do_writev+0x112/0x2f0 fs/read_write.c:1039\n __do_sys_writev fs/read_write.c:1112 [inline]\n __se_sys_writev fs/read_write.c:1109 [inline]\n __x64_sys_writev+0x75/0xb0 fs/read_write.c:1109\n do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287\n entry_SYSCALL_64_after_hwframe+0x49/0xbe\n\nFixes: 1da177e4c3f4 (\"Linux-2.6.12-rc2\")\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nCc: Steffen Klassert <steffen.klassert@secunet.com>\nCc: Nicolas Dichtel <nicolas.dichtel@6wind.com>\nReported-by: syzbot+0053c8...@syzkaller.appspotmail.com\nSigned-off-by: Steffen Klassert <steffen.klassert@secunet.com>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/5a38892dccc571c8ff386a6df243b744fc6110e2"},{"sha":"ab0b00d4fd147ba3100337e7c9849f9a37224b02","author":{"name":"Paolo Abeni","email":"6e4ffc2e3438feb7acb34f6b67e6ae17e700099c@redhat.com"},"message":"netfilter: ebtables: handle string from userspace with care\n\n[ Upstream commit 94c752f99954797da583a84c4907ff19e92550a4 ]\n\nstrlcpy() can't be safely used on a user-space provided string,\nas it can try to read beyond the buffer's end, if the latter is\nnot NULL terminated.\n\nLeveraging the above, syzbot has been able to trigger the following\nsplat:\n\nBUG: KASAN: stack-out-of-bounds in strlcpy include/linux/string.h:300\n[inline]\nBUG: KASAN: stack-out-of-bounds in compat_mtw_from_user\nnet/bridge/netfilter/ebtables.c:1957 [inline]\nBUG: KASAN: stack-out-of-bounds in ebt_size_mwt\nnet/bridge/netfilter/ebtables.c:2059 [inline]\nBUG: KASAN: stack-out-of-bounds in size_entry_mwt\nnet/bridge/netfilter/ebtables.c:2155 [inline]\nBUG: KASAN: stack-out-of-bounds in compat_copy_entries+0x96c/0x14a0\nnet/bridge/netfilter/ebtables.c:2194\nWrite of size 33 at addr ffff8801b0abf888 by task syz-executor0/4504\n\nCPU: 0 PID: 4504 Comm: syz-executor0 Not tainted 4.17.0-rc2+ #40\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS\nGoogle 01/01/2011\nCall Trace:\n  __dump_stack lib/dump_stack.c:77 [inline]\n  dump_stack+0x1b9/0x294 lib/dump_stack.c:113\n  print_address_description+0x6c/0x20b mm/kasan/report.c:256\n  kasan_report_error mm/kasan/report.c:354 [inline]\n  kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412\n  check_memory_region_inline mm/kasan/kasan.c:260 [inline]\n  check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267\n  memcpy+0x37/0x50 mm/kasan/kasan.c:303\n  strlcpy include/linux/string.h:300 [inline]\n  compat_mtw_from_user net/bridge/netfilter/ebtables.c:1957 [inline]\n  ebt_size_mwt net/bridge/netfilter/ebtables.c:2059 [inline]\n  size_entry_mwt net/bridge/netfilter/ebtables.c:2155 [inline]\n  compat_copy_entries+0x96c/0x14a0 net/bridge/netfilter/ebtables.c:2194\n  compat_do_replace+0x483/0x900 net/bridge/netfilter/ebtables.c:2285\n  compat_do_ebt_set_ctl+0x2ac/0x324 net/bridge/netfilter/ebtables.c:2367\n  compat_nf_sockopt net/netfilter/nf_sockopt.c:144 [inline]\n  compat_nf_setsockopt+0x9b/0x140 net/netfilter/nf_sockopt.c:156\n  compat_ip_setsockopt+0xff/0x140 net/ipv4/ip_sockglue.c:1279\n  inet_csk_compat_setsockopt+0x97/0x120 net/ipv4/inet_connection_sock.c:1041\n  compat_tcp_setsockopt+0x49/0x80 net/ipv4/tcp.c:2901\n  compat_sock_common_setsockopt+0xb4/0x150 net/core/sock.c:3050\n  __compat_sys_setsockopt+0x1ab/0x7c0 net/compat.c:403\n  __do_compat_sys_setsockopt net/compat.c:416 [inline]\n  __se_compat_sys_setsockopt net/compat.c:413 [inline]\n  __ia32_compat_sys_setsockopt+0xbd/0x150 net/compat.c:413\n  do_syscall_32_irqs_on arch/x86/entry/common.c:323 [inline]\n  do_fast_syscall_32+0x345/0xf9b arch/x86/entry/common.c:394\n  entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139\nRIP: 0023:0xf7fb3cb9\nRSP: 002b:00000000fff0c26c EFLAGS: 00000282 ORIG_RAX: 000000000000016e\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000000000\nRDX: 0000000000000080 RSI: 0000000020000300 RDI: 00000000000005f4\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n\nThe buggy address belongs to the page:\npage:ffffea0006c2afc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0\nflags: 0x2fffc0000000000()\nraw: 02fffc0000000000 0000000000000000 0000000000000000 00000000ffffffff\nraw: 0000000000000000 ffffea0006c20101 0000000000000000 0000000000000000\npage dumped because: kasan: bad access detected\n\nFix the issue replacing the unsafe function with strscpy() and\ntaking care of possible errors.\n\nFixes: 81e675c227ec (\"netfilter: ebtables: add CONFIG_COMPAT support\")\nReported-and-tested-by: syzbot+4e42a04e0bc33cb6c087@syzkaller.appspotmail.com\nSigned-off-by: Paolo Abeni <pabeni@redhat.com>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/ab0b00d4fd147ba3100337e7c9849f9a37224b02"},{"sha":"24a04933972ad73ab15544bdc2cda290171e1344","author":{"name":"Julian Anastasov","email":"84572ef2253ef81e2d8cd8c65849f4d9a3881f47@ssi.bg"},"message":"ipvs: fix buffer overflow with sync daemon and service\n\n[ Upstream commit 52f96757905bbf0edef47f3ee6c7c784e7f8ff8a ]\n\nsyzkaller reports for buffer overflow for interface name\nwhen starting sync daemons [1]\n\nWhat we do is that we copy user structure into larger stack\nbuffer but later we search NUL past the stack buffer.\nThe same happens for sched_name when adding/editing virtual server.\n\nWe are restricted by IP_VS_SCHEDNAME_MAXLEN and IP_VS_IFNAME_MAXLEN\nbeing used as size in include/uapi/linux/ip_vs.h, so they\ninclude the space for NUL.\n\nAs using strlcpy is wrong for unsafe source, replace it with\nstrscpy and add checks to return EINVAL if source string is not\nNUL-terminated. The incomplete strlcpy fix comes from 2.6.13.\n\nFor the netlink interface reduce the len parameter for\nIPVS_DAEMON_ATTR_MCAST_IFN and IPVS_SVC_ATTR_SCHED_NAME,\nso that we get proper EINVAL.\n\n[1]\nkernel BUG at lib/string.c:1052!\ninvalid opcode: 0000 [#1] SMP KASAN\nDumping ftrace buffer:\n    (ftrace buffer empty)\nModules linked in:\nCPU: 1 PID: 373 Comm: syz-executor936 Not tainted 4.17.0-rc4+ #45\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS\nGoogle 01/01/2011\nRIP: 0010:fortify_panic+0x13/0x20 lib/string.c:1051\nRSP: 0018:ffff8801c976f800 EFLAGS: 00010282\nRAX: 0000000000000022 RBX: 0000000000000040 RCX: 0000000000000000\nRDX: 0000000000000022 RSI: ffffffff8160f6f1 RDI: ffffed00392edef6\nRBP: ffff8801c976f800 R08: ffff8801cf4c62c0 R09: ffffed003b5e4fb0\nR10: ffffed003b5e4fb0 R11: ffff8801daf27d87 R12: ffff8801c976fa20\nR13: ffff8801c976fae4 R14: ffff8801c976fae0 R15: 000000000000048b\nFS:  00007fd99f75e700(0000) GS:ffff8801daf00000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200001c0 CR3: 00000001d6843000 CR4: 00000000001406e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n  strlen include/linux/string.h:270 [inline]\n  strlcpy include/linux/string.h:293 [inline]\n  do_ip_vs_set_ctl+0x31c/0x1d00 net/netfilter/ipvs/ip_vs_ctl.c:2388\n  nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]\n  nf_setsockopt+0x7d/0xd0 net/netfilter/nf_sockopt.c:115\n  ip_setsockopt+0xd8/0xf0 net/ipv4/ip_sockglue.c:1253\n  udp_setsockopt+0x62/0xa0 net/ipv4/udp.c:2487\n  ipv6_setsockopt+0x149/0x170 net/ipv6/ipv6_sockglue.c:917\n  tcp_setsockopt+0x93/0xe0 net/ipv4/tcp.c:3057\n  sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3046\n  __sys_setsockopt+0x1bd/0x390 net/socket.c:1903\n  __do_sys_setsockopt net/socket.c:1914 [inline]\n  __se_sys_setsockopt net/socket.c:1911 [inline]\n  __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911\n  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287\n  entry_SYSCALL_64_after_hwframe+0x49/0xbe\nRIP: 0033:0x447369\nRSP: 002b:00007fd99f75dda8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 00000000006e39e4 RCX: 0000000000447369\nRDX: 000000000000048b RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 0000000000000000 R08: 0000000000000018 R09: 0000000000000000\nR10: 00000000200001c0 R11: 0000000000000246 R12: 00000000006e39e0\nR13: 75a1ff93f0896195 R14: 6f745f3168746576 R15: 0000000000000001\nCode: 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b 48 89 df e8 d2 8f 48 fa eb\nde 55 48 89 fe 48 c7 c7 60 65 64 88 48 89 e5 e8 91 dd f3 f9 <0f> 0b 90 90\n90 90 90 90 90 90 90 90 90 55 48 89 e5 41 57 41 56\nRIP: fortify_panic+0x13/0x20 lib/string.c:1051 RSP: ffff8801c976f800\n\nReported-and-tested-by: syzbot+aac887f77319868646df@syzkaller.appspotmail.com\nFixes: e4ff67513096 (\"ipvs: add sync_maxlen parameter for the sync daemon\")\nFixes: 4da62fc70d7c (\"[IPVS]: Fix for overflows\")\nSigned-off-by: Julian Anastasov <ja@ssi.bg>\nAcked-by: Simon Horman <horms+renesas@verge.net.au>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/24a04933972ad73ab15544bdc2cda290171e1344"},{"sha":"acf477d528bfd2793ac8d13ff4368fa8e2e90c70","author":{"name":"Ivan Bornyakov","email":"c89336883acf45d2088b15bb51e4555899a0fc81@gmail.com"},"message":"atm: zatm: fix memcmp casting\n\n[ Upstream commit f9c6442a8f0b1dde9e755eb4ff6fa22bcce4eabc ]\n\nmemcmp() returns int, but eprom_try_esi() cast it to unsigned char. One\ncan lose significant bits and get 0 from non-0 value returned by the\nmemcmp().\n\nSigned-off-by: Ivan Bornyakov <brnkv.i1@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/acf477d528bfd2793ac8d13ff4368fa8e2e90c70"},{"sha":"8a6677e950b47765de106441691668a452c1095b","author":{"name":"Josh Hill","email":"c028c213ed5efcf30c3f4fc7361dbde0c893c5b7@joshuajhill.com"},"message":"net: qmi_wwan: Add Netgear Aircard 779S\n\n[ Upstream commit 2415f3bd059fe050eb98aedf93664d000ceb4e92 ]\n\nAdd support for Netgear Aircard 779S\n\nSigned-off-by: Josh Hill <josh@joshuajhill.com>\nAcked-by: Bjørn Mork <bjorn@mork.no>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/8a6677e950b47765de106441691668a452c1095b"},{"sha":"05be10a1e87f5d65f3177fad77b9bbd9ea6018db","author":{"name":"Finn Thain","email":"94052abb058aed443995dc4f8d236e022112765d@telegraphics.com.au"},"message":"net/sonic: Use dma_mapping_error()\n\n[ Upstream commit 26de0b76d9ba3200f09c6cb9d9618bda338be5f7 ]\n\nWith CONFIG_DMA_API_DEBUG=y, calling sonic_open() produces the\nmessage, \"DMA-API: device driver failed to check map error\".\nAdd the missing dma_mapping_error() call.\n\nCc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>\nSigned-off-by: Finn Thain <fthain@telegraphics.com.au>\nAcked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/05be10a1e87f5d65f3177fad77b9bbd9ea6018db"},{"sha":"2cb1b6033d10b2c613f79da40da9777a033ad85f","author":{"name":"Sasha Levin","email":"dfe12b7bde468b7bbc2ff152ce329c42255f1599@microsoft.com"},"message":"Revert \"Btrfs: fix scrub to repair raid6 corruption\"\n\nThis reverts commit 95b286daf7ba784191023ad110122703eb2ebabc.\n\nThis commit used an incorrect log message.\n\nReported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/2cb1b6033d10b2c613f79da40da9777a033ad85f"},{"sha":"4dff97920e13af3e92180eefa6b7712d4eac5e58","author":{"name":"Eric Dumazet","email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com"},"message":"tcp: do not overshoot window_clamp in tcp_rcv_space_adjust()\n\ncommit 02db55718d53f9d426cee504c27fb768e9ed4ffe upstream.\n\nWhile rcvbuf is properly clamped by tcp_rmem[2], rcvwin\nis left to a potentially too big value.\n\nIt has no serious effect, since :\n1) tcp_grow_window() has very strict checks.\n2) window_clamp can be mangled by user space to any value anyway.\n\ntcp_init_buffer_space() and companions use tcp_full_space(),\nwe use tcp_win_from_space() to avoid reloading sk->sk_rcvbuf\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nAcked-by: Soheil Hassas Yeganeh <soheil@google.com>\nAcked-by: Wei Wang <weiwan@google.com>\nAcked-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nCc: Benjamin Gilbert <benjamin.gilbert@coreos.com>\nSigned-off-by: Guenter Roeck <linux@roeck-us.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/4dff97920e13af3e92180eefa6b7712d4eac5e58"},{"sha":"b988ed89cfcfd1d9c327dd63b4293839766b13e3","author":{"name":"Liu Bo","email":"53bcb7ec3fc64af6813d2ef7ceefe23b63265886@oracle.com"},"message":"Btrfs: make raid6 rebuild retry more\n\n[ Upstream commit 8810f7517a3bc4ca2d41d022446d3f5fd6b77c09 ]\n\nThere is a scenario that can end up with rebuild process failing to\nreturn good content, i.e.\nsuppose that all disks can be read without problems and if the content\nthat was read out doesn't match its checksum, currently for raid6\nbtrfs at most retries twice,\n\n- the 1st retry is to rebuild with all other stripes, it'll eventually\n  be a raid5 xor rebuild,\n- if the 1st fails, the 2nd retry will deliberately fail parity p so\n  that it will do raid6 style rebuild,\n\nhowever, the chances are that another non-parity stripe content also\nhas something corrupted, so that the above retries are not able to\nreturn correct content, and users will think of this as data loss.\nMore seriouly, if the loss happens on some important internal btree\nroots, it could refuse to mount.\n\nThis extends btrfs to do more retries and each retry fails only one\nstripe.  Since raid6 can tolerate 2 disk failures, if there is one\nmore failure besides the failure on which we're recovering, this can\nalways work.\n\nThe worst case is to retry as many times as the number of raid6 disks,\nbut given the fact that such a scenario is really rare in practice,\nit's still acceptable.\n\nSigned-off-by: Liu Bo <bo.li.liu@oracle.com>\nSigned-off-by: David Sterba <dsterba@suse.com>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/b988ed89cfcfd1d9c327dd63b4293839766b13e3"},{"sha":"4c22010c134ad5da33bd68252446d19cd740a82c","author":{"name":"Daniel Glöckner","email":"9334386da73fed86a833aadf1e01e2ce4e4273e5@emlix.com"},"message":"usb: musb: fix remote wakeup racing with suspend\n\n[ Upstream commit ebc3dd688cd988754a304147753b13e58de1b5a1 ]\n\nIt has been observed that writing 0xF2 to the power register while it\nreads as 0xF4 results in the register having the value 0xF0, i.e. clearing\nRESUME and setting SUSPENDM in one go does not work. It might also violate\nthe USB spec to transition directly from resume to suspend, especially\nwhen not taking T_DRSMDN into account. But this is what happens when a\nremote wakeup occurs between SetPortFeature USB_PORT_FEAT_SUSPEND on the\nroot hub and musb_bus_suspend being called.\n\nThis commit returns -EBUSY when musb_bus_suspend is called while remote\nwakeup is signalled and thus avoids to reset the RESUME bit. Ignoring\nthis error when musb_port_suspend is called from musb_hub_control is ok.\n\nSigned-off-by: Daniel Glöckner <dg@emlix.com>\nSigned-off-by: Bin Liu <b-liu@ti.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/4c22010c134ad5da33bd68252446d19cd740a82c"},{"sha":"b397cdd8546916f86959b5942cc79204f9c93b80","author":{"name":"Xiangning Yu","email":"568e90fffaeea286f8fbe9fa9406575e41656970@gmail.com"},"message":"bonding: re-evaluate force_primary when the primary slave name changes\n\n[ Upstream commit eb55bbf865d9979098c6a7a17cbdb41237ece951 ]\n\nThere is a timing issue under active-standy mode, when bond_enslave() is\ncalled, bond->params.primary might not be initialized yet.\n\nAny time the primary slave string changes, bond->force_primary should be\nset to true to make sure the primary becomes the active slave.\n\nSigned-off-by: Xiangning Yu <yuxiangning@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/b397cdd8546916f86959b5942cc79204f9c93b80"},{"sha":"48ffbdea28808354b89447fac2d8524c29ce7ab4","author":{"name":"Frank van der Linden","email":"137df1b99e6de808ebf723ca24d5697a9ded7068@amazon.com"},"message":"tcp: verify the checksum of the first data segment in a new connection\n\n[ Upstream commit 4fd44a98ffe0d048246efef67ed640fdf2098a62 ]\n\ncommit 079096f103fa (\"tcp/dccp: install syn_recv requests into ehash\ntable\") introduced an optimization for the handling of child sockets\ncreated for a new TCP connection.\n\nBut this optimization passes any data associated with the last ACK of the\nconnection handshake up the stack without verifying its checksum, because it\ncalls tcp_child_process(), which in turn calls tcp_rcv_state_process()\ndirectly.  These lower-level processing functions do not do any checksum\nverification.\n\nInsert a tcp_checksum_complete call in the TCP_NEW_SYN_RECEIVE path to\nfix this.\n\nFixes: 079096f103fa (\"tcp/dccp: install syn_recv requests into ehash table\")\nSigned-off-by: Frank van der Linden <fllinden@amazon.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nTested-by: Balbir Singh <bsingharora@gmail.com>\nReviewed-by: Balbir Singh <bsingharora@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/48ffbdea28808354b89447fac2d8524c29ce7ab4"},{"sha":"0a986b2733551687becf4012da162aff62a6c3a4","author":{"name":"Lukas Czerner","email":"6c9141d0e2318b390a8a6bf8ecd9f819d16f05b4@redhat.com"},"message":"ext4: update mtime in ext4_punch_hole even if no blocks are released\n\ncommit eee597ac931305eff3d3fd1d61d6aae553bc0984 upstream.\n\nCurrently in ext4_punch_hole we're going to skip the mtime update if\nthere are no actual blocks to release. However we've actually modified\nthe file by zeroing the partial block so the mtime should be updated.\n\nMoreover the sync and datasync handling is skipped as well, which is\nalso wrong. Fix it.\n\nSigned-off-by: Lukas Czerner <lczerner@redhat.com>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nReported-by: Joe Habermann <joe.habermann@quantum.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/0a986b2733551687becf4012da162aff62a6c3a4"},{"sha":"f444af38dd73e073fb0bfda1c4ae7db648b4b499","author":{"name":"Jan Kara","email":"596727c8a0ea4db3ba2ceceedccbacd3d7b371b8@suse.cz"},"message":"ext4: fix fencepost error in check for inode count overflow during resize\n\ncommit 4f2f76f751433908364ccff82f437a57d0e6e9b7 upstream.\n\next4_resize_fs() has an off-by-one bug when checking whether growing of\na filesystem will not overflow inode count. As a result it allows a\nfilesystem with 8192 inodes per group to grow to 64TB which overflows\ninode count to 0 and makes filesystem unusable. Fix it.\n\nCc: stable@vger.kernel.org\nFixes: 3f8a6411fbada1fa482276591e037f3b1adcf55b\nReported-by: Jaco Kroon <jaco@uls.co.za>\nSigned-off-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nReviewed-by: Andreas Dilger <adilger@dilger.ca>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/f444af38dd73e073fb0bfda1c4ae7db648b4b499"},{"sha":"e05dd56499ab4e3597346b7dc5f1dfd5d1168d82","author":{"name":"Tetsuo Handa","email":"3d00b54ad717112934d0b63b7ac2975b44022a61@I-love.SAKURA.ne.jp"},"message":"driver core: Don't ignore class_dir_create_and_add() failure.\n\ncommit 84d0c27d6233a9ba0578b20f5a09701eb66cee42 upstream.\n\nsyzbot is hitting WARN() at kernfs_add_one() [1].\nThis is because kernfs_create_link() is confused by previous device_add()\ncall which continued without setting dev->kobj.parent field when\nget_device_parent() failed by memory allocation fault injection.\nFix this by propagating the error from class_dir_create_and_add() to\nthe calllers of get_device_parent().\n\n[1] https://syzkaller.appspot.com/bug?id=fae0fb607989ea744526d1c082a5b8de6529116f\n\nSigned-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>\nReported-by: syzbot <syzbot+df47f81c226b31d89fb1@syzkaller.appspotmail.com>\nCc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/e05dd56499ab4e3597346b7dc5f1dfd5d1168d82"},{"sha":"d85feb4259a2f234950c3ee0f493a855adef900b","author":{"name":"Qu Wenruo","email":"668a4a6da3341b25f8dc67d6a1b3c7eba3092599@suse.com"},"message":"btrfs: scrub: Don't use inode pages for device replace\n\ncommit ac0b4145d662a3b9e34085dea460fb06ede9b69b upstream.\n\n[BUG]\nBtrfs can create compressed extent without checksum (even though it\nshouldn't), and if we then try to replace device containing such extent,\nthe result device will contain all the uncompressed data instead of the\ncompressed one.\n\nTest case already submitted to fstests:\nhttps://patchwork.kernel.org/patch/10442353/\n\n[CAUSE]\nWhen handling compressed extent without checksum, device replace will\ngoe into copy_nocow_pages() function.\n\nIn that function, btrfs will get all inodes referring to this data\nextents and then use find_or_create_page() to get pages direct from that\ninode.\n\nThe problem here is, pages directly from inode are always uncompressed.\nAnd for compressed data extent, they mismatch with on-disk data.\nThus this leads to corrupted compressed data extent written to replace\ndevice.\n\n[FIX]\nIn this attempt, we could just remove the \"optimization\" branch, and let\nunified scrub_pages() to handle it.\n\nAlthough scrub_pages() won't bother reusing page cache, it will be a\nlittle slower, but it does the correct csum checking and won't cause\nsuch data corruption caused by \"optimization\".\n\nNote about the fix: this is the minimal fix that can be backported to\nolder stable trees without conflicts. The whole callchain from\ncopy_nocow_pages() can be deleted, and will be in followup patches.\n\nFixes: ff023aac3119 (\"Btrfs: add code to scrub to copy read data to another disk\")\nCC: stable@vger.kernel.org # 4.4+\nReported-by: James Harvey <jamespharvey20@gmail.com>\nReviewed-by: James Harvey <jamespharvey20@gmail.com>\nSigned-off-by: Qu Wenruo <wqu@suse.com>\n[ remove code removal, add note why ]\nSigned-off-by: David Sterba <dsterba@suse.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/d85feb4259a2f234950c3ee0f493a855adef900b"},{"sha":"9f1592e4a0464f9676b068ee4463f9d24553d52c","author":{"name":"Bo Chen","email":"24de44a46d60ea7ef40e24f5b6eddbe24de47648@pdx.edu"},"message":"ALSA: hda - Handle kzalloc() failure in snd_hda_attach_pcm_stream()\n\ncommit a3aa60d511746bd6c0d0366d4eb90a7998bcde8b upstream.\n\nWhen 'kzalloc()' fails in 'snd_hda_attach_pcm_stream()', a new pcm instance is\ncreated without setting its operators via 'snd_pcm_set_ops()'. Following\noperations on the new pcm instance can trigger kernel null pointer dereferences\nand cause kernel oops.\n\nThis bug was found with my work on building a gray-box fault-injection tool for\nlinux-kernel-module binaries. A kernel null pointer dereference was confirmed\nfrom line 'substream->ops->open()' in function 'snd_pcm_open_substream()' in\nfile 'sound/core/pcm_native.c'.\n\nThis patch fixes the bug by calling 'snd_device_free()' in the error handling\npath of 'kzalloc()', which removes the new pcm instance from the snd card before\nreturns with an error code.\n\nSigned-off-by: Bo Chen <chenbo@pdx.edu>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/9f1592e4a0464f9676b068ee4463f9d24553d52c"},{"sha":"4f88763cba461ee867fbc3cee0c5c136bb375832","author":{"name":"Dennis Wassenberg","email":"9904d09f91f413bbce5ce9ff7693490f4944ae00@secunet.com"},"message":"ALSA: hda: add dock and led support for HP EliteBook 830 G5\n\ncommit 2861751f67b91e1d24e68010ced96614fb3140f4 upstream.\n\nThis patch adds missing initialisation for HP 2013 UltraSlim Dock\nLine-In/Out PINs and activates keyboard mute/micmute leds\nfor HP EliteBook 830 G5\n\nSigned-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/4f88763cba461ee867fbc3cee0c5c136bb375832"},{"sha":"a8f007c1ada54b266a28ef5bf14a98eb1cfe1ae7","author":{"name":"Dennis Wassenberg","email":"9904d09f91f413bbce5ce9ff7693490f4944ae00@secunet.com"},"message":"ALSA: hda: add dock and led support for HP ProBook 640 G4\n\ncommit 7eef32c1ef895a3a96463f9cbd04203007cd5555 upstream.\n\nThis patch adds missing initialisation for HP 2013 UltraSlim Dock\nLine-In/Out PINs and activates keyboard mute/micmute leds\nfor HP ProBook 640 G4\n\nSigned-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/a8f007c1ada54b266a28ef5bf14a98eb1cfe1ae7"},{"sha":"6f5edfa503fc5e9d142ca5865464f870a1c9622d","author":{"name":"Tao Wang","email":"4b58cc4cc056905ee337c6d9e40f102132ee260c@hisilicon.com"},"message":"cpufreq: Fix new policy initialization during limits updates via sysfs\n\ncommit c7d1f119c48f64bebf0fa1e326af577c6152fe30 upstream.\n\nIf the policy limits are updated via cpufreq_update_policy() and\nsubsequently via sysfs, the limits stored in user_policy may be\nset incorrectly.\n\nFor example, if both min and max are set via sysfs to the maximum\navailable frequency, user_policy.min and user_policy.max will also\nbe the maximum.  If a policy notifier triggered by\ncpufreq_update_policy() lowers both the min and the max at this\npoint, that change is not reflected by the user_policy limits, so\nif the max is updated again via sysfs to the same lower value,\nthen user_policy.max will be lower than user_policy.min which\nshouldn't happen.  In particular, if one of the policy CPUs is\nthen taken offline and back online, cpufreq_set_policy() will\nfail for it due to a failing limits check.\n\nTo prevent that from happening, initialize the min and max fields\nof the new_policy object to the ones stored in user_policy that\nwere previously set via sysfs.\n\nSigned-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com>\nAcked-by: Viresh Kumar <viresh.kumar@linaro.org>\n[ rjw: Subject & changelog ]\nCc: All applicable <stable@vger.kernel.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.18/commits/6f5edfa503fc5e9d142ca5865464f870a1c9622d"}]}
{"actor":{"display_login":"Jackeagle"}}