CVE-2019-15221

commit 4b886fa2b8f167b70af8a21340dfb3e24711e084 Author: Greg Kroah-Hartman Date: Wed Jul 10 09:52:33 2019 +0200 Linux 5.1.17 commit 10a573205ddd74d94bfc1bff4dfc8828ab7c055a Author: Roman Bolshakov Date: Tue Jul 2 22:16:38 2019 +0300 scsi: target/iblock: Fix overrun in WRITE SAME emulation commit 5676234f20fef02f6ca9bd66c63a8860fce62645 upstream. WRITE SAME corrupts data on the block device behind iblock if the command is emulated. The emulation code issues (M - 1) * N times more bios than requested, where M is the number of 512 blocks per real block size and N is the NUMBER OF LOGICAL BLOCKS specified in WRITE SAME command. So, for a device with 4k blocks, 7 * N more LBAs gets written after the requested range. The issue happens because the number of 512 byte sectors to be written is decreased one by one while the real bios are typically from 1 to 8 512 byte sectors per bio. Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6") Cc: Signed-off-by: Roman Bolshakov Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit c43646a747ed9c21a9fbe7b0cfb49c92b57eaef8 Author: Geert Uytterhoeven Date: Mon Apr 1 13:53:57 2019 +0200 fs: VALIDATE_FS_PARSER should default to n commit 75f2d86b20bf6aec0392d6dd2ae3ffff26d2ae0e upstream. CONFIG_VALIDATE_FS_PARSER is a debugging tool to check that the parser tables are vaguely sane. It was set to default to ‘Y’ for the moment to catch errors in upcoming fs conversion development. Make sure it is not enabled by default in the final release of v5.1. Fixes: 31d921c7fb969172 (“vfs: Add configuration parser helpers”) Signed-off-by: Geert Uytterhoeven Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit abedf70e30e15c9e2ae8d9543fa56643168acd7c Author: Dan Carpenter Date: Mon Jun 24 16:49:40 2019 +0300 dmaengine: jz4780: Fix an endian bug in IRQ handler commit 4c89cc73d1da42ae48b5c5dfbfd12304d0b86786 upstream. The “pending” variable was a u32 but we cast it to an unsigned long pointer when we do the for_each_set_bit() loop. The problem is that on big endian 64bit systems that results in an out of bounds read. Fixes: 4e4106f5e942 (“dmaengine: jz4780: Fix transfers being ACKed too soon”) Signed-off-by: Dan Carpenter Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 598ffd879b8a951d1f2febc76f39b97697f65eaf Author: Robin Gong Date: Fri Jun 21 16:23:06 2019 +0800 dmaengine: imx-sdma: remove BD_INTR for channel0 commit 3f93a4f297961c12bb17aa16cb3a4d1291823cae upstream. It is possible for an irq triggered by channel0 to be received later after clks are disabled once firmware loaded during sdma probe. If that happens then clearing them by writing to SDMA_H_INTR won’t work and the kernel will hang processing infinite interrupts. Actually, don’t need interrupt triggered on channel0 since it’s pollling SDMA_H_STATSTOP to know channel0 done rather than interrupt in current code, just clear BD_INTR to disable channel0 interrupt to avoid the above case. This issue was brought by commit 1d069bfa3c78 (“dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler”) which didn’t take care the above case. Fixes: 1d069bfa3c78 (“dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler”) Cc: [email protected] #5.0+ Signed-off-by: Robin Gong Reported-by: Sven Van Asbroeck Tested-by: Sven Van Asbroeck Reviewed-by: Michael Olbrich Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit c68eb98ae2975cae25271e4f7334766c17686810 Author: Sricharan R Date: Fri Jun 28 17:39:46 2019 +0530 dmaengine: qcom: bam_dma: Fix completed descriptors count commit f6034225442c4a87906d36e975fd9e99a8f95487 upstream. One space is left unused in circular FIFO to differentiate ‘full’ and ‘empty’ cases. So take that in to account while counting for the descriptors completed. Fixes the issue reported here, https://lkml.org/lkml/2019/6/18/669 Cc: [email protected] Reported-by: Srinivas Kandagatla Signed-off-by: Sricharan R Tested-by: Srinivas Kandagatla Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit b7948d98a058c46360d6af0139664e85860c9e2d Author: Cedric Hombourger Date: Thu Jun 13 10:52:50 2019 +0200 MIPS: have “plain” make calls build dtbs for selected platforms commit 637dfa0fad6d91a9a709dc70549a6d20fa77f615 upstream. scripts/package/builddeb calls “make dtbs_install” after executing a plain make (i.e. no build targets specified). It will fail if dtbs were not built beforehand. Match the arm64 architecture where DTBs get built by the “all” target. Signed-off-by: Cedric Hombourger [[email protected]: s/builddep/builddeb] Signed-off-by: Paul Burton Cc: [email protected] Cc: [email protected] # v4.1+ Signed-off-by: Greg Kroah-Hartman commit 4b9615523be558c93f3c6a8510a5f536dc40dad9 Author: Dmitry Korotin Date: Mon Jun 24 19:05:27 2019 +0000 MIPS: Add missing EHB in mtc0 -> mfc0 sequence. commit 0b24cae4d535045f4c9e177aa228d4e97bad212c upstream. Add a missing EHB (Execution Hazard Barrier) in mtc0 -> mfc0 sequence. Without this execution hazard barrier it’s possible for the value read back from the KScratch register to be the value from before the mtc0. Reproducible on P5600 & P6600. The hazard is documented in the MIPS Architecture Reference Manual Vol. III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev 6.03 table 8.1 which includes: Producer | Consumer | Hazard ----------|----------|---------------------------- mtc0 | mfc0 | any coprocessor 0 register Signed-off-by: Dmitry Korotin [[email protected]: - Commit message tweaks. - Add Fixes tags. - Mark for stable back to v3.15 where P5600 support was introduced.] Signed-off-by: Paul Burton Fixes: 3d8bfdd03072 (“MIPS: Use C0_KScratch (if present) to hold PGD pointer.”) Fixes: 829dcc0a956a (“MIPS: Add MIPS P5600 probe support”) Cc: [email protected] Cc: [email protected] # v3.15+ Signed-off-by: Greg Kroah-Hartman commit e395c337f1445a93ae245f0d1240201dfb7ea8cb Author: Hauke Mehrtens Date: Mon Jun 17 00:30:39 2019 +0200 MIPS: Fix bounds check virt_addr_valid commit d6ed083f5cc621e15c15b56c3b585fd524dbcb0f upstream. The bounds check used the uninitialized variable vaddr, it should use the given parameter kaddr instead. When using the uninitialized value the compiler assumed it to be 0 and optimized this function to just return 0 in all cases. This should make the function check the range of the given address and only do the page map check in case it is in the expected range of virtual addresses. Fixes: 074a1e1167af (“MIPS: Bounds check virt_addr_valid”) Cc: [email protected] # v4.12+ Cc: Paul Burton Signed-off-by: Hauke Mehrtens Signed-off-by: Paul Burton Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Greg Kroah-Hartman commit 3774d334e314b65c97c98274be365e9d80ca1fe2 Author: Chuck Lever Date: Tue Jun 11 11:01:16 2019 -0400 svcrdma: Ignore source port when computing DRC hash commit 1e091c3bbf51d34d5d96337a59ce5ab2ac3ba2cc upstream. The DRC appears to be effectively empty after an RPC/RDMA transport reconnect. The problem is that each connection uses a different source port, which defeats the DRC hash. Clients always have to disconnect before they send retransmissions to reset the connection’s credit accounting, thus every retransmit on NFS/RDMA will miss the DRC. An NFS/RDMA client’s IP source port is meaningless for RDMA transports. The transport layer typically sets the source port value on the connection to a random ephemeral port. The server already ignores it for the “secure port” check. See commit 16e4d93f6de7 (“NFSD: Ignore client’s source port on RDMA transports”). The Linux NFS server’s DRC resolves XID collisions from the same source IP address by using the checksum of the first 200 bytes of the RPC call header. Signed-off-by: Chuck Lever Cc: [email protected] # v4.14+ Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 94f536c7556045f1920a78ef9d2c9a6fd398ef94 Author: Paul Menzel Date: Wed Jul 3 13:28:15 2019 +0200 nfsd: Fix overflow causing non-working mounts on 1 TB machines commit 3b2d4dcf71c4a91b420f835e52ddea8192300a3b upstream. Since commit 10a68cdf10 (nfsd: fix performance-limiting session calculation) (Linux 5.1-rc1 and 4.19.31), shares from NFS servers with 1 TB of memory cannot be mounted anymore. The mount just hangs on the client. The gist of commit 10a68cdf10 is the change below. -avail = clamp_t(int, avail, slotsize, avail/3); +avail = clamp_t(int, avail, slotsize, total_avail/3); Here are the macros. #define min_t(type, x, y) __careful_cmp((type)(x), (type)(y), <) #define clamp_t(type, val, lo, hi) min_t(type, max_t(type, val, lo), hi) `total_avail` is 8,434,659,328 on the 1 TB machine. `clamp_t()` casts the values to `int`, which for 32-bit integers can only hold values −2,147,483,648 (−2^31) through 2,147,483,647 (2^31 − 1). `avail` (in the function signature) is just 65536, so that no overflow was happening. Before the commit the assignment would result in 21845, and `num = 4`. When using `total_avail`, it is causing the assignment to be 18446744072226137429 (printed as %lu), and `num` is then 4164608182. My next guess is, that `nfsd_drc_mem_used` is then exceeded, and the server thinks there is no memory available any more for this client. Updating the arguments of `clamp_t()` and `min_t()` to `unsigned long` fixes the issue. Now, `avail = 65536` (before commit 10a68cdf10 `avail = 21845`), but `num = 4` remains the same. Fixes: c54f24e338ed (nfsd: fix performance-limiting session calculation) Cc: [email protected] Signed-off-by: Paul Menzel Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 03dbbec3388e7986bd62179891467d3e9f52f67b Author: Wanpeng Li Date: Tue Jul 2 17:25:02 2019 +0800 KVM: LAPIC: Fix pending interrupt in IRR blocked by software disable LAPIC commit bb34e690e9340bc155ebed5a3d75fc63ff69e082 upstream. Thomas reported that: | Background: | | In preparation of supporting IPI shorthands I changed the CPU offline | code to software disable the local APIC instead of just masking it. | That’s done by clearing the APIC_SPIV_APIC_ENABLED bit in the APIC_SPIV | register. | | Failure: | | When the CPU comes back online the startup code triggers occasionally | the warning in apic_pending_intr_clear(). That complains that the IRRs | are not empty. | | The offending vector is the local APIC timer vector who’s IRR bit is set | and stays set. | | It took me quite some time to reproduce the issue locally, but now I can | see what happens. | | It requires apicv_enabled=0, i.e. full apic emulation. With apicv_enabled=1 | (and hardware support) it behaves correctly. | | Here is the series of events: | | Guest CPU | | goes down | | native_cpu_disable() | | apic_soft_disable(); | | play_dead() | | … | | startup() | | if (apic_enabled()) | apic_pending_intr_clear() <- Not taken | | enable APIC | | apic_pending_intr_clear() <- Triggers warning because IRR is stale | | When this happens then the deadline timer or the regular APIC timer - | happens with both, has fired shortly before the APIC is disabled, but the | interrupt was not serviced because the guest CPU was in an interrupt | disabled region at that point. | | The state of the timer vector ISR/IRR bits: | | ISR IRR | before apic_soft_disable() 0 1 | after apic_soft_disable() 0 1 | | On startup 0 1 | | Now one would assume that the IRR is cleared after the INIT reset, but this | happens only on CPU0. | | Why? | | Because our CPU0 hotplug is just for testing to make sure nothing breaks | and goes through an NMI wakeup vehicle because INIT would send it through | the boots-trap code which is not really working if that CPU was not | physically unplugged. | | Now looking at a real world APIC the situation in that case is: | | ISR IRR | before apic_soft_disable() 0 1 | after apic_soft_disable() 0 1 | | On startup 0 0 | | Why? | | Once the dying CPU reenables interrupts the pending interrupt gets | delivered as a spurious interupt and then the state is clear. | | While that CPU0 hotplug test case is surely an esoteric issue, the APIC | emulation is still wrong, Even if the play_dead() code would not enable | interrupts then the pending IRR bit would turn into an ISR … interrupt | when the APIC is reenabled on startup. From SDM 10.4.7.2 Local APIC State After It Has Been Software Disabled * Pending interrupts in the IRR and ISR registers are held and require masking or handling by the CPU. In Thomas’s testing, hardware cpu will not respect soft disable LAPIC when IRR has already been set or APICv posted-interrupt is in flight, so we can skip soft disable APIC checking when clearing IRR and set ISR, continue to respect soft disable APIC when attempting to set IRR. Reported-by: Rong Chen Reported-by: Feng Tang Reported-by: Thomas Gleixner Tested-by: Thomas Gleixner Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Thomas Gleixner Cc: Rong Chen Cc: Feng Tang Cc: [email protected] Signed-off-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit d2bacadcff03cbde1bba0b3d848226dcced69b27 Author: Paolo Bonzini Date: Wed Jun 26 14:16:13 2019 +0200 KVM: x86: degrade WARN to pr_warn_ratelimited commit 3f16a5c318392cbb5a0c7a3d19dff8c8ef3c38ee upstream. This warning can be triggered easily by userspace, so it should certainly not cause a panic if panic_on_warn is set. Reported-by: [email protected] Suggested-by: Alexander Potapenko Acked-by: Alexander Potapenko Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 0615757300497d10704f276132a25d02817b0700 Author: Martin Schwidefsky Date: Wed Apr 24 12:49:44 2019 +0200 s390/mm: fix pxd_bad with folded page tables [ Upstream commit c9f621524e70774688db3cec60d85fa4c7de52e3 ] With git commit d1874a0c2805fcfa9162c972d6b7541e57adb542 “s390/mm: make the pxd_offset functions more robust” and a 2-level page table it can now happen that pgd_bad() gets asked to verify a large segment table entry. If the entry is marked as dirty pgd_bad() will incorrectly return true. Change the pgd_bad(), p4d_bad(), pud_bad() and pmd_bad() functions to first verify the table type, return false if the table level is lower than what the function is suppossed to check, return true if the table level is too high, and otherwise check the relevant region and segment table bits. pmd_bad() has to check against ~SEGMENT_ENTRY_BITS for normal page table pointers or ~SEGMENT_ENTRY_BITS_LARGE for large segment table entries. Same for pud_bad() which has to check against ~_REGION_ENTRY_BITS or ~_REGION_ENTRY_BITS_LARGE. Fixes: d1874a0c2805 (“s390/mm: make the pxd_offset functions more robust”) Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 3e9e67d03995f8eae4d498f25acc2423ae65d482 Author: Linus Torvalds Date: Mon May 6 11:28:23 2019 -0700 tty: rocket: fix incorrect forward declaration of 'rp_init()' [ Upstream commit 423ea3255424b954947d167681b71ded1b8fca53 ] Make the forward declaration actually match the real function definition, something that previous versions of gcc had just ignored. This is another patch to fix new warnings from gcc-9 before I start the merge window pulls. I don’t want to miss legitimate new warnings just because my system update brought a new compiler with new warnings. Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 723e3866fdd3fbba4539f6b17bcc590f3fd8ae11 Author: Nikolay Borisov Date: Fri May 17 10:44:25 2019 +0300 btrfs: Ensure replaced device doesn’t have pending chunk allocation commit debd1c065d2037919a7da67baf55cc683fee09f0 upstream. Recent FITRIM work, namely bbbf7243d62d (“btrfs: combine device update operations during transaction commit”) combined the way certain operations are recoded in a transaction. As a result an ASSERT was added in dev_replace_finish to ensure the new code works correctly. Unfortunately I got reports that it’s possible to trigger the assert, meaning that during a device replace it’s possible to have an unfinished chunk allocation on the source device. This is supposed to be prevented by the fact that a transaction is committed before finishing the replace oepration and alter acquiring the chunk mutex. This is not sufficient since by the time the transaction is committed and the chunk mutex acquired it’s possible to allocate a chunk depending on the workload being executed on the replaced device. This bug has been present ever since device replace was introduced but there was never code which checks for it. The correct way to fix is to ensure that there is no pending device modification operation when the chunk mutex is acquire and if there is repeat transaction commit. Unfortunately it’s not possible to just exclude the source device from btrfs_fs_devices::dev_alloc_list since this causes ENOSPC to be hit in transaction commit. Fixing that in another way would need to add special cases to handle the last writes and forbid new ones. The looped transaction fix is more obvious, and can be easily backported. The runtime of dev-replace is long so there’s no noticeable delay caused by that. Reported-by: David Sterba Fixes: 391cd9df81ac (“Btrfs: fix unprotected alloc list insertion during the finishing procedure of replace”) CC: [email protected] # 4.4+ Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit d4ad26edd623b66e9d2583c9cda6ab629ddbddee Author: Shakeel Butt Date: Thu Jul 4 15:14:42 2019 -0700 mm/vmscan.c: prevent useless kswapd loops commit dffcac2cb88e4ec5906235d64a83d802580b119e upstream. In production we have noticed hard lockups on large machines running large jobs due to kswaps hoarding lru lock within isolate_lru_pages when sc->reclaim_idx is 0 which is a small zone. The lru was couple hundred GiBs and the condition (page_zonenum(page) > sc->reclaim_idx) in isolate_lru_pages() was basically skipping GiBs of pages while holding the LRU spinlock with interrupt disabled. On further inspection, it seems like there are two issues: (1) If kswapd on the return from balance_pgdat() could not sleep (i.e. node is still unbalanced), the classzone_idx is unintentionally set to 0 and the whole reclaim cycle of kswapd will try to reclaim only the lowest and smallest zone while traversing the whole memory. (2) Fundamentally isolate_lru_pages() is really bad when the allocation has woken kswapd for a smaller zone on a very large machine running very large jobs. It can hoard the LRU spinlock while skipping over 100s of GiBs of pages. This patch only fixes (1). (2) needs a more fundamental solution. To fix (1), in the kswapd context, if pgdat->kswapd_classzone_idx is invalid use the classzone_idx of the previous kswapd loop otherwise use the one the waker has requested. Link: http://lkml.kernel.org/r/[email protected] Fixes: e716f2eb24de (“mm, vmscan: prevent kswapd sleeping prematurely due to mismatched classzone_idx”) Signed-off-by: Shakeel Butt Reviewed-by: Yang Shi Acked-by: Mel Gorman Cc: Johannes Weiner Cc: Michal Hocko Cc: Vlastimil Babka Cc: Hillf Danton Cc: Roman Gushchin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d0a2a5101c7cdd648a929a5e9519e2c87a6cb5fa Author: Petr Mladek Date: Thu Jun 27 10:13:34 2019 +0200 ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code() commit d5b844a2cf507fc7642c9ae80a9d585db3065c28 upstream. The commit 9f255b632bf12c4dd7 (“module: Fix livepatch/ftrace module text permissions race”) causes a possible deadlock between register_kprobe() and ftrace_run_update_code() when ftrace is using stop_machine(). The existing dependency chain (in reverse order) is: -> #1 (text_mutex){+.+.}: validate_chain.isra.21+0xb32/0xd70 __lock_acquire+0x4b8/0x928 lock_acquire+0x102/0x230 __mutex_lock+0x88/0x908 mutex_lock_nested+0x32/0x40 register_kprobe+0x254/0x658 init_kprobes+0x11a/0x168 do_one_initcall+0x70/0x318 kernel_init_freeable+0x456/0x508 kernel_init+0x22/0x150 ret_from_fork+0x30/0x34 kernel_thread_starter+0x0/0xc -> #0 (cpu_hotplug_lock.rw_sem){++++}: check_prev_add+0x90c/0xde0 validate_chain.isra.21+0xb32/0xd70 __lock_acquire+0x4b8/0x928 lock_acquire+0x102/0x230 cpus_read_lock+0x62/0xd0 stop_machine+0x2e/0x60 arch_ftrace_update_code+0x2e/0x40 ftrace_run_update_code+0x40/0xa0 ftrace_startup+0xb2/0x168 register_ftrace_function+0x64/0x88 klp_patch_object+0x1a2/0x290 klp_enable_patch+0x554/0x980 do_one_initcall+0x70/0x318 do_init_module+0x6e/0x250 load_module+0x1782/0x1990 __s390x_sys_finit_module+0xaa/0xf0 system_call+0xd8/0x2d0 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(text_mutex); lock(cpu_hotplug_lock.rw_sem); lock(text_mutex); lock(cpu_hotplug_lock.rw_sem); It is similar problem that has been solved by the commit 2d1e38f56622b9b (“kprobes: Cure hotplug lock ordering issues”). Many locks are involved. To be on the safe side, text_mutex must become a low level lock taken after cpu_hotplug_lock.rw_sem. This can’t be achieved easily with the current ftrace design. For example, arm calls set_all_modules_text_rw() already in ftrace_arch_code_modify_prepare(), see arch/arm/kernel/ftrace.c. This functions is called: + outside stop_machine() from ftrace_run_update_code() + without stop_machine() from ftrace_module_enable() Fortunately, the problematic fix is needed only on x86_64. It is the only architecture that calls set_all_modules_text_rw() in ftrace path and supports livepatching at the same time. Therefore it is enough to move text_mutex handling from the generic kernel/trace/ftrace.c into arch/x86/kernel/ftrace.c: ftrace_arch_code_modify_prepare() ftrace_arch_code_modify_post_process() This patch basically reverts the ftrace part of the problematic commit 9f255b632bf12c4dd7 (“module: Fix livepatch/ftrace module text permissions race”). And provides x86_64 specific-fix. Some refactoring of the ftrace code will be needed when livepatching is implemented for arm or nds32. These architectures call set_all_modules_text_rw() and use stop_machine() at the same time. Link: http://lkml.kernel.org/r/[email protected] Fixes: 9f255b632bf12c4dd7 (“module: Fix livepatch/ftrace module text permissions race”) Acked-by: Thomas Gleixner Reported-by: Miroslav Benes Reviewed-by: Miroslav Benes Reviewed-by: Josh Poimboeuf Signed-off-by: Petr Mladek [ As reviewed by Miroslav Benes , removed return value of ftrace_run_update_code() as it is a void function. ] Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 3d2a80000100ec7de166c3a72a3233a902e7d032 Author: Robert Beckett Date: Tue Jun 25 18:59:15 2019 +0100 drm/imx: only send event on crtc disable if kept disabled commit 5aeab2bfc9ffa72d3ca73416635cb3785dfc076f upstream. The event will be sent as part of the vblank enable during the modeset if the crtc is not being kept disabled. Fixes: 5f2f911578fb (“drm/imx: atomic phase 3 step 1: Use atomic configuration”) Signed-off-by: Robert Beckett Reviewed-by: Daniel Vetter Signed-off-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman commit c61d198157fb8755542c1d517431976064c536b8 Author: Robert Beckett Date: Tue Jun 25 18:59:13 2019 +0100 drm/imx: notify drm core before sending event during crtc disable commit 78c68e8f5cd24bd32ba4ca1cdfb0c30cf0642685 upstream. Notify drm core before sending pending events during crtc disable. This fixes the first event after disable having an old stale timestamp by having drm_crtc_vblank_off update the timestamp to now. This was seen while debugging weston log message: Warning: computed repaint delay is insane: -8212 msec This occurred due to: 1. driver starts up 2. fbcon comes along and restores fbdev, enabling vblank 3. vblank_disable_fn fires via timer disabling vblank, keeping vblank seq number and time set at current value (some time later) 4. weston starts and does a modeset 5. atomic commit disables crtc while it does the modeset 6. ipu_crtc_atomic_disable sends vblank with old seq number and time Fixes: a474478642d5 (“drm/imx: fix crtc vblank state regression”) Signed-off-by: Robert Beckett Reviewed-by: Daniel Vetter Signed-off-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman commit 7f426730b8b20b6e4f340f938b550cbaff64e75e Author: Lucas Stach Date: Thu Jun 27 16:42:00 2019 +0200 drm/etnaviv: add missing failure path to destroy suballoc commit be132e1375c1fffe48801296279079f8a59a9ed3 upstream. When something goes wrong in the GPU init after the cmdbuf suballocator has been constructed, we fail to destroy it properly. This causes havok later when the GPU is unbound due to a module unload or similar. Fixes: e66774dd6f6a (drm/etnaviv: add cmdbuf suballocator) Signed-off-by: Lucas Stach Tested-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 9455763a49212f3463dbeadeb7a1059b9a2d1fdd Author: Gerd Hoffmann Date: Fri Apr 5 06:46:02 2019 +0200 drm/virtio: move drm_connector_update_edid_property() call commit 41de4be6f6efa4132b29af51158cd672d93f2543 upstream. drm_connector_update_edid_property can sleep, we must not call it while holding a spinlock. Move the callsite. Fixes: b4b01b4995fb (“drm/virtio: add edid support”) Reported-by: Max Filippov Signed-off-by: Gerd Hoffmann Tested-by: Max Filippov Tested-by: Cornelia Huck Acked-by: Cornelia Huck Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman commit f728b21e2468d0742af2b9ced60088fe91bd981d Author: Alex Deucher Date: Mon Jul 1 08:38:12 2019 -0500 drm/amdgpu/gfx9: use reset default for PA_SC_FIFO_SIZE commit 25f09f858835b0e9a06213811031190a17d8ab78 upstream. Recommended by the hw team. Reviewed-and-Tested-by: Huang Rui Signed-off-by: Alex Deucher Cc: [email protected] Signed-off-by: Greg Kroah-Hartman commit 3f232903af86a92c78680e4a3b5e6bd996579eed Author: Lyude Paul Date: Thu Jun 20 19:21:26 2019 -0400 drm/amdgpu: Don’t skip display settings in hwmgr_resume() commit 688f3d1ebedffa310b6591bd1b63fa0770d945fe upstream. I’m not entirely sure why this is, but for some reason: 921935dc6404 (“drm/amd/powerplay: enforce display related settings only on needed”) Breaks runtime PM resume on the Radeon PRO WX 3100 (Lexa) in one the pre-production laptops I have. The issue manifests as the following messages in dmesg: [drm] UVD and UVD ENC initialized successfully. amdgpu 0000:3b:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring vce1 test failed (-110) [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block failed -110 [drm:amdgpu_device_resume [amdgpu]] *ERROR* amdgpu_device_ip_resume failed (-110). And happens after about 6-10 runtime PM suspend/resume cycles (sometimes sooner, if you’re lucky!). Unfortunately I can’t seem to pin down precisely which part in psm_adjust_power_state_dynamic that is causing the issue, but not skipping the display setting setup seems to fix it. Hopefully if there is a better fix for this, this patch will spark discussion around it. Fixes: 921935dc6404 (“drm/amd/powerplay: enforce display related settings only on needed”) Cc: Evan Quan Cc: Alex Deucher Cc: Huang Rui Cc: Rex Zhu Cc: Likun Gao Cc: # v5.1+ Signed-off-by: Lyude Paul Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 5150d80f63190b663a0dca59dce11c14ef2f9a2c Author: Evan Quan Date: Thu Jun 27 11:01:04 2019 +0800 drm/amd/powerplay: use hardware fan control if no powerplay fan table commit f78c581e22d4b33359ac3462e8d0504735df01f4 upstream. Otherwise, you may get divided-by-zero error or corrput the SMU fan control feature. Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Tested-by: Slava Abramov Acked-by: Slava Abramov Signed-off-by: Alex Deucher Cc: [email protected] Signed-off-by: Greg Kroah-Hartman commit e7d14cc87cfee8209b9a2ca522ac375233bb7670 Author: Chris Wilson Date: Fri Apr 19 12:17:47 2019 +0100 drm/i915/ringbuffer: EMIT_INVALIDATE *before* switch context commit c84c9029d782a3a0d2a7f0522ecb907314d43e2c upstream. Despite what I think the prm recommends, commit f2253bd9859b (“drm/i915/ringbuffer: EMIT_INVALIDATE after switch context”) turned out to be a huge mistake when enabling Ironlake contexts as the GPU would hang on either a MI_FLUSH or PIPE_CONTROL immediately following the MI_SET_CONTEXT of an active mesa context (more vanilla contexts, e.g. simple rendercopies with igt, do not suffer). Ville found the following clue, "[DevCTG+]: For the invalidate operation of the pipe control, the following pointers are affected. The invalidate operation affects the restore of these packets. If the pipe control invalidate operation is completed before the context save, the indirect pointers will not be restored from memory. 1. Pipeline State Pointer 2. Media State Pointer 3. Constant Buffer Packet" which suggests by us emitting the INVALIDATE prior to the MI_SET_CONTEXT, we prevent the context-restore from chasing the dangling pointers within the image, and explains why this likely prevents the GPU hang. Signed-off-by: Chris Wilson Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 928f8f42310f244501a7c70daac82c196112c190 in drm-intel-next) Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111014 Fixes: f2253bd9859b (“drm/i915/ringbuffer: EMIT_INVALIDATE after switch context”) Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 18cd20c0fa1bb0a3844b4b2ef6cfb22a85f8e051 Author: Ard Biesheuvel Date: Tue Jun 25 19:08:54 2019 +0200 arm64: kaslr: keep modules inside module region when KASAN is enabled commit 6f496a555d93db7a11d4860b9220d904822f586a upstream. When KASLR and KASAN are both enabled, we keep the modules where they are, and randomize the placement of the kernel so it is within 2 GB of the module region. The reason for this is that putting modules in the vmalloc region (like we normally do when KASLR is enabled) is not possible in this case, given that the entire vmalloc region is already backed by KASAN zero shadow pages, and so allocating dedicated KASAN shadow space as required by loaded modules is not possible. The default module allocation window is set to [_etext - 128MB, _etext] in kaslr.c, which is appropriate for KASLR kernels booted without a seed or with ‘nokaslr’ on the command line. However, as it turns out, it is not quite correct for the KASAN case, since it still intersects the vmalloc region at the top, where attempts to allocate shadow pages will collide with the KASAN zero shadow pages, causing a WARN() and all kinds of other trouble. So cap the top end to MODULES_END explicitly when running with KASAN. Cc: # 4.9+ Acked-by: Catalin Marinas Tested-by: Catalin Marinas Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 09cc58c8671330bb46294611e61a498f9e817f17 Author: Joshua Scott Date: Wed Jun 26 10:11:08 2019 +1200 ARM: dts: armada-xp-98dx3236: Switch to armada-38x-uart serial node commit 80031361747aec92163464f2ee08870fec33bcb0 upstream. Switch to the “marvell,armada-38x-uart” driver variant to empty the UART buffer before writing to the UART_LCR register. Signed-off-by: Joshua Scott Tested-by: Andrew Lunn Acked-by: Gregory CLEMENT . Cc: [email protected] Fixes: 43e28ba87708 (“ARM: dts: Use armada-370-xp as a base for armada-xp-98dx3236”) Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit ce3ce345cfd20671570596a6f5265abacc0c7021 Author: Eiichi Tsukata Date: Tue Jun 25 10:29:10 2019 +0900 tracing/snapshot: Resize spare buffer if size changed commit 46cc0b44428d0f0e81f11ea98217fc0edfbeab07 upstream. Current snapshot implementation swaps two ring_buffers even though their sizes are different from each other, that can cause an inconsistency between the contents of buffer_size_kb file and the current buffer size. For example: # cat buffer_size_kb 7 (expanded: 1408) # echo 1 > events/enable # grep bytes per_cpu/cpu0/stats bytes: 1441020 # echo 1 > snapshot // current:1408, spare:1408 # echo 123 > buffer_size_kb // current:123, spare:1408 # echo 1 > snapshot // current:1408, spare:123 # grep bytes per_cpu/cpu0/stats bytes: 1443700 # cat buffer_size_kb 123 // != current:1408 And also, a similar per-cpu case hits the following WARNING: Reproducer: # echo 1 > per_cpu/cpu0/snapshot # echo 123 > buffer_size_kb # echo 1 > per_cpu/cpu0/snapshot WARNING: WARNING: CPU: 0 PID: 1946 at kernel/trace/trace.c:1607 update_max_tr_single.part.0+0x2b8/0x380 Modules linked in: CPU: 0 PID: 1946 Comm: bash Not tainted 5.2.0-rc6 #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014 RIP: 0010:update_max_tr_single.part.0+0x2b8/0x380 Code: ff e8 dc da f9 ff 0f 0b e9 88 fe ff ff e8 d0 da f9 ff 44 89 ee bf f5 ff ff ff e8 33 dc f9 ff 41 83 fd f5 74 96 e8 b8 da f9 ff <0f> 0b eb 8d e8 af da f9 ff 0f 0b e9 bf fd ff ff e8 a3 da f9 ff 48 RSP: 0018:ffff888063e4fca0 EFLAGS: 00010093 RAX: ffff888066214380 RBX: ffffffff99850fe0 RCX: ffffffff964298a8 RDX: 0000000000000000 RSI: 00000000fffffff5 RDI: 0000000000000005 RBP: 1ffff1100c7c9f96 R08: ffff888066214380 R09: ffffed100c7c9f9b R10: ffffed100c7c9f9a R11: 0000000000000003 R12: 0000000000000000 R13: 00000000ffffffea R14: ffff888066214380 R15: ffffffff99851060 FS: 00007f9f8173c700(0000) GS:ffff88806d000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000714dc0 CR3: 0000000066fa6000 CR4: 00000000000006f0 Call Trace: ? trace_array_printk_buf+0x140/0x140 ? __mutex_lock_slowpath+0x10/0x10 tracing_snapshot_write+0x4c8/0x7f0 ? trace_printk_init_buffers+0x60/0x60 ? selinux_file_permission+0x3b/0x540 ? tracer_preempt_off+0x38/0x506 ? trace_printk_init_buffers+0x60/0x60 __vfs_write+0x81/0x100 vfs_write+0x1e1/0x560 ksys_write+0x126/0x250 ? __ia32_sys_read+0xb0/0xb0 ? do_syscall_64+0x1f/0x390 do_syscall_64+0xc1/0x390 entry_SYSCALL_64_after_hwframe+0x49/0xbe This patch adds resize_buffer_duplicate_size() to check if there is a difference between current/spare buffer sizes and resize a spare buffer if necessary. Link: http://lkml.kernel.org/r/[email protected] Cc: [email protected] Fixes: ad909e21bbe69 (“tracing: Add internal tracing_snapshot() functions”) Signed-off-by: Eiichi Tsukata Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit d82bf47aa320a0df39df27e63e1e319c429b572e Author: Oleg Nesterov Date: Thu Jul 4 15:14:49 2019 -0700 swap_readpage(): avoid blk_wake_io_task() if !synchronous commit 8751853091998cd31e9e5f1e8206280155af8921 upstream. swap_readpage() sets waiter = bio->bi_private even if synchronous = F, this means that the caller can get the spurious wakeup after return. This can be fatal if blk_wake_io_task() does set_current_state(TASK_RUNNING) after the caller does set_special_state(), in the worst case the kernel can crash in do_task_dead(). Link: http://lkml.kernel.org/r/[email protected] Fixes: 0619317ff8baa2d (“block: add polled wakeup task helper”) Signed-off-by: Oleg Nesterov Reported-by: Qian Cai Acked-by: Hugh Dickins Reviewed-by: Jens Axboe Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 61ff807f0dd9e1daa3aa75ade32c102dedbcffd9 Author: Eric Biggers Date: Thu Jul 4 15:14:39 2019 -0700 fs/userfaultfd.c: disable irqs for fault_pending and event locks commit cbcfa130a911c613a1d9d921af2eea171c414172 upstream. When IOCB_CMD_POLL is used on a userfaultfd, aio_poll() disables IRQs and takes kioctx::ctx_lock, then userfaultfd_ctx::fd_wqh.lock. This may have to wait for userfaultfd_ctx::fd_wqh.lock to be released by userfaultfd_ctx_read(), which in turn can be waiting for userfaultfd_ctx::fault_pending_wqh.lock or userfaultfd_ctx::event_wqh.lock. But elsewhere the fault_pending_wqh and event_wqh locks are taken with IRQs enabled. Since the IRQ handler may take kioctx::ctx_lock, lockdep reports that a deadlock is possible. Fix it by always disabling IRQs when taking the fault_pending_wqh and event_wqh locks. Commit ae62c16e105a (“userfaultfd: disable irqs when taking the waitqueue lock”) didn’t fix this because it only accounted for the fd_wqh lock, not the other locks nested inside it. Link: http://lkml.kernel.org/r/[email protected] Fixes: bfe4037e722e (“aio: implement IOCB_CMD_POLL”) Signed-off-by: Eric Biggers Reported-by: [email protected] Reported-by: [email protected] Reported-by: [email protected] Reviewed-by: Andrew Morton Cc: Christoph Hellwig Cc: Andrea Arcangeli Cc: [4.19+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3e421061981c8bb6ddfb9ebf8469146b90ba7c50 Author: Herbert Xu Date: Mon Jun 24 18:32:26 2019 +0800 lib/mpi: Fix karactx leak in mpi_powm commit c8ea9fce2baf7b643384f36f29e4194fa40d33a6 upstream. Sometimes mpi_powm will leak karactx because a memory allocation failure causes a bail-out that skips the freeing of karactx. This patch moves the freeing of karactx to the end of the function like everything else so that it can’t be skipped. Reported-by: [email protected] Fixes: cdec9cb5167a (“crypto: GnuPG based MPI lib - source files…”) Cc: Signed-off-by: Herbert Xu Reviewed-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7b6532ed7a6380b5c8e3d9c3a1fefff12469c5d8 Author: Jan Kara Date: Thu Jun 6 11:10:28 2019 +0200 dax: Fix xarray entry association for mixed mappings commit 1571c029a2ff289683ddb0a32253850363bcb8a7 upstream. When inserting entry into xarray, we store mapping and index in corresponding struct pages for memory error handling. When it happened that one process was mapping file at PMD granularity while another process at PTE granularity, we could wrongly deassociate PMD range and then reassociate PTE range leaving the rest of struct pages in PMD range without mapping information which could later cause missed notifications about memory errors. Fix the problem by calling the association / deassociation code if and only if we are really going to update the xarray (deassociating and associating zero or empty entries is just no-op so there’s no reason to complicate the code with trying to avoid the calls for these cases). Cc: Fixes: d2c997c0f145 (“fs, dax: use page->mapping to warn if truncate…”) Signed-off-by: Jan Kara Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 786db71da5e5af3c202ed41e9a8daccec890c83b Author: Dennis Wassenberg Date: Fri Jun 28 10:54:53 2019 +0200 ALSA: hda/realtek - Change front mic location for Lenovo M710q commit bef33e19203dde434bcdf21c449e3fb4f06c2618 upstream. On M710q Lenovo ThinkCentre machine, there are two front mics, we change the location for one of them to avoid conflicts. Signed-off-by: Dennis Wassenberg Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 32a4cd4c8bea773ea3d741e0e1e1abae9ced298d Author: Richard Sailer Date: Wed Jun 19 13:33:11 2019 +0200 ALSA: hda/realtek: Add quirks for several Clevo notebook barebones commit 503d90b30602a3295978e46d844ccc8167400fe6 upstream. This adds 4 SND_PCI_QUIRK(…) lines for several barebone models of the ODM Clevo. The model names are written in regex syntax to describe/match all clevo models that are similar enough and use the same PCI SSID that this fixup works for them. Additionally the lines regarding SSID 0x96e1 and 0x97e1 didn’t fix audio for the all our Clevo notebooks using these SSIDs (models Clevo P960* and P970*) since ALC1220_FIXP_CLEVO_PB51ED_PINS swapped pins that are not necesarry to be swapped. This patch initiates ALC1220_FIXUP_CLEVO_P950 instead for these model and fixes the audio. Fixes: 80690a276f44 (“ALSA: hda/realtek - Add quirk for Tuxedo XC 1509”) Signed-off-by: Richard Sailer Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 97001b394f87e5250bbdd7a488faf8bf6d9d5b1f Author: Colin Ian King Date: Thu Jun 27 17:43:08 2019 +0100 ALSA: usb-audio: fix sign unintended sign extension on left shifts commit 2acf5a3e6e9371e63c9e4ff54d84d08f630467a0 upstream. There are a couple of left shifts of unsigned 8 bit values that first get promoted to signed ints and hence get sign extended on the shift if the top bit of the 8 bit values are set. Fix this by casting the 8 bit values to unsigned ints to stop the unintentional sign extension. Addresses-Coverity: (“Unintended sign extension”) Signed-off-by: Colin Ian King Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 308e490d61bcca5a1114372550edc19187051ccb Author: Takashi Iwai Date: Tue Jul 2 20:07:21 2019 +0200 ALSA: line6: Fix write on zero-sized buffer commit 3450121997ce872eb7f1248417225827ea249710 upstream. LINE6 drivers allocate the buffers based on the value returned from usb_maxpacket() calls. The manipulated device may return zero for this, and this results in the kmalloc() with zero size (and it may succeed) while the other part of the driver code writes the packet data with the fixed size – which eventually overwrites. This patch adds a simple sanity check for the invalid buffer size for avoiding that problem. Reported-by: [email protected] Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 139b5516cb45cc0560dec1f61a61ad14d8445e77 Author: Takashi Sakamoto Date: Mon Jul 1 23:43:53 2019 +0900 ALSA: firewire-lib/fireworks: fix miss detection of received MIDI messages commit 7fbd1753b64eafe21cf842348a40a691d0dee440 upstream. In IEC 61883-6, 8 MIDI data streams are multiplexed into single MIDI conformant data channel. The index of stream is calculated by modulo 8 of the value of data block counter. In fireworks, the value of data block counter in CIP header has a quirk with firmware version v5.0.0, v5.7.3 and v5.8.0. This brings ALSA IEC 61883-1/6 packet streaming engine to miss detection of MIDI messages. This commit fixes the miss detection to modify the value of data block counter for the modulo calculation. For maintainers, this bug exists since a commit 18f5ed365d3f (“ALSA: fireworks/firewire-lib: add support for recent firmware quirk”) in Linux kernel v4.2. There’re many changes since the commit. This fix can be backported to Linux kernel v4.4 or later. I tagged a base commit to the backport for your convenience. Besides, my work for Linux kernel v5.3 brings heavy code refactoring and some structure members are renamed in 'sound/firewire/amdtp-stream.h’. The content of this patch brings conflict when merging -rc tree with this patch and the latest tree. I request maintainers to solve the conflict to replace ‘tx_first_dbc’ with 'ctx_data.tx.first_dbc’. Fixes: df075feefbd3 (“ALSA: firewire-lib: complete AM824 data block processing layer”) Cc: # v4.4+ Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ff487e21a8a7121828c01cd005928e1f1407e055 Author: Colin Ian King Date: Fri Jun 28 10:54:29 2019 +0100 ALSA: seq: fix incorrect order of dest_client/dest_ports arguments commit c3ea60c231446663afd6ea1054da6b7f830855ca upstream. There are two occurrances of a call to snd_seq_oss_fill_addr where the dest_client and dest_port arguments are in the wrong order. Fix this by swapping them around. Addresses-Coverity: (“Arguments in wrong order”) Signed-off-by: Colin Ian King Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5e961e899aee3488acc61d895dcc4048190736aa Author: Vincent Whitchurch Date: Tue Jul 2 09:53:25 2019 +0200 crypto: cryptd - Fix skcipher instance memory leak commit 1a0fad630e0b7cff38e7691b28b0517cfbb0633f upstream. cryptd_skcipher_free() fails to free the struct skcipher_instance allocated in cryptd_create_skcipher(), leading to a memory leak. This is detected by kmemleak on bootup on ARM64 platforms: unreferenced object 0xffff80003377b180 (size 1024): comm "cryptomgr_probe", pid 822, jiffies 4294894830 (age 52.760s) backtrace: kmem_cache_alloc_trace+0x270/0x2d0 cryptd_create+0x990/0x124c cryptomgr_probe+0x5c/0x1e8 kthread+0x258/0x318 ret_from_fork+0x10/0x1c Fixes: 4e0958d19bd8 (“crypto: cryptd - Add support for skcipher”) Cc: Signed-off-by: Vincent Whitchurch Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 5781d162ec7de101d7ea41afaf8cf0b741fecb5e Author: Eric Biggers Date: Tue Jul 2 14:17:00 2019 -0700 crypto: user - prevent operating on larval algorithms commit 21d4120ec6f5b5992b01b96ac484701163917b63 upstream. Michal Suchanek reported [1] that running the pcrypt_aead01 test from LTP [2] in a loop and holding Ctrl-C causes a NULL dereference of alg->cra_users.next in crypto_remove_spawns(), via crypto_del_alg(). The test repeatedly uses CRYPTO_MSG_NEWALG and CRYPTO_MSG_DELALG. The crash occurs when the instance that CRYPTO_MSG_DELALG is trying to unregister isn’t a real registered algorithm, but rather is a "test larval", which is a special “algorithm” added to the algorithms list while the real algorithm is still being tested. Larvals don’t have initialized cra_users, so that causes the crash. Normally pcrypt_aead01 doesn’t trigger this because CRYPTO_MSG_NEWALG waits for the algorithm to be tested; however, CRYPTO_MSG_NEWALG returns early when interrupted. Everything else in the “crypto user configuration” API has this same bug too, i.e. it inappropriately allows operating on larval algorithms (though it doesn’t look like the other cases can cause a crash). Fix this by making crypto_alg_match() exclude larval algorithms. [1] https://lkml.kernel.org/r/[email protected] [2] https://github.com/linux-test-project/ltp/blob/20190517/testcases/kernel/crypto/pcrypt_aead01.c Reported-by: Michal Suchanek Fixes: a38f7907b926 (“crypto: Add userspace configuration API”) Cc: # v3.2+ Cc: Steffen Klassert Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 49887fc3f2a7e6185777af3a9c96095aeb2bce1b Author: Jann Horn Date: Thu Jul 4 17:32:23 2019 +0200 ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEME commit 6994eefb0053799d2e07cd140df6c2ea106c41ee upstream. Fix two issues: When called for PTRACE_TRACEME, ptrace_link() would obtain an RCU reference to the parent’s objective credentials, then give that pointer to get_cred(). However, the object lifetime rules for things like struct cred do not permit unconditionally turning an RCU reference into a stable reference. PTRACE_TRACEME records the parent’s credentials as if the parent was acting as the subject, but that’s not the case. If a malicious unprivileged child uses PTRACE_TRACEME and the parent is privileged, and at a later point, the parent process becomes attacker-controlled (because it drops privileges and calls execve()), the attacker ends up with control over two processes with a privileged ptrace relationship, which can be abused to ptrace a suid binary and obtain root privileges. Fix both of these by always recording the credentials of the process that is requesting the creation of the ptrace relationship: current_cred() can’t change under us, and current is the proper subject for access control. This change is theoretically userspace-visible, but I am not aware of any code that it will actually break. Fixes: 64b875f7ac8a (“ptrace: Capture the ptracer’s creds not PT_PTRACE_CAP”) Signed-off-by: Jann Horn Acked-by: Oleg Nesterov Cc: [email protected] Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1c7c91a9a8f39f0ba7b2b6958f259748fa2f3c96 Author: Wei Li Date: Thu Jun 6 11:17:54 2019 +0800 ftrace: Fix NULL pointer dereference in free_ftrace_func_mapper() [ Upstream commit 04e03d9a616c19a47178eaca835358610e63a1dd ] The mapper may be NULL when called from register_ftrace_function_probe() with probe->data == NULL. This issue can be reproduced as follow (it may be covered by compiler optimization sometime): / # cat /sys/kernel/debug/tracing/set_ftrace_filter #### all functions enabled #### / # echo foo_bar:dump > /sys/kernel/debug/tracing/set_ftrace_filter [ 206.949100] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 206.952402] Mem abort info: [ 206.952819] ESR = 0x96000006 [ 206.955326] Exception class = DABT (current EL), IL = 32 bits [ 206.955844] SET = 0, FnV = 0 [ 206.956272] EA = 0, S1PTW = 0 [ 206.956652] Data abort info: [ 206.957320] ISV = 0, ISS = 0x00000006 [ 206.959271] CM = 0, WnR = 0 [ 206.959938] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000419f3a000 [ 206.960483] [0000000000000000] pgd=0000000411a87003, pud=0000000411a83003, pmd=0000000000000000 [ 206.964953] Internal error: Oops: 96000006 [#1] SMP [ 206.971122] Dumping ftrace buffer: [ 206.973677] (ftrace buffer empty) [ 206.975258] Modules linked in: [ 206.976631] Process sh (pid: 281, stack limit = 0x(____ptrval____)) [ 206.978449] CPU: 10 PID: 281 Comm: sh Not tainted 5.2.0-rc1+ #17 [ 206.978955] Hardware name: linux,dummy-virt (DT) [ 206.979883] pstate: 60000005 (nZCv daif -PAN -UAO) [ 206.980499] pc : free_ftrace_func_mapper+0x2c/0x118 [ 206.980874] lr : ftrace_count_free+0x68/0x80 [ 206.982539] sp : ffff0000182f3ab0 [ 206.983102] x29: ffff0000182f3ab0 x28: ffff8003d0ec1700 [ 206.983632] x27: ffff000013054b40 x26: 0000000000000001 [ 206.984000] x25: ffff00001385f000 x24: 0000000000000000 [ 206.984394] x23: ffff000013453000 x22: ffff000013054000 [ 206.984775] x21: 0000000000000000 x20: ffff00001385fe28 [ 206.986575] x19: ffff000013872c30 x18: 0000000000000000 [ 206.987111] x17: 0000000000000000 x16: 0000000000000000 [ 206.987491] x15: ffffffffffffffb0 x14: 0000000000000000 [ 206.987850] x13: 000000000017430e x12: 0000000000000580 [ 206.988251] x11: 0000000000000000 x10: cccccccccccccccc [ 206.988740] x9 : 0000000000000000 x8 : ffff000013917550 [ 206.990198] x7 : ffff000012fac2e8 x6 : ffff000012fac000 [ 206.991008] x5 : ffff0000103da588 x4 : 0000000000000001 [ 206.991395] x3 : 0000000000000001 x2 : ffff000013872a28 [ 206.991771] x1 : 0000000000000000 x0 : 0000000000000000 [ 206.992557] Call trace: [ 206.993101] free_ftrace_func_mapper+0x2c/0x118 [ 206.994827] ftrace_count_free+0x68/0x80 [ 206.995238] release_probe+0xfc/0x1d0 [ 206.995555] register_ftrace_function_probe+0x4a8/0x868 [ 206.995923] ftrace_trace_probe_callback.isra.4+0xb8/0x180 [ 206.996330] ftrace_dump_callback+0x50/0x70 [ 206.996663] ftrace_regex_write.isra.29+0x290/0x3a8 [ 206.997157] ftrace_filter_write+0x44/0x60 [ 206.998971] __vfs_write+0x64/0xf0 [ 206.999285] vfs_write+0x14c/0x2f0 [ 206.999591] ksys_write+0xbc/0x1b0 [ 206.999888] __arm64_sys_write+0x3c/0x58 [ 207.000246] el0_svc_common.constprop.0+0x408/0x5f0 [ 207.000607] el0_svc_handler+0x144/0x1c8 [ 207.000916] el0_svc+0x8/0xc [ 207.003699] Code: aa0003f8 a9025bf5 aa0103f5 f946ea80 (f9400303) [ 207.008388] —[ end trace 7b6d11b5f542bdf1 ]— [ 207.010126] Kernel panic - not syncing: Fatal exception [ 207.011322] SMP: stopping secondary CPUs [ 207.013956] Dumping ftrace buffer: [ 207.014595] (ftrace buffer empty) [ 207.015632] Kernel Offset: disabled [ 207.017187] CPU features: 0x002,20006008 [ 207.017985] Memory Limit: none [ 207.019825] —[ end Kernel panic - not syncing: Fatal exception ]— Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Wei Li Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 77dd6d8ecc2e3bc3ee3d475671d77dc6d84d978b Author: Josh Poimboeuf Date: Thu Jun 13 20:07:22 2019 -0500 module: Fix livepatch/ftrace module text permissions race [ Upstream commit 9f255b632bf12c4dd7fc31caee89aa991ef75176 ] It’s possible for livepatch and ftrace to be toggling a module’s text permissions at the same time, resulting in the following panic: BUG: unable to handle page fault for address: ffffffffc005b1d9 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 3ea0c067 P4D 3ea0c067 PUD 3ea0e067 PMD 3cc13067 PTE 3b8a1061 Oops: 0003 [#1] PREEMPT SMP PTI CPU: 1 PID: 453 Comm: insmod Tainted: G O K 5.2.0-rc1-a188339ca5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-20181126_142135-anatol 04/01/2014 RIP: 0010:apply_relocate_add+0xbe/0x14c Code: fa 0b 74 21 48 83 fa 18 74 38 48 83 fa 0a 75 40 eb 08 48 83 38 00 74 33 eb 53 83 38 00 75 4e 89 08 89 c8 eb 0a 83 38 00 75 43 <89> 08 48 63 c1 48 39 c8 74 2e eb 48 83 38 00 75 32 48 29 c1 89 08 RSP: 0018:ffffb223c00dbb10 EFLAGS: 00010246 RAX: ffffffffc005b1d9 RBX: 0000000000000000 RCX: ffffffff8b200060 RDX: 000000000000000b RSI: 0000004b0000000b RDI: ffff96bdfcd33000 RBP: ffffb223c00dbb38 R08: ffffffffc005d040 R09: ffffffffc005c1f0 R10: ffff96bdfcd33c40 R11: ffff96bdfcd33b80 R12: 0000000000000018 R13: ffffffffc005c1f0 R14: ffffffffc005e708 R15: ffffffff8b2fbc74 FS: 00007f5f447beba8(0000) GS:ffff96bdff900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc005b1d9 CR3: 000000003cedc002 CR4: 0000000000360ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: klp_init_object_loaded+0x10f/0x219 ? preempt_latency_start+0x21/0x57 klp_enable_patch+0x662/0x809 ? virt_to_head_page+0x3a/0x3c ? kfree+0x8c/0x126 patch_init+0x2ed/0x1000 [livepatch_test02] ? 0xffffffffc0060000 do_one_initcall+0x9f/0x1c5 ? kmem_cache_alloc_trace+0xc4/0xd4 ? do_init_module+0x27/0x210 do_init_module+0x5f/0x210 load_module+0x1c41/0x2290 ? fsnotify_path+0x3b/0x42 ? strstarts+0x2b/0x2b ? kernel_read+0x58/0x65 __do_sys_finit_module+0x9f/0xc3 ? __do_sys_finit_module+0x9f/0xc3 __x64_sys_finit_module+0x1a/0x1c do_syscall_64+0x52/0x61 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The above panic occurs when loading two modules at the same time with ftrace enabled, where at least one of the modules is a livepatch module: CPU0 CPU1 klp_enable_patch() klp_init_object_loaded() module_disable_ro() ftrace_module_enable() ftrace_arch_code_modify_post_process() set_all_modules_text_ro() klp_write_object_relocations() apply_relocate_add() *patches read-only code* - BOOM A similar race exists when toggling ftrace while loading a livepatch module. Fix it by ensuring that the livepatch and ftrace code patching operations – and their respective permissions changes – are protected by the text_mutex. Link: http://lkml.kernel.org/r/ab43d56ab909469ac5d2520c5d944ad6d4abd476.1560474114.git.jpoimboe@redhat.com Reported-by: Johannes Erdfelt Fixes: 444d13ff10fb (“modules: add ro_after_init support”) Acked-by: Jessica Yu Reviewed-by: Petr Mladek Reviewed-by: Miroslav Benes Signed-off-by: Josh Poimboeuf Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit b61581d5c2d3236645bf387bc418fe9310661f8b Author: Vasily Gorbik Date: Wed Jun 5 13:11:58 2019 +0200 tracing: avoid build warning with HAVE_NOP_MCOUNT [ Upstream commit cbdaeaf050b730ea02e9ab4ff844ce54d85dbe1d ] Selecting HAVE_NOP_MCOUNT enables -mnop-mcount (if gcc supports it) and sets CC_USING_NOP_MCOUNT. Reuse __is_defined (which is suitable for testing CC_USING_* defines) to avoid conditional compilation and fix the following gcc 9 warning on s390: kernel/trace/ftrace.c:2514:1: warning: ‘ftrace_code_disable’ defined but not used [-Wunused-function] Link: http://lkml.kernel.org/r/patch.git-1a82d13f33ac.your-ad-here.call-01559732716-ext-6629@work.hours Fixes: 2f4df0017baed (“tracing: Add -mcount-nop option support”) Signed-off-by: Vasily Gorbik Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 12006942792bba95db84339ab8cc7a28b525226d Author: swkhack Date: Thu Jun 13 15:56:08 2019 -0700 mm/mlock.c: change count_mm_mlocked_page_nr return type [ Upstream commit 0874bb49bb21bf24deda853e8bf61b8325e24bcb ] On a 64-bit machine the value of “vma->vm_end - vma->vm_start” may be negative when using 32 bit ints and the “count >> PAGE_SHIFT"’s result will be wrong. So change the local variable and return value to unsigned long to fix the problem. Link: http://lkml.kernel.org/r/[email protected] Fixes: 0cf2f6f6dc60 (“mm: mlock: check against vma for actual mlock() size”) Signed-off-by: swkhack Acked-by: Michal Hocko Reviewed-by: Andrew Morton Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 80d567f799c18814c2065df840c74d76ded2fc3c Author: Manuel Traut Date: Thu Jun 13 15:55:52 2019 -0700 scripts/decode_stacktrace.sh: prefix addr2line with $CROSS_COMPILE [ Upstream commit c04e32e911653442fc834be6e92e072aeebe01a1 ] At least for ARM64 kernels compiled with the crosstoolchain from Debian/stretch or with the toolchain from kernel.org the line number is not decoded correctly by 'decode_stacktrace.sh’: $ echo "[ 136.513051] f1+0x0/0xc [kcrash]" | \ CROSS_COMPILE=/opt/gcc-8.1.0-nolibc/aarch64-linux/bin/aarch64-linux- \ ./scripts/decode_stacktrace.sh /scratch/linux-arm64/vmlinux \ /scratch/linux-arm64 \ /nfs/debian/lib/modules/4.20.0-devel [ 136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:68) kcrash If addr2line from the toolchain is used the decoded line number is correct: [ 136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:57) kcrash Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Manuel Traut Acked-by: Konstantin Khlebnikov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8f4b554b089bb1a74191f7becd7d1822586497a8 Author: Joel Savitz Date: Wed Jun 12 11:50:48 2019 -0400 cpuset: restore sanity to cpuset_cpus_allowed_fallback() [ Upstream commit d477f8c202d1f0d4791ab1263ca7657bbe5cf79e ] In the case that a process is constrained by taskset(1) (i.e. sched_setaffinity(2)) to a subset of available cpus, and all of those are subsequently offlined, the scheduler will set tsk->cpus_allowed to the current value of task_cs(tsk)->effective_cpus. This is done via a call to do_set_cpus_allowed() in the context of cpuset_cpus_allowed_fallback() made by the scheduler when this case is detected. This is the only call made to cpuset_cpus_allowed_fallback() in the latest mainline kernel. However, this is not sane behavior. I will demonstrate this on a system running the latest upstream kernel with the following initial configuration: # grep -i cpu /proc/$$/status Cpus_allowed: ffffffff,fffffff Cpus_allowed_list: 0-63 (Where cpus 32-63 are provided via smt.) If we limit our current shell process to cpu2 only and then offline it and reonline it: # taskset -p 4 $$ pid 2272’s current affinity mask: ffffffffffffffff pid 2272’s new affinity mask: 4 # echo off > /sys/devices/system/cpu/cpu2/online # dmesg | tail -3 [ 2195.866089] process 2272 (bash) no longer affine to cpu2 [ 2195.872700] IRQ 114: no longer affine to CPU2 [ 2195.879128] smpboot: CPU 2 is now offline # echo on > /sys/devices/system/cpu/cpu2/online # dmesg | tail -1 [ 2617.043572] smpboot: Booting Node 0 Processor 2 APIC 0x4 We see that our current process now has an affinity mask containing every cpu available on the system _except_ the one we originally constrained it to: # grep -i cpu /proc/$$/status Cpus_allowed: ffffffff,fffffffb Cpus_allowed_list: 0-1,3-63 This is not sane behavior, as the scheduler can now not only place the process on previously forbidden cpus, it can’t even schedule it on the cpu it was originally constrained to! Other cases result in even more exotic affinity masks. Take for instance a process with an affinity mask containing only cpus provided by smt at the moment that smt is toggled, in a configuration such as the following: # taskset -p f000000000 $$ # grep -i cpu /proc/$$/status Cpus_allowed: 000000f0,00000000 Cpus_allowed_list: 36-39 A double toggle of smt results in the following behavior: # echo off > /sys/devices/system/cpu/smt/control # echo on > /sys/devices/system/cpu/smt/control # grep -i cpus /proc/$$/status Cpus_allowed: ffffff00,ffffffff Cpus_allowed_list: 0-31,40-63 This is even less sane than the previous case, as the new affinity mask excludes all smt-provided cpus with ids less than those that were previously in the affinity mask, as well as those that were actually in the mask. With this patch applied, both of these cases end in the following state: # grep -i cpu /proc/$$/status Cpus_allowed: ffffffff,ffffffff Cpus_allowed_list: 0-63 The original policy is discarded. Though not ideal, it is the simplest way to restore sanity to this fallback case without reinventing the cpuset wheel that rolls down the kernel just fine in cgroup v2. A user who wishes for the previous affinity mask to be restored in this fallback case can use that mechanism instead. This patch modifies scheduler behavior by instead resetting the mask to task_cs(tsk)->cpus_allowed by default, and cpu_possible mask in legacy mode. I tested the cases above on both modes. Note that the scheduler uses this fallback mechanism if and only if _every_ other valid avenue has been traveled, and it is the last resort before calling BUG(). Suggested-by: Waiman Long Suggested-by: Phil Auld Signed-off-by: Joel Savitz Acked-by: Phil Auld Acked-by: Waiman Long Acked-by: Peter Zijlstra (Intel) Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit e2beb74acae6e8a036b3b6a2dc28d577e1c07df0 Author: Will Deacon Date: Tue Jun 11 12:47:34 2019 +0100 arm64: tlbflush: Ensure start/end of address range are aligned to stride [ Upstream commit 01d57485fcdb9f9101a10a18e32d5f8b023cab86 ] Since commit 3d65b6bbc01e (“arm64: tlbi: Set MAX_TLBI_OPS to PTRS_PER_PTE”), we resort to per-ASID invalidation when attempting to perform more than PTRS_PER_PTE invalidation instructions in a single call to __flush_tlb_range(). Whilst this is beneficial, the mmu_gather code does not ensure that the end address of the range is rounded-up to the stride when freeing intermediate page tables in pXX_free_tlb(), which defeats our range checking. Align the bounds passed into __flush_tlb_range(). Cc: Catalin Marinas Cc: Peter Zijlstra Reported-by: Hanjun Guo Tested-by: Hanjun Guo Reviewed-by: Hanjun Guo Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 60bc55dea8053f69cf3677adcc7a23f94e4b3c5c Author: Linus Walleij Date: Thu May 30 22:24:24 2019 +0200 i2c: pca-platform: Fix GPIO lookup code [ Upstream commit a0cac264a86fbf4d6cb201fbbb73c1d335e3248a ] The devm_gpiod_request_gpiod() call will add "-gpios” to any passed connection ID before looking it up. I do not think the reset GPIO on this platform is named “reset-gpios-gpios” but rather “reset-gpios” in the device tree, so fix this up so that we get a proper reset GPIO handle. Also drop the inclusion of the legacy GPIO header. Fixes: 0e8ce93bdceb (“i2c: pca-platform: add devicetree awareness”) Signed-off-by: Linus Walleij Reviewed-by: Chris Packham Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 3d76f277b103354de038ab1c5ec2d1d7a9a579d7 Author: Vadim Pasternak Date: Thu May 23 16:41:52 2019 +0000 platform/mellanox: mlxreg-hotplug: Add devm_free_irq call to remove flow [ Upstream commit 8c2eb7b6468ad4aa5600aed01aa0715f921a3f8b ] Add devm_free_irq() call to mlxreg-hotplug remove() for clean release of devices irq resource. Fix debugobjects warning triggered by rmmod It prevents of use-after-free memory, related to mlxreg_hotplug_work_handler. Issue has been reported as debugobjects warning triggered by ‘rmmod mlxtreg-hotplug’ flow, while running kernel with CONFIG_DEBUG_OBJECTS* options. [ 2489.623551] ODEBUG: free active (active state 0) object type: work_struct hint: mlxreg_hotplug_work_handler+0x0/0x7f0 [mlxreg_hotplug] [ 2489.637097] WARNING: CPU: 5 PID: 3924 at lib/debugobjects.c:328 debug_print_object+0xfe/0x180 [ 2489.637165] RIP: 0010:debug_print_object+0xfe/0x180 ? [ 2489.637214] Call Trace: [ 2489.637225] __debug_check_no_obj_freed+0x25e/0x320 [ 2489.637231] kfree+0x82/0x110 [ 2489.637238] release_nodes+0x33c/0x4e0 [ 2489.637242] ? devres_remove_group+0x1b0/0x1b0 [ 2489.637247] device_release_driver_internal+0x146/0x270 [ 2489.637251] driver_detach+0x73/0xe0 [ 2489.637254] bus_remove_driver+0xa1/0x170 [ 2489.637261] __x64_sys_delete_module+0x29e/0x320 [ 2489.637265] ? __ia32_sys_delete_module+0x320/0x320 [ 2489.637268] ? blkcg_exit_queue+0x20/0x20 [ 2489.637273] ? task_work_run+0x7d/0x100 [ 2489.637278] ? exit_to_usermode_loop+0x5b/0xf0 [ 2489.637281] do_syscall_64+0x73/0x160 [ 2489.637287] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 2489.637290] RIP: 0033:0x7f95c3596fd7 The difference in release flow with and with no devm_free_irq is listed below: bus: 'platform’: remove driver mlxreg-hotplug mlxreg_hotplug_remove(start) -> devm_free_irq (with new code) mlxreg_hotplug_remove (end) release_nodes (start) mlxreg-hotplug: DEVRES REL devm_hwmon_release (8 bytes) device: 'hwmon3’: device_unregister PM: Removing info for No Bus:hwmon3 mlxreg-hotplug: DEVRES REL devm_kzalloc_release (88 bytes) mlxreg-hotplug: DEVRES REL devm_kzalloc_release (6 bytes) mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes) mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes) mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes) mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes) mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes) mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes) mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes) mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes) mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes) mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes) mlxreg-hotplug: DEVRES REL devm_irq_release (16 bytes) (no new code) mlxreg-hotplug: DEVRES REL devm_kzalloc_release (1376 bytes) ------------[ cut here ]------------ (no new code): ODEBUG: free active (active state 0) object type: work_struct hint: mlxreg_hotplug_work_handler release_nodes(end) driver: 'mlxreg-hotplug’: driver_release Fixes: 1f976f6978bf (“platform/x86: Move Mellanox platform hotplug driver to platform/mellanox”) Signed-off-by: Vadim Pasternak Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit f3f865f565fa267d8e12decea5903d2fad30e8a9 Author: Vadim Pasternak Date: Wed Jun 5 07:51:03 2019 +0000 platform/x86: mlx-platform: Fix parent device in i2c-mux-reg device registration [ Upstream commit 160da20b254dd4bfc5828f12c208fa831ad4be6c ] Fix the issue found while running kernel with the option CONFIG_DEBUG_TEST_DRIVER_REMOVE. Driver ‘mlx-platform’ registers ‘i2c_mlxcpld’ device and then registers few underlying ‘i2c-mux-reg’ devices: priv->pdev_i2c = platform_device_register_simple("i2c_mlxcpld", nr, NULL, 0); … for (i = 0; i < ARRAY_SIZE(mlxplat_mux_data); i++) { priv->pdev_mux[i] = platform_device_register_resndata( &mlxplat_dev->dev, "i2c-mux-reg", i, NULL, 0, &mlxplat_mux_data[i], sizeof(mlxplat_mux_data[i])); But actual parent of “i2c-mux-reg” device is priv->pdev_i2c->dev and not mlxplat_dev->dev. Patch fixes parent device parameter in a call to platform_device_register_resndata() for "i2c-mux-reg". It solves the race during initialization flow while ‘i2c_mlxcpld.1’ is removing after probe, while ‘i2c-mux-reg.0’ is still in probing flow: ‘i2c_mlxcpld.1’ flow: probe -> remove -> probe. ‘i2c-mux-reg.0’ flow: probe -> … [ 12:621096] Registering platform device 'i2c_mlxcpld.1’. Parent at platform [ 12:621117] device: 'i2c_mlxcpld.1’: device_add [ 12:621155] bus: 'platform’: add device i2c_mlxcpld.1 [ 12:621384] Registering platform device 'i2c-mux-reg.0’. Parent at mlxplat [ 12:621395] device: 'i2c-mux-reg.0’: device_add [ 12:621425] bus: 'platform’: add device i2c-mux-reg.0 [ 12:621806] Registering platform device 'i2c-mux-reg.1’. Parent at mlxplat [ 12:621828] device: 'i2c-mux-reg.1’: device_add [ 12:621892] bus: 'platform’: add device i2c-mux-reg.1 [ 12:621906] bus: 'platform’: add driver i2c_mlxcpld [ 12:621996] bus: 'platform’: driver_probe_device: matched device i2c_mlxcpld.1 with driver i2c_mlxcpld [ 12:622003] bus: 'platform’: really_probe: probing driver i2c_mlxcpld with device i2c_mlxcpld.1 [ 12:622100] i2c_mlxcpld i2c_mlxcpld.1: no default pinctrl state [ 12:622293] device: 'i2c-1’: device_add [ 12:627280] bus: 'i2c’: add device i2c-1 [ 12:627692] device: 'i2c-1’: device_add [ 12.629639] bus: 'platform’: add driver i2c-mux-reg [ 12.629718] bus: 'platform’: driver_probe_device: matched device i2c-mux-reg.0 with driver i2c-mux-reg [ 12.629723] bus: 'platform’: really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.0 [ 12.629818] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state [ 12.629981] platform i2c-mux-reg.0: Driver i2c-mux-reg requests probe deferral [ 12.629986] platform i2c-mux-reg.0: Added to deferred list [ 12.629992] bus: 'platform’: driver_probe_device: matched device i2c-mux-reg.1 with driver i2c-mux-reg [ 12.629997] bus: 'platform’: really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.1 [ 12.630091] i2c-mux-reg i2c-mux-reg.1: no default pinctrl state [ 12.630247] platform i2c-mux-reg.1: Driver i2c-mux-reg requests probe deferral [ 12.630252] platform i2c-mux-reg.1: Added to deferred list [ 12.640892] devices_kset: Moving i2c-mux-reg.0 to end of list [ 12.640900] platform i2c-mux-reg.0: Retrying from deferred list [ 12.640911] bus: 'platform’: driver_probe_device: matched device i2c-mux-reg.0 with driver i2c-mux-reg [ 12.640919] bus: 'platform’: really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.0 [ 12.640999] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state [ 12.641177] platform i2c-mux-reg.0: Driver i2c-mux-reg requests probe deferral [ 12.641187] platform i2c-mux-reg.0: Added to deferred list [ 12.641198] devices_kset: Moving i2c-mux-reg.1 to end of list [ 12.641219] platform i2c-mux-reg.1: Retrying from deferred list [ 12.641237] bus: 'platform’: driver_probe_device: matched device i2c-mux-reg.1 with driver i2c-mux-reg [ 12.641247] bus: 'platform’: really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.1 [ 12.641331] i2c-mux-reg i2c-mux-reg.1: no default pinctrl state [ 12.641465] platform i2c-mux-reg.1: Driver i2c-mux-reg requests probe deferral [ 12.641469] platform i2c-mux-reg.1: Added to deferred list [ 12.646427] device: 'i2c-1’: device_add [ 12.646647] bus: 'i2c’: add device i2c-1 [ 12.647104] device: 'i2c-1’: device_add [ 12.669231] devices_kset: Moving i2c-mux-reg.0 to end of list [ 12.669240] platform i2c-mux-reg.0: Retrying from deferred list [ 12.669258] bus: 'platform’: driver_probe_device: matched device i2c-mux-reg.0 with driver i2c-mux-reg [ 12.669263] bus: 'platform’: really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.0 [ 12.669343] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state [ 12.669585] device: 'i2c-2’: device_add [ 12.669795] bus: 'i2c’: add device i2c-2 [ 12.670201] device: 'i2c-2’: device_add [ 12.671427] i2c i2c-1: Added multiplexed i2c bus 2 [ 12.671514] device: 'i2c-3’: device_add [ 12.671724] bus: 'i2c’: add device i2c-3 [ 12.672136] device: 'i2c-3’: device_add [ 12.673378] i2c i2c-1: Added multiplexed i2c bus 3 [ 12.673472] device: 'i2c-4’: device_add [ 12.673676] bus: 'i2c’: add device i2c-4 [ 12.674060] device: 'i2c-4’: device_add [ 12.675861] i2c i2c-1: Added multiplexed i2c bus 4 [ 12.675941] device: 'i2c-5’: device_add [ 12.676150] bus: 'i2c’: add device i2c-5 [ 12.676550] device: 'i2c-5’: device_add [ 12.678103] i2c i2c-1: Added multiplexed i2c bus 5 [ 12.678193] device: 'i2c-6’: device_add [ 12.678395] bus: 'i2c’: add device i2c-6 [ 12.678774] device: 'i2c-6’: device_add [ 12.679969] i2c i2c-1: Added multiplexed i2c bus 6 [ 12.680065] device: 'i2c-7’: device_add [ 12.680275] bus: 'i2c’: add device i2c-7 [ 12.680913] device: 'i2c-7’: device_add [ 12.682506] i2c i2c-1: Added multiplexed i2c bus 7 [ 12.682600] device: 'i2c-8’: device_add [ 12.682808] bus: 'i2c’: add device i2c-8 [ 12.683189] device: 'i2c-8’: device_add [ 12.683907] device: 'i2c-1’: device_unregister [ 12.683945] device: 'i2c-1’: device_unregister [ 12.684387] device: 'i2c-1’: device_create_release [ 12.684536] bus: 'i2c’: remove device i2c-1 [ 12.686019] i2c i2c-8: Failed to create compatibility class link [ 12.686086] ------------[ cut here ]------------ [ 12.686087] can’t create symlink to mux device [ 12.686224] Workqueue: events deferred_probe_work_func [ 12.686135] WARNING: CPU: 7 PID: 436 at drivers/i2c/i2c-mux.c:416 i2c_mux_add_adapter+0x729/0x7d0 [i2c_mux] [ 12.686232] RIP: 0010:i2c_mux_add_adapter+0x729/0x7d0 [i2c_mux] [ 0x190/0x190 [i2c_mux] [ 12.686300] ? i2c_mux_alloc+0xac/0x110 [i2c_mux] [ 12.686306] ? i2c_mux_reg_set+0x200/0x200 [i2c_mux_reg] [ 12.686313] i2c_mux_reg_probe+0x22c/0x731 [i2c_mux_reg] [ 12.686322] ? i2c_mux_reg_deselect+0x60/0x60 [i2c_mux_reg] [ 12.686346] platform_drv_probe+0xa8/0x110 [ 12.686351] really_probe+0x185/0x720 [ 12.686358] driver_probe_device+0xdf/0x1f0 … [ 12.686522] i2c i2c-1: Added multiplexed i2c bus 8 [ 12.686621] device: 'i2c-9’: device_add [ 12.686626] kobject_add_internal failed for i2c-9 (error: -2 parent: i2c-1) [ 12.694729] i2c-core: adapter 'i2c-1-mux (chan_id 8)': can’t register device (-2) [ 12.705726] i2c i2c-1: failed to add mux-adapter 8 as bus 9 (error=-2) [ 12.714494] device: 'i2c-8’: device_unregister [ 12.714537] device: 'i2c-8’: device_unregister Fixes: 6613d18e9038 (“platform/x86: mlx-platform: Move module from arch/x86”) Signed-off-by: Vadim Pasternak Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit b551985b981f3a1e0ca17374eba340d9df2d79a3 Author: Mathew King Date: Mon May 20 16:41:24 2019 -0600 platform/x86: intel-vbtn: Report switch events when event wakes device [ Upstream commit cb1921b17adbe6509538098ac431033378cd7165 ] When a switch event, such as tablet mode/laptop mode or docked/undocked, wakes a device make sure that the value of the swich is reported. Without when a device is put in tablet mode from laptop mode when it is suspended or vice versa the device will wake up but mode will be incorrect. Tested by suspending a device in laptop mode and putting it in tablet mode, the device resumes and is in tablet mode. When suspending the device in tablet mode and putting it in laptop mode the device resumes and is in laptop mode. Signed-off-by: Mathew King Reviewed-by: Jett Rink Reviewed-by: Mario Limonciello Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit f1585ebaee71e67e8f46d6d640df9d00fb0c4b70 Author: Hans de Goede Date: Wed Jun 12 09:02:02 2019 +0200 platform/x86: asus-wmi: Only Tell EC the OS will handle display hotkeys from asus_nb_wmi [ Upstream commit 401fee8195d401b2b94dee57383f627050724d5b ] Commit 78f3ac76d9e5 (“platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey”) causes the backlight to be permanently off on various EeePC laptop models using the eeepc-wmi driver (Asus EeePC 1015BX, Asus EeePC 1025C). The asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL) call added by that commit is made conditional in this commit and only enabled in the quirk_entry structs in the asus-nb-wmi driver fixing the broken display / backlight on various EeePC laptop models. Cc: João Paulo Rechi Vita Fixes: 78f3ac76d9e5 (“platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey”) Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit c2784e57271e415bca7b6ae8caedb87ad27724a8 Author: Alex Levin Date: Fri Jun 7 15:19:11 2019 -0700 ASoC: Intel: sst: fix kmalloc call with wrong flags [ Upstream commit 3da428ff2aa5a5191ba2f1630eea75f03242f3f2 ] When calling kmalloc with GFP_KERNEL in case CONFIG_SLOB is unset, kmem_cache_alloc_trace is called. In case CONFIG_TRACING is set, kmem_cache_alloc_trace will ball slab_alloc, which will call slab_pre_alloc_hook which might_sleep_if. The context in which it is called in this case, the intel_sst_interrupt_mrfld, calling a sleeping kmalloc generates a BUG(): Fixes: 972b0d456e64 (“ASoC: Intel: remove GFP_ATOMIC, use GFP_KERNEL”) [ 20.250671] BUG: sleeping function called from invalid context at mm/slab.h:422 [ 20.250683] in_atomic(): 1, irqs_disabled(): 1, pid: 1791, name: Chrome_IOThread [ 20.250690] CPU: 0 PID: 1791 Comm: Chrome_IOThread Tainted: G W 4.19.43 #61 [ 20.250693] Hardware name: GOOGLE Kefka, BIOS Google_Kefka.7287.337.0 03/02/2017 [ 20.250697] Call Trace: [ 20.250704] [ 20.250716] dump_stack+0x7e/0xc3 [ 20.250725] ___might_sleep+0x12a/0x140 [ 20.250731] kmem_cache_alloc_trace+0x53/0x1c5 [ 20.250736] ? update_cfs_rq_load_avg+0x17e/0x1aa [ 20.250740] ? cpu_load_update+0x6c/0xc2 [ 20.250746] sst_create_ipc_msg+0x2d/0x88 [ 20.250752] intel_sst_interrupt_mrfld+0x12a/0x22c [ 20.250758] __handle_irq_event_percpu+0x133/0x228 [ 20.250764] handle_irq_event_percpu+0x35/0x7a [ 20.250768] handle_irq_event+0x36/0x55 [ 20.250773] handle_fasteoi_irq+0xab/0x16c [ 20.250779] handle_irq+0xd9/0x11e [ 20.250785] do_IRQ+0x54/0xe0 [ 20.250791] common_interrupt+0xf/0xf [ 20.250795] [ 20.250800] RIP: 0010:__lru_cache_add+0x4e/0xad [ 20.250806] Code: 00 01 48 c7 c7 b8 df 01 00 65 48 03 3c 25 28 f1 00 00 48 8b 48 08 48 89 ca 48 ff ca f6 c1 01 48 0f 44 d0 f0 ff 42 34 0f b6 0f <89> ca fe c2 88 17 48 89 44 cf 08 80 fa 0f 74 0e 48 8b 08 66 85 c9 [ 20.250809] RSP: 0000:ffffa568810bfd98 EFLAGS: 00000202 ORIG_RAX: ffffffffffffffd6 [ 20.250814] RAX: ffffd3b904eb1940 RBX: ffffd3b904eb1940 RCX: 0000000000000004 [ 20.250817] RDX: ffffd3b904eb1940 RSI: ffffa10ee5c47450 RDI: ffffa10efba1dfb8 [ 20.250821] RBP: ffffa568810bfda8 R08: ffffa10ef9c741c1 R09: dead000000000100 [ 20.250824] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa10ee8d52a40 [ 20.250827] R13: ffffa10ee8d52000 R14: ffffa10ee5c47450 R15: 800000013ac65067 [ 20.250835] lru_cache_add_active_or_unevictable+0x4e/0xb8 [ 20.250841] handle_mm_fault+0xd98/0x10c4 [ 20.250848] __do_page_fault+0x235/0x42d [ 20.250853] ? page_fault+0x8/0x30 [ 20.250858] do_page_fault+0x3d/0x17a [ 20.250862] ? page_fault+0x8/0x30 [ 20.250866] page_fault+0x1e/0x30 [ 20.250872] RIP: 0033:0x7962fdea9304 [ 20.250875] Code: 0f 11 4c 17 f0 c3 48 3b 15 f1 26 31 00 0f 83 e2 00 00 00 48 39 f7 72 0f 74 12 4c 8d 0c 16 4c 39 cf 0f 82 63 01 00 00 48 89 d1 a4 c3 80 fa 08 73 12 80 fa 04 73 1e 80 fa 01 77 26 72 05 0f b6 [ 20.250879] RSP: 002b:00007962f4db5468 EFLAGS: 00010206 [ 20.250883] RAX: 00003c8cc9d47008 RBX: 0000000000000000 RCX: 0000000000001b48 [ 20.250886] RDX: 0000000000002b40 RSI: 00003c8cc9551000 RDI: 00003c8cc9d48000 [ 20.250890] RBP: 00007962f4db5820 R08: 0000000000000000 R09: 00003c8cc9552b48 [ 20.250893] R10: 0000562dd1064d30 R11: 00003c8cc825b908 R12: 00003c8cc966d3c0 [ 20.250896] R13: 00003c8cc9e280c0 R14: 0000000000000000 R15: 0000000000000000 Signed-off-by: Alex Levin Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c7e65a33d75d5aafcf18d9cf84786bc4436a0ba5 Author: Ranjani Sridharan Date: Fri Jun 7 22:07:06 2019 -0700 ASoC: core: Fix deadlock in snd_soc_instantiate_card() [ Upstream commit 495f926c68ddb905a7a0192963096138c6a934e1 ] Move the client_mutex lock to snd_soc_unbind_card() before removing link components. This prevents the deadlock in the error path in snd_soc_instantiate_card(). Fixes: 34ac3c3eb8 (ASoC: core: lock client_mutex while removing link components) Reported-by: kernelci.org bot Signed-off-by: Ranjani Sridharan Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0a1c42cf2a9a0f799bc834f9c15156d28a6c6089 Author: Hans de Goede Date: Fri May 24 14:57:59 2019 +0200 drm: panel-orientation-quirks: Add quirk for GPD MicroPC [ Upstream commit 652b8b086538c8a10de5aa5cbdaef79333b46358 ] GPD has done it again, make a nice device (good), use way too generic DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly). Because of the too generic DMI strings this entry is also doing bios-date matching, so the gpd_micropc data struct may very well need to be updated with some extra bios-dates in the future. Acked-by: Maxime Ripard Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit f2f2bb60d998abde10de7e483ef9e17639892450) Signed-off-by: Sasha Levin commit eabfa988ceec0ff630f04b4669b30018a7dad300 Author: Hans de Goede Date: Fri May 24 14:57:58 2019 +0200 drm: panel-orientation-quirks: Add quirk for GPD pocket2 [ Upstream commit 15abc7110a77555d3bf72aaef46d1557db0a4ac5 ] GPD has done it again, make a nice device (good), use way too generic DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly). Because of the too generic DMI strings this entry is also doing bios-date matching, so the gpd_pocket2 data struct may very well need to be updated with some extra bios-dates in the future. Changes in v2: -Add one more known BIOS date to the list of BIOS dates Cc: Jurgen Kramer Reported-by: Jurgen Kramer Acked-by: Maxime Ripard Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 6dab9102dd7b144e5723915438e0d6c473018cd0) Signed-off-by: Sasha Levin commit ebae5c66fa67cfd5cdd5c7ef8f76cdf08a4391e3 Author: H. Nikolaus Schaller Date: Tue Jun 4 14:35:58 2019 +0200 gpio: pca953x: hack to fix 24 bit gpio expanders [ Upstream commit 3b00691cc46a4089368a008b30655a8343411715 ] 24 bit expanders use REG_ADDR_AI in combination with register addressing. This conflicts with regmap which takes this bit as part of the register number, i.e. a second cache entry is defined for accessed with REG_ADDR_AI being set although on the chip it is the same register as with REG_ADDR_AI being cleared. The problem was introduced by commit b32cecb46bdc (“gpio: pca953x: Extract the register address mangling to single function”) but only became visible by commit 8b9f9d4dc511 (“regmap: verify if register is writeable before writing operations”) because before, the regmap size was effectively ignored and pca953x_writeable_register() did know to ignore REG_ADDR_AI. Still, there were two separate cache entries created. Since the use of REG_ADDR_AI seems to be static we can work around this issue by simply increasing the size of the regmap to cover the “virtual” registers with REG_ADDR_AI being set. This only means that half of the regmap buffer will be unused. Reported-by: H. Nikolaus Schaller Suggested-by: Linus Walleij Signed-off-by: H. Nikolaus Schaller Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f55e3e088fcf989411d8bceb9969e8e1daaaf0aa Author: Don Brace Date: Mon Jun 3 16:43:29 2019 -0500 scsi: hpsa: correct ioaccel2 chaining [ Upstream commit 625d7d3518875c4d303c652a198feaa13d9f52d9 ] - set ioaccel2_sg_element member ‘chain_indicator’ to IOACCEL2_LAST_SG for the last s/g element. - set ioaccel2_sg_element member ‘chain_indicator’ to IOACCEL2_CHAIN when chaining. Reviewed-by: Bader Ali - Saleh Reviewed-by: Scott Teel Reviewed-by: Matt Perricone Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b6cb887f36a1d06e0f3e139188bacc80ef02f126 Author: Amadeusz Sławiński Date: Wed Jun 5 15:45:52 2019 +0200 SoC: rt274: Fix internal jack assignment in set_jack callback [ Upstream commit 04268bf2757a125616b6c2140e6250f43b7b737a ] When we call snd_soc_component_set_jack(component, NULL, NULL) we should set rt274->jack to passed jack, so when interrupt is triggered it calls snd_soc_jack_report(rt274->jack, …) with proper value. This fixes problem in machine where in register, we call snd_soc_register(component, &headset, NULL), which just calls rt274_mic_detect via callback. Now when machine driver is removed “headset” will be gone, so we need to tell codec driver that it’s gone with: snd_soc_register(component, NULL, NULL), but we also need to be able to handle NULL jack argument here gracefully. If we don’t set it to NULL, next time the rt274_irq runs it will call snd_soc_jack_report with first argument being invalid pointer and there will be Oops. Signed-off-by: Amadeusz Sławiński Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 69b418b02a6c5defcc08d5529a253c30bbdb6ac3 Author: Amadeusz Sławiński Date: Wed May 22 11:21:41 2019 -0500 ALSA: hdac: fix memory release for SST and SOF drivers [ Upstream commit 6d647b736a6b1cbf2f8deab0e6a94c34a6ea9d60 ] During the integration of HDaudio support, we changed the way in which we get hdev in snd_hdac_ext_bus_device_init() to use one preallocated with devm_kzalloc(), however it still left kfree(hdev) in snd_hdac_ext_bus_device_exit(). It leads to oopses when trying to rmmod and modprobe. Fix it, by just removing kfree call. SOF also uses some of the snd_hdac_ functions for HDAudio support but allocated the memory with kzalloc. A matching fix is provided separately to align all users of the snd_hdac_ library. Fixes: 6298542fa33b (“ALSA: hdac: remove memory allocation from snd_hdac_ext_bus_device_init”) Reviewed-by: Takashi Iwai Signed-off-by: Amadeusz Sławiński Signed-off-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1f0b3bbaeb896123a0742c13940e3ae3a720645f Author: Tzung-Bi Shih Date: Tue Jun 4 11:31:02 2019 +0800 ASoC: core: move DAI pre-links initiation to snd_soc_instantiate_card [ Upstream commit 70fc53734e71ce51f46dfcfd1a1c319e1cfe080c ] Kernel crashes when an ASoC component rebinding. The dai_link->platforms has been reset to NULL by soc_cleanup_platform() in soc_cleanup_card_resources() when un-registering component. However, it has no chance to re-allocate the dai_link->platforms when registering the component again. Move the DAI pre-links initiation from snd_soc_register_card() to snd_soc_instantiate_card() to make sure all DAI pre-links get initiated when component rebinding. As an example, by using the following commands: - echo -n max98357a > /sys/bus/platform/drivers/max98357a/unbind - echo -n max98357a > /sys/bus/platform/drivers/max98357a/bind Got the error message: "Unable to handle kernel NULL pointer dereference at virtual address". The call trace: snd_soc_is_matching_component+0x30/0x6c soc_bind_dai_link+0x16c/0x240 snd_soc_bind_card+0x1e4/0xb10 snd_soc_add_component+0x270/0x300 snd_soc_register_component+0x54/0x6c Signed-off-by: Tzung-Bi Shih Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 54f49e2211274fb24778387dbabeaa768125b8cc Author: Pierre-Louis Bossart Date: Tue Jun 4 15:08:58 2019 -0500 ASoC: Intel: cht_bsw_rt5672: fix kernel oops with platform_name override [ Upstream commit 9bbc799318a34061703f2a980e2b6df7fc6760f0 ] The platform override code uses devm_ functions to allocate memory for the new name but the card device is not initialized. Fix by moving the init earlier. Fixes: f403906da05cd (“ASoC: Intel: cht_bsw_rt5672: platform name fixup support”) Signed-off-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1cdfe1888cc28e4c441782e11b0828abed79bbdd Author: Pierre-Louis Bossart Date: Tue Jun 4 15:08:57 2019 -0500 ASoC: Intel: cht_bsw_nau8824: fix kernel oops with platform_name override [ Upstream commit 096701e8131425044d2054a0c210d6ea24ee7386 ] The platform override code uses devm_ functions to allocate memory for the new name but the card device is not initialized. Fix by moving the init earlier. Fixes: 4506db8043341 (“ASoC: Intel: cht_bsw_nau8824: platform name fixup support”) Signed-off-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6eee5b3490c26b1ecfe82af4127bfcf11d87fd76 Author: Pierre-Louis Bossart Date: Tue Jun 4 15:08:56 2019 -0500 ASoC: Intel: bytcht_es8316: fix kernel oops with platform_name override [ Upstream commit 79136a016add1acb690fe8d96be50dd22a143d26 ] The platform override code uses devm_ functions to allocate memory for the new name but the card device is not initialized. Fix by moving the init earlier. Fixes: e4bc6b1195f64 (“ASoC: Intel: bytcht_es8316: platform name fixup support”) Signed-off-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 11c8ff977b23425a8986d5d77db5ab2a0d14dedd Author: Pierre-Louis Bossart Date: Tue Jun 4 15:08:55 2019 -0500 ASoC: Intel: cht_bsw_max98090: fix kernel oops with platform_name override [ Upstream commit fb54555134b9b17835545e4d096b5550c27eed64 ] The platform override code uses devm_ functions to allocate memory for the new name but the card device is not initialized. Fix by moving the init earlier. Fixes: 7e7e24d7c7ff0 (“ASoC: Intel: cht_bsw_max98090_ti: platform name fixup support”) Signed-off-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f5c842ff25bc11750ab7a4f4d36d285ad62f630d Author: Andrzej Pietrasiewicz Date: Mon Apr 1 12:50:45 2019 +0200 usb: gadget: dwc2: fix zlp handling [ Upstream commit 066cfd0770aba8a9ac79b59d99530653885d919d ] The patch 10209abe87f5ebfd482a00323f5236d6094d0865 usb: dwc2: gadget: Add scatter-gather mode avoided a NULL pointer dereference (hs_ep->req == NULL) by calling dwc2_gadget_fill_nonisoc_xfer_dma_one() directly instead of through the dwc2_gadget_config_nonisoc_xfer_ddma() wrapper, which unconditionally dereferenced the said pointer. However, this was based on an incorrect assumption that in the context of dwc2_hsotg_program_zlp() the pointer is always NULL, which is not the case. The result were SB CV MSC tests failing starting from Test Case 6. Instead, this patch reverts to calling the wrapper and adds a check for the pointer being NULL inside the wrapper. Fixes: 10209abe87f5 (usb: dwc2: gadget: Add scatter-gather mode) Acked-by: Minas Harutyunyan Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 3b302f77201262bfb26e01ee31f35e2effd8f33d Author: Alexandre Belloni Date: Wed May 22 14:07:36 2019 +0200 usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMIC [ Upstream commit fbc318afadd6e7ae2252d6158cf7d0c5a2132f7d ] Gadget drivers may queue request in interrupt context. This would lead to a descriptor allocation in that context. In that case we would hit BUG_ON(in_interrupt()) in __get_vm_area_node. Also remove the unnecessary cast. Acked-by: Sylvain Lemieux Tested-by: James Grant Signed-off-by: Alexandre Belloni Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit ea1fb51b49a05137c73b397dbaa038a5f7e5c4c8 Author: Young Xiao [email protected] Date: Tue May 28 20:17:54 2019 +0800 usb: gadget: fusb300_udc: Fix memory leak of fusb300->ep[i] [ Upstream commit 62fd0e0a24abeebe2c19fce49dd5716d9b62042d ] There is no deallocation of fusb300->ep[i] elements, allocated at fusb300_probe. The patch adds deallocation of fusb300->ep array elements. Signed-off-by: Young Xiao [email protected] Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit a795fdcd8e1c079c67513314b95ad632cae296ad Author: Kan Liang Date: Mon Jun 3 06:41:20 2019 -0700 x86/CPU: Add more Icelake model numbers [ Upstream commit e35faeb64146f2015f2aec14b358ae508e4066db ] Add the CPUID model numbers of Icelake (ICL) desktop and server processors to the Intel family list. [ Qiuxu: Sort the macros by model number. ] Signed-off-by: Kan Liang Signed-off-by: Borislav Petkov Cc: “H. Peter Anvin” Cc: Andy Shevchenko Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Qiuxu Zhuo Cc: Rajneesh Bhardwaj Cc: [email protected] Cc: Thomas Gleixner Cc: Tony Luck Cc: x86-ml Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin commit c9e39461f2bccf144dad17332668151022a65963 Author: Marcus Cooper Date: Mon Jun 3 19:47:28 2019 +0200 ASoC: sun4i-i2s: Add offset to RX channel select [ Upstream commit f9927000cb35f250051f0f1878db12ee2626eea1 ] Whilst testing the capture functionality of the i2s on the newer SoCs it was noticed that the recording was somewhat distorted. This was due to the offset not being set correctly on the receiver side. Signed-off-by: Marcus Cooper Acked-by: Maxime Ripard Acked-by: Chen-Yu Tsai Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bba440b1c8119f17c5518748e1724b3c430b207d Author: Marcus Cooper Date: Mon Jun 3 19:47:27 2019 +0200 ASoC: sun4i-i2s: Fix sun8i tx channel offset mask [ Upstream commit 7e46169a5f35762f335898a75d1b8a242f2ae0f5 ] Although not causing any noticeable issues, the mask for the channel offset is covering too many bits. Signed-off-by: Marcus Cooper Acked-by: Maxime Ripard Acked-by: Chen-Yu Tsai Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5db5be87f74e2cb0aeddff3c9212bba1a2b17974 Author: Yu-Hsuan Hsu Date: Tue Jun 4 18:49:09 2019 +0800 ASoC: max98090: remove 24-bit format support if RJ is 0 [ Upstream commit 5628c8979642a076f91ee86c3bae5ad251639af0 ] The supported formats are S16_LE and S24_LE now. However, by datasheet of max98090, S24_LE is only supported when it is in the right justified mode. We should remove 24-bit format if it is not in that mode to avoid triggering error. Signed-off-by: Yu-Hsuan Hsu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 52d006fa3e35a341d38a2226372cb4af896229ca Author: Hsin-Yi Wang Date: Thu May 30 17:18:47 2019 +0800 drm/mediatek: call mtk_dsi_stop() after mtk_drm_crtc_atomic_disable() [ Upstream commit 2458d9d6d94be982b917e93c61a89b4426f32e31 ] mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which needs ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called, ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called after last irq, it will timeout with this message: "vblank wait timed out on crtc 0". This happens sometimes when turning off the screen. In drm_atomic_helper.c#disable_outputs(), the calling sequence when turning off the screen is: 1. mtk_dsi_encoder_disable() --> mtk_output_dsi_disable() --> mtk_dsi_stop(); /* sometimes make vblank timeout in atomic_disable */ --> mtk_dsi_poweroff(); 2. mtk_drm_crtc_atomic_disable() --> drm_crtc_wait_one_vblank(); … --> mtk_dsi_ddp_stop() --> mtk_dsi_poweroff(); mtk_dsi_poweroff() has reference count design, change to make mtk_dsi_stop() called in mtk_dsi_poweroff() when refcount is 0. Fixes: 0707632b5bac (“drm/mediatek: update DSI sub driver flow for sending commands to panel”) Signed-off-by: Hsin-Yi Wang Signed-off-by: CK Hu Signed-off-by: Sasha Levin commit 7dd1a64b8f8ca8c5aea66c92d7f35fbd2181b22f Author: Hsin-Yi Wang Date: Wed May 29 18:25:55 2019 +0800 drm/mediatek: clear num_pipes when unbind driver [ Upstream commit a4cd1d2b016d5d043ab2c4b9c4ec50a5805f5396 ] num_pipes is used for mutex created in mtk_drm_crtc_create(). If we don’t clear num_pipes count, when rebinding driver, the count will be accumulated. From mtk_disp_mutex_get(), there can only be at most 10 mutex id. Clear this number so it starts from 0 in every rebind. Fixes: 119f5173628a (“drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.”) Signed-off-by: Hsin-Yi Wang Signed-off-by: CK Hu Signed-off-by: Sasha Levin commit 815c6c19890fa962865e9fcec81917f43936d4c0 Author: Hsin-Yi Wang Date: Wed May 29 18:25:54 2019 +0800 drm/mediatek: call drm_atomic_helper_shutdown() when unbinding driver [ Upstream commit cf49b24ffa62766f8f04cd1c4cf17b75d29b240a ] shutdown all CRTC when unbinding drm driver. Fixes: 119f5173628a (“drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.”) Signed-off-by: Hsin-Yi Wang Signed-off-by: CK Hu Signed-off-by: Sasha Levin commit e059430742dba6ef80ebf8bea9b070a1891536bd Author: Hsin-Yi Wang Date: Wed May 29 18:25:53 2019 +0800 drm/mediatek: unbind components in mtk_drm_unbind() [ Upstream commit f0fd848342802bc0f74620d387eead53e8905804 ] Unbinding components (i.e. mtk_dsi and mtk_disp_ovl/rdma/color) will trigger master(mtk_drm)'s .unbind(), and currently mtk_drm’s unbind won’t actually unbind components. During the next bind, mtk_drm_kms_init() is called, and the components are added back. .unbind() should call mtk_drm_kms_deinit() to unbind components. And since component_master_del() in .remove() will trigger .unbind(), which will also unregister device, it’s fine to remove original functions called here. Fixes: 119f5173628a (“drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.”) Signed-off-by: Hsin-Yi Wang Signed-off-by: CK Hu Signed-off-by: Sasha Levin commit 57d304784345db77090c08ac6fa8d70ee1969b68 Author: Hsin-Yi Wang Date: Wed May 29 18:25:52 2019 +0800 drm/mediatek: fix unbind functions [ Upstream commit 8fd7a37b191f93737f6280a9b5de65f98acc12c9 ] detatch panel in mtk_dsi_destroy_conn_enc(), since .bind will try to attach it again. Fixes: 2e54c14e310f (“drm/mediatek: Add DSI sub driver”) Signed-off-by: Hsin-Yi Wang Signed-off-by: CK Hu Signed-off-by: Sasha Levin commit 48f2ed69e872adfbd93205b3c61fa88fe9054acf Author: Ranjani Sridharan Date: Fri May 31 09:01:37 2019 -0700 ASoC: hda: fix unbalanced codec dev refcount for HDA_DEV_ASOC [ Upstream commit d6947bb234dcc86e878d502516d0fb9d635aa2ae ] HDA_DEV_ASOC type codec device refcounts are managed differently from HDA_DEV_LEGACY devices. The refcount is released explicitly in snd_hdac_ext_bus_device_remove() for ASOC type devices. So, remove the put_device() call in snd_hda_codec_dev_free() for such devices to make the refcount balanced. This will prevent the NULL pointer exception when the codec driver is released after the card is freed. Signed-off-by: Ranjani Sridharan Reviewed-by: Takashi Iwai Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 052fd24a902693f48cfa38ad677463d48a6a4d00 Author: Kovács Tamás Date: Fri May 31 19:22:26 2019 +0200 ASoC: Intel: Baytrail: add quirk for Aegex 10 (RU2) tablet [ Upstream commit 3e951e7914408aee196db77a5cb377801c85692a ] This tablet has an incorrect acpi identifier just like Thinkpad10 tablet, which is why it is trying to load the RT5640 driver instead of the RT5762 driver. The RT5640 driver, on the other hand, checks the hardware ID, so no driver are loaded during boot. This fix resolves to load the RT5672 driver on this tablet during boot. It also provides the correct IO configuration, like the jack detect mode 3, for 1.8V pullup. I would like to thank Pierre-Louis Bossart for helping with this patch. Signed-off-by: Kovács Tamás Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 260381edbe3e1fefb23c794ed5e84bed0573563e Author: Błażej Szczygieł Date: Sun May 12 22:33:13 2019 +0200 HID: a4tech: fix horizontal scrolling [ Upstream commit abf82e8f7e9af40a49e3d905187c662a43c96c8f ] Since recent high resolution scrolling changes the A4Tech driver must check for the “REL_WHEEL_HI_RES” usage code. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203369 Fixes: 2dc702c991e3774af9d7ce410eef410ca9e2357e (“HID: input: use the Resolution Multiplier for high-resolution scrolling”) Signed-off-by: Błażej Szczygieł Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 7ae68002b53d42c61781f6f10ee735b5a41001b8 Author: Lu Baolu Date: Tue May 21 15:30:16 2019 +0800 iommu/vt-d: Set the right field for Page Walk Snoop [ Upstream commit 66d78ad316b0e1ca5ae19663468554e2c0e31c26 ] Set the page walk snoop to the right bit, otherwise the domain id field will be overlapped. Reported-by: Dave Jiang Fixes: 6f7db75e1c469 (“iommu/vt-d: Add second level page table interface”) Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit cd3d34cf030cf5f7352a079e38748271fd647142 Author: Ranjani Sridharan Date: Thu May 23 10:12:01 2019 -0700 ASoC: core: lock client_mutex while removing link components [ Upstream commit 34ac3c3eb8f0c07252ceddf0a22dd240e5c91ccb ] Removing link components results in topology unloading. So, acquire the client_mutex before removing components in soc_remove_link_components. This will prevent the lockdep warning seen when dai links are removed during topology removal. Signed-off-by: Ranjani Sridharan Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 451fd3b3d5db0bc1733e5b6b6c8fa4297fc26ce5 Author: YueHaibing Date: Thu May 16 15:56:56 2019 +0800 spi: bitbang: Fix NULL pointer dereference in spi_unregister_master [ Upstream commit 5caaf29af5ca82d5da8bc1d0ad07d9e664ccf1d8 ] If spi_register_master fails in spi_bitbang_start because device_add failure, We should return the error code other than 0, otherwise calling spi_bitbang_stop may trigger NULL pointer dereference like this: BUG: KASAN: null-ptr-deref in __list_del_entry_valid+0x45/0xd0 Read of size 8 at addr 0000000000000000 by task syz-executor.0/3661 CPU: 0 PID: 3661 Comm: syz-executor.0 Not tainted 5.1.0+ #28 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: dump_stack+0xa9/0x10e ? __list_del_entry_valid+0x45/0xd0 ? __list_del_entry_valid+0x45/0xd0 __kasan_report+0x171/0x18d ? __list_del_entry_valid+0x45/0xd0 kasan_report+0xe/0x20 __list_del_entry_valid+0x45/0xd0 spi_unregister_controller+0x99/0x1b0 spi_lm70llp_attach+0x3ae/0x4b0 [spi_lm70llp] ? 0xffffffffc1128000 ? klist_next+0x131/0x1e0 ? driver_detach+0x40/0x40 [parport] port_check+0x3b/0x50 [parport] bus_for_each_dev+0x115/0x180 ? subsys_dev_iter_exit+0x20/0x20 __parport_register_driver+0x1f0/0x210 [parport] ? 0xffffffffc1150000 do_one_initcall+0xb9/0x3b5 ? perf_trace_initcall_level+0x270/0x270 ? kasan_unpoison_shadow+0x30/0x40 ? kasan_unpoison_shadow+0x30/0x40 do_init_module+0xe0/0x330 load_module+0x38eb/0x4270 ? module_frob_arch_sections+0x20/0x20 ? kernel_read_file+0x188/0x3f0 ? find_held_lock+0x6d/0xd0 ? fput_many+0x1a/0xe0 ? __do_sys_finit_module+0x162/0x190 __do_sys_finit_module+0x162/0x190 ? __ia32_sys_init_module+0x40/0x40 ? __mutex_unlock_slowpath+0xb4/0x3f0 ? wait_for_completion+0x240/0x240 ? vfs_write+0x160/0x2a0 ? lockdep_hardirqs_off+0xb5/0x100 ? mark_held_locks+0x1a/0x90 ? do_syscall_64+0x14/0x2a0 do_syscall_64+0x72/0x2a0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Reported-by: Hulk Robot Fixes: 702a4879ec33 (“spi: bitbang: Let spi_bitbang_start() take a reference to master”) Signed-off-by: YueHaibing Reviewed-by: Geert Uytterhoeven Reviewed-by: Axel Lin Reviewed-by: Mukesh Ojha Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit be273895afd33f9f962627d3012b6248e602f24a Author: Viorel Suman Date: Mon May 13 10:02:42 2019 +0000 ASoC: ak4458: rstn_control - return a non-zero on error only [ Upstream commit 176a11834b65ec35e3b7a953f87fb9cc41309497 ] snd_soc_component_update_bits() may return 1 if operation was successful and the value of the register changed. Return a non-zero in ak4458_rstn_control for an error only. Signed-off-by: Shengjiu Wang Signed-off-by: Viorel Suman Reviewed-by: Daniel Baluta Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cb83b683c7908992ba8afbbd1de36086d4662bbe Author: Libin Yang Date: Wed May 8 10:32:41 2019 +0800 ASoC: soc-pcm: BE dai needs prepare when pause release after resume [ Upstream commit 5087a8f17df868601cd7568299e91c28086d2b45 ] If playback/capture is paused and system enters S3, after system returns from suspend, BE dai needs to call prepare() callback when playback/capture is released from pause if RESUME_INFO flag is not set. Currently, the dpcm_be_dai_prepare() function will block calling prepare() if the pcm is in SND_SOC_DPCM_STATE_PAUSED state. This will cause the following test case fail if the pcm uses BE: playback -> pause -> S3 suspend -> S3 resume -> pause release The playback may exit abnormally when pause is released because the BE dai prepare() is not called. This patch allows dpcm_be_dai_prepare() to call dai prepare() callback in SND_SOC_DPCM_STATE_PAUSED state. Signed-off-by: Libin Yang Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 99c155e8b03bd08e91370a094dd6e5072bc8f783 Author: Viorel Suman Date: Thu May 9 13:30:36 2019 +0000 ASoC: ak4458: add return value for ak4458_probe [ Upstream commit a8dee20d792432740509237943700fbcfc230bad ] AK4458 is probed successfully even if AK4458 is not present - this is caused by probe function returning no error on i2c access failure. Return an error on probe if i2c access has failed. Signed-off-by: Shengjiu Wang Signed-off-by: Viorel Suman Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 635bd38a42948728a63c198671fa99548b9f7f42 Author: Matt Flax Date: Wed May 8 16:33:13 2019 +1000 ASoC : cs4265 : readable register too low [ Upstream commit f3df05c805983427319eddc2411a2105ee1757cf ] The cs4265_readable_register function stopped short of the maximum register. An example bug is taken from : https://github.com/Audio-Injector/Ultra/issues/25 Where alsactl store fails with : Cannot read control '2,0,0,C Data Buffer,0’: Input/output error This patch fixes the bug by setting the cs4265 to have readable registers up to the maximum hardware register CS4265_MAX_REGISTER. Signed-off-by: Matt Flax Reviewed-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e3d95782b5baa91cb10240cd9e238bf516fbaea2 Author: Kai-Heng Feng Date: Mon Apr 22 14:57:04 2019 +0800 HID: i2c-hid: add iBall Aer3 to descriptor override [ Upstream commit eb6964fa6509b4f1152313f1e0bb67f0c54a6046 ] This device uses the SIPODEV SP1064 touchpad, which does not supply descriptors, so it has to be added to the override list. BugLink: https://bugs.launchpad.net/bugs/1825718 Signed-off-by: Kai-Heng Feng Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit c6e2eab05915e56767198b688c020b9b8f6d35ca Author: Matthew Wilcox (Oracle) Date: Tue May 14 16:05:45 2019 -0400 idr: Fix idr_get_next race with idr_remove commit 5c089fd0c73411f2170ab795c9ffc16718c7d007 upstream. If the entry is deleted from the IDR between the call to radix_tree_iter_find() and rcu_dereference_raw(), idr_get_next() will return NULL, which will end the iteration prematurely. We should instead continue to the next entry in the IDR. This only happens if the iteration is protected by the RCU lock. Most IDR users use a spinlock or semaphore to exclude simultaneous modifications. It was noticed once the PID allocator was converted to use the IDR, as it uses the RCU lock, but there may be other users elsewhere in the kernel. We can’t use the normal pattern of calling radix_tree_deref_retry() (which catches both a retry entry in a leaf node and a node entry in the root) as the IDR supports storing entries which are unaligned, which will trigger an infinite loop if they are encountered. Instead, we have to explicitly check whether the entry is a retry entry. Fixes: 0a835c4f090a (“Reimplement IDR and IDA using the radix tree”) Reported-by: Brendan Gregg Tested-by: Brendan Gregg Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Greg Kroah-Hartman commit dec05569d399ba85268fa50a0562b7920e228fca Author: Florian Westphal Date: Tue May 21 13:24:33 2019 +0200 netfilter: nft_flow_offload: IPCB is only valid for ipv4 family commit 69aeb538587e087bfc81dd1f465eab3558ff3158 upstream. Guard this with a check vs. ipv4, IPCB isn’t valid in ipv6 case. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit f771e171f12958e095fa3e32820749bffb5a7502 Author: Florian Westphal Date: Tue May 21 13:24:32 2019 +0200 netfilter: nft_flow_offload: don’t offload when sequence numbers need adjustment commit 91a9048f238063dde7feea752b9dd386f7e3808b upstream. We can’t deal with tcp sequence number rewrite in flow_offload. While at it, simplify helper check, we only need to know if the extension is present, we don’t need the helper data. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit c2f7a528c3d925d0292e474998d2daf8649f287c Author: Florian Westphal Date: Tue May 21 13:24:31 2019 +0200 netfilter: nft_flow_offload: set liberal tracking mode for tcp commit 8437a6209f76f85a2db1abb12a9bde2170801617 upstream. Without it, whenever a packet has to be pushed up the stack (e.g. because of mtu mismatch), then conntrack will flag packets as invalid, which in turn breaks NAT. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit fa84c445fba40500c4154ce7ba5476099558e6b2 Author: Florian Westphal Date: Tue May 21 13:24:30 2019 +0200 netfilter: nf_flow_table: ignore DF bit setting commit e75b3e1c9bc5b997d09bdf8eb72ab3dd3c1a7072 upstream. Its irrelevant if the DF bit is set or not, we must pass packet to stack in either case. If the DF bit is set, we must pass it to stack so the appropriate ICMP error can be generated. If the DF is not set, we must pass it to stack for fragmentation. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 50c5095a4db998c8c268c3edead147bb4857d4b9 Author: Oleg Nesterov Date: Fri Jun 28 12:06:50 2019 -0700 signal: remove the wrong signal_pending() check in restore_user_sigmask() commit 97abc889ee296faf95ca0e978340fb7b942a3e32 upstream. This is the minimal fix for stable, I’ll send cleanups later. Commit 854a6ed56839 ("signal: Add restore_user_sigmask()") introduced the visible change which breaks user-space: a signal temporary unblocked by set_user_sigmask() can be delivered even if the caller returns success or timeout. Change restore_user_sigmask() to accept the additional “interrupted” argument which should be used instead of signal_pending() check, and update the callers. Eric said: : For clarity. I don’t think this is required by posix, or fundamentally to : remove the races in select. It is what linux has always done and we have : applications who care so I agree this fix is needed. : : Further in any case where the semantic change that this patch rolls back : (aka where allowing a signal to be delivered and the select like call to : complete) would be advantage we can do as well if not better by using : signalfd. : : Michael is there any chance we can get this guarantee of the linux : implementation of pselect and friends clearly documented. The guarantee : that if the system call completes successfully we are guaranteed that no : signal that is unblocked by using sigmask will be delivered? Link: http://lkml.kernel.org/r/[email protected] Fixes: 854a6ed56839a40f6b5d02a2962f48841482eec4 ("signal: Add restore_user_sigmask()") Signed-off-by: Oleg Nesterov Reported-by: Eric Wong Tested-by: Eric Wong Acked-by: “Eric W. Biederman” Acked-by: Arnd Bergmann Acked-by: Deepa Dinamani Cc: Michael Kerrisk Cc: Jens Axboe Cc: Davidlohr Bueso Cc: Jason Baron Cc: Thomas Gleixner Cc: Al Viro Cc: David Laight Cc: [5.0+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 382abb7e21fb7f14f48b75a9553d434c28010688 Author: Matias Karhumaa Date: Tue Jul 2 16:35:09 2019 +0200 Bluetooth: Fix faulty expression for minimum encryption key size check commit eca94432934fe5f141d084f2e36ee2c0e614cc04 upstream. Fix minimum encryption key size check so that HCI_MIN_ENC_KEY_SIZE is also allowed as stated in the comment. This bug caused connection problems with devices having maximum encryption key size of 7 octets (56-bit). Fixes: 693cd8ce3f88 (“Bluetooth: Fix regression with minimum encryption key size alignment”) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203997 Signed-off-by: Matias Karhumaa Cc: [email protected] Signed-off-by: Marcel Holtmann Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman