{"push_id":2918870794,"size":71,"distinct_size":40,"ref":"refs/heads/slimd+","head":"38b36184948ade33e023a043ff088a8aa0646b1c","before":"fd9cf3b2ffcd5b002c364e824069101155286d2c","commits":[{"sha":"b425c9b04e145534e289d817c31ecb66a45c52db","author":{"name":"Nathan Chancellor","email":"f65d3f2dc139dcfe7b6f0b0a466af3bc5fed8fa7@gmail.com"},"message":"Merge 4.4.158 into kernel.lnx.4.4.r27-rel\n\nChanges in 4.4.158: (69 commits)\n        iommu/arm-smmu-v3: sync the OVACKFLG to PRIQ consumer register\n        ALSA: msnd: Fix the default sample sizes\n        ALSA: usb-audio: Fix multiple definitions in AU0828_DEVICE() macro\n        xfrm: fix 'passing zero to ERR_PTR()' warning\n        gfs2: Special-case rindex for gfs2_grow\n        clk: imx6ul: fix missing of_node_put()\n        kbuild: add .DELETE_ON_ERROR special target\n        dmaengine: pl330: fix irq race with terminate_all\n        MIPS: ath79: fix system restart\n        media: videobuf2-core: check for q->error in vb2_core_qbuf()\n        mtd/maps: fix solutionengine.c printk format warnings\n        fbdev: omapfb: off by one in omapfb_register_client()\n        video: goldfishfb: fix memory leak on driver remove\n        fbdev/via: fix defined but not used warning\n        perf powerpc: Fix callchain ip filtering when return address is in a register\n        fbdev: Distinguish between interlaced and progressive modes\n        ARM: exynos: Clear global variable on init error path\n        perf powerpc: Fix callchain ip filtering\n        powerpc/powernv: opal_put_chars partial write fix\n        MIPS: jz4740: Bump zload address\n        mac80211: restrict delayed tailroom needed decrement\n        xen-netfront: fix queue name setting\n        arm64: dts: qcom: db410c: Fix Bluetooth LED trigger\n        s390/qeth: fix race in used-buffer accounting\n        s390/qeth: reset layer2 attribute on layer switch\n        platform/x86: toshiba_acpi: Fix defined but not used build warnings\n        crypto: sharah - Unregister correct algorithms for SAHARA 3\n        xen-netfront: fix warn message as irq device name has '/'\n        RDMA/cma: Protect cma dev list with lock\n        pstore: Fix incorrect persistent ram buffer mapping\n        xen/netfront: fix waiting for xenbus state change\n        IB/ipoib: Avoid a race condition between start_xmit and cm_rep_handler\n        Tools: hv: Fix a bug in the key delete code\n        misc: hmc6352: fix potential Spectre v1\n        usb: Don't die twice if PCI xhci host is not responding in resume\n        USB: Add quirk to support DJI CineSSD\n        usb: Avoid use-after-free by flushing endpoints early in usb_set_interface()\n        usb: host: u132-hcd: Fix a sleep-in-atomic-context bug in u132_get_frame()\n        USB: add quirk for WORLDE Controller KS49 or Prodipe MIDI 49C USB controller\n        USB: net2280: Fix erroneous synchronization change\n        USB: serial: io_ti: fix array underflow in completion handler\n        usb: misc: uss720: Fix two sleep-in-atomic-context bugs\n        USB: yurex: Fix buffer over-read in yurex_write()\n        usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()\n        cifs: prevent integer overflow in nxt_dir_entry()\n        CIFS: fix wrapping bugs in num_entries()\n        binfmt_elf: Respect error return from `regset->active'\n        audit: fix use-after-free in audit_add_watch\n        mtdchar: fix overflows in adjustment of `count`\n        MIPS: loongson64: cs5536: Fix PCI_OHCI_INT_REG reads\n        ARM: hisi: handle of_iomap and fix missing of_node_put\n        ARM: hisi: fix error handling and missing of_node_put\n        ARM: hisi: check of_iomap and fix missing of_node_put\n        drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping\n        parport: sunbpp: fix error return code\n        coresight: Handle errors in finding input/output ports\n        coresight: tpiu: Fix disabling timeouts\n        gpiolib: Mark gpio_suffixes array with __maybe_unused\n        drm/amdkfd: Fix error codes in kfd_get_process\n        rtc: bq4802: add error handling for devm_ioremap\n        ALSA: pcm: Fix snd_interval_refine first/last with open min/max\n        selftest: timers: Tweak raw_skew to SKIP when ADJ_OFFSET/other clock adjustments are in progress\n        drm/panel: type promotion bug in s6e8aa0_read_mtp_id()\n        pinctrl: qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant\n        USB: serial: ti_usb_3410_5052: fix array underflow in completion handler\n        mei: bus: type promotion bug in mei_nfc_if_version()\n        drivers: net: cpsw: fix segfault in case of bad phy-handle\n        MIPS: VDSO: Match data page cache colouring when D$ aliases\n        Linux 4.4.158\n\nSigned-off-by: Nathan Chancellor <natechancellor@gmail.com>","distinct":false,"url":"https://api.github.com/repos/travarilo/kernel_asus_sdm660/commits/b425c9b04e145534e289d817c31ecb66a45c52db"},{"sha":"ec56e98f80666644fa43f17092fdcd861348eea1","author":{"name":"Suren Baghdasaryan","email":"6c9ae9a1a5f38d4caff88933ca76ff7fe5ebb0f0@google.com"},"message":"NFC: Fix possible memory corruption when handling SHDLC I-Frame commands\n\ncommit 674d9de02aa7d521ebdf66c3958758bdd9c64e11 upstream.\n\nWhen handling SHDLC I-Frame commands \"pipe\" field used for indexing\ninto an array should be checked before usage. If left unchecked it\nmight access memory outside of the array of size NFC_HCI_MAX_PIPES(127).\n\nMalformed NFC HCI frames could be injected by a malicious NFC device\ncommunicating with the device being attacked (remote attack vector),\nor even by an attacker with physical access to the I2C bus such that\nthey could influence the data transfers on that bus (local attack vector).\nskb->data is controlled by the attacker and has only been sanitized in\nthe most trivial ways (CRC check), therefore we can consider the\ncreate_info struct and all of its members to tainted. 'create_info->pipe'\nwith max value of 255 (uint8) is used to take an offset of the\nhdev->pipes array of 127 elements which can lead to OOB write.\n\nCc: Samuel Ortiz <sameo@linux.intel.com>\nCc: Allen Pais <allen.pais@oracle.com>\nCc: \"David S. Miller\" <davem@davemloft.net>\nSuggested-by: Kevin Deus <kdeus@google.com>\nSigned-off-by: Suren Baghdasaryan <surenb@google.com>\nAcked-by: Kees Cook <keescook@chromium.org>\nCc: stable <stable@vger.kernel.org>\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/travarilo/kernel_asus_sdm660/commits/ec56e98f80666644fa43f17092fdcd861348eea1"},{"sha":"b413ee0476ea3426846a8139a71514bb627f7596","author":{"name":"Suren Baghdasaryan","email":"6c9ae9a1a5f38d4caff88933ca76ff7fe5ebb0f0@google.com"},"message":"NFC: Fix the number of pipes\n\ncommit e285d5bfb7e9785d289663baef252dd315e171f8 upstream.\n\nAccording to ETSI TS 102 622 specification chapter 4.4 pipe identifier\nis 7 bits long which allows for 128 unique pipe IDs. Because\nNFC_HCI_MAX_PIPES is used as the number of pipes supported and not\nas the max pipe ID, its value should be 128 instead of 127.\n\nnfc_hci_recv_from_llc extracts pipe ID from packet header using\nNFC_HCI_FRAGMENT(0x7F) mask which allows for pipe ID value of 127.\nSame happens when NCI_HCP_MSG_GET_PIPE() is being used. With\npipes array having only 127 elements and pipe ID of 127 the OOB memory\naccess will result.\n\nCc: Samuel Ortiz <sameo@linux.intel.com>\nCc: Allen Pais <allen.pais@oracle.com>\nCc: \"David S. Miller\" <davem@davemloft.net>\nSuggested-by: Dan Carpenter <dan.carpenter@oracle.com>\nSigned-off-by: Suren Baghdasaryan <surenb@google.com>\nReviewed-by: Kees Cook <keescook@chromium.org>\nCc: stable <stable@vger.kernel.org>\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/travarilo/kernel_asus_sdm660/commits/b413ee0476ea3426846a8139a71514bb627f7596"},{"sha":"68d542be69b3b045d5309fc15d1665aefb6fd6dc","author":{"name":"Sébastien Szymanski","email":"df6bdf20a159eda54db82d97e15e3f2b8626ef27@armadeus.com"},"message":"ASoC: cs4265: fix MMTLR Data switch control\n\ncommit 90a3b7f8aba3011badacd6d8121e03aa24ac79d1 upstream.\n\nThe MMTLR bit is in the CS4265_SPDIF_CTL2 register at address 0x12 bit 0\nand not at address 0x0 bit 1. Fix this.\n\nSigned-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nCc: stable@vger.kernel.org\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/travarilo/kernel_asus_sdm660/commits/68d542be69b3b045d5309fc15d1665aefb6fd6dc"},{"sha":"1da7fa6383fde3e7a4954460352f7f4574c99bfd","author":{"name":"Takashi Sakamoto","email":"d5ec7d0cd8074757a1f5eb708bc105c3065a65ea@sakamocchi.jp"},"message":"ALSA: bebob: use address returned by kmalloc() instead of kernel stack for streaming DMA mapping\n\ncommit 493626f2d87a74e6dbea1686499ed6e7e600484e upstream.\n\nWhen executing 'fw_run_transaction()' with 'TCODE_WRITE_BLOCK_REQUEST',\nan address of 'payload' argument is used for streaming DMA mapping by\n'firewire_ohci' module if 'size' argument is larger than 8 byte.\nAlthough in this case the address should not be on kernel stack, current\nimplementation of ALSA bebob driver uses data in kernel stack for a cue\nto boot M-Audio devices. This often brings unexpected result, especially\nfor a case of CONFIG_VMAP_STACK=y.\n\nThis commit fixes the bug.\n\nReference: https://bugzilla.kernel.org/show_bug.cgi?id=201021\nReference: https://forum.manjaro.org/t/firewire-m-audio-410-driver-wont-load-firmware/51165\nFixes: a2b2a7798fb6('ALSA: bebob: Send a cue to load firmware for M-Audio Firewire series')\nCc: <stable@vger.kernel.org> # v3.16+\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/travarilo/kernel_asus_sdm660/commits/1da7fa6383fde3e7a4954460352f7f4574c99bfd"},{"sha":"66d1019aff7c7d423a1ef44c3ea8fd89dd1c35bd","author":{"name":"Willy Tarreau","email":"aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu"},"message":"ALSA: emu10k1: fix possible info leak to userspace on SNDRV_EMU10K1_IOCTL_INFO\n\ncommit 49434c6c575d2008c0abbc93e615019f39e01252 upstream.\n\nsnd_emu10k1_fx8010_ioctl(SNDRV_EMU10K1_IOCTL_INFO) allocates\nmemory using kmalloc() and partially fills it by calling\nsnd_emu10k1_fx8010_info() before returning the resulting\nstructure to userspace, leaving uninitialized holes. Let's\njust use kzalloc() here.\n\nBugLink: http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.html\nSigned-off-by: Willy Tarreau <w@1wt.eu>\nCc: Jann Horn <jannh@google.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/travarilo/kernel_asus_sdm660/commits/66d1019aff7c7d423a1ef44c3ea8fd89dd1c35bd"},{"sha":"39b38432c8ac6c084a8cadc3dba07c570ac2866b","author":{"name":"Mario Limonciello","email":"3f0fe7ef7a1360c182d345338042daf40343329b@dell.com"},"message":"platform/x86: alienware-wmi: Correct a memory leak\n\ncommit ff0e9f26288d2daee4950f42b37a3d3d30d36ec1 upstream.\n\nAn ACPI buffer that was allocated was not being freed after use.\n\nSigned-off-by: Mario Limonciello <mario.limonciello@dell.com>\nCc: stable@vger.kernel.org\nSigned-off-by: Darren Hart (VMware) <dvhart@infradead.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/travarilo/kernel_asus_sdm660/commits/39b38432c8ac6c084a8cadc3dba07c570ac2866b"},{"sha":"bd1468048aa3e2af865da92990539946d4483989","author":{"name":"Juergen Gross","email":"29bbaec13092d36559e3abc6f27f7d09c395819f@suse.com"},"message":"xen/netfront: don't bug in case of too many frags\n\ncommit ad4f15dc2c70b1de5e0a64d27335962fbc9cf71c upstream.\n\nCommit 57f230ab04d291 (\"xen/netfront: raise max number of slots in\nxennet_get_responses()\") raised the max number of allowed slots by one.\nThis seems to be problematic in some configurations with netback using\na larger MAX_SKB_FRAGS value (e.g. old Linux kernel with MAX_SKB_FRAGS\ndefined as 18 instead of nowadays 17).\n\nInstead of BUG_ON() in this case just fall back to retransmission.\n\nFixes: 57f230ab04d291 (\"xen/netfront: raise max number of slots in xennet_get_responses()\")\nCc: stable@vger.kernel.org\nSigned-off-by: Juergen Gross <jgross@suse.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/travarilo/kernel_asus_sdm660/commits/bd1468048aa3e2af865da92990539946d4483989"},{"sha":"28ca9ed1c95547daee49749287393ef6e540dbaa","author":{"name":"Boris Ostrovsky","email":"b41c17b861974b03cec38e3ec2992769b9bfae55@oracle.com"},"message":"xen/x86/vpmu: Zero struct pt_regs before calling into sample handling code\n\ncommit 70513d58751d7c6c1a0133557b13089b9f2e3e66 upstream.\n\nOtherwise we may leak kernel stack for events that sample user\nregisters.\n\nReported-by: Mark Rutland <mark.rutland@arm.com>\nReviewed-by: Juergen Gross <jgross@suse.com>\nSigned-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nCc: stable@vger.kernel.org\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/travarilo/kernel_asus_sdm660/commits/28ca9ed1c95547daee49749287393ef6e540dbaa"},{"sha":"fed4d566a8215ab04d1e674a47d5746b051699f2","author":{"name":"Vaibhav Nagarnaik","email":"1fa667586c90bce718fd3c486c1144f98789d483@google.com"},"message":"ring-buffer: Allow for rescheduling when removing pages\n\ncommit 83f365554e47997ec68dc4eca3f5dce525cd15c3 upstream.\n\nWhen reducing ring buffer size, pages are removed by scheduling a work\nitem on each CPU for the corresponding CPU ring buffer. After the pages\nare removed from ring buffer linked list, the pages are free()d in a\ntight loop. The loop does not give up CPU until all pages are removed.\nIn a worst case behavior, when lot of pages are to be freed, it can\ncause system stall.\n\nAfter the pages are removed from the list, the free() can happen while\nthe work is rescheduled. Call cond_resched() in the loop to prevent the\nsystem hangup.\n\nLink: http://lkml.kernel.org/r/20180907223129.71994-1-vnagarnaik@google.com\n\nCc: stable@vger.kernel.org\nFixes: 83f40318dab00 (\"ring-buffer: Make removal of ring buffer pages atomic\")\nReported-by: Jason Behmer <jbehmer@google.com>\nSigned-off-by: Vaibhav Nagarnaik <vnagarnaik@google.com>\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/travarilo/kernel_asus_sdm660/commits/fed4d566a8215ab04d1e674a47d5746b051699f2"},{"sha":"4da7f35b06702b1bc011270f15084a574ac76e1f","author":{"name":"Joel Fernandes (Google)","email":"4816dabf8db1bc6cac35b3a24cab2ff844b5b0c7@joelfernandes.org"},"message":"mm: shmem.c: Correctly annotate new inodes for lockdep\n\ncommit b45d71fb89ab8adfe727b9d0ee188ed58582a647 upstream.\n\nDirectories and inodes don't necessarily need to be in the same lockdep\nclass.  For ex, hugetlbfs splits them out too to prevent false positives\nin lockdep.  Annotate correctly after new inode creation.  If its a\ndirectory inode, it will be put into a different class.\n\nThis should fix a lockdep splat reported by syzbot:\n\n> ======================================================\n> WARNING: possible circular locking dependency detected\n> 4.18.0-rc8-next-20180810+ #36 Not tainted\n> ------------------------------------------------------\n> syz-executor900/4483 is trying to acquire lock:\n> 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: inode_lock\n> include/linux/fs.h:765 [inline]\n> 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at:\n> shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602\n>\n> but task is already holding lock:\n> 0000000025208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630\n> drivers/staging/android/ashmem.c:448\n>\n> which lock already depends on the new lock.\n>\n> -> #2 (ashmem_mutex){+.+.}:\n>        __mutex_lock_common kernel/locking/mutex.c:925 [inline]\n>        __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073\n>        mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088\n>        ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361\n>        call_mmap include/linux/fs.h:1844 [inline]\n>        mmap_region+0xf27/0x1c50 mm/mmap.c:1762\n>        do_mmap+0xa10/0x1220 mm/mmap.c:1535\n>        do_mmap_pgoff include/linux/mm.h:2298 [inline]\n>        vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357\n>        ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585\n>        __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]\n>        __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]\n>        __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91\n>        do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290\n>        entry_SYSCALL_64_after_hwframe+0x49/0xbe\n>\n> -> #1 (&mm->mmap_sem){++++}:\n>        __might_fault+0x155/0x1e0 mm/memory.c:4568\n>        _copy_to_user+0x30/0x110 lib/usercopy.c:25\n>        copy_to_user include/linux/uaccess.h:155 [inline]\n>        filldir+0x1ea/0x3a0 fs/readdir.c:196\n>        dir_emit_dot include/linux/fs.h:3464 [inline]\n>        dir_emit_dots include/linux/fs.h:3475 [inline]\n>        dcache_readdir+0x13a/0x620 fs/libfs.c:193\n>        iterate_dir+0x48b/0x5d0 fs/readdir.c:51\n>        __do_sys_getdents fs/readdir.c:231 [inline]\n>        __se_sys_getdents fs/readdir.c:212 [inline]\n>        __x64_sys_getdents+0x29f/0x510 fs/readdir.c:212\n>        do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290\n>        entry_SYSCALL_64_after_hwframe+0x49/0xbe\n>\n> -> #0 (&sb->s_type->i_mutex_key#9){++++}:\n>        lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924\n>        down_write+0x8f/0x130 kernel/locking/rwsem.c:70\n>        inode_lock include/linux/fs.h:765 [inline]\n>        shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602\n>        ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455\n>        ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797\n>        vfs_ioctl fs/ioctl.c:46 [inline]\n>        file_ioctl fs/ioctl.c:501 [inline]\n>        do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685\n>        ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702\n>        __do_sys_ioctl fs/ioctl.c:709 [inline]\n>        __se_sys_ioctl fs/ioctl.c:707 [inline]\n>        __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707\n>        do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290\n>        entry_SYSCALL_64_after_hwframe+0x49/0xbe\n>\n> other info that might help us debug this:\n>\n> Chain exists of:\n>   &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex\n>\n>  Possible unsafe locking scenario:\n>\n>        CPU0                    CPU1\n>        ----                    ----\n>   lock(ashmem_mutex);\n>                                lock(&mm->mmap_sem);\n>                                lock(ashmem_mutex);\n>   lock(&sb->s_type->i_mutex_key#9);\n>\n>  *** DEADLOCK ***\n>\n> 1 lock held by syz-executor900/4483:\n>  #0: 0000000025208078 (ashmem_mutex){+.+.}, at:\n> ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448\n\nLink: http://lkml.kernel.org/r/20180821231835.166639-1-joel@joelfernandes.org\nSigned-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>\nReported-by: syzbot <syzkaller@googlegroups.com>\nReviewed-by: NeilBrown <neilb@suse.com>\nSuggested-by: NeilBrown <neilb@suse.com>\nCc: Matthew Wilcox <willy@infradead.org>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Hugh Dickins <hughd@google.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/travarilo/kernel_asus_sdm660/commits/4da7f35b06702b1bc011270f15084a574ac76e1f"},{"sha":"cb66016b7b895b8f27609ee128c0b71da7213816","author":{"name":"Toke Høiland-Jørgensen","email":"c739cf9ea9032889618db8b95a03da66fcc9867e@toke.dk"},"message":"gso_segment: Reset skb->mac_len after modifying network header\n\n[ Upstream commit c56cae23c6b167acc68043c683c4573b80cbcc2c ]\n\nWhen splitting a GSO segment that consists of encapsulated packets, the\nskb->mac_len of the segments can end up being set wrong, causing packet\ndrops in particular when using act_mirred and ifb interfaces in\ncombination with a qdisc that splits GSO packets.\n\nThis happens because at the time skb_segment() is called, network_header\nwill point to the inner header, throwing off the calculation in\nskb_reset_mac_len(). The network_header is subsequently adjust by the\nouter IP gso_segment handlers, but they don't set the mac_len.\n\nFix this by adding skb_reset_mac_len() calls to both the IPv4 and IPv6\ngso_segment handlers, after they modify the network_header.\n\nMany thanks to Eric Dumazet for his help in identifying the cause of\nthe bug.\n\nAcked-by: Dave Taht <dave.taht@gmail.com>\nReviewed-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Toke Høiland-Jørgensen <toke@toke.dk>\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/travarilo/kernel_asus_sdm660/commits/cb66016b7b895b8f27609ee128c0b71da7213816"},{"sha":"2ec3b47a784685347c29ff5e46bc1f2429eaf264","author":{"name":"Eric Dumazet","email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com"},"message":"ipv6: fix possible use-after-free in ip6_xmit()\n\n[ Upstream commit bbd6528d28c1b8e80832b3b018ec402b6f5c3215 ]\n\nIn the unlikely case ip6_xmit() has to call skb_realloc_headroom(),\nwe need to call skb_set_owner_w() before consuming original skb,\notherwise we risk a use-after-free.\n\nBring IPv6 in line with what we do in IPv4 to fix this.\n\nFixes: 1da177e4c3f41 (\"Linux-2.6.12-rc2\")\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/travarilo/kernel_asus_sdm660/commits/2ec3b47a784685347c29ff5e46bc1f2429eaf264"},{"sha":"fee0d234419708192925c9e25a461f1f43dab24f","author":{"name":"Willy Tarreau","email":"aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu"},"message":"net/appletalk: fix minor pointer leak to userspace in SIOCFINDIPDDPRT\n\n[ Upstream commit 9824dfae5741275473a23a7ed5756c7b6efacc9d ]\n\nFields ->dev and ->next of struct ipddp_route may be copied to\nuserspace on the SIOCFINDIPDDPRT ioctl. This is only accessible\nto CAP_NET_ADMIN though. Let's manually copy the relevant fields\ninstead of using memcpy().\n\nBugLink: http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.html\nCc: Jann Horn <jannh@google.com>\nSigned-off-by: Willy Tarreau <w@1wt.eu>\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/travarilo/kernel_asus_sdm660/commits/fee0d234419708192925c9e25a461f1f43dab24f"},{"sha":"b8214c557ca00d9e3110555d919f44ff16d512a4","author":{"name":"Colin Ian King","email":"d100aa70785e45ee8deab668147d941941915c21@canonical.com"},"message":"net: hp100: fix always-true check for link up state\n\n[ Upstream commit a7f38002fb69b44f8fc622ecb838665d0b8666af ]\n\nThe operation ~(p100_inb(VG_LAN_CFG_1) & HP100_LINK_UP) returns a value\nthat is always non-zero and hence the wait for the link to drop always\nterminates prematurely.  Fix this by using a logical not operator instead\nof a bitwise complement.  This issue has been in the driver since\npre-2.6.12-rc2.\n\nDetected by CoverityScan, CID#114157 (\"Logical vs. bitwise operator\")\n\nSigned-off-by: Colin Ian King <colin.king@canonical.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/travarilo/kernel_asus_sdm660/commits/b8214c557ca00d9e3110555d919f44ff16d512a4"},{"sha":"c6e386425347a8e704440f925d49496e5edfea60","author":{"name":"Vasily Khoruzhick","email":"8d423c6462c386eeb08996628b7802c179650542@arista.com"},"message":"neighbour: confirm neigh entries when ARP packet is received\n\n[ Upstream commit f0e0d04413fcce9bc76388839099aee93cd0d33b ]\n\nUpdate 'confirmed' timestamp when ARP packet is received. It shouldn't\naffect locktime logic and anyway entry can be confirmed by any higher-layer\nprotocol. Thus it makes sense to confirm it when ARP packet is received.\n\nFixes: 77d7123342dc (\"neighbour: update neigh timestamps iff update is effective\")\nSigned-off-by: Vasily Khoruzhick <vasilykh@arista.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/travarilo/kernel_asus_sdm660/commits/c6e386425347a8e704440f925d49496e5edfea60"},{"sha":"afba6121b3b7e1737b7e7dafbf6b7eafbcdc659c","author":{"name":"Vincent Pelletier","email":"79ed65387ffcd88b36f0a80b55bba4063084e90e@gmail.com"},"message":"scsi: target: iscsi: Use hex2bin instead of a re-implementation\n\ncommit 1816494330a83f2a064499d8ed2797045641f92c upstream.\n\nThis change has the following effects, in order of descreasing importance:\n\n1) Prevent a stack buffer overflow\n\n2) Do not append an unnecessary NULL to an anyway binary buffer, which\n   is writing one byte past client_digest when caller is:\n   chap_string_to_hex(client_digest, chap_r, strlen(chap_r));\n\nThe latter was found by KASAN (see below) when input value hes expected size\n(32 hex chars), and further analysis revealed a stack buffer overflow can\nhappen when network-received value is longer, allowing an unauthenticated\nremote attacker to smash up to 17 bytes after destination buffer (16 bytes\nattacker-controlled and one null).  As switching to hex2bin requires\nspecifying destination buffer length, and does not internally append any null,\nit solves both issues.\n\nThis addresses CVE-2018-14633.\n\nBeyond this:\n\n- Validate received value length and check hex2bin accepted the input, to log\n  this rejection reason instead of just failing authentication.\n\n- Only log received CHAP_R and CHAP_C values once they passed sanity checks.\n\n==================================================================\nBUG: KASAN: stack-out-of-bounds in chap_string_to_hex+0x32/0x60 [iscsi_target_mod]\nWrite of size 1 at addr ffff8801090ef7c8 by task kworker/0:0/1021\n\nCPU: 0 PID: 1021 Comm: kworker/0:0 Tainted: G           O      4.17.8kasan.sess.connops+ #2\nHardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 05/19/2014\nWorkqueue: events iscsi_target_do_login_rx [iscsi_target_mod]\nCall Trace:\n dump_stack+0x71/0xac\n print_address_description+0x65/0x22e\n ? chap_string_to_hex+0x32/0x60 [iscsi_target_mod]\n kasan_report.cold.6+0x241/0x2fd\n chap_string_to_hex+0x32/0x60 [iscsi_target_mod]\n chap_server_compute_md5.isra.2+0x2cb/0x860 [iscsi_target_mod]\n ? chap_binaryhex_to_asciihex.constprop.5+0x50/0x50 [iscsi_target_mod]\n ? ftrace_caller_op_ptr+0xe/0xe\n ? __orc_find+0x6f/0xc0\n ? unwind_next_frame+0x231/0x850\n ? kthread+0x1a0/0x1c0\n ? ret_from_fork+0x35/0x40\n ? ret_from_fork+0x35/0x40\n ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]\n ? deref_stack_reg+0xd0/0xd0\n ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]\n ? is_module_text_address+0xa/0x11\n ? kernel_text_address+0x4c/0x110\n ? __save_stack_trace+0x82/0x100\n ? ret_from_fork+0x35/0x40\n ? save_stack+0x8c/0xb0\n ? 0xffffffffc1660000\n ? iscsi_target_do_login+0x155/0x8d0 [iscsi_target_mod]\n ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]\n ? process_one_work+0x35c/0x640\n ? worker_thread+0x66/0x5d0\n ? kthread+0x1a0/0x1c0\n ? ret_from_fork+0x35/0x40\n ? iscsi_update_param_value+0x80/0x80 [iscsi_target_mod]\n ? iscsit_release_cmd+0x170/0x170 [iscsi_target_mod]\n chap_main_loop+0x172/0x570 [iscsi_target_mod]\n ? chap_server_compute_md5.isra.2+0x860/0x860 [iscsi_target_mod]\n ? rx_data+0xd6/0x120 [iscsi_target_mod]\n ? iscsit_print_session_params+0xd0/0xd0 [iscsi_target_mod]\n ? cyc2ns_read_begin.part.2+0x90/0x90\n ? _raw_spin_lock_irqsave+0x25/0x50\n ? memcmp+0x45/0x70\n iscsi_target_do_login+0x875/0x8d0 [iscsi_target_mod]\n ? iscsi_target_check_first_request.isra.5+0x1a0/0x1a0 [iscsi_target_mod]\n ? del_timer+0xe0/0xe0\n ? memset+0x1f/0x40\n ? flush_sigqueue+0x29/0xd0\n iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]\n ? iscsi_target_nego_release+0x80/0x80 [iscsi_target_mod]\n ? iscsi_target_restore_sock_callbacks+0x130/0x130 [iscsi_target_mod]\n process_one_work+0x35c/0x640\n worker_thread+0x66/0x5d0\n ? flush_rcu_work+0x40/0x40\n kthread+0x1a0/0x1c0\n ? kthread_bind+0x30/0x30\n ret_from_fork+0x35/0x40\n\nThe buggy address belongs to the page:\npage:ffffea0004243bc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0\nflags: 0x17fffc000000000()\nraw: 017fffc000000000 0000000000000000 0000000000000000 00000000ffffffff\nraw: ffffea0004243c20 ffffea0004243ba0 0000000000000000 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff8801090ef680: f2 f2 f2 f2 f2 f2 f2 01 f2 f2 f2 f2 f2 f2 f2 00\n ffff8801090ef700: f2 f2 f2 f2 f2 f2 f2 00 02 f2 f2 f2 f2 f2 f2 00\n>ffff8801090ef780: 00 f2 f2 f2 f2 f2 f2 00 00 f2 f2 f2 f2 f2 f2 00\n                                              ^\n ffff8801090ef800: 00 f2 f2 f2 f2 f2 f2 00 00 00 00 02 f2 f2 f2 f2\n ffff8801090ef880: f2 f2 f2 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00\n==================================================================\n\nSigned-off-by: Vincent Pelletier <plr.vincent@gmail.com>\nReviewed-by: Mike Christie <mchristi@redhat.com>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/travarilo/kernel_asus_sdm660/commits/afba6121b3b7e1737b7e7dafbf6b7eafbcdc659c"},{"sha":"98e14c520fff92344cb0c7472be4b963fc5fa44f","author":{"name":"Junxiao Bi","email":"adb0658383f88ec6beb1fb7689ba0dac7c1c4882@oracle.com"},"message":"ocfs2: fix ocfs2 read block panic\n\ncommit 234b69e3e089d850a98e7b3145bd00e9b52b1111 upstream.\n\nWhile reading block, it is possible that io error return due to underlying\nstorage issue, in this case, BH_NeedsValidate was left in the buffer head.\nThen when reading the very block next time, if it was already linked into\njournal, that will trigger the following panic.\n\n[203748.702517] kernel BUG at fs/ocfs2/buffer_head_io.c:342!\n[203748.702533] invalid opcode: 0000 [#1] SMP\n[203748.702561] Modules linked in: ocfs2 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sunrpc dm_switch dm_queue_length dm_multipath bonding be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i iw_cxgb4 cxgb4 cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_devintf iTCO_wdt iTCO_vendor_support dcdbas ipmi_ssif i2c_core ipmi_si ipmi_msghandler acpi_pad pcspkr sb_edac edac_core lpc_ich mfd_core shpchp sg tg3 ptp pps_core ext4 jbd2 mbcache2 sr_mod cdrom sd_mod ahci libahci megaraid_sas wmi dm_mirror dm_region_hash dm_log dm_mod\n[203748.703024] CPU: 7 PID: 38369 Comm: touch Not tainted 4.1.12-124.18.6.el6uek.x86_64 #2\n[203748.703045] Hardware name: Dell Inc. PowerEdge R620/0PXXHP, BIOS 2.5.2 01/28/2015\n[203748.703067] task: ffff880768139c00 ti: ffff88006ff48000 task.ti: ffff88006ff48000\n[203748.703088] RIP: 0010:[<ffffffffa05e9f09>]  [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2]\n[203748.703130] RSP: 0018:ffff88006ff4b818  EFLAGS: 00010206\n[203748.703389] RAX: 0000000008620029 RBX: ffff88006ff4b910 RCX: 0000000000000000\n[203748.703885] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000023079fe\n[203748.704382] RBP: ffff88006ff4b8d8 R08: 0000000000000000 R09: ffff8807578c25b0\n[203748.704877] R10: 000000000f637376 R11: 000000003030322e R12: 0000000000000000\n[203748.705373] R13: ffff88006ff4b910 R14: ffff880732fe38f0 R15: 0000000000000000\n[203748.705871] FS:  00007f401992c700(0000) GS:ffff880bfebc0000(0000) knlGS:0000000000000000\n[203748.706370] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[203748.706627] CR2: 00007f4019252440 CR3: 00000000a621e000 CR4: 0000000000060670\n[203748.707124] Stack:\n[203748.707371]  ffff88006ff4b828 ffffffffa0609f52 ffff88006ff4b838 0000000000000001\n[203748.707885]  0000000000000000 0000000000000000 ffff880bf67c3800 ffffffffa05eca00\n[203748.708399]  00000000023079ff ffffffff81c58b80 0000000000000000 0000000000000000\n[203748.708915] Call Trace:\n[203748.709175]  [<ffffffffa0609f52>] ? ocfs2_inode_cache_io_unlock+0x12/0x20 [ocfs2]\n[203748.709680]  [<ffffffffa05eca00>] ? ocfs2_empty_dir_filldir+0x80/0x80 [ocfs2]\n[203748.710185]  [<ffffffffa05ec0cb>] ocfs2_read_dir_block_direct+0x3b/0x200 [ocfs2]\n[203748.710691]  [<ffffffffa05f0fbf>] ocfs2_prepare_dx_dir_for_insert.isra.57+0x19f/0xf60 [ocfs2]\n[203748.711204]  [<ffffffffa065660f>] ? ocfs2_metadata_cache_io_unlock+0x1f/0x30 [ocfs2]\n[203748.711716]  [<ffffffffa05f4f3a>] ocfs2_prepare_dir_for_insert+0x13a/0x890 [ocfs2]\n[203748.712227]  [<ffffffffa05f442e>] ? ocfs2_check_dir_for_entry+0x8e/0x140 [ocfs2]\n[203748.712737]  [<ffffffffa061b2f2>] ocfs2_mknod+0x4b2/0x1370 [ocfs2]\n[203748.713003]  [<ffffffffa061c385>] ocfs2_create+0x65/0x170 [ocfs2]\n[203748.713263]  [<ffffffff8121714b>] vfs_create+0xdb/0x150\n[203748.713518]  [<ffffffff8121b225>] do_last+0x815/0x1210\n[203748.713772]  [<ffffffff812192e9>] ? path_init+0xb9/0x450\n[203748.714123]  [<ffffffff8121bca0>] path_openat+0x80/0x600\n[203748.714378]  [<ffffffff811bcd45>] ? handle_pte_fault+0xd15/0x1620\n[203748.714634]  [<ffffffff8121d7ba>] do_filp_open+0x3a/0xb0\n[203748.714888]  [<ffffffff8122a767>] ? __alloc_fd+0xa7/0x130\n[203748.715143]  [<ffffffff81209ffc>] do_sys_open+0x12c/0x220\n[203748.715403]  [<ffffffff81026ddb>] ? syscall_trace_enter_phase1+0x11b/0x180\n[203748.715668]  [<ffffffff816f0c9f>] ? system_call_after_swapgs+0xe9/0x190\n[203748.715928]  [<ffffffff8120a10e>] SyS_open+0x1e/0x20\n[203748.716184]  [<ffffffff816f0d5e>] system_call_fastpath+0x18/0xd7\n[203748.716440] Code: 00 00 48 8b 7b 08 48 83 c3 10 45 89 f8 44 89 e1 44 89 f2 4c 89 ee e8 07 06 11 e1 48 8b 03 48 85 c0 75 df 8b 5d c8 e9 4d fa ff ff <0f> 0b 48 8b 7d a0 e8 dc c6 06 00 48 b8 00 00 00 00 00 00 00 10\n[203748.717505] RIP  [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2]\n[203748.717775]  RSP <ffff88006ff4b818>\n\nJoesph ever reported a similar panic.\nLink: https://oss.oracle.com/pipermail/ocfs2-devel/2013-May/008931.html\n\nLink: http://lkml.kernel.org/r/20180912063207.29484-1-junxiao.bi@oracle.com\nSigned-off-by: Junxiao Bi <junxiao.bi@oracle.com>\nCc: Joseph Qi <jiangqi903@gmail.com>\nCc: Mark Fasheh <mark@fasheh.com>\nCc: Joel Becker <jlbec@evilplan.org>\nCc: Changwei Ge <ge.changwei@h3c.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/travarilo/kernel_asus_sdm660/commits/98e14c520fff92344cb0c7472be4b963fc5fa44f"},{"sha":"64436716c3a538ed65413c5257c6176dae5d807c","author":{"name":"Lyude Paul","email":"1d05c5face2dc786c0af2cf362656a51f0df9b63@redhat.com"},"message":"drm/nouveau/drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()\n\ncommit 6833fb1ec120bf078e1a527c573a09d4de286224 upstream.\n\nIt's true we can't resume the device from poll workers in\nnouveau_connector_detect(). We can however, prevent the autosuspend\ntimer from elapsing immediately if it hasn't already without risking any\nsort of deadlock with the runtime suspend/resume operations. So do that\ninstead of entirely avoiding grabbing a power reference.\n\nSigned-off-by: Lyude Paul <lyude@redhat.com>\nReviewed-by: Karol Herbst <kherbst@redhat.com>\nAcked-by: Daniel Vetter <daniel@ffwll.ch>\nCc: stable@vger.kernel.org\nCc: Lukas Wunner <lukas@wunner.de>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/travarilo/kernel_asus_sdm660/commits/64436716c3a538ed65413c5257c6176dae5d807c"},{"sha":"1aa698b65186c13ed775896ed1dfec7c26c73d60","author":{"name":"Gustavo A. R. Silva","email":"beac5f8171fcde5e2ec734cc5d25d03e7362e8de@embeddedor.com"},"message":"tty: vt_ioctl: fix potential Spectre v1\n\ncommit e97267cb4d1ee01ca0929638ec0fcbb0904f903d upstream.\n\nvsa.console is indirectly controlled by user-space, hence leading to\na potential exploitation of the Spectre variant 1 vulnerability.\n\nThis issue was detected with the help of Smatch:\n\ndrivers/tty/vt/vt_ioctl.c:711 vt_ioctl() warn: potential spectre issue\n'vc_cons' [r]\n\nFix this by sanitizing vsa.console before using it to index vc_cons\n\nNotice that given that speculation windows are large, the policy is\nto kill the speculation on the first load and not worry if it can be\ncompleted with a dependent load/store [1].\n\n[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2\n\nCc: stable@vger.kernel.org\nSigned-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>\nReviewed-by: Alan Cox <alan@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/travarilo/kernel_asus_sdm660/commits/1aa698b65186c13ed775896ed1dfec7c26c73d60"}]}
{"actor":{"display_login":"travarilo"}}