{"push_id":1342726849,"size":34,"distinct_size":34,"ref":"refs/heads/mainline-n7.0","head":"717c70c2d60a973f5f10e2219882075472a8cb55","before":"718f0cf6a8db79a9659737a1b1591a2224338ee0","commits":[{"sha":"001e7c364a04bd23a35773ea8fb99ace63225f78","author":{"name":"lucien","email":"0c651f6709819e543c4ca1708bc1021b57131127@gmail.com"},"message":"sctp: translate host order to network order when setting a hmacid\n\n[ Upstream commit ed5a377d87dc4c87fb3e1f7f698cba38cd893103 ]\n\nnow sctp auth cannot work well when setting a hmacid manually, which\nis caused by that we didn't use the network order for hmacid, so fix\nit by adding the transformation in sctp_auth_ep_set_hmacs.\n\neven we set hmacid with the network order in userspace, it still\ncan't work, because of this condition in sctp_auth_ep_set_hmacs():\n\n\t\tif (id > SCTP_AUTH_HMAC_ID_MAX)\n\t\t\treturn -EOPNOTSUPP;\n\nso this wasn't working before and thus it won't break compatibility.\n\nFixes: 65b07e5d0d09 (\"[SCTP]: API updates to suport SCTP-AUTH extensions.\")\nSigned-off-by: Xin Long <lucien.xin@gmail.com>\nSigned-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>\nAcked-by: Neil Horman <nhorman@tuxdriver.com>\nAcked-by: Vlad Yasevich <vyasevich@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/001e7c364a04bd23a35773ea8fb99ace63225f78"},{"sha":"0022c1a6deb4218568f877c70f29bbd43ab21e48","author":{"name":"Neil Horman","email":"490c3644041cdec787fa30a5cd5c4dcfde13be34@tuxdriver.com"},"message":"snmp: Remove duplicate OUTMCAST stat increment\n\n[ Upstream commit 41033f029e393a64e81966cbe34d66c6cf8a2e7e ]\n\nthe OUTMCAST stat is double incremented, getting bumped once in the mcast code\nitself, and again in the common ip output path.  Remove the mcast bump, as its\nnot needed\n\nValidated by the reporter, with good results\n\nSigned-off-by: Neil Horman <nhorman@tuxdriver.com>\nReported-by: Claus Jensen <claus.jensen@microsemi.com>\nCC: Claus Jensen <claus.jensen@microsemi.com>\nCC: David Miller <davem@davemloft.net>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/0022c1a6deb4218568f877c70f29bbd43ab21e48"},{"sha":"dfbd2fc0a00f62ac467379e5338235d0c1de6802","author":{"name":"Bjørn Mork","email":"73004647096653cb035375f893ae959ac7bd4f38@mork.no"},"message":"net: qmi_wwan: add XS Stick W100-2 from 4G Systems\n\n[ Upstream commit 68242a5a1e2edce39b069385cbafb82304eac0f1 ]\n\nThomas reports\n\"\n4gsystems sells two total different LTE-surfsticks under the same name.\n..\nThe newer version of XS Stick W100 is from \"omega\"\n..\nUnder windows the driver switches to the same ID, and uses MI03\\6 for\nnetwork and MI01\\6 for modem.\n..\necho \"1c9e 9b01\" > /sys/bus/usb/drivers/qmi_wwan/new_id\necho \"1c9e 9b01\" > /sys/bus/usb-serial/drivers/option1/new_id\n\nT:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0\nD:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1\nP:  Vendor=1c9e ProdID=9b01 Rev=02.32\nS:  Manufacturer=USB Modem\nS:  Product=USB Modem\nS:  SerialNumber=\nC:  #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA\nI:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option\nI:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option\nI:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option\nI:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan\nI:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage\n\nNow all important things are there:\n\nwwp0s29f7u2i3 (net), ttyUSB2 (at), cdc-wdm0 (qmi), ttyUSB1 (at)\n\nThere is also ttyUSB0, but it is not usable, at least not for at.\n\nThe device works well with qmi and ModemManager-NetworkManager.\n\"\n\nReported-by: Thomas Schäfer <tschaefer@t-online.de>\nSigned-off-by: Bjørn Mork <bjorn@mork.no>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/dfbd2fc0a00f62ac467379e5338235d0c1de6802"},{"sha":"642e63b4ec371052211c48dc90900529126cdc56","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"tcp: md5: fix lockdep annotation\n\n[ Upstream commit 1b8e6a01e19f001e9f93b39c32387961c91ed3cc ]\n\nWhen a passive TCP is created, we eventually call tcp_md5_do_add()\nwith sk pointing to the child. It is not owner by the user yet (we\nwill add this socket into listener accept queue a bit later anyway)\n\nBut we do own the spinlock, so amend the lockdep annotation to avoid\nfollowing splat :\n\n[ 8451.090932] net/ipv4/tcp_ipv4.c:923 suspicious rcu_dereference_protected() usage!\n[ 8451.090932]\n[ 8451.090932] other info that might help us debug this:\n[ 8451.090932]\n[ 8451.090934]\n[ 8451.090934] rcu_scheduler_active = 1, debug_locks = 1\n[ 8451.090936] 3 locks held by socket_sockopt_/214795:\n[ 8451.090936]  #0:  (rcu_read_lock){.+.+..}, at: [<ffffffff855c6ac1>] __netif_receive_skb_core+0x151/0xe90\n[ 8451.090947]  #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff85618143>] ip_local_deliver_finish+0x43/0x2b0\n[ 8451.090952]  #2:  (slock-AF_INET){+.-...}, at: [<ffffffff855acda5>] sk_clone_lock+0x1c5/0x500\n[ 8451.090958]\n[ 8451.090958] stack backtrace:\n[ 8451.090960] CPU: 7 PID: 214795 Comm: socket_sockopt_\n\n[ 8451.091215] Call Trace:\n[ 8451.091216]  <IRQ>  [<ffffffff856fb29c>] dump_stack+0x55/0x76\n[ 8451.091229]  [<ffffffff85123b5b>] lockdep_rcu_suspicious+0xeb/0x110\n[ 8451.091235]  [<ffffffff8564544f>] tcp_md5_do_add+0x1bf/0x1e0\n[ 8451.091239]  [<ffffffff85645751>] tcp_v4_syn_recv_sock+0x1f1/0x4c0\n[ 8451.091242]  [<ffffffff85642b27>] ? tcp_v4_md5_hash_skb+0x167/0x190\n[ 8451.091246]  [<ffffffff85647c78>] tcp_check_req+0x3c8/0x500\n[ 8451.091249]  [<ffffffff856451ae>] ? tcp_v4_inbound_md5_hash+0x11e/0x190\n[ 8451.091253]  [<ffffffff85647170>] tcp_v4_rcv+0x3c0/0x9f0\n[ 8451.091256]  [<ffffffff85618143>] ? ip_local_deliver_finish+0x43/0x2b0\n[ 8451.091260]  [<ffffffff856181b6>] ip_local_deliver_finish+0xb6/0x2b0\n[ 8451.091263]  [<ffffffff85618143>] ? ip_local_deliver_finish+0x43/0x2b0\n[ 8451.091267]  [<ffffffff85618d38>] ip_local_deliver+0x48/0x80\n[ 8451.091270]  [<ffffffff85618510>] ip_rcv_finish+0x160/0x700\n[ 8451.091273]  [<ffffffff8561900e>] ip_rcv+0x29e/0x3d0\n[ 8451.091277]  [<ffffffff855c74b7>] __netif_receive_skb_core+0xb47/0xe90\n\nFixes: a8afca0329988 (\"tcp: md5: protects md5sig_info with RCU\")\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nReported-by: Willem de Bruijn <willemb@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/642e63b4ec371052211c48dc90900529126cdc56"},{"sha":"36d3e52b96b6f5ef295d538bd1c791e57a5fc082","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"tcp: initialize tp->copied_seq in case of cross SYN connection\n\n[ Upstream commit 142a2e7ece8d8ac0e818eb2c91f99ca894730e2a ]\n\nDmitry provided a syzkaller (http://github.com/google/syzkaller)\ngenerated program that triggers the WARNING at\nnet/ipv4/tcp.c:1729 in tcp_recvmsg() :\n\nWARN_ON(tp->copied_seq != tp->rcv_nxt &&\n        !(flags & (MSG_PEEK | MSG_TRUNC)));\n\nHis program is specifically attempting a Cross SYN TCP exchange,\nthat we support (for the pleasure of hackers ?), but it looks we\nlack proper tcp->copied_seq initialization.\n\nThanks again Dmitry for your report and testings.\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nTested-by: Dmitry Vyukov <dvyukov@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/36d3e52b96b6f5ef295d538bd1c791e57a5fc082"},{"sha":"1cb5468215f5ac190a0ccec20023df3f1e71a6f9","author":{"name":"Daniel Borkmann","email":"4b94a04674ad2c69d990e94ab196ac3f8e9e03d4@iogearbox.net"},"message":"net, scm: fix PaX detected msg_controllen overflow in scm_detach_fds\n\n[ Upstream commit 6900317f5eff0a7070c5936e5383f589e0de7a09 ]\n\nDavid and HacKurx reported a following/similar size overflow triggered\nin a grsecurity kernel, thanks to PaX's gcc size overflow plugin:\n\n(Already fixed in later grsecurity versions by Brad and PaX Team.)\n\n[ 1002.296137] PAX: size overflow detected in function scm_detach_fds net/core/scm.c:314\n               cicus.202_127 min, count: 4, decl: msg_controllen; num: 0; context: msghdr;\n[ 1002.296145] CPU: 0 PID: 3685 Comm: scm_rights_recv Not tainted 4.2.3-grsec+ #7\n[ 1002.296149] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, [...]\n[ 1002.296153]  ffffffff81c27366 0000000000000000 ffffffff81c27375 ffffc90007843aa8\n[ 1002.296162]  ffffffff818129ba 0000000000000000 ffffffff81c27366 ffffc90007843ad8\n[ 1002.296169]  ffffffff8121f838 fffffffffffffffc fffffffffffffffc ffffc90007843e60\n[ 1002.296176] Call Trace:\n[ 1002.296190]  [<ffffffff818129ba>] dump_stack+0x45/0x57\n[ 1002.296200]  [<ffffffff8121f838>] report_size_overflow+0x38/0x60\n[ 1002.296209]  [<ffffffff816a979e>] scm_detach_fds+0x2ce/0x300\n[ 1002.296220]  [<ffffffff81791899>] unix_stream_read_generic+0x609/0x930\n[ 1002.296228]  [<ffffffff81791c9f>] unix_stream_recvmsg+0x4f/0x60\n[ 1002.296236]  [<ffffffff8178dc00>] ? unix_set_peek_off+0x50/0x50\n[ 1002.296243]  [<ffffffff8168fac7>] sock_recvmsg+0x47/0x60\n[ 1002.296248]  [<ffffffff81691522>] ___sys_recvmsg+0xe2/0x1e0\n[ 1002.296257]  [<ffffffff81693496>] __sys_recvmsg+0x46/0x80\n[ 1002.296263]  [<ffffffff816934fc>] SyS_recvmsg+0x2c/0x40\n[ 1002.296271]  [<ffffffff8181a3ab>] entry_SYSCALL_64_fastpath+0x12/0x85\n\nFurther investigation showed that this can happen when an *odd* number of\nfds are being passed over AF_UNIX sockets.\n\nIn these cases CMSG_LEN(i * sizeof(int)) and CMSG_SPACE(i * sizeof(int)),\nwhere i is the number of successfully passed fds, differ by 4 bytes due\nto the extra CMSG_ALIGN() padding in CMSG_SPACE() to an 8 byte boundary\non 64 bit. The padding is used to align subsequent cmsg headers in the\ncontrol buffer.\n\nWhen the control buffer passed in from the receiver side *lacks* these 4\nbytes (e.g. due to buggy/wrong API usage), then msg->msg_controllen will\noverflow in scm_detach_fds():\n\n  int cmlen = CMSG_LEN(i * sizeof(int));  <--- cmlen w/o tail-padding\n  err = put_user(SOL_SOCKET, &cm->cmsg_level);\n  if (!err)\n    err = put_user(SCM_RIGHTS, &cm->cmsg_type);\n  if (!err)\n    err = put_user(cmlen, &cm->cmsg_len);\n  if (!err) {\n    cmlen = CMSG_SPACE(i * sizeof(int));  <--- cmlen w/ 4 byte extra tail-padding\n    msg->msg_control += cmlen;\n    msg->msg_controllen -= cmlen;         <--- iff no tail-padding space here ...\n  }                                            ... wrap-around\n\nF.e. it will wrap to a length of 18446744073709551612 bytes in case the\nreceiver passed in msg->msg_controllen of 20 bytes, and the sender\nproperly transferred 1 fd to the receiver, so that its CMSG_LEN results\nin 20 bytes and CMSG_SPACE in 24 bytes.\n\nIn case of MSG_CMSG_COMPAT (scm_detach_fds_compat()), I haven't seen an\nissue in my tests as alignment seems always on 4 byte boundary. Same\nshould be in case of native 32 bit, where we end up with 4 byte boundaries\nas well.\n\nIn practice, passing msg->msg_controllen of 20 to recvmsg() while receiving\na single fd would mean that on successful return, msg->msg_controllen is\nbeing set by the kernel to 24 bytes instead, thus more than the input\nbuffer advertised. It could f.e. become an issue if such application later\non zeroes or copies the control buffer based on the returned msg->msg_controllen\nelsewhere.\n\nMaximum number of fds we can send is a hard upper limit SCM_MAX_FD (253).\n\nGoing over the code, it seems like msg->msg_controllen is not being read\nafter scm_detach_fds() in scm_recv() anymore by the kernel, good!\n\nRelevant recvmsg() handler are unix_dgram_recvmsg() (unix_seqpacket_recvmsg())\nand unix_stream_recvmsg(). Both return back to their recvmsg() caller,\nand ___sys_recvmsg() places the updated length, that is, new msg_control -\nold msg_control pointer into msg->msg_controllen (hence the 24 bytes seen\nin the example).\n\nLong time ago, Wei Yongjun fixed something related in commit 1ac70e7ad24a\n(\"[NET]: Fix function put_cmsg() which may cause usr application memory\noverflow\").\n\nRFC3542, section 20.2. says:\n\n  The fields shown as \"XX\" are possible padding, between the cmsghdr\n  structure and the data, and between the data and the next cmsghdr\n  structure, if required by the implementation. While sending an\n  application may or may not include padding at the end of last\n  ancillary data in msg_controllen and implementations must accept both\n  as valid. On receiving a portable application must provide space for\n  padding at the end of the last ancillary data as implementations may\n  copy out the padding at the end of the control message buffer and\n  include it in the received msg_controllen. When recvmsg() is called\n  if msg_controllen is too small for all the ancillary data items\n  including any trailing padding after the last item an implementation\n  may set MSG_CTRUNC.\n\nSince we didn't place MSG_CTRUNC for already quite a long time, just do\nthe same as in 1ac70e7ad24a to avoid an overflow.\n\nBtw, even man-page author got this wrong :/ See db939c9b26e9 (\"cmsg.3: Fix\nerror in SCM_RIGHTS code sample\"). Some people must have copied this (?),\nthus it got triggered in the wild (reported several times during boot by\nDavid and HacKurx).\n\nNo Fixes tag this time as pre 2002 (that is, pre history tree).\n\nReported-by: David Sterba <dave@jikos.cz>\nReported-by: HacKurx <hackurx@gmail.com>\nCc: PaX Team <pageexec@freemail.hu>\nCc: Emese Revfy <re.emese@gmail.com>\nCc: Brad Spengler <spender@grsecurity.net>\nCc: Wei Yongjun <yongjun_wei@trendmicro.com.cn>\nCc: Eric Dumazet <edumazet@google.com>\nReviewed-by: Hannes Frederic Sowa <hannes@stressinduktion.org>\nSigned-off-by: Daniel Borkmann <daniel@iogearbox.net>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/1cb5468215f5ac190a0ccec20023df3f1e71a6f9"},{"sha":"df4f6be9650681aa4750f827e5f46183ce24089a","author":{"name":"Nikolay Aleksandrov","email":"64c6133501914790fe0371388ffd86301bcc142b@cumulusnetworks.com"},"message":"net: ipmr: fix static mfc/dev leaks on table destruction\n\n[ Upstream commit 0e615e9601a15efeeb8942cf7cd4dadba0c8c5a7 ]\n\nWhen destroying an mrt table the static mfc entries and the static\ndevices are kept, which leads to devices that can never be destroyed\n(because of refcnt taken) and leaked memory, for example:\nunreferenced object 0xffff880034c144c0 (size 192):\n  comm \"mfc-broken\", pid 4777, jiffies 4320349055 (age 46001.964s)\n  hex dump (first 32 bytes):\n    98 53 f0 34 00 88 ff ff 98 53 f0 34 00 88 ff ff  .S.4.....S.4....\n    ef 0a 0a 14 01 02 03 04 00 00 00 00 01 00 00 00  ................\n  backtrace:\n    [<ffffffff815c1b9e>] kmemleak_alloc+0x4e/0xb0\n    [<ffffffff811ea6e0>] kmem_cache_alloc+0x190/0x300\n    [<ffffffff815931cb>] ip_mroute_setsockopt+0x5cb/0x910\n    [<ffffffff8153d575>] do_ip_setsockopt.isra.11+0x105/0xff0\n    [<ffffffff8153e490>] ip_setsockopt+0x30/0xa0\n    [<ffffffff81564e13>] raw_setsockopt+0x33/0x90\n    [<ffffffff814d1e14>] sock_common_setsockopt+0x14/0x20\n    [<ffffffff814d0b51>] SyS_setsockopt+0x71/0xc0\n    [<ffffffff815cdbf6>] entry_SYSCALL_64_fastpath+0x16/0x7a\n    [<ffffffffffffffff>] 0xffffffffffffffff\n\nMake sure that everything is cleaned on netns destruction.\n\nSigned-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>\nReviewed-by: Cong Wang <cwang@twopensource.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/df4f6be9650681aa4750f827e5f46183ce24089a"},{"sha":"09eb1672ff489ffdf8c6341b065dfc6e0532b7f8","author":{"name":"Nikolay Aleksandrov","email":"64c6133501914790fe0371388ffd86301bcc142b@cumulusnetworks.com"},"message":"net: ip6mr: fix static mfc/dev leaks on table destruction\n\n[ Upstream commit 4c6980462f32b4f282c5d8e5f7ea8070e2937725 ]\n\nSimilar to ipv4, when destroying an mrt table the static mfc entries and\nthe static devices are kept, which leads to devices that can never be\ndestroyed (because of refcnt taken) and leaked memory. Make sure that\neverything is cleaned up on netns destruction.\n\nFixes: 8229efdaef1e (\"netns: ip6mr: enable namespace support in ipv6 multicast forwarding code\")\nCC: Benjamin Thery <benjamin.thery@bull.net>\nSigned-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>\nReviewed-by: Cong Wang <cwang@twopensource.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/09eb1672ff489ffdf8c6341b065dfc6e0532b7f8"},{"sha":"1803f77e213c96374768b413cf0a9dcbf96cec6a","author":{"name":"Aaro Koskinen","email":"c50bd9eacd8e36aece90d59a66da34d1a45e47ef@iki.fi"},"message":"broadcom: fix PHY_ID_BCM5481 entry in the id table\n\n[ Upstream commit 3c25a860d17b7378822f35d8c9141db9507e3beb ]\n\nCommit fcb26ec5b18d (\"broadcom: move all PHY_ID's to header\")\nupdated broadcom_tbl to use PHY_IDs, but incorrectly replaced 0x0143bca0\nwith PHY_ID_BCM5482 (making a duplicate entry, and completely omitting\nthe original). Fix that.\n\nFixes: fcb26ec5b18d (\"broadcom: move all PHY_ID's to header\")\nSigned-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/1803f77e213c96374768b413cf0a9dcbf96cec6a"},{"sha":"df15cad9c90c6d1c7a839cc2e65292122fee0aba","author":{"name":"Michal Kubeček","email":"47170cf003259559754eb8c2b060d5264f7a71b5@suse.cz"},"message":"ipv6: distinguish frag queues by device for multicast and link-local packets\n\n[ Upstream commit 264640fc2c5f4f913db5c73fa3eb1ead2c45e9d7 ]\n\nIf a fragmented multicast packet is received on an ethernet device which\nhas an active macvlan on top of it, each fragment is duplicated and\nreceived both on the underlying device and the macvlan. If some\nfragments for macvlan are processed before the whole packet for the\nunderlying device is reassembled, the \"overlapping fragments\" test in\nip6_frag_queue() discards the whole fragment queue.\n\nTo resolve this, add device ifindex to the search key and require it to\nmatch reassembling multicast packets and packets to link-local\naddresses.\n\nNote: similar patch has been already submitted by Yoshifuji Hideaki in\n\n  http://patchwork.ozlabs.org/patch/220979/\n\nbut got lost and forgotten for some reason.\n\nSigned-off-by: Michal Kubecek <mkubecek@suse.cz>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/df15cad9c90c6d1c7a839cc2e65292122fee0aba"},{"sha":"50cebce9b91726f5784642738a0662fa37f2d99e","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"ipv6: sctp: implement sctp_v6_destroy_sock()\n\n[ Upstream commit 602dd62dfbda3e63a2d6a3cbde953ebe82bf5087 ]\n\nDmitry Vyukov reported a memory leak using IPV6 SCTP sockets.\n\nWe need to call inet6_destroy_sock() to properly release\ninet6 specific fields.\n\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nAcked-by: Daniel Borkmann <daniel@iogearbox.net>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/50cebce9b91726f5784642738a0662fa37f2d99e"},{"sha":"fcbb7c66b63d59955169422f02cced18ad445e7f","author":{"name":"Filipe Manana","email":"396addc00218539530419b15da697a581cb02fca@suse.com"},"message":"Btrfs: fix race leading to BUG_ON when running delalloc for nodatacow\n\ncommit 1d512cb77bdbda80f0dd0620a3b260d697fd581d upstream.\n\nIf we are using the NO_HOLES feature, we have a tiny time window when\nrunning delalloc for a nodatacow inode where we can race with a concurrent\nlink or xattr add operation leading to a BUG_ON.\n\nThis happens because at run_delalloc_nocow() we end up casting a leaf item\nof type BTRFS_INODE_[REF|EXTREF]_KEY or of type BTRFS_XATTR_ITEM_KEY to a\nfile extent item (struct btrfs_file_extent_item) and then analyse its\nextent type field, which won't match any of the expected extent types\n(values BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]) and therefore trigger an\nexplicit BUG_ON(1).\n\nThe following sequence diagram shows how the race happens when running a\nno-cow dellaloc range [4K, 8K[ for inode 257 and we have the following\nneighbour leafs:\n\n             Leaf X (has N items)                    Leaf Y\n\n [ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ]  [ (257 EXTENT_DATA 8192), ... ]\n              slot N - 2         slot N - 1              slot 0\n\n (Note the implicit hole for inode 257 regarding the [0, 8K[ range)\n\n       CPU 1                                         CPU 2\n\n run_dealloc_nocow()\n   btrfs_lookup_file_extent()\n     --> searches for a key with value\n         (257 EXTENT_DATA 4096) in the\n         fs/subvol tree\n     --> returns us a path with\n         path->nodes[0] == leaf X and\n         path->slots[0] == N\n\n   because path->slots[0] is >=\n   btrfs_header_nritems(leaf X), it\n   calls btrfs_next_leaf()\n\n   btrfs_next_leaf()\n     --> releases the path\n\n                                              hard link added to our inode,\n                                              with key (257 INODE_REF 500)\n                                              added to the end of leaf X,\n                                              so leaf X now has N + 1 keys\n\n     --> searches for the key\n         (257 INODE_REF 256), because\n         it was the last key in leaf X\n         before it released the path,\n         with path->keep_locks set to 1\n\n     --> ends up at leaf X again and\n         it verifies that the key\n         (257 INODE_REF 256) is no longer\n         the last key in the leaf, so it\n         returns with path->nodes[0] ==\n         leaf X and path->slots[0] == N,\n         pointing to the new item with\n         key (257 INODE_REF 500)\n\n   the loop iteration of run_dealloc_nocow()\n   does not break out the loop and continues\n   because the key referenced in the path\n   at path->nodes[0] and path->slots[0] is\n   for inode 257, its type is < BTRFS_EXTENT_DATA_KEY\n   and its offset (500) is less then our delalloc\n   range's end (8192)\n\n   the item pointed by the path, an inode reference item,\n   is (incorrectly) interpreted as a file extent item and\n   we get an invalid extent type, leading to the BUG_ON(1):\n\n   if (extent_type == BTRFS_FILE_EXTENT_REG ||\n      extent_type == BTRFS_FILE_EXTENT_PREALLOC) {\n       (...)\n   } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) {\n       (...)\n   } else {\n       BUG_ON(1)\n   }\n\nThe same can happen if a xattr is added concurrently and ends up having\na key with an offset smaller then the delalloc's range end.\n\nSo fix this by skipping keys with a type smaller than\nBTRFS_EXTENT_DATA_KEY.\n\nSigned-off-by: Filipe Manana <fdmanana@suse.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/fcbb7c66b63d59955169422f02cced18ad445e7f"},{"sha":"1775b453d8545bba13c33e7376a39200becc560d","author":{"name":"Daeho Jeong","email":"10047286f23c4492b9fcf1500c061890203906c4@samsung.com"},"message":"ext4, jbd2: ensure entering into panic after recording an error in superblock\n\ncommit 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 upstream.\n\nIf a EXT4 filesystem utilizes JBD2 journaling and an error occurs, the\njournaling will be aborted first and the error number will be recorded\ninto JBD2 superblock and, finally, the system will enter into the\npanic state in \"errors=panic\" option.  But, in the rare case, this\nsequence is little twisted like the below figure and it will happen\nthat the system enters into panic state, which means the system reset\nin mobile environment, before completion of recording an error in the\njournal superblock. In this case, e2fsck cannot recognize that the\nfilesystem failure occurred in the previous run and the corruption\nwouldn't be fixed.\n\nTask A                        Task B\next4_handle_error()\n-> jbd2_journal_abort()\n  -> __journal_abort_soft()\n    -> __jbd2_journal_abort_hard()\n    | -> journal->j_flags |= JBD2_ABORT;\n    |\n    |                         __ext4_abort()\n    |                         -> jbd2_journal_abort()\n    |                         | -> __journal_abort_soft()\n    |                         |   -> if (journal->j_flags & JBD2_ABORT)\n    |                         |           return;\n    |                         -> panic()\n    |\n    -> jbd2_journal_update_sb_errno()\n\nTested-by: Hobin Woo <hobin.woo@samsung.com>\nSigned-off-by: Daeho Jeong <daeho.jeong@samsung.com>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/1775b453d8545bba13c33e7376a39200becc560d"},{"sha":"2b2e3caa060acd6935ed8286b188486f08e75859","author":{"name":"Stefan Richter","email":"16efdbbf738233a9ad8a4fa9829ced5985a9ed16@s5r6.in-berlin.de"},"message":"firewire: ohci: fix JMicron JMB38x IT context discovery\n\ncommit 100ceb66d5c40cc0c7018e06a9474302470be73c upstream.\n\nReported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo\ncontrollers:  Often or even most of the time, the controller is\ninitialized with the message \"added OHCI v1.10 device as card 0, 4 IR +\n0 IT contexts, quirks 0x10\".  With 0 isochronous transmit DMA contexts\n(IT contexts), applications like audio output are impossible.\n\nHowever, OHCI-1394 demands that at least 4 IT contexts are implemented\nby the link layer controller, and indeed JMicron JMB38x do implement\nfour of them.  Only their IsoXmitIntMask register is unreliable at early\naccess.\n\nWith my own JMB381 single function controller I found:\n  - I can reproduce the problem with a lower probability than Craig's.\n  - If I put a loop around the section which clears and reads\n    IsoXmitIntMask, then either the first or the second attempt will\n    return the correct initial mask of 0x0000000f.  I never encountered\n    a case of needing more than a second attempt.\n  - Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet)\n    before the first write, the subsequent read will return the correct\n    result.\n  - If I merely ignore a wrong read result and force the known real\n    result, later isochronous transmit DMA usage works just fine.\n\nSo let's just fix this chip bug up by the latter method.  Tested with\nJMB381 on kernel 3.13 and 4.3.\n\nSince OHCI-1394 generally requires 4 IT contexts at a minium, this\nworkaround is simply applied whenever the initial read of IsoXmitIntMask\nreturns 0, regardless whether it's a JMicron chip or not.  I never heard\nof this issue together with any other chip though.\n\nI am not 100% sure that this fix works on the OHCI-1394 part of JMB380\nand JMB388 combo controllers exactly the same as on the JMB381 single-\nfunction controller, but so far I haven't had a chance to let an owner\nof a combo chip run a patched kernel.\n\nStrangely enough, IsoRecvIntMask is always reported correctly, even\nthough it is probed right before IsoXmitIntMask.\n\nReported-by: Clifford Dunn\nReported-by: Craig Moore <craig.moore@qenos.com>\nSigned-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/2b2e3caa060acd6935ed8286b188486f08e75859"},{"sha":"ceebb66b0341530703a0188a32c5ffe48a1b6598","author":{"name":"Benjamin Coddington","email":"a662de85d20459d74b4e8c23fc1cb2d7c8533504@redhat.com"},"message":"nfs4: start callback_ident at idr 1\n\ncommit c68a027c05709330fe5b2f50c50d5fa02124b5d8 upstream.\n\nIf clp->cl_cb_ident is zero, then nfs_cb_idr_remove_locked() skips removing\nit when the nfs_client is freed.  A decoding or server bug can then find\nand try to put that first nfs_client which would lead to a crash.\n\nSigned-off-by: Benjamin Coddington <bcodding@redhat.com>\nFixes: d6870312659d (\"nfs4client: convert to idr_alloc()\")\nSigned-off-by: Trond Myklebust <trond.myklebust@primarydata.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/ceebb66b0341530703a0188a32c5ffe48a1b6598"},{"sha":"ab48ccfd0f5f9ecf718a670d0297d61e524820d8","author":{"name":"Jeff Layton","email":"0a799ee4f46e914219e7741adcc5e93178d519ec@poochiereds.net"},"message":"nfs: if we have no valid attrs, then don't declare the attribute cache valid\n\ncommit c812012f9ca7cf89c9e1a1cd512e6c3b5be04b85 upstream.\n\nIf we pass in an empty nfs_fattr struct to nfs_update_inode, it will\n(correctly) not update any of the attributes, but it then clears the\nNFS_INO_INVALID_ATTR flag, which indicates that the attributes are\nup to date. Don't clear the flag if the fattr struct has no valid\nattrs to apply.\n\nReviewed-by: Steve French <steve.french@primarydata.com>\nSigned-off-by: Jeff Layton <jeff.layton@primarydata.com>\nSigned-off-by: Trond Myklebust <trond.myklebust@primarydata.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/ab48ccfd0f5f9ecf718a670d0297d61e524820d8"},{"sha":"7fd8e436f0129d3a6a0098f41ffd4095a2190db8","author":{"name":"Jonas Jonsson","email":"7f140b51f30eb0762518f611c7ec9a2dd0c91007@ludd.ltu.se"},"message":"USB: cdc_acm: Ignore Infineon Flash Loader utility\n\ncommit f33a7f72e5fc033daccbb8d4753d7c5c41a4d67b upstream.\n\nSome modems, such as the Telit UE910, are using an Infineon Flash Loader\nutility. It has two interfaces, 2/2/0 (Abstract Modem) and 10/0/0 (CDC\nData). The latter can be used as a serial interface to upgrade the\nfirmware of the modem. However, that isn't possible when the cdc-acm\ndriver takes control of the device.\n\nThe following is an explanation of the behaviour by Daniele Palmas during\ndiscussion on linux-usb.\n\n\"This is what happens when the device is turned on (without modifying\nthe drivers):\n\n[155492.352031] usb 1-3: new high-speed USB device number 27 using ehci-pci\n[155492.485429] usb 1-3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11\n[155492.485436] usb 1-3: New USB device found, idVendor=058b, idProduct=0041\n[155492.485439] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0\n[155492.485952] cdc_acm 1-3:1.0: ttyACM0: USB ACM device\n\nThis is the flashing device that is caught by the cdc-acm driver. Once\nthe ttyACM appears, the application starts sending a magic string\n(simple write on the file descriptor) to keep the device in flashing\nmode. If this magic string is not properly received in a certain time\ninterval, the modem goes on in normal operative mode:\n\n[155493.748094] usb 1-3: USB disconnect, device number 27\n[155494.916025] usb 1-3: new high-speed USB device number 28 using ehci-pci\n[155495.059978] usb 1-3: New USB device found, idVendor=1bc7, idProduct=0021\n[155495.059983] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3\n[155495.059986] usb 1-3: Product: 6 CDC-ACM + 1 CDC-ECM\n[155495.059989] usb 1-3: Manufacturer: Telit\n[155495.059992] usb 1-3: SerialNumber: 359658044004697\n[155495.138958] cdc_acm 1-3:1.0: ttyACM0: USB ACM device\n[155495.140832] cdc_acm 1-3:1.2: ttyACM1: USB ACM device\n[155495.142827] cdc_acm 1-3:1.4: ttyACM2: USB ACM device\n[155495.144462] cdc_acm 1-3:1.6: ttyACM3: USB ACM device\n[155495.145967] cdc_acm 1-3:1.8: ttyACM4: USB ACM device\n[155495.147588] cdc_acm 1-3:1.10: ttyACM5: USB ACM device\n[155495.154322] cdc_ether 1-3:1.12 wwan0: register 'cdc_ether' at usb-0000:00:1a.7-3, Mobile Broadband Network Device, 00:00:11:12:13:14\n\nUsing the cdc-acm driver, the string, though being sent in the same way\nthan using the usb-serial-simple driver (I can confirm that the data is\npassing properly since I used an hw usb sniffer), does not make the\ndevice to stay in flashing mode.\"\n\nSigned-off-by: Jonas Jonsson <jonas@ludd.ltu.se>\nTested-by: Daniele Palmas <dnlplm@gmail.com>\nSigned-off-by: Johan Hovold <johan@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/7fd8e436f0129d3a6a0098f41ffd4095a2190db8"},{"sha":"693915382b08c769531c2b6620cccb7fbafef977","author":{"name":"Konstantin Shkolnyy","email":"b17b7438ce28450aa65073850047cde5a9fa74f6@gmail.com"},"message":"USB: cp210x: Remove CP2110 ID from compatibility list\n\ncommit 7c90e610b60cd1ed6abafd806acfaedccbbe52d1 upstream.\n\nCP2110 ID (0x10c4, 0xea80) doesn't belong here because it's a HID\nand completely different from CP210x devices.\n\nSigned-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>\nSigned-off-by: Johan Hovold <johan@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/693915382b08c769531c2b6620cccb7fbafef977"},{"sha":"924db8791ec3daa8fdee79cba3396cd3418f3349","author":{"name":"Alan Stern","email":"5c4cbde65af01ad64f5b2177d0cd78ab5b01e5a1@rowland.harvard.edu"},"message":"USB: add quirk for devices with broken LPM\n\ncommit ad87e03213b552a5c33d5e1e7a19a73768397010 upstream.\n\nSome USB device / host controller combinations seem to have problems\nwith Link Power Management.  For example, Steinar found that his xHCI\ncontroller wouldn't handle bandwidth calculations correctly for two\nvideo cards simultaneously when LPM was enabled, even though the bus\nhad plenty of bandwidth available.\n\nThis patch introduces a new quirk flag for devices that should remain\ndisabled for LPM, and creates quirk entries for Steinar's devices.\n\nSigned-off-by: Alan Stern <stern@rowland.harvard.edu>\nReported-by: Steinar H. Gunderson <sgunderson@bigfoot.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/924db8791ec3daa8fdee79cba3396cd3418f3349"},{"sha":"6076ac01144ab119c85608b89c97fd7c9c1d88f8","author":{"name":"Alexey Khoroshilov","email":"ace9a61ddd722b948531d2d4c78db504ebfc9f1b@ispras.ru"},"message":"USB: whci-hcd: add check for dma mapping error\n\ncommit f9fa1887dcf26bd346665a6ae3d3f53dec54cba1 upstream.\n\nqset_fill_page_list() do not check for dma mapping errors.\n\nFound by Linux Driver Verification project (linuxtesting.org).\n\nSigned-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/B14CKB1RD-Kernel/B14CKB1RD_Kernel_N6/commits/6076ac01144ab119c85608b89c97fd7c9c1d88f8"}]}
{"actor":{"display_login":"REV3NT3CH"}}