bisecting cause commit starting from dfd42facf1e4ada021b939b4e19c935dcdd55566 building syzkaller on a7dab6385c1d95547a88e22577fb56fbcd5c37eb testing commit dfd42facf1e4ada021b939b4e19c935dcdd55566 compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: 26ed1ea0dd59713076c573c81c8270c37489b44aa02f1e876defd8cc330e2c94 all runs: crashed: KASAN: use-after-free Read in madvise_update_vma testing release v5.16 testing commit df0cc57e057f18e44dac8e6c18aba47ab53202f9 compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: 6392e7dc90e0a4647080a5029d93ca58348fb8a5852ea8aba24fe1cfc2cb5f6d all runs: OK # git bisect start dfd42facf1e4ada021b939b4e19c935dcdd55566 df0cc57e057f18e44dac8e6c18aba47ab53202f9 Bisecting: 6307 revisions left to test after this (roughly 13 steps) [1dbfae0113f1423b42c304989a3cc8a7dd0ea53e] Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 testing commit 1dbfae0113f1423b42c304989a3cc8a7dd0ea53e compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: e17f60ae22a8d5f12b97f601c9cedb78859bac4a6bcf0a4aa8ac30adf7e788ca all runs: OK # git bisect good 1dbfae0113f1423b42c304989a3cc8a7dd0ea53e Bisecting: 3049 revisions left to test after this (roughly 12 steps) [3bad80dab94a16c9b7991105e3bffd5fe5957e9a] Merge tag 'char-misc-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc testing commit 3bad80dab94a16c9b7991105e3bffd5fe5957e9a compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: aa4e36b85998ef9495aa116fd15871aa88db1b19f801e7a166aab3774909b9f1 all runs: OK # git bisect good 3bad80dab94a16c9b7991105e3bffd5fe5957e9a Bisecting: 1549 revisions left to test after this (roughly 11 steps) [fd6f57bfda7c36f2d465cee39d5d8c623db5d7aa] Merge tag 'kbuild-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild testing commit fd6f57bfda7c36f2d465cee39d5d8c623db5d7aa compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: 283788172519b71a954cf64181157e49ac5759fdf314054bcda0e44af2633778 all runs: crashed: KASAN: use-after-free Read in madvise_update_vma # git bisect bad fd6f57bfda7c36f2d465cee39d5d8c623db5d7aa Bisecting: 628 revisions left to test after this (roughly 10 steps) [79e06c4c4950be2abd8ca5d2428a8c915aa62c24] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm testing commit 79e06c4c4950be2abd8ca5d2428a8c915aa62c24 compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: 99c1f266d0aa5d8242be1bf69f3ec7d114994ba813f4e028c4ceb97ac90b644f all runs: crashed: KASAN: use-after-free Read in madvise_update_vma # git bisect bad 79e06c4c4950be2abd8ca5d2428a8c915aa62c24 Bisecting: 354 revisions left to test after this (roughly 9 steps) [d0a231f01e5b25bacd23e6edc7c979a18a517b2b] Merge tag 'pci-v5.17-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci testing commit d0a231f01e5b25bacd23e6edc7c979a18a517b2b compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: 8b955bc6b3d6fc98c7a07ec4fccd78cc1d97a007f531c92013d8b621257d406e all runs: crashed: KASAN: use-after-free Read in madvise_update_vma # git bisect bad d0a231f01e5b25bacd23e6edc7c979a18a517b2b Bisecting: 251 revisions left to test after this (roughly 8 steps) [59d41458f143b7a20997b1e78b5c15d9d3e998c3] Merge tag 'drm-next-2022-01-14' of git://anongit.freedesktop.org/drm/drm testing commit 59d41458f143b7a20997b1e78b5c15d9d3e998c3 compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: ddbc03830b4eab84cf96dcacb4ee89322bc6c7a6816ccdc1c4c9ead40ec95b84 all runs: crashed: KASAN: use-after-free Read in madvise_update_vma # git bisect bad 59d41458f143b7a20997b1e78b5c15d9d3e998c3 Bisecting: 131 revisions left to test after this (roughly 7 steps) [4492bf452af532493b6591d2e090a0f8f7c11674] Docs/admin-guide/mm/damon/usage: mention tracepoint at the beginning testing commit 4492bf452af532493b6591d2e090a0f8f7c11674 compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: bbe1a4682d011701b2c50584ce250e73fec476f60be2cb44c8ca5ab4586fdbd5 all runs: crashed: KASAN: use-after-free Read in madvise_update_vma # git bisect bad 4492bf452af532493b6591d2e090a0f8f7c11674 Bisecting: 65 revisions left to test after this (roughly 6 steps) [08d5b29eac7dd5e6c79b66d390ecbb9219e05931] mm: ptep_clear() page table helper testing commit 08d5b29eac7dd5e6c79b66d390ecbb9219e05931 compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: fb692e5e4c22fc42a4ac2bf1746eac2db1dfc8445b8fb77c46533a37f5077983 all runs: crashed: KASAN: use-after-free Read in madvise_update_vma # git bisect bad 08d5b29eac7dd5e6c79b66d390ecbb9219e05931 Bisecting: 32 revisions left to test after this (roughly 5 steps) [0e7325f03f09802d1667b8860e10fe39c25bf14c] device-dax: set mapping prior to vmf_insert_pfn{,_pmd,pud}() testing commit 0e7325f03f09802d1667b8860e10fe39c25bf14c compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: 738ed4b8f5b0c52db21d2f06e30e26f170333e5870ce028ee6bd1f86043c597e all runs: OK # git bisect good 0e7325f03f09802d1667b8860e10fe39c25bf14c Bisecting: 16 revisions left to test after this (roughly 4 steps) [46a53371f3fd9bf873fdd9c4df75b1cd86df1098] mm/page_counter: remove an incorrect call to propagate_protected_usage() testing commit 46a53371f3fd9bf873fdd9c4df75b1cd86df1098 compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: 144a5791eff50f454cbb08d9d9c6ae23841f0faf6f06b3b9d04aeb2cf5891da5 all runs: OK # git bisect good 46a53371f3fd9bf873fdd9c4df75b1cd86df1098 Bisecting: 8 revisions left to test after this (roughly 3 steps) [9a10064f5625d5572c3626c1516e0bebc6c9fe9b] mm: add a field to store names for private anonymous memory testing commit 9a10064f5625d5572c3626c1516e0bebc6c9fe9b compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: a6db44021e1c66b4f4b9be4fe4d51dd3c36d795913dacc6dab5462eda9ac71da all runs: crashed: KASAN: use-after-free Read in madvise_update_vma # git bisect bad 9a10064f5625d5572c3626c1516e0bebc6c9fe9b Bisecting: 3 revisions left to test after this (roughly 2 steps) [4e5aa1f4c2b489bc6f3ab5ca54747b18a847289d] memcg: add per-memcg vmalloc stat testing commit 4e5aa1f4c2b489bc6f3ab5ca54747b18a847289d compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: 6888b8876fdb4195d92f3edf08ddf10676eebcd28a79b91af2cc6523065278de all runs: OK # git bisect good 4e5aa1f4c2b489bc6f3ab5ca54747b18a847289d Bisecting: 1 revision left to test after this (roughly 1 step) [36ef159f4408b08eae7f2af6d62bedd3f4343758] mm: remove redundant check about FAULT_FLAG_ALLOW_RETRY bit testing commit 36ef159f4408b08eae7f2af6d62bedd3f4343758 compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: 640c320c3805b4dab6e3d87cd439f66b85e1ca6a31e774214882cfec7ec41e69 all runs: OK # git bisect good 36ef159f4408b08eae7f2af6d62bedd3f4343758 Bisecting: 0 revisions left to test after this (roughly 0 steps) [ac1e9acc5acf0b41d54de6a4c45471644f8b97ff] mm: rearrange madvise code to allow for reuse testing commit ac1e9acc5acf0b41d54de6a4c45471644f8b97ff compiler: gcc (GCC) 10.2.1 20210217, GNU ld (GNU Binutils for Debian) 2.35.2 kernel signature: fdf3871f7c83e6c0975c1cfe4e242b8209b606b7d1317d71257685ca3078fbf1 all runs: OK # git bisect good ac1e9acc5acf0b41d54de6a4c45471644f8b97ff 9a10064f5625d5572c3626c1516e0bebc6c9fe9b is the first bad commit commit 9a10064f5625d5572c3626c1516e0bebc6c9fe9b Author: Colin Cross Date: Fri Jan 14 14:05:59 2022 -0800 mm: add a field to store names for private anonymous memory In many userspace applications, and especially in VM based applications like Android uses heavily, there are multiple different allocators in use. At a minimum there is libc malloc and the stack, and in many cases there are libc malloc, the stack, direct syscalls to mmap anonymous memory, and multiple VM heaps (one for small objects, one for big objects, etc.). Each of these layers usually has its own tools to inspect its usage; malloc by compiling a debug version, the VM through heap inspection tools, and for direct syscalls there is usually no way to track them. On Android we heavily use a set of tools that use an extended version of the logic covered in Documentation/vm/pagemap.txt to walk all pages mapped in userspace and slice their usage by process, shared (COW) vs. unique mappings, backing, etc. This can account for real physical memory usage even in cases like fork without exec (which Android uses heavily to share as many private COW pages as possible between processes), Kernel SamePage Merging, and clean zero pages. It produces a measurement of the pages that only exist in that process (USS, for unique), and a measurement of the physical memory usage of that process with the cost of shared pages being evenly split between processes that share them (PSS). If all anonymous memory is indistinguishable then figuring out the real physical memory usage (PSS) of each heap requires either a pagemap walking tool that can understand the heap debugging of every layer, or for every layer's heap debugging tools to implement the pagemap walking logic, in which case it is hard to get a consistent view of memory across the whole system. Tracking the information in userspace leads to all sorts of problems. It either needs to be stored inside the process, which means every process has to have an API to export its current heap information upon request, or it has to be stored externally in a filesystem that somebody needs to clean up on crashes. It needs to be readable while the process is still running, so it has to have some sort of synchronization with every layer of userspace. Efficiently tracking the ranges requires reimplementing something like the kernel vma trees, and linking to it from every layer of userspace. It requires more memory, more syscalls, more runtime cost, and more complexity to separately track regions that the kernel is already tracking. This patch adds a field to /proc/pid/maps and /proc/pid/smaps to show a userspace-provided name for anonymous vmas. The names of named anonymous vmas are shown in /proc/pid/maps and /proc/pid/smaps as [anon:]. Userspace can set the name for a region of memory by calling prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, start, len, (unsigned long)name) Setting the name to NULL clears it. The name length limit is 80 bytes including NUL-terminator and is checked to contain only printable ascii characters (including space), except '[',']','\','$' and '`'. Ascii strings are being used to have a descriptive identifiers for vmas, which can be understood by the users reading /proc/pid/maps or /proc/pid/smaps. Names can be standardized for a given system and they can include some variable parts such as the name of the allocator or a library, tid of the thread using it, etc. The name is stored in a pointer in the shared union in vm_area_struct that points to a null terminated string. Anonymous vmas with the same name (equivalent strings) and are otherwise mergeable will be merged. The name pointers are not shared between vmas even if they contain the same name. The name pointer is stored in a union with fields that are only used on file-backed mappings, so it does not increase memory usage. CONFIG_ANON_VMA_NAME kernel configuration is introduced to enable this feature. It keeps the feature disabled by default to prevent any additional memory overhead and to avoid confusing procfs parsers on systems which are not ready to support named anonymous vmas. The patch is based on the original patch developed by Colin Cross, more specifically on its latest version [1] posted upstream by Sumit Semwal. It used a userspace pointer to store vma names. In that design, name pointers could be shared between vmas. However during the last upstreaming attempt, Kees Cook raised concerns [2] about this approach and suggested to copy the name into kernel memory space, perform validity checks [3] and store as a string referenced from vm_area_struct. One big concern is about fork() performance which would need to strdup anonymous vma names. Dave Hansen suggested experimenting with worst-case scenario of forking a process with 64k vmas having longest possible names [4]. I ran this experiment on an ARM64 Android device and recorded a worst-case regression of almost 40% when forking such a process. This regression is addressed in the followup patch which replaces the pointer to a name with a refcounted structure that allows sharing the name pointer between vmas of the same name. Instead of duplicating the string during fork() or when splitting a vma it increments the refcount. [1] https://lore.kernel.org/linux-mm/20200901161459.11772-4-sumit.semwal@linaro.org/ [2] https://lore.kernel.org/linux-mm/202009031031.D32EF57ED@keescook/ [3] https://lore.kernel.org/linux-mm/202009031022.3834F692@keescook/ [4] https://lore.kernel.org/linux-mm/5d0358ab-8c47-2f5f-8e43-23b89d6a8e95@intel.com/ Changes for prctl(2) manual page (in the options section): PR_SET_VMA Sets an attribute specified in arg2 for virtual memory areas starting from the address specified in arg3 and spanning the size specified in arg4. arg5 specifies the value of the attribute to be set. Note that assigning an attribute to a virtual memory area might prevent it from being merged with adjacent virtual memory areas due to the difference in that attribute's value. Currently, arg2 must be one of: PR_SET_VMA_ANON_NAME Set a name for anonymous virtual memory areas. arg5 should be a pointer to a null-terminated string containing the name. The name length including null byte cannot exceed 80 bytes. If arg5 is NULL, the name of the appropriate anonymous virtual memory areas will be reset. The name can contain only printable ascii characters (including space), except '[',']','\','$' and '`'. This feature is available only if the kernel is built with the CONFIG_ANON_VMA_NAME option enabled. [surenb@google.com: docs: proc.rst: /proc/PID/maps: fix malformed table] Link: https://lkml.kernel.org/r/20211123185928.2513763-1-surenb@google.com [surenb: rebased over v5.15-rc6, replaced userpointer with a kernel copy, added input sanitization and CONFIG_ANON_VMA_NAME config. The bulk of the work here was done by Colin Cross, therefore, with his permission, keeping him as the author] Link: https://lkml.kernel.org/r/20211019215511.3771969-2-surenb@google.com Signed-off-by: Colin Cross Signed-off-by: Suren Baghdasaryan Reviewed-by: Kees Cook Cc: Stephen Rothwell Cc: Al Viro Cc: Cyrill Gorcunov Cc: Dave Hansen Cc: David Rientjes Cc: "Eric W. Biederman" Cc: Hugh Dickins Cc: Ingo Molnar Cc: Jan Glauber Cc: Johannes Weiner Cc: John Stultz Cc: Mel Gorman Cc: Minchan Kim Cc: Oleg Nesterov Cc: Pekka Enberg Cc: Peter Zijlstra Cc: Rob Landley Cc: "Serge E. Hallyn" Cc: Shaohua Li Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Documentation/filesystems/proc.rst | 6 +- fs/proc/task_mmu.c | 12 +++- fs/userfaultfd.c | 7 +- include/linux/mm.h | 13 +++- include/linux/mm_types.h | 64 ++++++++++++++++-- include/uapi/linux/prctl.h | 3 + kernel/fork.c | 2 + kernel/sys.c | 63 ++++++++++++++++++ mm/Kconfig | 14 ++++ mm/madvise.c | 129 +++++++++++++++++++++++++++++++++++-- mm/mempolicy.c | 3 +- mm/mlock.c | 2 +- mm/mmap.c | 38 ++++++----- mm/mprotect.c | 2 +- 14 files changed, 324 insertions(+), 34 deletions(-) culprit signature: a6db44021e1c66b4f4b9be4fe4d51dd3c36d795913dacc6dab5462eda9ac71da parent signature: fdf3871f7c83e6c0975c1cfe4e242b8209b606b7d1317d71257685ca3078fbf1 revisions tested: 16, total time: 2h38m14.534691133s (build: 1h53m41.965439579s, test: 43m9.248514853s) first bad commit: 9a10064f5625d5572c3626c1516e0bebc6c9fe9b mm: add a field to store names for private anonymous memory recipients (to): ["akpm@linux-foundation.org" "ccross@google.com" "keescook@chromium.org" "surenb@google.com" "torvalds@linux-foundation.org"] recipients (cc): [] crash: KASAN: use-after-free Read in madvise_update_vma ================================================================== BUG: KASAN: use-after-free in strcmp+0x9b/0xb0 lib/string.c:346 Read of size 1 at addr ffff88801d11b1c0 by task syz-executor107/4003 CPU: 1 PID: 4003 Comm: syz-executor107 Not tainted 5.16.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x57/0x7d lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan/report.c:247 __kasan_report mm/kasan/report.c:433 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:450 strcmp+0x9b/0xb0 lib/string.c:346 replace_vma_anon_name mm/madvise.c:110 [inline] madvise_update_vma+0x40f/0x6a0 mm/madvise.c:181 madvise_vma_behavior+0xdb/0x1380 mm/madvise.c:1012 madvise_walk_vmas+0x164/0x280 mm/madvise.c:1176 do_madvise.part.0+0x119/0x270 mm/madvise.c:1354 do_madvise mm/madvise.c:1367 [inline] __do_sys_madvise mm/madvise.c:1367 [inline] __se_sys_madvise mm/madvise.c:1365 [inline] __x64_sys_madvise+0xcc/0x130 mm/madvise.c:1365 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f973ea84b19 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe99758f88 EFLAGS: 00000246 ORIG_RAX: 000000000000001c RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f973ea84b19 RDX: 000000000000000b RSI: 0000000000001000 RDI: 0000000020ffc000 RBP: 00007f973ea48cc0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000020000000 R11: 0000000000000246 R12: 00007f973ea48d50 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 3614: kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:434 [inline] ____kasan_kmalloc mm/kasan/common.c:513 [inline] ____kasan_kmalloc mm/kasan/common.c:472 [inline] __kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:522 kmalloc include/linux/slab.h:590 [inline] kzalloc include/linux/slab.h:724 [inline] apparmor_sk_alloc_security+0x69/0xf0 security/apparmor/lsm.c:785 security_sk_alloc+0x44/0x80 security/security.c:2263 sk_prot_alloc+0x178/0x200 net/core/sock.c:1923 sk_alloc+0x27/0x810 net/core/sock.c:1973 inet_create net/ipv4/af_inet.c:318 [inline] inet_create+0x2a4/0xd60 net/ipv4/af_inet.c:244 __sock_create+0x23e/0x590 net/socket.c:1464 sock_create net/socket.c:1515 [inline] __sys_socket+0xd6/0x1a0 net/socket.c:1557 __do_sys_socket net/socket.c:1566 [inline] __se_sys_socket net/socket.c:1564 [inline] __x64_sys_socket+0x6a/0xb0 net/socket.c:1564 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 4003: kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:46 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:366 [inline] ____kasan_slab_free mm/kasan/common.c:328 [inline] __kasan_slab_free+0xff/0x130 mm/kasan/common.c:374 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:1723 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1749 slab_free mm/slub.c:3513 [inline] kfree+0xf6/0x560 mm/slub.c:4561 free_vma_anon_name mm/madvise.c:96 [inline] free_vma_anon_name+0x59/0xa0 mm/madvise.c:91 vm_area_free+0x9/0x20 kernel/fork.c:375 __vma_adjust+0x738/0x20b0 mm/mmap.c:961 vma_merge+0x6f9/0x12e0 mm/mmap.c:1216 madvise_update_vma+0x199/0x6a0 mm/madvise.c:149 madvise_vma_behavior+0xdb/0x1380 mm/madvise.c:1012 madvise_walk_vmas+0x164/0x280 mm/madvise.c:1176 do_madvise.part.0+0x119/0x270 mm/madvise.c:1354 do_madvise mm/madvise.c:1367 [inline] __do_sys_madvise mm/madvise.c:1367 [inline] __se_sys_madvise mm/madvise.c:1365 [inline] __x64_sys_madvise+0xcc/0x130 mm/madvise.c:1365 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff88801d11b1c0 which belongs to the cache kmalloc-16 of size 16 The buggy address is located 0 bytes inside of 16-byte region [ffff88801d11b1c0, ffff88801d11b1d0) The buggy address belongs to the page: page:ffffea00007446c0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1d11b flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000200 0000000000000000 dead000000000001 ffff88800fc413c0 raw: 0000000000000000 0000000080800080 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 1, ts 4776970319, free_ts 0 prep_new_page mm/page_alloc.c:2428 [inline] get_page_from_freelist+0xa6f/0x2f10 mm/page_alloc.c:4159 __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5379 alloc_page_interleave+0xf/0x1c0 mm/mempolicy.c:2037 alloc_slab_page mm/slub.c:1793 [inline] allocate_slab mm/slub.c:1930 [inline] new_slab+0x32d/0x4a0 mm/slub.c:1993 ___slab_alloc+0x91a/0xfd0 mm/slub.c:3022 __slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3109 slab_alloc_node mm/slub.c:3200 [inline] slab_alloc mm/slub.c:3242 [inline] __kmalloc_track_caller+0x2e7/0x320 mm/slub.c:4925 kstrdup+0x29/0x50 mm/util.c:60 __kernfs_new_node+0x94/0x7b0 fs/kernfs/dir.c:581 kernfs_new_node fs/kernfs/dir.c:647 [inline] kernfs_create_dir_ns+0x80/0x220 fs/kernfs/dir.c:984 sysfs_create_dir_ns+0x116/0x260 fs/sysfs/dir.c:59 create_dir lib/kobject.c:89 [inline] kobject_add_internal+0x27b/0x930 lib/kobject.c:255 kobject_add_varg lib/kobject.c:390 [inline] kobject_add+0x120/0x190 lib/kobject.c:442 device_add+0x2d6/0x1b80 drivers/base/core.c:3329 usb_hub_create_port_device+0x361/0xc90 drivers/usb/core/port.c:564 hub_configure drivers/usb/core/hub.c:1655 [inline] hub_probe.cold+0x1f9b/0x24a6 drivers/usb/core/hub.c:1889 page_owner free stack trace missing Memory state around the buggy address: ffff88801d11b080: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc ffff88801d11b100: 00 00 fc fc 00 00 fc fc 00 00 fc fc fa fb fc fc >ffff88801d11b180: fa fb fc fc 00 00 fc fc fa fb fc fc fb fb fc fc ^ ffff88801d11b200: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc ffff88801d11b280: fb fb fc fc fb fb fc fc fb fb fc fc 00 07 fc fc ==================================================================