{"push_id":2147831398,"size":14,"distinct_size":1,"ref":"refs/heads/tuxonice-3.18","head":"be58d0e4b707a303ed85ab76df198db494773988","before":"eeac28384b733b14ada98b6c8e4ecb82b3c8a3df","commits":[{"sha":"3f45934ed0bd864f878a78c3dfbd1ad437ba427f","author":{"name":"WANG Cong","email":"3f5d79d28d6d48052800caba9df0b30e06fefe41@gmail.com"},"message":"ipv6/dccp: do not inherit ipv6_mc_list from parent\n\ncommit 83eaddab4378db256d00d295bda6ca997cd13a52 upstream.\n\nLike commit 657831ffc38e (\"dccp/tcp: do not inherit mc_list from parent\")\nwe should clear ipv6_mc_list etc. for IPv6 sockets too.\n\nCc: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Cong Wang <xiyou.wangcong@gmail.com>\nAcked-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Connor O'Brien <connoro@google.com>\n[AmitP: cherry-picked this backported commit from android-3.18]\nSigned-off-by: Amit Pundir <amit.pundir@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/3f45934ed0bd864f878a78c3dfbd1ad437ba427f"},{"sha":"b4b4a3b633cbaaba16b1a21a2e3d3c0fead187da","author":{"name":"Eric W. Biederman","email":"e4ccc9f9b54eebd6cb8fc7643b8083f628b68ff2@xmission.com"},"message":"net/sctp: Always set scope_id in sctp_inet6_skb_msgname\n\n\n[ Upstream commit 7c8a61d9ee1df0fb4747879fa67a99614eb62fec ]\n\nAlexandar Potapenko while testing the kernel with KMSAN and syzkaller\ndiscovered that in some configurations sctp would leak 4 bytes of\nkernel stack.\n\nWorking with his reproducer I discovered that those 4 bytes that\nare leaked is the scope id of an ipv6 address returned by recvmsg.\n\nWith a little code inspection and a shrewd guess I discovered that\nsctp_inet6_skb_msgname only initializes the scope_id field for link\nlocal ipv6 addresses to the interface index the link local address\npertains to instead of initializing the scope_id field for all ipv6\naddresses.\n\nThat is almost reasonable as scope_id's are meaniningful only for link\nlocal addresses.  Set the scope_id in all other cases to 0 which is\nnot a valid interface index to make it clear there is nothing useful\nin the scope_id field.\n\nThere should be no danger of breaking userspace as the stack leak\nguaranteed that previously meaningless random data was being returned.\n\nFixes: 372f525b495c (\"SCTP:  Resync with LKSCTP tree.\")\nHistory-tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git\nReported-by: Alexander Potapenko <glider@google.com>\nTested-by: Alexander Potapenko <glider@google.com>\nSigned-off-by: \"Eric W. Biederman\" <ebiederm@xmission.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/NigelCunningham/tuxonice-kernel/commits/b4b4a3b633cbaaba16b1a21a2e3d3c0fead187da"},{"sha":"475b9905b0c09ee64d45aa4bbcfd89f3546fc9cc","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"tcp: do not mangle skb->cb[] in tcp_make_synack()\n\n\n[ Upstream commit 3b11775033dc87c3d161996c54507b15ba26414a ]\n\nChristoph Paasch sent a patch to address the following issue :\n\ntcp_make_synack() is leaving some TCP private info in skb->cb[],\nthen send the packet by other means than tcp_transmit_skb()\n\ntcp_transmit_skb() makes sure to clear skb->cb[] to not confuse\nIPv4/IPV6 stacks, but we have no such cleanup for SYNACK.\n\ntcp_make_synack() should not use tcp_init_nondata_skb() :\n\ntcp_init_nondata_skb() really should be limited to skbs put in write/rtx\nqueues (the ones that are only sent via tcp_transmit_skb())\n\nThis patch fixes the issue and should even save few cpu cycles ;)\n\nFixes: 971f10eca186 (\"tcp: better TCP_SKB_CB layout to reduce cache line misses\")\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nReported-by: Christoph Paasch <cpaasch@apple.com>\nReviewed-by: Christoph Paasch <cpaasch@apple.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/NigelCunningham/tuxonice-kernel/commits/475b9905b0c09ee64d45aa4bbcfd89f3546fc9cc"},{"sha":"5b2af5fff8faeb56e654108a7d6465d52996d3a5","author":{"name":"Ye Yin","email":"c09b248acf5db482d338807c0ab42c7c059fb2f4@gmail.com"},"message":"netfilter/ipvs: clear ipvs_property flag when SKB net namespace changed\n\n\n[ Upstream commit 2b5ec1a5f9738ee7bf8f5ec0526e75e00362c48f ]\n\nWhen run ipvs in two different network namespace at the same host, and one\nipvs transport network traffic to the other network namespace ipvs.\n'ipvs_property' flag will make the second ipvs take no effect. So we should\nclear 'ipvs_property' when SKB network namespace changed.\n\nFixes: 621e84d6f373 (\"dev: introduce skb_scrub_packet()\")\nSigned-off-by: Ye Yin <hustcat@gmail.com>\nSigned-off-by: Wei Zhou <chouryzhou@gmail.com>\nSigned-off-by: Julian Anastasov <ja@ssi.bg>\nSigned-off-by: Simon Horman <horms@verge.net.au>\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/NigelCunningham/tuxonice-kernel/commits/5b2af5fff8faeb56e654108a7d6465d52996d3a5"},{"sha":"39c3fff9ef51ba9f2748f37ad7d9cfef365e87fe","author":{"name":"Xin Long","email":"0c651f6709819e543c4ca1708bc1021b57131127@gmail.com"},"message":"sctp: do not peel off an assoc from one netns to another one\n\n\n[ Upstream commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74 ]\n\nNow when peeling off an association to the sock in another netns, all\ntransports in this assoc are not to be rehashed and keep use the old\nkey in hashtable.\n\nAs a transport uses sk->net as the hash key to insert into hashtable,\nit would miss removing these transports from hashtable due to the new\nnetns when closing the sock and all transports are being freeed, then\nlater an use-after-free issue could be caused when looking up an asoc\nand dereferencing those transports.\n\nThis is a very old issue since very beginning, ChunYu found it with\nsyzkaller fuzz testing with this series:\n\n  socket$inet6_sctp()\n  bind$inet6()\n  sendto$inet6()\n  unshare(0x40000000)\n  getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST()\n  getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF()\n\nThis patch is to block this call when peeling one assoc off from one\nnetns to another one, so that the netns of all transport would not\ngo out-sync with the key in hashtable.\n\nNote that this patch didn't fix it by rehashing transports, as it's\ndifficult to handle the situation when the tuple is already in use\nin the new netns. Besides, no one would like to peel off one assoc\nto another netns, considering ipaddrs, ifaces, etc. are usually\ndifferent.\n\nReported-by: ChunYu Wang <chunwang@redhat.com>\nSigned-off-by: Xin Long <lucien.xin@gmail.com>\nAcked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>\nAcked-by: Neil Horman <nhorman@tuxdriver.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/NigelCunningham/tuxonice-kernel/commits/39c3fff9ef51ba9f2748f37ad7d9cfef365e87fe"},{"sha":"e823c90371874557d4393060568cb7629436849f","author":{"name":"Huacai Chen","email":"9d0d2ac0186c70d2f0f61b72cb4fe11060be1605@lemote.com"},"message":"fealnx: Fix building error on MIPS\n\n\n[ Upstream commit cc54c1d32e6a4bb3f116721abf900513173e4d02 ]\n\nThis patch try to fix the building error on MIPS. The reason is MIPS\nhas already defined the LONG macro, which conflicts with the LONG enum\nin drivers/net/ethernet/fealnx.c.\n\nSigned-off-by: Huacai Chen <chenhc@lemote.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/NigelCunningham/tuxonice-kernel/commits/e823c90371874557d4393060568cb7629436849f"},{"sha":"5c44a51d67e915fd5d3f2251ce285ffb50e74277","author":{"name":"Jason A. Donenfeld","email":"99e030c4305a4e4b1828d232b8797d3ca296d80a@zx2c4.com"},"message":"af_netlink: ensure that NLMSG_DONE never fails in dumps\n\n\n[ Upstream commit 0642840b8bb008528dbdf929cec9f65ac4231ad0 ]\n\nThe way people generally use netlink_dump is that they fill in the skb\nas much as possible, breaking when nla_put returns an error. Then, they\nget called again and start filling out the next skb, and again, and so\nforth. The mechanism at work here is the ability for the iterative\ndumping function to detect when the skb is filled up and not fill it\npast the brim, waiting for a fresh skb for the rest of the data.\n\nHowever, if the attributes are small and nicely packed, it is possible\nthat a dump callback function successfully fills in attributes until the\nskb is of size 4080 (libmnl's default page-sized receive buffer size).\nThe dump function completes, satisfied, and then, if it happens to be\nthat this is actually the last skb, and no further ones are to be sent,\nthen netlink_dump will add on the NLMSG_DONE part:\n\n  nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE, sizeof(len), NLM_F_MULTI);\n\nIt is very important that netlink_dump does this, of course. However, in\nthis example, that call to nlmsg_put_answer will fail, because the\nprevious filling by the dump function did not leave it enough room. And\nhow could it possibly have done so? All of the nla_put variety of\nfunctions simply check to see if the skb has enough tailroom,\nindependent of the context it is in.\n\nIn order to keep the important assumptions of all netlink dump users, it\nis therefore important to give them an skb that has this end part of the\ntail already reserved, so that the call to nlmsg_put_answer does not\nfail. Otherwise, library authors are forced to find some bizarre sized\nreceive buffer that has a large modulo relative to the common sizes of\nmessages received, which is ugly and buggy.\n\nThis patch thus saves the NLMSG_DONE for an additional message, for the\ncase that things are dangerously close to the brim. This requires\nkeeping track of the errno from ->dump() across calls.\n\nSigned-off-by: Jason A. Donenfeld <Jason@zx2c4.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/NigelCunningham/tuxonice-kernel/commits/5c44a51d67e915fd5d3f2251ce285ffb50e74277"},{"sha":"28343f8b19c48a9c431930e75890d31dbf80a094","author":{"name":"Cong Wang","email":"3f5d79d28d6d48052800caba9df0b30e06fefe41@gmail.com"},"message":"vlan: fix a use-after-free in vlan_device_event()\n\n\n[ Upstream commit 052d41c01b3a2e3371d66de569717353af489d63 ]\n\nAfter refcnt reaches zero, vlan_vid_del() could free\ndev->vlan_info via RCU:\n\n\tRCU_INIT_POINTER(dev->vlan_info, NULL);\n\tcall_rcu(&vlan_info->rcu, vlan_info_rcu_free);\n\nHowever, the pointer 'grp' still points to that memory\nsince it is set before vlan_vid_del():\n\n        vlan_info = rtnl_dereference(dev->vlan_info);\n        if (!vlan_info)\n                goto out;\n        grp = &vlan_info->grp;\n\nDepends on when that RCU callback is scheduled, we could\ntrigger a use-after-free in vlan_group_for_each_dev()\nright following this vlan_vid_del().\n\nFix it by moving vlan_vid_del() before setting grp. This\nis also symmetric to the vlan_vid_add() we call in\nvlan_device_event().\n\nReported-by: Fengguang Wu <fengguang.wu@intel.com>\nFixes: efc73f4bbc23 (\"net: Fix memory leak - vlan_info struct\")\nCc: Alexander Duyck <alexander.duyck@gmail.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Girish Moodalbail <girish.moodalbail@oracle.com>\nSigned-off-by: Cong Wang <xiyou.wangcong@gmail.com>\nReviewed-by: Girish Moodalbail <girish.moodalbail@oracle.com>\nTested-by: Fengguang Wu <fengguang.wu@intel.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/NigelCunningham/tuxonice-kernel/commits/28343f8b19c48a9c431930e75890d31dbf80a094"},{"sha":"72df596704b8ce5448e92dea14851e767a9ae592","author":{"name":"Roberto Sassu","email":"3d2915b434588dcc0b22bc72c3dd7e31214daff1@huawei.com"},"message":"ima: do not update security.ima if appraisal status is not INTEGRITY_PASS\n\ncommit 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb upstream.\n\nCommit b65a9cfc2c38 (\"Untangling ima mess, part 2: deal with counters\")\nmoved the call of ima_file_check() from may_open() to do_filp_open() at a\npoint where the file descriptor is already opened.\n\nThis breaks the assumption made by IMA that file descriptors being closed\nbelong to files whose access was granted by ima_file_check(). The\nconsequence is that security.ima and security.evm are updated with good\nvalues, regardless of the current appraisal status.\n\nFor example, if a file does not have security.ima, IMA will create it after\nopening the file for writing, even if access is denied. Access to the file\nwill be allowed afterwards.\n\nAvoid this issue by checking the appraisal status before updating\nsecurity.ima.\n\nSigned-off-by: Roberto Sassu <roberto.sassu@huawei.com>\nSigned-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>\nSigned-off-by: James Morris <james.l.morris@oracle.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/72df596704b8ce5448e92dea14851e767a9ae592"},{"sha":"f72e2ba19765ec94ab1b704bce53c3d1ca13202e","author":{"name":"alex chen","email":"9df84bb6e8b4d3fd3333964a31a723cec322493a@huawei.com"},"message":"ocfs2: should wait dio before inode lock in ocfs2_setattr()\n\ncommit 28f5a8a7c033cbf3e32277f4cc9c6afd74f05300 upstream.\n\nwe should wait dio requests to finish before inode lock in\nocfs2_setattr(), otherwise the following deadlock will happen:\n\nprocess 1                  process 2                    process 3\ntruncate file 'A'          end_io of writing file 'A'   receiving the bast messages\nocfs2_setattr\n ocfs2_inode_lock_tracker\n  ocfs2_inode_lock_full\n inode_dio_wait\n  __inode_dio_wait\n  -->waiting for all dio\n  requests finish\n                                                        dlm_proxy_ast_handler\n                                                         dlm_do_local_bast\n                                                          ocfs2_blocking_ast\n                                                           ocfs2_generic_handle_bast\n                                                            set OCFS2_LOCK_BLOCKED flag\n                        dio_end_io\n                         dio_bio_end_aio\n                          dio_complete\n                           ocfs2_dio_end_io\n                            ocfs2_dio_end_io_write\n                             ocfs2_inode_lock\n                              __ocfs2_cluster_lock\n                               ocfs2_wait_for_mask\n                               -->waiting for OCFS2_LOCK_BLOCKED\n                               flag to be cleared, that is waiting\n                               for 'process 1' unlocking the inode lock\n                           inode_dio_end\n                           -->here dec the i_dio_count, but will never\n                           be called, so a deadlock happened.\n\nLink: http://lkml.kernel.org/r/59F81636.70508@huawei.com\nSigned-off-by: Alex Chen <alex.chen@huawei.com>\nReviewed-by: Jun Piao <piaojun@huawei.com>\nReviewed-by: Joseph Qi <jiangqi903@gmail.com>\nAcked-by: Changwei Ge <ge.changwei@h3c.com>\nCc: Mark Fasheh <mfasheh@versity.com>\nCc: Joel Becker <jlbec@evilplan.org>\nCc: Junxiao Bi <junxiao.bi@oracle.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/f72e2ba19765ec94ab1b704bce53c3d1ca13202e"},{"sha":"2722def0f5274f4ccd8a768736158bb297c5feee","author":{"name":"Corey Minyard","email":"071a590458d8bec3fad0c7ad3b06e399a06650d5@mvista.com"},"message":"ipmi: fix unsigned long underflow\n\ncommit 392a17b10ec4320d3c0e96e2a23ebaad1123b989 upstream.\n\nWhen I set the timeout to a specific value such as 500ms, the timeout\nevent will not happen in time due to the overflow in function\ncheck_msg_timeout:\n...\n\tent->timeout -= timeout_period;\n\tif (ent->timeout > 0)\n\t\treturn;\n...\n\nThe type of timeout_period is long, but ent->timeout is unsigned long.\nThis patch makes the type consistent.\n\nReported-by: Weilong Chen <chenweilong@huawei.com>\nSigned-off-by: Corey Minyard <cminyard@mvista.com>\nTested-by: Weilong Chen <chenweilong@huawei.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/2722def0f5274f4ccd8a768736158bb297c5feee"},{"sha":"d73b3941f58ef10d3dbd9de148c5f534ce6bb0fd","author":{"name":"Jan Harkes","email":"999563fb342dbe6832937dffef13808b5a23ef67@cs.cmu.edu"},"message":"coda: fix 'kernel memory exposure attempt' in fsync\n\ncommit d337b66a4c52c7b04eec661d86c2ef6e168965a2 upstream.\n\nWhen an application called fsync on a file in Coda a small request with\njust the file identifier was allocated, but the declared length was set\nto the size of union of all possible upcall requests.\n\nThis bug has been around for a very long time and is now caught by the\nextra checking in usercopy that was introduced in Linux-4.8.\n\nThe exposure happens when the Coda cache manager process reads the fsync\nupcall request at which point it is killed. As a result there is nobody\nservicing any further upcalls, trapping any processes that try to access\nthe mounted Coda filesystem.\n\nSigned-off-by: Jan Harkes <jaharkes@cs.cmu.edu>\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/d73b3941f58ef10d3dbd9de148c5f534ce6bb0fd"},{"sha":"7166ceea0a4eba3f8c86925ad60e6f0543db6234","author":{"name":"Greg Kroah-Hartman","email":"4931344b09d7a7d3573e8b1ebec918e229ead9bf@linuxfoundation.org"},"message":"Linux 3.18.84","distinct":false,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/7166ceea0a4eba3f8c86925ad60e6f0543db6234"},{"sha":"be58d0e4b707a303ed85ab76df198db494773988","author":{"name":"Nigel Cunningham","email":"5dad0977a17fd74e47ffcbd491a07de76d9951cd@nigelcunningham.com.au"},"message":"Merge branch 'upstream-3.18' into tuxonice-3.18","distinct":true,"url":"https://api.github.com/repos/NigelCunningham/tuxonice-kernel/commits/be58d0e4b707a303ed85ab76df198db494773988"}]}
{"actor":{"display_login":"NigelCunningham"}}