{"push_id":2646388735,"size":22,"distinct_size":0,"ref":"refs/heads/aosp-common/upstream-linux-3.18.y","head":"31767764c025981d818b09c004f6e357151a9ca3","before":"b0b357c20ca6171b8ac698351f5202402b7ad7d5","commits":[{"sha":"7ca1225a55481a62fe9739c2d88837570d1201f1","author":{"name":"Steven Rostedt (VMware)","email":"43232e92d70cc7aa53504ad0397085ee47bad87f@goodmis.org"},"message":"tracing: Fix crash when freeing instances with event triggers\n\ncommit 86b389ff22bd6ad8fd3cb98e41cd271886c6d023 upstream.\n\nIf a instance has an event trigger enabled when it is freed, it could cause\nan access of free memory. Here's the case that crashes:\n\n # cd /sys/kernel/tracing\n # mkdir instances/foo\n # echo snapshot > instances/foo/events/initcall/initcall_start/trigger\n # rmdir instances/foo\n\nWould produce:\n\n general protection fault: 0000 [#1] PREEMPT SMP PTI\n Modules linked in: tun bridge ...\n CPU: 5 PID: 6203 Comm: rmdir Tainted: G        W         4.17.0-rc4-test+ #933\n Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016\n RIP: 0010:clear_event_triggers+0x3b/0x70\n RSP: 0018:ffffc90003783de0 EFLAGS: 00010286\n RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b2b RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800c7130ba0\n RBP: ffffc90003783e00 R08: ffff8801131993f8 R09: 0000000100230016\n R10: ffffc90003783d80 R11: 0000000000000000 R12: ffff8800c7130ba0\n R13: ffff8800c7130bd8 R14: ffff8800cc093768 R15: 00000000ffffff9c\n FS:  00007f6f4aa86700(0000) GS:ffff88011eb40000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f6f4a5aed60 CR3: 00000000cd552001 CR4: 00000000001606e0\n Call Trace:\n  event_trace_del_tracer+0x2a/0xc5\n  instance_rmdir+0x15c/0x200\n  tracefs_syscall_rmdir+0x52/0x90\n  vfs_rmdir+0xdb/0x160\n  do_rmdir+0x16d/0x1c0\n  __x64_sys_rmdir+0x17/0x20\n  do_syscall_64+0x55/0x1a0\n  entry_SYSCALL_64_after_hwframe+0x49/0xbe\n\nThis was due to the call the clears out the triggers when an instance is\nbeing deleted not removing the trigger from the link list.\n\nCc: stable@vger.kernel.org\nFixes: 85f2b08268c01 (\"tracing: Add basic event trigger framework\")\nSigned-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/7ca1225a55481a62fe9739c2d88837570d1201f1"},{"sha":"b1ebe5e9a3744a00f9a3ffdc74b4d996c9deba28","author":{"name":"Sachin Grover","email":"af668b036f98d0122bb232b04400bb78b43edbba@codeaurora.org"},"message":"selinux: KASAN: slab-out-of-bounds in xattr_getsecurity\n\ncommit efe3de79e0b52ca281ef6691480c8c68c82a4657 upstream.\n\nCall trace:\n [<ffffff9203a8d7a8>] dump_backtrace+0x0/0x428\n [<ffffff9203a8dbf8>] show_stack+0x28/0x38\n [<ffffff920409bfb8>] dump_stack+0xd4/0x124\n [<ffffff9203d187e8>] print_address_description+0x68/0x258\n [<ffffff9203d18c00>] kasan_report.part.2+0x228/0x2f0\n [<ffffff9203d1927c>] kasan_report+0x5c/0x70\n [<ffffff9203d1776c>] check_memory_region+0x12c/0x1c0\n [<ffffff9203d17cdc>] memcpy+0x34/0x68\n [<ffffff9203d75348>] xattr_getsecurity+0xe0/0x160\n [<ffffff9203d75490>] vfs_getxattr+0xc8/0x120\n [<ffffff9203d75d68>] getxattr+0x100/0x2c8\n [<ffffff9203d76fb4>] SyS_fgetxattr+0x64/0xa0\n [<ffffff9203a83f70>] el0_svc_naked+0x24/0x28\n\nIf user get root access and calls security.selinux setxattr() with an\nembedded NUL on a file and then if some process performs a getxattr()\non that file with a length greater than the actual length of the string,\nit would result in a panic.\n\nTo fix this, add the actual length of the string to the security context\ninstead of the length passed by the userspace process.\n\nSigned-off-by: Sachin Grover <sgrover@codeaurora.org>\nCc: stable@vger.kernel.org\nSigned-off-by: Paul Moore <paul@paul-moore.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/b1ebe5e9a3744a00f9a3ffdc74b4d996c9deba28"},{"sha":"4ff12f87c37257ac68b5bfa676409c7b35529168","author":{"name":"Eric Biggers","email":"6f6115196800bbe9712b3f04c7e40093bb382fc5@google.com"},"message":"cfg80211: further limit wiphy names to 64 bytes\n\ncommit 814596495dd2b9d4aab92d8f89cf19060d25d2ea upstream.\n\nwiphy names were recently limited to 128 bytes by commit a7cfebcb7594\n(\"cfg80211: limit wiphy names to 128 bytes\").  As it turns out though,\nthis isn't sufficient because dev_vprintk_emit() needs the syslog header\nstring \"SUBSYSTEM=ieee80211\\0DEVICE=+ieee80211:$devname\" to fit into 128\nbytes.  This triggered the \"device/subsystem name too long\" WARN when\nthe device name was >= 90 bytes.  As before, this was reproduced by\nsyzbot by sending an HWSIM_CMD_NEW_RADIO command to the MAC80211_HWSIM\ngeneric netlink family.\n\nFix it by further limiting wiphy names to 64 bytes.\n\nReported-by: syzbot+e64565577af34b3768dc@syzkaller.appspotmail.com\nFixes: a7cfebcb7594 (\"cfg80211: limit wiphy names to 128 bytes\")\nSigned-off-by: Eric Biggers <ebiggers@google.com>\nSigned-off-by: Johannes Berg <johannes.berg@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/4ff12f87c37257ac68b5bfa676409c7b35529168"},{"sha":"c78305763b140a426d74c8e937a96ecc76cfd15e","author":{"name":"Eric Dumazet","email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com"},"message":"tcp: avoid integer overflows in tcp_rcv_space_adjust()\n\ncommit 607065bad9931e72207b0cac365d7d4abc06bd99 upstream.\n\nWhen using large tcp_rmem[2] values (I did tests with 500 MB),\nI noticed overflows while computing rcvwin.\n\nLets fix this before the following patch.\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>\n[Backport: sysctl_tcp_rmem is not Namespace-ify'd in older kernels]\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/commits/c78305763b140a426d74c8e937a96ecc76cfd15e"},{"sha":"38de6fffc79afb12c33f6ebe18fda85c26fc6965","author":{"name":"Maciej W. Rozycki","email":"78f3a3d9d6e4d907a7d12e475d0a751d6b7e256b@mips.com"},"message":"MIPS: ptrace: Fix PTRACE_PEEKUSR requests for 64-bit FGRs\n\ncommit c7e814628df65f424fe197dde73bfc67e4a244d7 upstream.\n\nUse 64-bit accesses for 64-bit floating-point general registers with\nPTRACE_PEEKUSR, removing the truncation of their upper halves in the\nFR=1 mode, caused by commit bbd426f542cb (\"MIPS: Simplify FP context\naccess\"), which inadvertently switched them to using 32-bit accesses.\n\nThe PTRACE_POKEUSR side is fine as it's never been broken and continues\nusing 64-bit accesses.\n\nFixes: bbd426f542cb (\"MIPS: Simplify FP context access\")\nSigned-off-by: Maciej W. Rozycki <macro@mips.com>\nCc: Ralf Baechle <ralf@linux-mips.org>\nCc: linux-mips@linux-mips.org\nCc: <stable@vger.kernel.org> # 3.15+\nPatchwork: https://patchwork.linux-mips.org/patch/19334/\nSigned-off-by: James Hogan <jhogan@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/38de6fffc79afb12c33f6ebe18fda85c26fc6965"},{"sha":"d4dd8e5bb708f65f919802b7a5a9102a9457c876","author":{"name":"Ondrej Zary","email":"ba324ca7b1c77fc20bb970d5aff6eea9377918a5@rainbow-software.org"},"message":"drm/i915: Disable LVDS on Radiant P845\n\ncommit b3fb22733ae61050f8d10a1d6a8af176c5c5db1a upstream.\n\nRadiant P845 does not have LVDS, only VGA.\n\nCc: stable@vger.kernel.org\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105468\nSigned-off-by: Ondrej Zary <linux@rainbow-software.org>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nLink: https://patchwork.freedesktop.org/patch/msgid/20180309222204.4771-1-linux@rainbow-software.org\n(cherry picked from commit 7f7105f99b75aca4f8c2a748ed6b82c7f8be3293)\nSigned-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/d4dd8e5bb708f65f919802b7a5a9102a9457c876"},{"sha":"43e631b78eb132f56d22e338ab48d925cc1450a6","author":{"name":"Al Viro","email":"de609eb4d5d70b1d38ec6642adbfc33a2781f63c@zeniv.linux.org.uk"},"message":"fix io_destroy()/aio_complete() race\n\ncommit 4faa99965e027cc057c5145ce45fa772caa04e8d upstream.\n\nIf io_destroy() gets to cancelling everything that can be cancelled and\ngets to kiocb_cancel() calling the function driver has left in ->ki_cancel,\nit becomes vulnerable to a race with IO completion.  At that point req\nis already taken off the list and aio_complete() does *NOT* spin until\nwe (in free_ioctx_users()) releases ->ctx_lock.  As the result, it proceeds\nto kiocb_free(), freing req just it gets passed to ->ki_cancel().\n\nFix is simple - remove from the list after the call of kiocb_cancel().  All\ninstances of ->ki_cancel() already have to cope with the being called with\niocb still on list - that's what happens in io_cancel(2).\n\nCc: stable@kernel.org\nFixes: 0460fef2a921 \"aio: use cancellation list lazily\"\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/Jackeagle/kernel_msm/commits/43e631b78eb132f56d22e338ab48d925cc1450a6"},{"sha":"6d64aecd1ac3bd4c843bd04f732d3c372cd73da7","author":{"name":"Hugh Dickins","email":"d3abdf3e2800e6cb849f11b81e6eb50b34d96431@google.com"},"message":"mm: fix the NULL mapping case in __isolate_lru_page()\n\ncommit 145e1a71e090575c74969e3daa8136d1e5b99fc8 upstream.\n\nGeorge Boole would have noticed a slight error in 4.16 commit\n69d763fc6d3a (\"mm: pin address_space before dereferencing it while\nisolating an LRU page\").  Fix it, to match both the comment above it,\nand the original behaviour.\n\nAlthough anonymous pages are not marked PageDirty at first, we have an\nold habit of calling SetPageDirty when a page is removed from swap\ncache: so there's a category of ex-swap pages that are easily\nmigratable, but were inadvertently excluded from compaction's async\nmigration in 4.16.\n\nLink: http://lkml.kernel.org/r/alpine.LSU.2.11.1805302014001.12558@eggly.anvils\nFixes: 69d763fc6d3a (\"mm: pin address_space before dereferencing it while isolating an LRU page\")\nSigned-off-by: Hugh Dickins <hughd@google.com>\nAcked-by: Minchan Kim <minchan@kernel.org>\nAcked-by: Mel Gorman <mgorman@techsingularity.net>\nReported-by:  Ivan Kalvachev <ikalvachev@gmail.com>\nCc: \"Huang, Ying\" <ying.huang@intel.com>\nCc: Jan Kara <jack@suse.cz>\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/Jackeagle/kernel_msm/commits/6d64aecd1ac3bd4c843bd04f732d3c372cd73da7"},{"sha":"bf3ff108832e28b7ca8df5a02e2a03ced29cd31e","author":{"name":"Linus Torvalds","email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org"},"message":"mmap: introduce sane default mmap limits\n\ncommit be83bbf806822b1b89e0a0f23cd87cddc409e429 upstream.\n\nThe internal VM \"mmap()\" interfaces are based on the mmap target doing\neverything using page indexes rather than byte offsets, because\ntraditionally (ie 32-bit) we had the situation that the byte offset\ndidn't fit in a register.  So while the mmap virtual address was limited\nby the word size of the architecture, the backing store was not.\n\nSo we're basically passing \"pgoff\" around as a page index, in order to\nbe able to describe backing store locations that are much bigger than\nthe word size (think files larger than 4GB etc).\n\nBut while this all makes a ton of sense conceptually, we've been dogged\nby various drivers that don't really understand this, and internally\nwork with byte offsets, and then try to work with the page index by\nturning it into a byte offset with \"pgoff << PAGE_SHIFT\".\n\nWhich obviously can overflow.\n\nAdding the size of the mapping to it to get the byte offset of the end\nof the backing store just exacerbates the problem, and if you then use\nthis overflow-prone value to check various limits of your device driver\nmmap capability, you're just setting yourself up for problems.\n\nThe correct thing for drivers to do is to do their limit math in page\nindices, the way the interface is designed.  Because the generic mmap\ncode _does_ test that the index doesn't overflow, since that's what the\nmmap code really cares about.\n\nHOWEVER.\n\nFinding and fixing various random drivers is a sisyphean task, so let's\njust see if we can just make the core mmap() code do the limiting for\nus.  Realistically, the only \"big\" backing stores we need to care about\nare regular files and block devices, both of which are known to do this\nproperly, and which have nice well-defined limits for how much data they\ncan access.\n\nSo let's special-case just those two known cases, and then limit other\nrandom mmap users to a backing store that still fits in \"unsigned long\".\nRealistically, that's not much of a limit at all on 64-bit, and on\n32-bit architectures the only worry might be the GPU drivers, which can\nhave big physical address spaces.\n\nTo make it possible for drivers like that to say that they are 64-bit\nclean, this patch does repurpose the \"FMODE_UNSIGNED_OFFSET\" bit in the\nfile flags to allow drivers to mark their file descriptors as safe in\nthe full 64-bit mmap address space.\n\n[ The timing for doing this is less than optimal, and this should really\n  go in a merge window. But realistically, this needs wide testing more\n  than it needs anything else, and being main-line is the only way to do\n  that.\n\n  So the earlier the better, even if it's outside the proper development\n  cycle        - Linus ]\n\nCc: Kees Cook <keescook@chromium.org>\nCc: Dan Carpenter <dan.carpenter@oracle.com>\nCc: Al Viro <viro@zeniv.linux.org.uk>\nCc: Willy Tarreau <w@1wt.eu>\nCc: Dave Airlie <airlied@redhat.com>\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/Jackeagle/kernel_msm/commits/bf3ff108832e28b7ca8df5a02e2a03ced29cd31e"},{"sha":"3bbdc2a45ad86e0f82e5d73c1f28d0e60901d3c5","author":{"name":"Linus Torvalds","email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org"},"message":"mmap: relax file size limit for regular files\n\ncommit 423913ad4ae5b3e8fb8983f70969fb522261ba26 upstream.\n\nCommit be83bbf80682 (\"mmap: introduce sane default mmap limits\") was\nintroduced to catch problems in various ad-hoc character device drivers\ndoing mmap and getting the size limits wrong.  In the process, it used\n\"known good\" limits for the normal cases of mapping regular files and\nblock device drivers.\n\nIt turns out that the \"s_maxbytes\" limit was less \"known good\" than I\nthought.  In particular, /proc doesn't set it, but exposes one regular\nfile to mmap: /proc/vmcore.  As a result, that file got limited to the\ndefault MAX_INT s_maxbytes value.\n\nThis went unnoticed for a while, because apparently the only thing that\nneeds it is the s390 kernel zfcpdump, but there might be other tools\nthat use this too.\n\nVasily suggested just changing s_maxbytes for all of /proc, which isn't\nwrong, but makes me nervous at this stage.  So instead, just make the\nnew mmap limit always be MAX_LFS_FILESIZE for regular files, which won't\naffect anything else.  It wasn't the regular file case I was worried\nabout.\n\nI'd really prefer for maxsize to have been per-inode, but that is not\nhow things are today.\n\nFixes: be83bbf80682 (\"mmap: introduce sane default mmap limits\")\nReported-by: Vasily Gorbik <gor@linux.ibm.com>\nCc: Al Viro <viro@zeniv.linux.org.uk>\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/Jackeagle/kernel_msm/commits/3bbdc2a45ad86e0f82e5d73c1f28d0e60901d3c5"},{"sha":"1a16822592fe2bdb3a14a8c8f0029ef07a40f053","author":{"name":"Dave Airlie","email":"f2295d84e358395675bc8031be58672073ae065e@redhat.com"},"message":"drm: set FMODE_UNSIGNED_OFFSET for drm files\n\ncommit 76ef6b28ea4f81c3d511866a9b31392caa833126 upstream.\n\nSince we have the ttm and gem vma managers using a subset\nof the file address space for objects, and these start at\n0x100000000 they will overflow the new mmap checks.\n\nI've checked all the mmap routines I could see for any\nbad behaviour but overall most people use GEM/TTM VMA\nmanagers even the legacy drivers have a hashtable.\n\nReported-and-Tested-by: Arthur Marsh (amarsh04 on #radeon)\nFixes: be83bbf8068 (mmap: introduce sane default mmap limits)\nSigned-off-by: Dave Airlie <airlied@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/1a16822592fe2bdb3a14a8c8f0029ef07a40f053"},{"sha":"fde5217c8c38469fddb285486b1f93d8994587c5","author":{"name":"Julia Lawall","email":"3d4a3affaf9163789962e9770780389962bda29d@lip6.fr"},"message":"bnx2x: use the right constant\n\n[ Upstream commit dd612f18a49b63af8b3a5f572d999bdb197385bc ]\n\nNearby code that also tests port suggests that the P0 constant should be\nused when port is zero.\n\nThe semantic match that finds this problem is as follows:\n(http://coccinelle.lip6.fr/)\n\n// <smpl>\n@@\nexpression e,e1;\n@@\n\n* e ? e1 : e1\n// </smpl>\n\nFixes: 6c3218c6f7e5 (\"bnx2x: Adjust ETS to 578xx\")\nSigned-off-by: Julia Lawall <Julia.Lawall@lip6.fr>\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/commits/fde5217c8c38469fddb285486b1f93d8994587c5"},{"sha":"19775c9291dd6a33a00cd0b353b5cbf0a6027450","author":{"name":"Alexey Kodanev","email":"230f550b09df4d04cb9a8036b198a530acf758d3@oracle.com"},"message":"dccp: don't free ccid2_hc_tx_sock struct in dccp_disconnect()\n\n[ Upstream commit 2677d20677314101293e6da0094ede7b5526d2b1 ]\n\nSyzbot reported the use-after-free in timer_is_static_object() [1].\n\nThis can happen because the structure for the rto timer (ccid2_hc_tx_sock)\nis removed in dccp_disconnect(), and ccid2_hc_tx_rto_expire() can be\ncalled after that.\n\nThe report [1] is similar to the one in commit 120e9dabaf55 (\"dccp:\ndefer ccid_hc_tx_delete() at dismantle time\"). And the fix is the same,\ndelay freeing ccid2_hc_tx_sock structure, so that it is freed in\ndccp_sk_destruct().\n\n[1]\n\n==================================================================\nBUG: KASAN: use-after-free in timer_is_static_object+0x80/0x90\nkernel/time/timer.c:607\nRead of size 8 at addr ffff8801bebb5118 by task syz-executor2/25299\n\nCPU: 1 PID: 25299 Comm: syz-executor2 Not tainted 4.17.0-rc5+ #54\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS\nGoogle 01/01/2011\nCall Trace:\n  <IRQ>\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  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433\n  timer_is_static_object+0x80/0x90 kernel/time/timer.c:607\n  debug_object_activate+0x2d9/0x670 lib/debugobjects.c:508\n  debug_timer_activate kernel/time/timer.c:709 [inline]\n  debug_activate kernel/time/timer.c:764 [inline]\n  __mod_timer kernel/time/timer.c:1041 [inline]\n  mod_timer+0x4d3/0x13b0 kernel/time/timer.c:1102\n  sk_reset_timer+0x22/0x60 net/core/sock.c:2742\n  ccid2_hc_tx_rto_expire+0x587/0x680 net/dccp/ccids/ccid2.c:147\n  call_timer_fn+0x230/0x940 kernel/time/timer.c:1326\n  expire_timers kernel/time/timer.c:1363 [inline]\n  __run_timers+0x79e/0xc50 kernel/time/timer.c:1666\n  run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692\n  __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285\n  invoke_softirq kernel/softirq.c:365 [inline]\n  irq_exit+0x1d1/0x200 kernel/softirq.c:405\n  exiting_irq arch/x86/include/asm/apic.h:525 [inline]\n  smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052\n  apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863\n  </IRQ>\n...\nAllocated by task 25374:\n  save_stack+0x43/0xd0 mm/kasan/kasan.c:448\n  set_track mm/kasan/kasan.c:460 [inline]\n  kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553\n  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490\n  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554\n  ccid_new+0x25b/0x3e0 net/dccp/ccid.c:151\n  dccp_hdlr_ccid+0x27/0x150 net/dccp/feat.c:44\n  __dccp_feat_activate+0x184/0x270 net/dccp/feat.c:344\n  dccp_feat_activate_values+0x3a7/0x819 net/dccp/feat.c:1538\n  dccp_create_openreq_child+0x472/0x610 net/dccp/minisocks.c:128\n  dccp_v4_request_recv_sock+0x12c/0xca0 net/dccp/ipv4.c:408\n  dccp_v6_request_recv_sock+0x125d/0x1f10 net/dccp/ipv6.c:415\n  dccp_check_req+0x455/0x6a0 net/dccp/minisocks.c:197\n  dccp_v4_rcv+0x7b8/0x1f3f net/dccp/ipv4.c:841\n  ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215\n  NF_HOOK include/linux/netfilter.h:288 [inline]\n  ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256\n  dst_input include/net/dst.h:450 [inline]\n  ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396\n  NF_HOOK include/linux/netfilter.h:288 [inline]\n  ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492\n  __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592\n  __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657\n  process_backlog+0x219/0x760 net/core/dev.c:5337\n  napi_poll net/core/dev.c:5735 [inline]\n  net_rx_action+0x7b7/0x1930 net/core/dev.c:5801\n  __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285\n\nFreed by task 25374:\n  save_stack+0x43/0xd0 mm/kasan/kasan.c:448\n  set_track mm/kasan/kasan.c:460 [inline]\n  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521\n  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528\n  __cache_free mm/slab.c:3498 [inline]\n  kmem_cache_free+0x86/0x2d0 mm/slab.c:3756\n  ccid_hc_tx_delete+0xc3/0x100 net/dccp/ccid.c:190\n  dccp_disconnect+0x130/0xc66 net/dccp/proto.c:286\n  dccp_close+0x3bc/0xe60 net/dccp/proto.c:1045\n  inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427\n  inet6_release+0x50/0x70 net/ipv6/af_inet6.c:460\n  sock_release+0x96/0x1b0 net/socket.c:594\n  sock_close+0x16/0x20 net/socket.c:1149\n  __fput+0x34d/0x890 fs/file_table.c:209\n  ____fput+0x15/0x20 fs/file_table.c:243\n  task_work_run+0x1e4/0x290 kernel/task_work.c:113\n  tracehook_notify_resume include/linux/tracehook.h:191 [inline]\n  exit_to_usermode_loop+0x2bd/0x310 arch/x86/entry/common.c:166\n  prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]\n  syscall_return_slowpath arch/x86/entry/common.c:265 [inline]\n  do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290\n  entry_SYSCALL_64_after_hwframe+0x49/0xbe\n\nThe buggy address belongs to the object at ffff8801bebb4cc0\n  which belongs to the cache ccid2_hc_tx_sock of size 1240\nThe buggy address is located 1112 bytes inside of\n  1240-byte region [ffff8801bebb4cc0, ffff8801bebb5198)\nThe buggy address belongs to the page:\npage:ffffea0006faed00 count:1 mapcount:0 mapping:ffff8801bebb41c0\nindex:0xffff8801bebb5240 compound_mapcount: 0\nflags: 0x2fffc0000008100(slab|head)\nraw: 02fffc0000008100 ffff8801bebb41c0 ffff8801bebb5240 0000000100000003\nraw: ffff8801cdba3138 ffffea0007634120 ffff8801cdbaab40 0000000000000000\npage dumped because: kasan: bad access detected\n...\n==================================================================\n\nReported-by: syzbot+5d47e9ec91a6f15dbd6f@syzkaller.appspotmail.com\nSigned-off-by: Alexey Kodanev <alexey.kodanev@oracle.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/commits/19775c9291dd6a33a00cd0b353b5cbf0a6027450"},{"sha":"843e5ed69e0dc373729699639a0d125e6e91ea0e","author":{"name":"Govindarajulu Varadarajan","email":"23201a0b7c282ba7648eee48dc47345ae8ab5331@cisco.com"},"message":"enic: set DMA mask to 47 bit\n\n[ Upstream commit 322eaa06d55ebc1402a4a8d140945cff536638b4 ]\n\nIn commit 624dbf55a359b (\"driver/net: enic: Try DMA 64 first, then\nfailover to DMA\") DMA mask was changed from 40 bits to 64 bits.\nHardware actually supports only 47 bits.\n\nFixes: 624dbf55a359b (\"driver/net: enic: Try DMA 64 first, then failover to DMA\")\nSigned-off-by: Govindarajulu Varadarajan <gvaradar@cisco.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/commits/843e5ed69e0dc373729699639a0d125e6e91ea0e"},{"sha":"8c79f7300031e24f849bd7f54515ae67bd05b3e1","author":{"name":"Sabrina Dubroca","email":"4452d71687b6bc2c9389c3349fdc17fbd73b833b@queasysnail.net"},"message":"ip6mr: only set ip6mr_table from setsockopt when ip6mr_new_table succeeds\n\n[ Upstream commit 848235edb5c93ed086700584c8ff64f6d7fc778d ]\n\nCurrently, raw6_sk(sk)->ip6mr_table is set unconditionally during\nip6_mroute_setsockopt(MRT6_TABLE). A subsequent attempt at the same\nsetsockopt will fail with -ENOENT, since we haven't actually created\nthat table.\n\nA similar fix for ipv4 was included in commit 5e1859fbcc3c (\"ipv4: ipmr:\nvarious fixes and cleanups\").\n\nFixes: d1db275dd3f6 (\"ipv6: ip6mr: support multiple tables\")\nSigned-off-by: Sabrina Dubroca <sd@queasysnail.net>\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/commits/8c79f7300031e24f849bd7f54515ae67bd05b3e1"},{"sha":"c9912b7d9eed3a381d265efbaf3ebd3b64fe4da9","author":{"name":"Wenwen Wang","email":"bafc5a1ee344249d3957e4d34f33647904b567dc@umn.edu"},"message":"isdn: eicon: fix a missing-check bug\n\n[ Upstream commit 6009d1fe6ba3bb2dab55921da60465329cc1cd89 ]\n\nIn divasmain.c, the function divas_write() firstly invokes the function\ndiva_xdi_open_adapter() to open the adapter that matches with the adapter\nnumber provided by the user, and then invokes the function diva_xdi_write()\nto perform the write operation using the matched adapter. The two functions\ndiva_xdi_open_adapter() and diva_xdi_write() are located in diva.c.\n\nIn diva_xdi_open_adapter(), the user command is copied to the object 'msg'\nfrom the userspace pointer 'src' through the function pointer 'cp_fn',\nwhich eventually calls copy_from_user() to do the copy. Then, the adapter\nnumber 'msg.adapter' is used to find out a matched adapter from the\n'adapter_queue'. A matched adapter will be returned if it is found.\nOtherwise, NULL is returned to indicate the failure of the verification on\nthe adapter number.\n\nAs mentioned above, if a matched adapter is returned, the function\ndiva_xdi_write() is invoked to perform the write operation. In this\nfunction, the user command is copied once again from the userspace pointer\n'src', which is the same as the 'src' pointer in diva_xdi_open_adapter() as\nboth of them are from the 'buf' pointer in divas_write(). Similarly, the\ncopy is achieved through the function pointer 'cp_fn', which finally calls\ncopy_from_user(). After the successful copy, the corresponding command\nprocessing handler of the matched adapter is invoked to perform the write\noperation.\n\nIt is obvious that there are two copies here from userspace, one is in\ndiva_xdi_open_adapter(), and one is in diva_xdi_write(). Plus, both of\nthese two copies share the same source userspace pointer, i.e., the 'buf'\npointer in divas_write(). Given that a malicious userspace process can race\nto change the content pointed by the 'buf' pointer, this can pose potential\nsecurity issues. For example, in the first copy, the user provides a valid\nadapter number to pass the verification process and a valid adapter can be\nfound. Then the user can modify the adapter number to an invalid number.\nThis way, the user can bypass the verification process of the adapter\nnumber and inject inconsistent data.\n\nThis patch reuses the data copied in\ndiva_xdi_open_adapter() and passes it to diva_xdi_write(). This way, the\nabove issues can be avoided.\n\nSigned-off-by: Wenwen Wang <wang6495@umn.edu>\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/commits/c9912b7d9eed3a381d265efbaf3ebd3b64fe4da9"},{"sha":"6c2d8d7adb6370496654e36ce05e84202fb27d70","author":{"name":"Eric Dumazet","email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com"},"message":"net/packet: refine check for priv area size\n\n[ Upstream commit eb73190f4fbeedf762394e92d6a4ec9ace684c88 ]\n\nsyzbot was able to trick af_packet again [1]\n\nVarious commits tried to address the problem in the past,\nbut failed to take into account V3 header size.\n\n[1]\n\ntpacket_rcv: packet too big, clamped from 72 to 4294967224. macoff=96\nBUG: KASAN: use-after-free in prb_run_all_ft_ops net/packet/af_packet.c:1016 [inline]\nBUG: KASAN: use-after-free in prb_fill_curr_block.isra.59+0x4e5/0x5c0 net/packet/af_packet.c:1039\nWrite of size 2 at addr ffff8801cb62000e by task kworker/1:2/2106\n\nCPU: 1 PID: 2106 Comm: kworker/1:2 Not tainted 4.17.0-rc7+ #77\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: ipv6_addrconf addrconf_dad_work\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 __asan_report_store2_noabort+0x17/0x20 mm/kasan/report.c:436\n prb_run_all_ft_ops net/packet/af_packet.c:1016 [inline]\n prb_fill_curr_block.isra.59+0x4e5/0x5c0 net/packet/af_packet.c:1039\n __packet_lookup_frame_in_block net/packet/af_packet.c:1094 [inline]\n packet_current_rx_frame net/packet/af_packet.c:1117 [inline]\n tpacket_rcv+0x1866/0x3340 net/packet/af_packet.c:2282\n dev_queue_xmit_nit+0x891/0xb90 net/core/dev.c:2018\n xmit_one net/core/dev.c:3049 [inline]\n dev_hard_start_xmit+0x16b/0xc10 net/core/dev.c:3069\n __dev_queue_xmit+0x2724/0x34c0 net/core/dev.c:3584\n dev_queue_xmit+0x17/0x20 net/core/dev.c:3617\n neigh_resolve_output+0x679/0xad0 net/core/neighbour.c:1358\n neigh_output include/net/neighbour.h:482 [inline]\n ip6_finish_output2+0xc9c/0x2810 net/ipv6/ip6_output.c:120\n ip6_finish_output+0x5fe/0xbc0 net/ipv6/ip6_output.c:154\n NF_HOOK_COND include/linux/netfilter.h:277 [inline]\n ip6_output+0x227/0x9b0 net/ipv6/ip6_output.c:171\n dst_output include/net/dst.h:444 [inline]\n NF_HOOK include/linux/netfilter.h:288 [inline]\n ndisc_send_skb+0x100d/0x1570 net/ipv6/ndisc.c:491\n ndisc_send_ns+0x3c1/0x8d0 net/ipv6/ndisc.c:633\n addrconf_dad_work+0xbef/0x1340 net/ipv6/addrconf.c:4033\n process_one_work+0xc1e/0x1b50 kernel/workqueue.c:2145\n worker_thread+0x1cc/0x1440 kernel/workqueue.c:2279\n kthread+0x345/0x410 kernel/kthread.c:240\n ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412\n\nThe buggy address belongs to the page:\npage:ffffea00072d8800 count:0 mapcount:-127 mapping:0000000000000000 index:0xffff8801cb620e80\nflags: 0x2fffc0000000000()\nraw: 02fffc0000000000 0000000000000000 ffff8801cb620e80 00000000ffffff80\nraw: ffffea00072e3820 ffffea0007132d20 0000000000000002 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff8801cb61ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff8801cb61ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n>ffff8801cb620000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n                      ^\n ffff8801cb620080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n ffff8801cb620100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n\nFixes: 2b6867c2ce76 (\"net/packet: fix overflow in check for priv area size\")\nFixes: dc808110bb62 (\"packet: handle too big packets for PACKET_V3\")\nFixes: f6fb8f100b80 (\"af-packet: TPACKET_V3 flexible buffer implementation.\")\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nReported-by: syzbot <syzkaller@googlegroups.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/commits/6c2d8d7adb6370496654e36ce05e84202fb27d70"},{"sha":"7f56a980db98be8b71c2d46d03d6d407f08aad91","author":{"name":"Daniele Palmas","email":"c212f6c5eed30fada5e618fe1393e6ce361c7c24@gmail.com"},"message":"net: usb: cdc_mbim: add flag FLAG_SEND_ZLP\n\n[ Upstream commit 9f7c728332e8966084242fcd951aa46583bc308c ]\n\nTesting Telit LM940 with ICMP packets > 14552 bytes revealed that\nthe modem needs FLAG_SEND_ZLP to properly work, otherwise the cdc\nmbim data interface won't be anymore responsive.\n\nSigned-off-by: Daniele Palmas <dnlplm@gmail.com>\nAcked-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":false,"url":"https://api.github.com/repos/Jackeagle/kernel_msm/commits/7f56a980db98be8b71c2d46d03d6d407f08aad91"},{"sha":"dcd71a2323967ecdf48e52f40a6efe0bd384a2fb","author":{"name":"Jack Morgenstein","email":"067deeb0d1a5180729b0e79bbb5b609fc5bbbab4@dev.mellanox.co.il"},"message":"net/mlx4: Fix irq-unsafe spinlock usage\n\n[ Upstream commit d546b67cda015fb92bfee93d5dc0ceadb91deaee ]\n\nspin_lock/unlock was used instead of spin_un/lock_irq\nin a procedure used in process space, on a spinlock\nwhich can be grabbed in an interrupt.\n\nThis caused the stack trace below to be displayed (on kernel\n4.17.0-rc1 compiled with Lock Debugging enabled):\n\n[  154.661474] WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected\n[  154.668909] 4.17.0-rc1-rdma_rc_mlx+ #3 Tainted: G          I\n[  154.675856] -----------------------------------------------------\n[  154.682706] modprobe/10159 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:\n[  154.690254] 00000000f3b0e495 (&(&qp_table->lock)->rlock){+.+.}, at: mlx4_qp_remove+0x20/0x50 [mlx4_core]\n[  154.700927]\nand this task is already holding:\n[  154.707461] 0000000094373b5d (&(&cq->lock)->rlock/1){....}, at: destroy_qp_common+0x111/0x560 [mlx4_ib]\n[  154.718028] which would create a new lock dependency:\n[  154.723705]  (&(&cq->lock)->rlock/1){....} -> (&(&qp_table->lock)->rlock){+.+.}\n[  154.731922]\nbut this new dependency connects a SOFTIRQ-irq-safe lock:\n[  154.740798]  (&(&cq->lock)->rlock){..-.}\n[  154.740800]\n... which became SOFTIRQ-irq-safe at:\n[  154.752163]   _raw_spin_lock_irqsave+0x3e/0x50\n[  154.757163]   mlx4_ib_poll_cq+0x36/0x900 [mlx4_ib]\n[  154.762554]   ipoib_tx_poll+0x4a/0xf0 [ib_ipoib]\n...\nto a SOFTIRQ-irq-unsafe lock:\n[  154.815603]  (&(&qp_table->lock)->rlock){+.+.}\n[  154.815604]\n... which became SOFTIRQ-irq-unsafe at:\n[  154.827718] ...\n[  154.827720]   _raw_spin_lock+0x35/0x50\n[  154.833912]   mlx4_qp_lookup+0x1e/0x50 [mlx4_core]\n[  154.839302]   mlx4_flow_attach+0x3f/0x3d0 [mlx4_core]\n\nSince mlx4_qp_lookup() is called only in process space, we can\nsimply replace the spin_un/lock calls with spin_un/lock_irq calls.\n\nFixes: 6dc06c08bef1 (\"net/mlx4: Fix the check in attaching steering rules\")\nSigned-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>\nSigned-off-by: Tariq Toukan <tariqt@mellanox.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/commits/dcd71a2323967ecdf48e52f40a6efe0bd384a2fb"},{"sha":"e384b14546b9fbd02954471bc75280e3b4f58412","author":{"name":"Dan Carpenter","email":"ff341aa343d564f9e53e9dcb6996be8c04859a66@oracle.com"},"message":"team: use netdev_features_t instead of u32\n\n[ Upstream commit 25ea66544bfd1d9df1b7e1502f8717e85fa1e6e6 ]\n\nThis code was introduced in 2011 around the same time that we made\nnetdev_features_t a u64 type.  These days a u32 is not big enough to\nhold all the potential features.\n\nSigned-off-by: Dan Carpenter <dan.carpenter@oracle.com>\nAcked-by: Jiri Pirko <jiri@mellanox.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/commits/e384b14546b9fbd02954471bc75280e3b4f58412"}]}
{"actor":{"display_login":"Jackeagle"}}