{"push_id":920832114,"size":5,"distinct_size":5,"ref":"refs/heads/cm-12.1","head":"75257f23eec4fa64e860fa71b704ef0040c6eedb","before":"024f0406189652e963588715182eff8c215edb68","commits":[{"sha":"0067d82e6cfaee0b884a2993675d8c60ce0b1533","author":{"email":"8c1011c9d06fc72acd93645d683782ab9543044d@google.com","name":"Michael Halcrow"},"message":"eCryptfs: Remove buggy and unnecessary write in file name decode routine\n\nDmitry Chernenkov used KASAN to discover that eCryptfs writes past the\nend of the allocated buffer during encrypted filename decoding. This\nfix corrects the issue by getting rid of the unnecessary 0 write when\nthe current bit offset is 2.\n\nChange-Id: Id8e04a580e550495c46cd36fec430a1ec4342940\nSigned-off-by: Michael Halcrow <mhalcrow@google.com>\nReported-by: Dmitry Chernenkov <dmitryc@google.com>\nSuggested-by: Kees Cook <keescook@chromium.org>\nCc: stable@vger.kernel.org # v2.6.29+: 51ca58d eCryptfs: Filename Encryption: Encoding and encryption functions\nSigned-off-by: Tyler Hicks <tyhicks@canonical.com>","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_samsung_tuna/commits/0067d82e6cfaee0b884a2993675d8c60ce0b1533"},{"sha":"d408024149843f95dbe5cae4eafca0eae02c7aa4","author":{"email":"cef439e78636cdab99cd2923826c5065a0743e5b@strlen.de","name":"Florian Westphal"},"message":"netfilter: conntrack: disable generic tracking for known protocols\n\nGiven following iptables ruleset:\n\n-P FORWARD DROP\n-A FORWARD -m sctp --dport 9 -j ACCEPT\n-A FORWARD -p tcp --dport 80 -j ACCEPT\n-A FORWARD -p tcp -m conntrack -m state ESTABLISHED,RELATED -j ACCEPT\n\nOne would assume that this allows SCTP on port 9 and TCP on port 80.\nUnfortunately, if the SCTP conntrack module is not loaded, this allows\n*all* SCTP communication, to pass though, i.e. -p sctp -j ACCEPT,\nwhich we think is a security issue.\n\nThis is because on the first SCTP packet on port 9, we create a dummy\n\"generic l4\" conntrack entry without any port information (since\nconntrack doesn't know how to extract this information).\n\nAll subsequent packets that are unknown will then be in established\nstate since they will fallback to proto_generic and will match the\n'generic' entry.\n\nOur originally proposed version [1] completely disabled generic protocol\ntracking, but Jozsef suggests to not track protocols for which a more\nsuitable helper is available, hence we now mitigate the issue for in\ntree known ct protocol helpers only, so that at least NAT and direction\ninformation will still be preserved for others.\n\n [1] http://www.spinics.net/lists/netfilter-devel/msg33430.html\n\nJoint work with Daniel Borkmann.\n\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Daniel Borkmann <dborkman@redhat.com>\nAcked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\n\nConflicts:\n\tnet/netfilter/nf_conntrack_proto_generic.c\n\nChange-Id: I5f7ddfa2d29672cc4533ad907bd7605bdc6c4bf7","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_samsung_tuna/commits/d408024149843f95dbe5cae4eafca0eae02c7aa4"},{"sha":"f961ec0465ca0ed66db09753c16c36a56d25a896","author":{"email":"9ff04a02a69f376b2b9aeec27187017cbf3cf5f9@redhat.com","name":"Daniel Borkmann"},"message":"netfilter: nf_conntrack_dccp: fix skb_header_pointer API usages\n\nSome occurences in the netfilter tree use skb_header_pointer() in\nthe following way ...\n\n  struct dccp_hdr _dh, *dh;\n  ...\n  skb_header_pointer(skb, dataoff, sizeof(_dh), &dh);\n\n... where dh itself is a pointer that is being passed as the copy\nbuffer. Instead, we need to use &_dh as the forth argument so that\nwe're copying the data into an actual buffer that sits on the stack.\n\nCurrently, we probably could overwrite memory on the stack (e.g.\nwith a possibly mal-formed DCCP packet), but unintentionally, as\nwe only want the buffer to be placed into _dh variable.\n\nChange-Id: I73508115362de789b6133f1f6d103210f6965d18\nFixes: 2bc780499aa3 (\"[NETFILTER]: nf_conntrack: add DCCP protocol support\")\nSigned-off-by: Daniel Borkmann <dborkman@redhat.com>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_samsung_tuna/commits/f961ec0465ca0ed66db09753c16c36a56d25a896"},{"sha":"79e791c800f14c312e62bdf06319adf6fe73411d","author":{"email":"eec72676ad9a62f2727dfed6d270d98c0d02adec@linux.intel.com","name":"Kirill A. Shutemov"},"message":"mm: Fix NULL pointer dereference in madvise(MADV_WILLNEED) support\n\nSasha Levin found a NULL pointer dereference that is due to a missing\npage table lock, which in turn is due to the pmd entry in question being\na transparent huge-table entry.\n\nThe code - introduced in commit 1998cc048901 (\"mm: make\nmadvise(MADV_WILLNEED) support swap file prefetch\") - correctly checks\nfor this situation using pmd_none_or_trans_huge_or_clear_bad(), but it\nturns out that that function doesn't work correctly.\n\npmd_none_or_trans_huge_or_clear_bad() expected that pmd_bad() would\ntrigger if the transparent hugepage bit was set, but it doesn't do that\nif pmd_numa() is also set. Note that the NUMA bit only gets set on real\nNUMA machines, so people trying to reproduce this on most normal\ndevelopment systems would never actually trigger this.\n\nFix it by removing the very subtle (and subtly incorrect) expectation,\nand instead just checking pmd_trans_huge() explicitly.\n\nReported-by: Sasha Levin <sasha.levin@oracle.com>\nAcked-by: Andrea Arcangeli <aarcange@redhat.com>\n[ Additionally remove the now stale test for pmd_trans_huge() inside the\n  pmd_bad() case - Linus ]\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nChange-Id: I3f3763f236ef102de735297cd175cf514d40d28f","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_samsung_tuna/commits/79e791c800f14c312e62bdf06319adf6fe73411d"},{"sha":"75257f23eec4fa64e860fa71b704ef0040c6eedb","author":{"email":"74c05afa918858348d6db8037d82fa8124870113@openvz.org","name":"Andrey Vagin"},"message":"netfilter: nf_conntrack: reserve two bytes for nf_ct_ext->len\n\n\"len\" contains sizeof(nf_ct_ext) and size of extensions. In a worst\ncase it can contain all extensions. Bellow you can find sizes for all\ntypes of extensions. Their sum is definitely bigger than 256.\n\nnf_ct_ext_types[0]->len = 24\nnf_ct_ext_types[1]->len = 32\nnf_ct_ext_types[2]->len = 24\nnf_ct_ext_types[3]->len = 32\nnf_ct_ext_types[4]->len = 152\nnf_ct_ext_types[5]->len = 2\nnf_ct_ext_types[6]->len = 16\nnf_ct_ext_types[7]->len = 8\n\nI have seen \"len\" up to 280 and my host has crashes w/o this patch.\n\nThe right way to fix this problem is reducing the size of the ecache\nextension (4) and Florian is going to do this, but these changes will\nbe quite large to be appropriate for a stable tree.\n\nChange-Id: If9efaf2b103cf304bbfa583e354cfad3faa77ac2\nFixes: 5b423f6a40a0 (netfilter: nf_conntrack: fix racy timer handling with reliable)\nCc: Pablo Neira Ayuso <pablo@netfilter.org>\nCc: Patrick McHardy <kaber@trash.net>\nCc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>\nCc: \"David S. Miller\" <davem@davemloft.net>\nSigned-off-by: Andrey Vagin <avagin@openvz.org>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>","distinct":true,"url":"https://api.github.com/repos/CyanogenMod/android_kernel_samsung_tuna/commits/75257f23eec4fa64e860fa71b704ef0040c6eedb"}]}