Update 5.10.x+fslc up to v5.10.52 #400
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
commit 81f2023 upstream. Commit d1f0441 ("certs: Add ability to preload revocation certs") created a new generated file for revocation certs, but didn't tell git to ignore it. Thus causing unnecessary "git status" noise after a kernel build with CONFIG_SYSTEM_REVOCATION_LIST enabled. Add the proper gitignore magic. Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 507345b upstream. When there is no cached DFS referral of tcon->dfs_path, then reconnect to same share. Signed-off-by: Paulo Alcantara (SUSE) <[email protected]> Cc: <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…ed_mmio commit 23fa2e4 upstream. BUG: KASAN: use-after-free in kvm_vm_ioctl_unregister_coalesced_mmio+0x7c/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:183 Read of size 8 at addr ffff0000c03a2500 by task syz-executor083/4269 CPU: 5 PID: 4269 Comm: syz-executor083 Not tainted 5.10.0 Freescale#7 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x2d0 arch/arm64/kernel/stacktrace.c:132 show_stack+0x28/0x34 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x110/0x164 lib/dump_stack.c:118 print_address_description+0x78/0x5c8 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [inline] kasan_report+0x148/0x1e4 mm/kasan/report.c:562 check_memory_region_inline mm/kasan/generic.c:183 [inline] __asan_load8+0xb4/0xbc mm/kasan/generic.c:252 kvm_vm_ioctl_unregister_coalesced_mmio+0x7c/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:183 kvm_vm_ioctl+0xe30/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3755 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall arch/arm64/kernel/syscall.c:48 [inline] el0_svc_common arch/arm64/kernel/syscall.c:158 [inline] do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:220 el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367 el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383 el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670 Allocated by task 4269: stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121 kasan_save_stack mm/kasan/common.c:48 [inline] kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc+0xdc/0x120 mm/kasan/common.c:461 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:475 kmem_cache_alloc_trace include/linux/slab.h:450 [inline] kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:664 [inline] kvm_vm_ioctl_register_coalesced_mmio+0x78/0x1cc arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:146 kvm_vm_ioctl+0x7e8/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3746 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall arch/arm64/kernel/syscall.c:48 [inline] el0_svc_common arch/arm64/kernel/syscall.c:158 [inline] do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:220 el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367 el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383 el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670 Freed by task 4269: stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121 kasan_save_stack mm/kasan/common.c:48 [inline] kasan_set_track+0x38/0x6c mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:355 __kasan_slab_free+0x124/0x150 mm/kasan/common.c:422 kasan_slab_free+0x10/0x1c mm/kasan/common.c:431 slab_free_hook mm/slub.c:1544 [inline] slab_free_freelist_hook mm/slub.c:1577 [inline] slab_free mm/slub.c:3142 [inline] kfree+0x104/0x38c mm/slub.c:4124 coalesced_mmio_destructor+0x94/0xa4 arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:102 kvm_iodevice_destructor include/kvm/iodev.h:61 [inline] kvm_io_bus_unregister_dev+0x248/0x280 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:4374 kvm_vm_ioctl_unregister_coalesced_mmio+0x158/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:186 kvm_vm_ioctl+0xe30/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3755 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall arch/arm64/kernel/syscall.c:48 [inline] el0_svc_common arch/arm64/kernel/syscall.c:158 [inline] do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:220 el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367 el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383 el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670 If kvm_io_bus_unregister_dev() return -ENOMEM, we already call kvm_iodevice_destructor() inside this function to delete 'struct kvm_coalesced_mmio_dev *dev' from list and free the dev, but kvm_iodevice_destructor() is called again, it will lead the above issue. Let's check the the return value of kvm_io_bus_unregister_dev(), only call kvm_iodevice_destructor() if the return value is 0. Cc: Paolo Bonzini <[email protected]> Cc: [email protected] Reported-by: Hulk Robot <[email protected]> Signed-off-by: Kefeng Wang <[email protected]> Message-Id: <[email protected]> Cc: [email protected] Fixes: 5d3c4c7 ("KVM: Stop looking for coalesced MMIO zones if the bus is destroyed", 2021-04-20) Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 4bf48e3 upstream. Ignore the guest MAXPHYADDR reported by CPUID.0x8000_0008 if TDP, i.e. NPT, is disabled, and instead use the host's MAXPHYADDR. Per AMD'S APM: Maximum guest physical address size in bits. This number applies only to guests using nested paging. When this field is zero, refer to the PhysAddrSize field for the maximum guest physical address size. Fixes: 24c82e5 ("KVM: Sanitize cpuid") Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit fc9bf2e upstream. Ignore "dynamic" host adjustments to the physical address mask when generating the masks for guest PTEs, i.e. the guest PA masks. The host physical address space and guest physical address space are two different beasts, e.g. even though SEV's C-bit is the same bit location for both host and guest, disabling SME in the host (which clears shadow_me_mask) does not affect the guest PTE->GPA "translation". For non-SEV guests, not dropping bits is the correct behavior. Assuming KVM and userspace correctly enumerate/configure guest MAXPHYADDR, bits that are lost as collateral damage from memory encryption are treated as reserved bits, i.e. KVM will never get to the point where it attempts to generate a gfn using the affected bits. And if userspace wants to create a bogus vCPU, then userspace gets to deal with the fallout of hardware doing odd things with bad GPAs. For SEV guests, not dropping the C-bit is technically wrong, but it's a moot point because KVM can't read SEV guest's page tables in any case since they're always encrypted. Not to mention that the current KVM code is also broken since sme_me_mask does not have to be non-zero for SEV to be supported by KVM. The proper fix would be to teach all of KVM to correctly handle guest private memory, but that's a task for the future. Fixes: d0ec49d ("kvm/x86/svm: Support Secure Memory Encryption within KVM") Cc: [email protected] Cc: Brijesh Singh <[email protected]> Cc: Tom Lendacky <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> [Use a new header instead of adding header guards to paging_tmpl.h. - Paolo] Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit fce7e15 upstream. APM states that #GP is raised upon write to MSR_VM_HSAVE_PA when the supplied address is not page-aligned or is outside of "maximum supported physical address for this implementation". page_address_valid() check seems suitable. Also, forcefully page-align the address when it's written from VMM. Signed-off-by: Vitaly Kuznetsov <[email protected]> Message-Id: <[email protected]> Cc: [email protected] Reviewed-by: Maxim Levitsky <[email protected]> [Add comment about behavior for host-provided values. - Paolo] Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…->run() commit f85d401 upstream. When the host is using debug registers but the guest is not using them nor is the guest in guest-debug state, the kvm code does not reset the host debug registers before kvm_x86->run(). Rather, it relies on the hardware vmentry instruction to automatically reset the dr7 registers which ensures that the host breakpoints do not affect the guest. This however violates the non-instrumentable nature around VM entry and exit; for example, when a host breakpoint is set on vcpu->arch.cr2, Another issue is consistency. When the guest debug registers are active, the host breakpoints are reset before kvm_x86->run(). But when the guest debug registers are inactive, the host breakpoints are delayed to be disabled. The host tracing tools may see different results depending on what the guest is doing. To fix the problems, we clear %db7 unconditionally before kvm_x86->run() if the host has set any breakpoints, no matter if the guest is using them or not. Signed-off-by: Lai Jiangshan <[email protected]> Message-Id: <[email protected]> Cc: [email protected] [Only clear %db7 instead of reloading all debug registers. - Paolo] Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 93aa71a upstream. Commit 66a834d ("scsi: core: Fix error handling of scsi_host_alloc()") changed the allocation logic to call put_device() to perform host cleanup with the assumption that IDA removal and stopping the kthread would properly be performed in scsi_host_dev_release(). However, in the unlikely case that the error handler thread fails to spawn, shost->ehandler is set to ERR_PTR(-ENOMEM). The error handler cleanup code in scsi_host_dev_release() will call kthread_stop() if shost->ehandler != NULL which will always be the case whether the kthread was successfully spawned or not. In the case that it failed to spawn this has the nasty side effect of trying to dereference an invalid pointer when kthread_stop() is called. The following splat provides an example of this behavior in the wild: scsi host11: error handler thread failed to spawn, error = -4 Kernel attempted to read user page (10c) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x0000010c Faulting instruction address: 0xc00000000818e9a8 Oops: Kernel access of bad area, sig: 11 [Freescale#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: ibmvscsi(+) scsi_transport_srp dm_multipath dm_mirror dm_region hash dm_log dm_mod fuse overlay squashfs loop CPU: 12 PID: 274 Comm: systemd-udevd Not tainted 5.13.0-rc7 Freescale#1 NIP: c00000000818e9a8 LR: c0000000089846e8 CTR: 0000000000007ee8 REGS: c000000037d12ea0 TRAP: 0300 Not tainted (5.13.0-rc7) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28228228 XER: 20040001 CFAR: c0000000089846e4 DAR: 000000000000010c DSISR: 40000000 IRQMASK: 0 GPR00: c0000000089846e8 c000000037d13140 c000000009cc1100 fffffffffffffffc GPR04: 0000000000000001 0000000000000000 0000000000000000 c000000037dc0000 GPR08: 0000000000000000 c000000037dc0000 0000000000000001 00000000fffff7ff GPR12: 0000000000008000 c00000000a049000 c000000037d13d00 000000011134d5a0 GPR16: 0000000000001740 c0080000190d0000 c0080000190d1740 c000000009129288 GPR20: c000000037d13bc0 0000000000000001 c000000037d13bc0 c0080000190b7898 GPR24: c0080000190b7708 0000000000000000 c000000033bb2c48 0000000000000000 GPR28: c000000046b28280 0000000000000000 000000000000010c fffffffffffffffc NIP [c00000000818e9a8] kthread_stop+0x38/0x230 LR [c0000000089846e8] scsi_host_dev_release+0x98/0x160 Call Trace: [c000000033bb2c48] 0xc000000033bb2c48 (unreliable) [c0000000089846e8] scsi_host_dev_release+0x98/0x160 [c00000000891e960] device_release+0x60/0x100 [c0000000087e55c4] kobject_release+0x84/0x210 [c00000000891ec78] put_device+0x28/0x40 [c000000008984ea4] scsi_host_alloc+0x314/0x430 [c0080000190b38bc] ibmvscsi_probe+0x54/0xad0 [ibmvscsi] [c000000008110104] vio_bus_probe+0xa4/0x4b0 [c00000000892a860] really_probe+0x140/0x680 [c00000000892aefc] driver_probe_device+0x15c/0x200 [c00000000892b63c] device_driver_attach+0xcc/0xe0 [c00000000892b740] __driver_attach+0xf0/0x200 [c000000008926f28] bus_for_each_dev+0xa8/0x130 [c000000008929ce4] driver_attach+0x34/0x50 [c000000008928fc0] bus_add_driver+0x1b0/0x300 [c00000000892c798] driver_register+0x98/0x1a0 [c00000000810eb60] __vio_register_driver+0x80/0xe0 [c0080000190b4a30] ibmvscsi_module_init+0x9c/0xdc [ibmvscsi] [c0000000080121d0] do_one_initcall+0x60/0x2d0 [c000000008261abc] do_init_module+0x7c/0x320 [c000000008265700] load_module+0x2350/0x25b0 [c000000008265cb4] __do_sys_finit_module+0xd4/0x160 [c000000008031110] system_call_exception+0x150/0x2d0 [c00000000800d35c] system_call_common+0xec/0x278 Fix this be nulling shost->ehandler when the kthread fails to spawn. Link: https://lore.kernel.org/r/[email protected] Fixes: 66a834d ("scsi: core: Fix error handling of scsi_host_alloc()") Cc: [email protected] Reviewed-by: Ming Lei <[email protected]> Signed-off-by: Tyrel Datwyler <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…ble pull commit 8b3bdd9 upstream. On remote cable pull, a zfcp_port keeps its status and only gets ZFCP_STATUS_PORT_LINK_TEST added. Only after an ADISC timeout, we would actually start port recovery and remove ZFCP_STATUS_COMMON_UNBLOCKED which zfcp_sysfs_port_fc_security_show() detected and reported as "unknown" instead of the old and possibly stale zfcp_port->connection_info. Add check for ZFCP_STATUS_PORT_LINK_TEST for timely "unknown" report. Link: https://lore.kernel.org/r/[email protected] Fixes: a17c784 ("scsi: zfcp: report FC Endpoint Security in sysfs") Cc: <[email protected]> Freescale#5.7+ Reviewed-by: Benjamin Block <[email protected]> Signed-off-by: Steffen Maier <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 704adfb upstream. The histogram logic was allowing events with char * pointers to be used as normal strings. But it was easy to crash the kernel with: # echo 'hist:keys=filename' > events/syscalls/sys_enter_openat/trigger And open some files, and boom! BUG: unable to handle page fault for address: 00007f2ced0c3280 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1173fa067 P4D 1173fa067 PUD 1171b6067 PMD 1171dd067 PTE 0 Oops: 0000 [Freescale#1] PREEMPT SMP CPU: 6 PID: 1810 Comm: cat Not tainted 5.13.0-rc5-test+ Freescale#61 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:strlen+0x0/0x20 Code: f6 82 80 2a 0b a9 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2a 0b a9 20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 RSP: 0018:ffffbdbf81567b50 EFLAGS: 00010246 RAX: 0000000000000003 RBX: ffff93815cdb3800 RCX: ffff9382401a22d0 RDX: 0000000000000100 RSI: 0000000000000000 RDI: 00007f2ced0c3280 RBP: 0000000000000100 R08: ffff9382409ff074 R09: ffffbdbf81567c98 R10: ffff9382409ff074 R11: 0000000000000000 R12: ffff9382409ff074 R13: 0000000000000001 R14: ffff93815a744f00 R15: 00007f2ced0c3280 FS: 00007f2ced0f8580(0000) GS:ffff93825a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2ced0c3280 CR3: 0000000107069005 CR4: 00000000001706e0 Call Trace: event_hist_trigger+0x463/0x5f0 ? find_held_lock+0x32/0x90 ? sched_clock_cpu+0xe/0xd0 ? lock_release+0x155/0x440 ? kernel_init_free_pages+0x6d/0x90 ? preempt_count_sub+0x9b/0xd0 ? kernel_init_free_pages+0x6d/0x90 ? get_page_from_freelist+0x12c4/0x1680 ? __rb_reserve_next+0xe5/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 event_triggers_call+0x52/0xe0 ftrace_syscall_enter+0x264/0x2c0 syscall_trace_enter.constprop.0+0x1ee/0x210 do_syscall_64+0x1c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Where it triggered a fault on strlen(key) where key was the filename. The reason is that filename is a char * to user space, and the histogram code just blindly dereferenced it, with obvious bad results. I originally tried to use strncpy_from_user/kernel_nofault() but found that there's other places that its dereferenced and not worth the effort. Just do not allow "char *" to act like strings. Link: https://lkml.kernel.org/r/[email protected] Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Tzvetomir Stoyanov <[email protected]> Cc: [email protected] Acked-by: Namhyung Kim <[email protected]> Acked-by: Tom Zanussi <[email protected]> Fixes: 79e577c ("tracing: Support string type key properly") Fixes: 5967bd5 ("tracing: Let filter_assign_type() detect FILTER_PTR_STRING") Signed-off-by: Steven Rostedt (VMware) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 0abb33b upstream. We skip filling out the pt with scratch entries if the va range covers the entire pt, since we later have to fill it with the PTEs for the object pages anyway. However this might leave open a small window where the PTEs don't point to anything valid for the HW to consume. When for example using 2M GTT pages this fill_px() showed up as being quite significant in perf measurements, and ends up being completely wasted since we ignore the pt and just use the pde directly. Anyway, currently we have our PTE construction split between alloc and insert, which is probably slightly iffy nowadays, since the alloc doesn't actually allocate anything anymore, instead it just sets up the page directories and points the PTEs at the scratch page. Later when we do the insert step we re-program the PTEs again. Better might be to squash the alloc and insert into a single step, then bringing back this optimisation(along with some others) should be possible. Fixes: 1482667 ("drm/i915: Only initialize partially filled pagetables") Signed-off-by: Matthew Auld <[email protected]> Cc: Jon Bloomfield <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: <[email protected]> # v4.15+ Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 8f88ca7) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 2feeb52 upstream. The conversion to ww mutexes failed to address the fence code which already returns -EDEADLK when we run out of fences. Ww mutexes on the other hand treat -EDEADLK as an internal errno value indicating a need to restart the operation due to a deadlock. So now when the fence code returns -EDEADLK the higher level code erroneously restarts everything instead of returning the error to userspace as is expected. To remedy this let's switch the fence code to use a different errno value for this. -ENOBUFS seems like a semi-reasonable unique choice. Apart from igt the only user of this I could find is sna, and even there all we do is dump the current fence registers from debugfs into the X server log. So no user visible functionality is affected. If we really cared about preserving this we could of course convert back to -EDEADLK higher up, but doesn't seem like that's worth the hassle here. Not quite sure which commit specifically broke this, but I'll just attribute it to the general gem ww mutex work. Cc: [email protected] Cc: Maarten Lankhorst <[email protected]> Cc: Thomas Hellström <[email protected]> Testcase: igt/gem_pread/exhaustion Testcase: igt/gem_pwrite/basic-exhaustion Testcase: igt/gem_fenced_exec_thrash/too-many-fences Fixes: 80f0b67 ("drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]> (cherry picked from commit 78d2ad7) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 3b04627 upstream. The following sequence can be used to trigger a UAF: int fscontext_fd = fsopen("cgroup"); int fd_null = open("/dev/null, O_RDONLY); int fsconfig(fscontext_fd, FSCONFIG_SET_FD, "source", fd_null); close_range(3, ~0U, 0); The cgroup v1 specific fs parser expects a string for the "source" parameter. However, it is perfectly legitimate to e.g. specify a file descriptor for the "source" parameter. The fs parser doesn't know what a filesystem allows there. So it's a bug to assume that "source" is always of type fs_value_is_string when it can reasonably also be fs_value_is_file. This assumption in the cgroup code causes a UAF because struct fs_parameter uses a union for the actual value. Access to that union is guarded by the param->type member. Since the cgroup paramter parser didn't check param->type but unconditionally moved param->string into fc->source a close on the fscontext_fd would trigger a UAF during put_fs_context() which frees fc->source thereby freeing the file stashed in param->file causing a UAF during a close of the fd_null. Fix this by verifying that param->type is actually a string and report an error if not. In follow up patches I'll add a new generic helper that can be used here and by other filesystems instead of this error-prone copy-pasta fix. But fixing it in here first makes backporting a it to stable a lot easier. Fixes: 8d2451f ("cgroup1: switch to option-by-option parsing") Reported-by: [email protected] Cc: Christoph Hellwig <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: <[email protected]> Cc: syzkaller-bugs <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 0af7782 upstream. The execution of fb_delete_videomode() is not based on the result of the previous fbcon_mode_deleted(). As a result, the mode is directly deleted, regardless of whether it is still in use, which may cause UAF. ================================================================== BUG: KASAN: use-after-free in fb_mode_is_equal+0x36e/0x5e0 \ drivers/video/fbdev/core/modedb.c:924 Read of size 4 at addr ffff88807e0ddb1c by task syz-executor.0/18962 CPU: 2 PID: 18962 Comm: syz-executor.0 Not tainted 5.10.45-rc1+ Freescale#3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ... Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x137/0x1be lib/dump_stack.c:118 print_address_description+0x6c/0x640 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [inline] kasan_report+0x13d/0x1e0 mm/kasan/report.c:562 fb_mode_is_equal+0x36e/0x5e0 drivers/video/fbdev/core/modedb.c:924 fbcon_mode_deleted+0x16a/0x220 drivers/video/fbdev/core/fbcon.c:2746 fb_set_var+0x1e1/0xdb0 drivers/video/fbdev/core/fbmem.c:975 do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 18960: kasan_save_stack mm/kasan/common.c:48 [inline] kasan_set_track+0x3d/0x70 mm/kasan/common.c:56 kasan_set_free_info+0x17/0x30 mm/kasan/generic.c:355 __kasan_slab_free+0x108/0x140 mm/kasan/common.c:422 slab_free_hook mm/slub.c:1541 [inline] slab_free_freelist_hook+0xd6/0x1a0 mm/slub.c:1574 slab_free mm/slub.c:3139 [inline] kfree+0xca/0x3d0 mm/slub.c:4121 fb_delete_videomode+0x56a/0x820 drivers/video/fbdev/core/modedb.c:1104 fb_set_var+0x1f3/0xdb0 drivers/video/fbdev/core/fbmem.c:978 do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 13ff178 ("fbcon: Call fbcon_mode_deleted/new_modelist directly") Signed-off-by: Zhen Lei <[email protected]> Cc: <[email protected]> # v5.3+ Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 35d3e8c upstream. [Why] When we receive CSN message to notify one port is disconnected, we will implicitly set its corresponding num_slots to 0. Later on, we will eventually call drm_dp_update_payload_part1() to arrange down streams. In drm_dp_update_payload_part1(), we iterate over all proposed_vcpis[] to do the update. Not specific to a target sink only. For example, if we light up 2 monitors, Monitor_A and Monitor_B, and then we unplug Monitor_B. Later on, when we call drm_dp_update_payload_part1() to try to update payload for Monitor_A, we'll also implicitly clean payload for Monitor_B at the same time. And finally, when we try to call drm_dp_update_payload_part1() to clean payload for Monitor_B, we will do nothing at this time since payload for Monitor_B has been cleaned up previously. For StarTech 1to3 DP hub, it seems like if we didn't update DPCD payload ID table then polling for "ACT Handled"(BIT_1 of DPCD 002C0h) will fail and this polling will last for 3 seconds. Therefore, guess the best way is we don't set the proposed_vcpi[] diretly. Let user of these herlper functions to set the proposed_vcpi directly. [How] 1. Revert commit 7617e96 ("drm/dp_mst: clear time slots for ports invalid") 2. Tackle the issue in previous commit by skipping those trasient proposed VCPIs. These stale VCPIs shoulde be explicitly cleared by user later on. Changes since v1: * Change debug macro to use drm_dbg_kms() instead * Amend the commit message to add Fixed & Cc tags Signed-off-by: Wayne Lin <[email protected]> Fixes: 7617e96 ("drm/dp_mst: clear time slots for ports invalid") Cc: Lyude Paul <[email protected]> Cc: Wayne Lin <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: [email protected] Cc: <[email protected]> # v5.5+ Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 3769e4c upstream. [Why] After unplug/hotplug hub from the system, userspace might start to clear stale payloads gradually. If we call drm_dp_mst_deallocate_vcpi() to release stale VCPI of those ports which are not relating to current topology, we have chane to wrongly clear active payload table entry for current topology. E.g. We have allocated VCPI 1 in current payload table and we call drm_dp_mst_deallocate_vcpi() to clean VCPI 1 in stale topology. In drm_dp_mst_deallocate_vcpi(), it will call drm_dp_mst_put_payload_id() tp put VCPI 1 and which means ID 1 is available again. Thereafter, if we want to allocate a new payload stream, it will find ID 1 is available by drm_dp_mst_assign_payload_id(). However, ID 1 is being used [How] Check target sink is relating to current topology or not before doing any payload table update. Searching upward to find the target sink's relevant root branch device. If the found root branch device is not the same root of current topology, don't update payload table. Changes since v1: * Change debug macro to use drm_dbg_kms() instead * Amend the commit message to add Cc tag. Signed-off-by: Wayne Lin <[email protected]> Cc: [email protected] Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…dbg_kms() commit 24ff3dc upstream. Commit 3769e4c ("drm/dp_mst: Avoid to mess up payload table by ports in stale topology") added to calls to drm_dbg_kms() but it missed the first parameter, the drm device breaking the build. Fixes: 3769e4c ("drm/dp_mst: Avoid to mess up payload table by ports in stale topology") Cc: Wayne Lin <[email protected]> Cc: Lyude Paul <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: José Roberto de Souza <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 7b49576 upstream. Even though the JZ4740 did not have the OSD mode, it had (according to the documentation) two DMA channels, but there is absolutely no information about how to select the second DMA channel. Make the ingenic-drm driver work in non-OSD mode by using the foreground0 plane (which is bound to the DMA0 channel) as the primary plane, instead of the foreground1 plane, which is the primary plane when in OSD mode. Fixes: 3c9bea4 ("drm/ingenic: Add support for OSD mode") Cc: <[email protected]> # v5.8+ Signed-off-by: Paul Cercueil <[email protected]> Acked-by: Daniel Vetter <[email protected]> Tested-by: H. Nikolaus Schaller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 68b433f upstream. It should have been an OVERLAY from the beginning. The documentation stipulates that there should be an unique PRIMARY plane per CRTC. Fixes: fc1acf3 ("drm/ingenic: Add support for the IPU") Cc: <[email protected]> # 5.8+ Signed-off-by: Paul Cercueil <[email protected]> Acked-by: Simon Ser <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
This reverts commit fcb041c which is commit 0ecb518 upstream. Turns out this was incomplete, as it is missing a dependancy, so drop it from the tree. Link: https://lore.kernel.org/r/CAJn8CcHHKSo7GF29Z1ufXJJpMUzn6+fdvwiqe9=JvgpcfvnbHQ@mail.gmail.com Reported-by: Xiaotian Feng <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Michael J. Ruhl <[email protected]> Cc: KuoHsiang Chou <[email protected]> Cc: kernel test robot <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Dave Airlie <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 04bef83 upstream. When a PIM hello packet is received on a bridge port with multicast snooping enabled, we mark it as a router port automatically, that includes adding that port the router port list. The multicast lock protects that list, but it is not acquired in the PIM message case leading to a race condition, we need to take it to fix the race. Cc: [email protected] Fixes: 91b02d3 ("bridge: mcast: add router port on PIM hello message") Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 000b728 upstream. When an MRD advertisement is received on a bridge port with multicast snooping enabled, we mark it as a router port automatically, that includes adding that port to the router port list. The multicast lock protects that list, but it is not acquired in the MRD advertisement case leading to a race condition, we need to take it to fix the race. Cc: [email protected] Cc: [email protected] Fixes: 4b3087c ("bridge: Snoop Multicast Router Advertisements") Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
[ Upstream commit ee522bc ] After device_get_match_data(), tlc591xx is not checked, add check for it and also check np after dev_of_node. Reported-by: Hulk Robot <[email protected]> Signed-off-by: Yang Yingliang <[email protected]> Signed-off-by: Pavel Machek <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 35564e2 ] When external RT714/715 devices are used for capture, we don't want the PCH DMICs to be used. Any information provided by the SOF platform driver or DMI quirks will be overridden. Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Reviewed-by: Libin Yang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit f0c0799 ] For fix below warning reported by static code analysis tool like Coverity from Synopsys: Signed-off-by: Robin Gong <[email protected]> Addresses-Coverity-ID: 12285639 ("Unchecked return value") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 5b86449 ] This patch fixes the wrong CDB payload report to IOP. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: ching Huang <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit b5befe8 ] An srcu_struct structure that is initialized before rcu_init_geometry() will have its srcu_node hierarchy based on CONFIG_NR_CPUS. Once rcu_init_geometry() is called, this hierarchy is compressed as needed for the actual maximum number of CPUs for this system. Later on, that srcu_struct structure is confused, sometimes referring to its initial CONFIG_NR_CPUS-based hierarchy, and sometimes instead to the new num_possible_cpus() hierarchy. For example, each of its ->mynode fields continues to reference the original leaf rcu_node structures, some of which might no longer exist. On the other hand, srcu_for_each_node_breadth_first() traverses to the new node hierarchy. There are at least two bad possible outcomes to this: 1) a) A callback enqueued early on an srcu_data structure (call it *sdp) is recorded pending on sdp->mynode->srcu_data_have_cbs in srcu_funnel_gp_start() with sdp->mynode pointing to a deep leaf (say 3 levels). b) The grace period ends after rcu_init_geometry() shrinks the nodes level to a single one. srcu_gp_end() walks through the new srcu_node hierarchy without ever reaching the old leaves so the callback is never executed. This is easily reproduced on an 8 CPUs machine with CONFIG_NR_CPUS >= 32 and "rcupdate.rcu_self_test=1". The srcu_barrier() after early tests verification never completes and the boot hangs: [ 5413.141029] INFO: task swapper/0:1 blocked for more than 4915 seconds. [ 5413.147564] Not tainted 5.12.0-rc4+ Freescale#28 [ 5413.151927] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 5413.159753] task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00004000 [ 5413.168099] Call Trace: [ 5413.170555] __schedule+0x36c/0x930 [ 5413.174057] ? wait_for_completion+0x88/0x110 [ 5413.178423] schedule+0x46/0xf0 [ 5413.181575] schedule_timeout+0x284/0x380 [ 5413.185591] ? wait_for_completion+0x88/0x110 [ 5413.189957] ? mark_held_locks+0x61/0x80 [ 5413.193882] ? mark_held_locks+0x61/0x80 [ 5413.197809] ? _raw_spin_unlock_irq+0x24/0x50 [ 5413.202173] ? wait_for_completion+0x88/0x110 [ 5413.206535] wait_for_completion+0xb4/0x110 [ 5413.210724] ? srcu_torture_stats_print+0x110/0x110 [ 5413.215610] srcu_barrier+0x187/0x200 [ 5413.219277] ? rcu_tasks_verify_self_tests+0x50/0x50 [ 5413.224244] ? rdinit_setup+0x2b/0x2b [ 5413.227907] rcu_verify_early_boot_tests+0x2d/0x40 [ 5413.232700] do_one_initcall+0x63/0x310 [ 5413.236541] ? rdinit_setup+0x2b/0x2b [ 5413.240207] ? rcu_read_lock_sched_held+0x52/0x80 [ 5413.244912] kernel_init_freeable+0x253/0x28f [ 5413.249273] ? rest_init+0x250/0x250 [ 5413.252846] kernel_init+0xa/0x110 [ 5413.256257] ret_from_fork+0x22/0x30 2) An srcu_struct structure that is initialized before rcu_init_geometry() and used afterward will always have stale rdp->mynode references, resulting in callbacks to be missed in srcu_gp_end(), just like in the previous scenario. This commit therefore causes init_srcu_struct_nodes to initialize the geometry, if needed. This ensures that the srcu_node hierarchy is properly built and distributed from the get-go. Suggested-by: Paul E. McKenney <[email protected]> Signed-off-by: Frederic Weisbecker <[email protected]> Cc: Boqun Feng <[email protected]> Cc: Lai Jiangshan <[email protected]> Cc: Neeraj Upadhyay <[email protected]> Cc: Josh Triplett <[email protected]> Cc: Joel Fernandes <[email protected]> Cc: Uladzislau Rezki <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 3066820 ] If another lockdep report runs concurrently with an RCU lockdep report from RCU_LOCKDEP_WARN(), the following sequence of events can occur: 1. debug_lockdep_rcu_enabled() sees that lockdep is enabled when called from (say) synchronize_rcu(). 2. Lockdep is disabled by a concurrent lockdep report. 3. debug_lockdep_rcu_enabled() evaluates its lockdep-expression argument, for example, lock_is_held(&rcu_bh_lock_map). 4. Because lockdep is now disabled, lock_is_held() plays it safe and returns the constant 1. 5. But in this case, the constant 1 is not safe, because invoking synchronize_rcu() under rcu_read_lock_bh() is disallowed. 6. debug_lockdep_rcu_enabled() wrongly invokes lockdep_rcu_suspicious(), resulting in a false-positive splat. This commit therefore changes RCU_LOCKDEP_WARN() to check debug_lockdep_rcu_enabled() after checking the lockdep expression, so that any "safe" returns from lock_is_held() are rejected by debug_lockdep_rcu_enabled(). This requires memory ordering, which is supplied by READ_ONCE(debug_locks). The resulting volatile accesses prevent the compiler from reordering and the fact that only one variable is being accessed prevents the underlying hardware from reordering. The combination works for IA64, which can reorder reads to the same location, but this is defeated by the volatile accesses, which compile to load instructions that provide ordering. Reported-by: [email protected] Reported-by: Matthew Wilcox <[email protected]> Reported-by: [email protected] Reported-by: Thomas Gleixner <[email protected]> Suggested-by: Boqun Feng <[email protected]> Reviewed-by: Boqun Feng <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
… by zero [ Upstream commit fcb10ee ] We should be very careful about the register values that will be used for division or modulo operations, althrough the possibility that the UARTBAUD register value is zero is very low, but we had better to deal with the "bad data" of hardware in advance to avoid division or modulo by zero leading to undefined kernel behavior. Signed-off-by: Sherry Sun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 8cac2f6 ] SYSRQ doesn't work with DMA. This is because there is no error indication whether a symbol had a framing error or not. Actually, this is not completely correct, there is a bit in the data register which is set in this case, but we'd have to read change the DMA access to 16 bit and we'd need to post process the data, thus make the DMA pointless in the first place. Signed-off-by: Michael Walle <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 5c6d0b5 ] Rename the external refclk inputs to the SERDES from dummy_cmn_refclk/dummy_cmn_refclk1 to cmn_refclk/cmn_refclk1 respectively. Also move the external refclk DT nodes outside the cbass_main DT node. Since in j721e common processor board, only the cmn_refclk1 is connected to 100MHz clock, fix the clock frequency. Fixes: afd094e ("arm64: dts: ti: k3-j721e-main: Add WIZ and SERDES PHY nodes") Signed-off-by: Kishon Vijay Abraham I <[email protected]> Reviewed-by: Aswath Govindraju <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 3b132ab ] On probe error the driver should unmap the IO memory. Smatch reports: drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: 'fsl_ifc_ctrl_dev->gregs' not released on lines: 298. Fixes: a20cbde ("powerpc/fsl: Add support for Integrated Flash Controller") Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 8e0d09b ] On probe error the driver should free the memory allocated for private structure. Fix this by using resource-managed allocation. Fixes: a20cbde ("powerpc/fsl: Add support for Integrated Flash Controller") Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit bd5431b ] Although the schematics of Pine A64-LTS and SoPine Baseboard shows both the RX and TX internal delay are enabled, they're using the same broken RTL8211E chip batch with Pine A64+, so they should use TXID instead, not ID. In addition, by checking the real components soldered on both a SoPine Baseboard and a Pine A64-LTS, RX delay is not enabled (GR69 soldered and GR70 NC) despite the schematics says it's enabled. It's a common situation for Pine64 boards that the NC information on schematics is not the same with the board. So the RGMII delay mode should be TXID on these boards. Fixes: c2b111e ("arm64: dts: allwinner: A64 Sopine: phy-mode rgmii-id") Signed-off-by: Icenowy Zheng <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 78b4b16 ] With [1] USB4 target-module node got defined in dra74x.dtsi file. However, the earlier definition in [2] was not removed, and this duplication of the target module is causing boot failure on dra74 variant boards - dra7-evm, dra76-evm. USB4 is only present in DRA74x variants, so keeping the entry in dra74x.dtsi and removing it from the top level interconnect hierarchy dra7-l4.dtsi file. This change makes the USB4 target module no longer visible to AM5718, DRA71x and DRA72x so removing references to it in their respective dts files. [1]: commit c7b72ab ("ARM: OMAP2+: Drop legacy platform data for dra7 dwc3") [2]: commit 549fce0 ("ARM: dts: dra7: Add l4 interconnect hierarchy and ti-sysc data") Fixes: c7b72ab ("ARM: OMAP2+: Drop legacy platform data for dra7 dwc3") Signed-off-by: Gowtham Tammana <[email protected]> Reviewed-by: Grygorii Strashko <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 414bfe1 ] ti,pindir-d0-out-d1-in property is expected to be of type boolean. Therefore, fix the property accordingly. Fixes: 444d66f ("ARM: dts: add spi wifi support to cm-t335") Signed-off-by: Aswath Govindraju <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 9b11fec ] ti,pindir-d0-out-d1-in property is expected to be of type boolean. Therefore, fix the property accordingly. Fixes: b0b0395 ("ARM: dts: am43x-epos-evm: set data pin directions for spi0 and spi1") Signed-off-by: Aswath Govindraju <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 4d57fd9 ] MODULE_DEVICE_TABLE is used to extract the device information out of the driver and builds a table when being compiled. If using this macro, kernel can find the driver if available when the device is plugged in, and then loads that driver and initializes the device. Fixes: 554fdba ("thermal: sprd: Add Spreadtrum thermal driver support") Signed-off-by: Chunyan Zhang <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit c016c26 ] Fix ethernet reset time properties as described in Documentation/devicetree/bindings/net/ethernet-phy.yaml Fixes: 52c7a08 ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2") Signed-off-by: Christoph Niedermaier <[email protected]> Cc: Shawn Guo <[email protected]> Cc: Fabio Estevam <[email protected]> Cc: Marek Vasut <[email protected]> Cc: NXP Linux Team <[email protected]> Cc: [email protected] To: [email protected] Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit e2bdd34 ] To make the ethernet cable plugin detection reliable the power detection of the smsc phy has been disabled. Fixes: 52c7a08 ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2") Signed-off-by: Christoph Niedermaier <[email protected]> Cc: Shawn Guo <[email protected]> Cc: Fabio Estevam <[email protected]> Cc: Marek Vasut <[email protected]> Cc: NXP Linux Team <[email protected]> Cc: [email protected] To: [email protected] Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit ddc873c ] The i2c bus can freeze at the end of transaction so the bus can no longer work. This scenario is improved by adding scl/sda gpios definitions to implement the i2c bus recovery mechanism. Fixes: 52c7a08 ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2") Signed-off-by: Christoph Niedermaier <[email protected]> Cc: Shawn Guo <[email protected]> Cc: Fabio Estevam <[email protected]> Cc: Marek Vasut <[email protected]> Cc: NXP Linux Team <[email protected]> Cc: [email protected] To: [email protected] Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 8946187 ] The fixed value of 157 used in the calculations are only correct for M3-W, on other Gen3 SoC it should be 167. The constant can be derived correctly from the static TJ_3 constant and the SoC specific TJ_1 value. Update the calculation be correct on all Gen3 SoCs. Fixes: 4eb39f7 ("thermal: rcar_gen3_thermal: Update value of Tj_1") Reported-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Niklas Söderlund <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit e34e602 ] The status decoding function mox_get_status() currently contains an incorrect check: if the error status is not MBOX_STS_SUCCESS, it always returns -EIO, so the comparison to MBOX_STS_FAIL is never executed and we don't get the actual error code sent by the firmware. Fix this. Signed-off-by: Marek Behún <[email protected]> Reviewed-by: Pali Rohár <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Fixes: 389711b ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 72f9988 ] Report a notice level message if a command is not supported by the rWTM firmware. This should not be an error, merely a notice, because the firmware can be used on boards that do not have manufacturing information burned. Fixes: 389711b ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Marek Behún <[email protected]> Reviewed-by: Pali Rohár <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
…t hwrng [ Upstream commit 2eab59c ] When Marvell's rWTM firmware, which does not support the GET_RANDOM command, is used, kernel prints an error message hwrng: no data available every 10 seconds. Fail probing of this driver if the rWTM firmware does not support the GET_RANDOM command. Fixes: 389711b ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Marek Behún <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit fae2016 ] Currently it is hard to determinate if on Armada 3720 device is HWRNG by running kernel accessible or not. So print information message into dmesg when HWRNG is available and registration was successful. Fixes: 389711b ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Pali Rohár <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
…or vdd_gpu on rk3399-roc-pc [ Upstream commit 06b2818 ] This might be a limitation of either the current panfrost driver devfreq implementation or how the gpu is implemented in RK3399 SoC. The gpu regulator must never get disabled or the registers get (randomly?) inaccessable by the driver. (see all other RK3399 boards) Fixes: ec7d731 ("arm64: dts: rockchip: Add node for gpu on rk3399-roc-pc") Signed-off-by: Alex Bee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
…399-roc-pc [ Upstream commit eb607cd ] Re-add the regulator-always-on property for vcc_sdio which supplies sdmmc, since it gets disabled during reboot now and the bootrom expects it to be enabled when booting from SD card. This makes rebooting impossible in that case and requires a hard reset to boot again. Fixes: 04a0077 ("arm64: dts: rockchip: Remove always-on properties from regulator nodes on rk3399-roc-pc.") Signed-off-by: Alex Bee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 030e413 ] If an error occurs after a pci_enable_pcie_error_reporting() call, it must be undone by a corresponding pci_disable_pcie_error_reporting() call, as already done in the remove function. Link: https://lore.kernel.org/r/77adb02cfea7f1364e5603ecf3930d8597ae356e.1623482155.git.christophe.jaillet@wanadoo.fr Fixes: 3567f36 ("[SCSI] be2iscsi: Fix AER handling in driver") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 3e1493f ] When a task wakes up on an idle rq, uclamp_rq_util_with() would max aggregate with rq value. But since there is no task enqueued yet, the values are stale based on the last task that was running. When the new task actually wakes up and enqueued, then the rq uclamp values should reflect that of the newly woken up task effective uclamp values. This is a problem particularly for uclamp_max because it default to 1024. If a task p with uclamp_max = 512 wakes up, then max aggregation would ignore the capping that should apply when this task is enqueued, which is wrong. Fix that by ignoring max aggregation if the rq is idle since in that case the effective uclamp value of the rq will be the ones of the task that will wake up. Fixes: 9d20ad7 ("sched/uclamp: Add uclamp_util_with()") Signed-off-by: Xuewen Yan <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Valentin Schneider <[email protected]> [qias: Changelog] Reviewed-by: Qais Yousef <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 9e66762 ] It turns out that jump_label_text_reserved() was reporting __init text as being reserved past the time when the __init text was freed and re-used. For a long time, this resulted in, at worst, not being able to kprobe text that happened to land at the re-used address. However a recent commit e7bf1ba ("jump_label, x86: Emit short JMP") made it a fatal mistake because it now needs to read the instruction in order to determine the conflict -- an instruction that's no longer there. Fixes: 4c3ef6d ("jump label: Add jump_label_text_reserved() to reserve jump points") Reported-by: kernel test robot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Masami Hiramatsu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 2bee6d1 ] It turns out that static_call_text_reserved() was reporting __init text as being reserved past the time when the __init text was freed and re-used. This is mostly harmless and will at worst result in refusing a kprobe. Fixes: 6333e8f ("static_call: Avoid kprobes on inline static_call()s") Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Masami Hiramatsu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit cddc40f ] My series to clean up the unaligned access implementation across architectures caused some mips randconfig builds to fail with: mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `decompress_kernel': decompress.c:(.text.decompress_kernel+0x54): undefined reference to `__bswapsi2' It turns out that this problem has already been fixed for the XZ decompressor but now it also shows up in (at least) LZO and LZ4. From my analysis I concluded that the compiler could always have emitted those calls, but the different implementation allowed it to make otherwise better decisions about not inlining the byteswap, which results in the link error when the out-of-line code is missing. While it could be addressed by adding it to the two decompressor implementations that are known to be affected, but as this only adds 112 bytes to the kernel, the safer choice is to always add them. Fixes: c50ec67 ("MIPS: zboot: Fix the build with XZ compression on older GCC versions") Fixes: 0652035 ("asm-generic: unaligned: remove byteshift helpers") Link: https://lore.kernel.org/linux-mm/[email protected]/ Link: https://lore.kernel.org/linux-mm/[email protected]/ Link: https://lore.kernel.org/linux-mm/[email protected]/ Link: https://lore.kernel.org/linux-mm/[email protected]/ Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 97e4880 ] Use DISABLE_BRANCH_PROFILING for arch/mips/boot/compressed/decompress.o to prevent linkage errors. mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `LZ4_decompress_fast_extDict': decompress.c:(.text+0x8c): undefined reference to `ftrace_likely_update' mips64-linux-ld: decompress.c:(.text+0xf4): undefined reference to `ftrace_likely_update' mips64-linux-ld: decompress.c:(.text+0x200): undefined reference to `ftrace_likely_update' mips64-linux-ld: decompress.c:(.text+0x230): undefined reference to `ftrace_likely_update' mips64-linux-ld: decompress.c:(.text+0x320): undefined reference to `ftrace_likely_update' mips64-linux-ld: arch/mips/boot/compressed/decompress.o:decompress.c:(.text+0x3f4): more undefined references to `ftrace_likely_update' follow Fixes: e76e1fd ("lib: add support for LZ4-compressed kernel") Reported-by: kernel test robot <[email protected]> Signed-off-by: Randy Dunlap <[email protected]> Cc: Thomas Bogendoerfer <[email protected]> Cc: [email protected] Cc: Kyungsik Lee <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 47ce852 ] Accessing raw timers (currently only CLOCK_MONOTONIC_RAW) through VDSO doesn't return the correct time when using the GIC as clock source. The address of the GIC mapped page is in this case not calculated correctly. The GIC mapped page is calculated from the VDSO data by subtracting PAGE_SIZE: void *get_gic(const struct vdso_data *data) { return (void __iomem *)data - PAGE_SIZE; } However, the data pointer is not page aligned for raw clock sources. This is because the VDSO data for raw clock sources (CS_RAW = 1) is stored after the VDSO data for coarse clock sources (CS_HRES_COARSE = 0). Therefore, only the VDSO data for CS_HRES_COARSE is page aligned: +--------------------+ | | | vd[CS_RAW] | ---+ | vd[CS_HRES_COARSE] | | +--------------------+ | -PAGE_SIZE | | | | GIC mapped page | <--+ | | +--------------------+ When __arch_get_hw_counter() is called with &vd[CS_RAW], get_gic returns the wrong address (somewhere inside the GIC mapped page). The GIC counter values are not returned which results in an invalid time. Fixes: a7f4df4 ("MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()") Signed-off-by: Martin Fäcknitz <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
commit 8092782 upstream. The "retval" variable needs to be signed for the error handling to work. Link: https://lore.kernel.org/r/YLjMEAFNxOas1mIp@mwanda Fixes: 7e26e3e ("scsi: scsi_dh_alua: Check for negative result value") Reviewed-by: Martin Wilck <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 8cae8cd upstream. There is no reasonable need for a buffer larger than this, and it avoids int overflow pitfalls. Fixes: 058504e ("fs/seq_file: fallback to vmalloc allocation") Suggested-by: Al Viro <[email protected]> Reported-by: Qualys Security Advisory <[email protected]> Signed-off-by: Eric Sandeen <[email protected]> Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Link: https://lore.kernel.org/r/[email protected] Tested-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Salvatore Bonaccorso <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Fox Chen <[email protected]> Tested-by: Jon Hunter <[email protected]> Tested-by: Sudip Mukherjee <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
This is the 5.10.52 stable release Signed-off-by: Andrey Zhizhikin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Automatic merge performed, no conflicts reported.
Kernel has been built for both aarch64 (
defconfig) and arm32 (imx_v6_v7_defconfig).-- andrey