[syzbot] [mm?] general protection fault in hugetlb_vma_lock_read

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: babe393974de Merge tag 'docs-6.7' of git://git.lwn.net/linux
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=176e7813680000
kernel config: https://syzkaller.appspot.com/x/.config?x=34994593e74fdcfe
dashboard link: https://syzkaller.appspot.com/bug?extid=93e7c679006f0d4e6105
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/81ff19e40c77/disk-babe3939.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/a92e6d2d9507/vmlinux-babe3939.xz
kernel image: https://storage.googleapis.com/syzbot-assets/afd2bad18cfc/bzImage-babe3939.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+93e7c6...@syzkaller.appspotmail.com

netlink: 12 bytes leftover after parsing attributes in process `syz-executor.1'.
general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef]
CPU: 1 PID: 15736 Comm: syz-executor.1 Not tainted 6.6.0-syzkaller-10265-gbabe393974de #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
RIP: 0010:__lock_acquire+0x109/0x5de0 kernel/locking/lockdep.c:5004
Code: 45 85 c9 0f 84 cc 0e 00 00 44 8b 05 21 dc 81 0b 45 85 c0 0f 84 be 0d 00 00 48 ba 00 00 00 00 00 fc ff df 4c 89 d1 48 c1 e9 03 <80> 3c 11 00 0f 85 e8 40 00 00 49 81 3a e0 09 b3 90 0f 84 96 0d 00
RSP: 0018:ffffc90003387378 EFLAGS: 00010006
RAX: ffff88801d5e9dc0 RBX: 1ffff92000670e9f RCX: 000000000000001d
RDX: dffffc0000000000 RSI: 0000000000000000 RDI: 00000000000000e8
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001
R10: 00000000000000e8 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
FS: 00007f07477fc6c0(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000b80 CR3: 000000006a8b7000 CR4: 00000000003506f0
Call Trace:
<TASK>
lock_acquire kernel/locking/lockdep.c:5753 [inline]
lock_acquire+0x1ae/0x510 kernel/locking/lockdep.c:5718
down_read+0x9c/0x470 kernel/locking/rwsem.c:1526
hugetlb_vma_lock_read mm/hugetlb.c:274 [inline]
hugetlb_vma_lock_read+0xae/0x100 mm/hugetlb.c:265
hugetlb_follow_page_mask+0x156/0xf20 mm/hugetlb.c:6500
follow_page_mask+0x49e/0xda0 mm/gup.c:824
__get_user_pages+0x366/0x1480 mm/gup.c:1237
__get_user_pages_locked mm/gup.c:1504 [inline]
__gup_longterm_locked+0x755/0x2570 mm/gup.c:2198
pin_user_pages_remote+0xee/0x140 mm/gup.c:3346
process_vm_rw_single_vec mm/process_vm_access.c:105 [inline]
process_vm_rw_core.constprop.0+0x43d/0xa10 mm/process_vm_access.c:215
process_vm_rw+0x2ff/0x360 mm/process_vm_access.c:283
__do_sys_process_vm_writev mm/process_vm_access.c:303 [inline]
__se_sys_process_vm_writev mm/process_vm_access.c:298 [inline]
__x64_sys_process_vm_writev+0xe2/0x1b0 mm/process_vm_access.c:298
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7f0746a7cae9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f07477fc0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000137
RAX: ffffffffffffffda RBX: 00007f0746b9bf80 RCX: 00007f0746a7cae9
RDX: 0000000000000001 RSI: 0000000020000b80 RDI: 0000000000001d1b
RBP: 00007f0746ac847a R08: 0000000000000001 R09: 0000000000000000
R10: 0000000020000f80 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f0746b9bf80 R15: 00007f0746cbfa48
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__lock_acquire+0x109/0x5de0 kernel/locking/lockdep.c:5004
Code: 45 85 c9 0f 84 cc 0e 00 00 44 8b 05 21 dc 81 0b 45 85 c0 0f 84 be 0d 00 00 48 ba 00 00 00 00 00 fc ff df 4c 89 d1 48 c1 e9 03 <80> 3c 11 00 0f 85 e8 40 00 00 49 81 3a e0 09 b3 90 0f 84 96 0d 00
RSP: 0018:ffffc90003387378 EFLAGS: 00010006
RAX: ffff88801d5e9dc0 RBX: 1ffff92000670e9f RCX: 000000000000001d
RDX: dffffc0000000000 RSI: 0000000000000000 RDI: 00000000000000e8
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001
R10: 00000000000000e8 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
FS: 00007f07477fc6c0(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000b80 CR3: 000000006a8b7000 CR4: 00000000003506f0
----------------
Code disassembly (best guess):
0: 45 85 c9 test %r9d,%r9d
3: 0f 84 cc 0e 00 00 je 0xed5
9: 44 8b 05 21 dc 81 0b mov 0xb81dc21(%rip),%r8d # 0xb81dc31
10: 45 85 c0 test %r8d,%r8d
13: 0f 84 be 0d 00 00 je 0xdd7
19: 48 ba 00 00 00 00 00 movabs $0xdffffc0000000000,%rdx
20: fc ff df
23: 4c 89 d1 mov %r10,%rcx
26: 48 c1 e9 03 shr $0x3,%rcx
* 2a: 80 3c 11 00 cmpb $0x0,(%rcx,%rdx,1) <-- trapping instruction
2e: 0f 85 e8 40 00 00 jne 0x411c
34: 49 81 3a e0 09 b3 90 cmpq $0xffffffff90b309e0,(%r10)
3b: 0f .byte 0xf
3c: 84 .byte 0x84
3d: 96 xchg %eax,%esi
3e: 0d .byte 0xd


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[xingwei lee]

Hello, since I found there is no reproduce from then to now. I try to reproduce this bug to generate repro.c.

Maybe this bug is the same bug as [syzbot] [mm?] general protection fault in hugetlb_vma_lock_write.
But no matter what, with the reproduce.c, we can quickly fix this bug or check the correctness of our fix.

#define _GNU_SOURCE

#include <dirent.h>
#include <endian.h>
#include <errno.h>
#include <fcntl.h>
#include <sched.h>
#include <signal.h>
#include <stdarg.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/prctl.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <time.h>
#include <unistd.h>

#ifndef __NR_memfd_create
#define __NR_memfd_create 319
#endif

static void sleep_ms(uint64_t ms)
{
usleep(ms * 1000);
}

static uint64_t current_time_ms(void)
{
struct timespec ts;
if (clock_gettime(CLOCK_MONOTONIC, &ts))
exit(1);
return (uint64_t)ts.tv_sec * 1000 + (uint64_t)ts.tv_nsec / 1000000;
}

static bool write_file(const char* file, const char* what, ...)
{
char buf[1024];
va_list args;
va_start(args, what);
vsnprintf(buf, sizeof(buf), what, args);
va_end(args);
buf[sizeof(buf) - 1] = 0;
int len = strlen(buf);
int fd = open(file, O_WRONLY | O_CLOEXEC);
if (fd == -1)
return false;
if (write(fd, buf, len) != len) {
int err = errno;
close(fd);
errno = err;
return false;
}
close(fd);
return true;
}

static void kill_and_wait(int pid, int* status)
{
kill(-pid, SIGKILL);
kill(pid, SIGKILL);
for (int i = 0; i < 100; i++) {
if (waitpid(-1, status, WNOHANG | __WALL) == pid)
return;
usleep(1000);
}
DIR* dir = opendir("/sys/fs/fuse/connections");
if (dir) {
for (;;) {
struct dirent* ent = readdir(dir);
if (!ent)
break;
if (strcmp(ent->d_name, ".") == 0 || strcmp(ent->d_name, "..") == 0)
continue;
char abort[300];
snprintf(abort, sizeof(abort), "/sys/fs/fuse/connections/%s/abort", ent->d_name);
int fd = open(abort, O_WRONLY);
if (fd == -1) {
continue;
}
if (write(fd, abort, 1) < 0) {
}
close(fd);
}
closedir(dir);
} else {
}
while (waitpid(-1, status, __WALL) != pid) {
}
}

static void setup_test()
{
prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0);
setpgrp();
write_file("/proc/self/oom_score_adj", "1000");
}

#define USLEEP_FORKED_CHILD (3 * 50 *1000)

static long handle_clone_ret(long ret)
{
if (ret != 0) {
return ret;
}
usleep(USLEEP_FORKED_CHILD);
syscall(__NR_exit, 0);
while (1) {
}
}

static long syz_clone(volatile long flags, volatile long stack, volatile long stack_len,
      volatile long ptid, volatile long ctid, volatile long tls)
{
long sp = (stack + stack_len) & ~15;
long ret = (long)syscall(__NR_clone, flags & ~CLONE_VM, sp, ptid, ctid, tls);
return handle_clone_ret(ret);
}

static void execute_one(void);

#define WAIT_FLAGS __WALL

static void loop(void)
{
int iter = 0;
for (;; iter++) {
int pid = fork();
if (pid < 0)
exit(1);
if (pid == 0) {
setup_test();
execute_one();
exit(0);
}
int status = 0;
uint64_t start = current_time_ms();
for (;;) {
if (waitpid(-1, &status, WNOHANG | WAIT_FLAGS) == pid)
break;
sleep_ms(1);
if (current_time_ms() - start < 5000)
continue;
kill_and_wait(pid, &status);
break;
}
}
}

uint64_t r[2] = {0xffffffffffffffff, 0x0};

void execute_one(void)
{
intptr_t res = 0;
memcpy((void*)0x20000800, "\001\375\256.+\246\214\266?2\0319\224S,|x?Ue[\275\341!\0033\274\'#\377\027\233%\363[d  \227\365G\227A\302\330\360Uq\346+\245l\224\v\266\a\027\\\373\004!\344\304\261\262\034\377C;\224Q\r\266}\234\354C\v\317\353\344\232R\345,\202\003\000\031\215\350\306\271\344\264\231\212\031P\270\214x\b\231\004R\005\257\242\3525\f\314\032\233\000Uf\245\367\200Tgi\264\300\346\264\357\250i\330\242\322(\230\233A\217\023\353\364b/\357!\217\366]-\351k\2662\211gEv\023\364\307\262\365\\\027\220\265\246\250\270o\017\342 \347\234$\327\362@\367cdv[\t\000\215\363\3141\r$\036\377\360P\262\227\270\274\353\221\207\213u\277\324\'\377\037\f\0016\235Q\356T\350\bY\000\262\006\246\276l\233.o\276\200\235x\325O\326h\\I\311\215\a\035\311\017\202\333s\307\203L\236\242\321\263\254\215\330\264\264\352\220Q\330\307\353%\213Op\032b\226\317\273\025\317\374N\355\000\000\000\000\000\000\000\000\000\000\000\000\000s\257\242\024]p+\226\036i|n\332\356\\\256\226*\202*\270j\332\252\024\037\035\370\370\256\374H\304\263j\350\317O\357\016\257e\265*\211\030\262w\226\b\033y\352T\335\263g6\274\205\262Y\314v\006\000\000\000\305e\220\3051\237\v_# \b\245\274P,|\351\326s\037\037\276\323\200\261\250 \316|df\2203\v\002\352.\003X\265\344,8\267\255EI\334A\247\314\327\371n\033\225\370\021Z\346:\003\316\376\002\214tdy~_oC\236\357\360\242K\351;\216:\001\003C\222\353\026\000\000\000\000\314Uxhg\377\344\a\203\246z\377\001\235 o_{!O\252jU\204 \351\2659r\234w\030Z\323\315\016\272\\\333\360\341\206\340\037\373\322\247\2040\216\n\275^\005\300\316uC}\250\307\255\206\327\025&\271]1\005J\226\360\204\301\f\246p\226\270\002\023pA\031\tf\022\210\310\234\311Cn\324\2447V\'+\314\277\r\251\020\035\317\353Klb\345:\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000G\337\273\300_\231F\364n]\024\274\315\323\237\237e\305\346\350Mb\306\202\202\314\312Xe\341\242\252\002\206\270\030\342C\353\251\027&\001&\'w\241t0\200\360\223\200\237\233\340\237\352\271\236D]#V\332\222\312\306\372.\326\3431\376\350\002\353X\220@\352\224\237a/\242-E\337\030yoSYua\031\357\363I\001\361\266\222gl7\361\035\027\027\361\313\217]\351Z\263q\365N\207\326q\300\320\213\273+\205\v\335n2lV\260]\254T\2636J\352\324\236\357L^ \301\364\374\000\000\000\000\000\000\000\000\000\000\000", 746);
res = syscall(__NR_memfd_create, /*name=*/0x20000800ul, /*flags=*/5ul);
if (res != -1)
r[0] = res;
syscall(__NR_mmap, /*addr=*/0x20000000ul, /*len=*/0x4000ul, /*prot=*/0xeul, /*flags=*/0x12ul, /*fd=*/r[0], /*offset=*/0ul);
syscall(__NR_socketpair, /*domain=*/2ul, /*type=*/2ul, /*proto=*/0, /*fds=*/0x200008c0ul);
res = -1;
res = syz_clone(/*flags=*/0, /*stack=*/0, /*stack_len=*/0, /*parentid=*/0, /*childtid=*/0, /*tls=*/0);
if (res != -1)
r[1] = res;
*(uint64_t*)0x20000f80 = 0;
*(uint64_t*)0x20000f88 = 0;
syscall(__NR_process_vm_writev, /*pid=*/r[1], /*loc_vec=*/0ul, /*loc_vlen=*/0ul, /*rem_vec=*/0x20000f80ul, /*rem_vlen=*/1ul, /*flags=*/0ul);

}
int main(void)
{
syscall(__NR_mmap, /*addr=*/0x1ffff000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=*/0x32ul, /*fd=*/-1, /*offset=*/0ul);
syscall(__NR_mmap, /*addr=*/0x20000000ul, /*len=*/0x1000000ul, /*prot=*/7ul, /*flags=*/0x32ul, /*fd=*/-1, /*offset=*/0ul);
syscall(__NR_mmap, /*addr=*/0x21000000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=*/0x32ul, /*fd=*/-1, /*offset=*/0ul);
loop();
return 0;
}

[Aleksandr Nogikh]

Please report it to the original thread on the Linux kernel mailing lists (to the same To and Cc). It's unlikely that relevant people will notice it just from the `syzkaller-bugs` list.

--
You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/8e1cd1e1-3941-4f01-8e85-dff9acd1d047n%40googlegroups.com.

[xingwei lee]

Hello, since I found there is no reproduce from then to now. I try to reproduce this bug to generate repro.c.

Maybe this bug is the same bug as [syzbot] [mm?] general protection fault in hugetlb_vma_lock_write I guess...

[xingwei lee]

Hi, nogikh. 

Since I was the frist to mail Linux kernel mailing lists and try to mail as you said above.

can I bother you to check my action is corret or not?

https://syzkaller.appspot.com/bug?extid=93e7c679006f0d4e6105

https://lore.kernel.org/all/CABOYnLzpDMPd3fJhi38N_jcQ...@mail.gmail.com/T/

and I also get the mail from the mail system makes me puzzled

This is the mail system at host lindbergh.monkeyblade.net

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

Thanks anyway.

[Mike Kravetz]

On 11/16/23 15:53, xingwei lee wrote:
> Hello, since I found there is no reproduce from then to now. I try to
> reproduce this bug to generate repro.c.
> Maybe this bug is the same bug as [syzbot] [mm?] general protection fault
> in hugetlb_vma_lock_write I guess...
> But no matter what, with the reproduce.c, we can quickly fix this bug or
> check the correctness of our fix.

I am not sure what fix you suggested for this issue. The following was
sent upstream and is now included in Andrew's tree and linux-next.

https://lore.kernel.org/linux-mm/20231114012033.259...@oracle.com/

I tested with a reproducer previously provided by syzbot, and assume this
resolves the issue with your reproducer as well.
--
Mike Kravetz

[Aleksandr Nogikh]

I think it's normal -- some of the emails were taken from commit history and may no longer exist. Don't worry about this specific error much.
Your email was definitely accepted by the Linux kernel mailing lists and you got a reply, which was the actual intention.

--
You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/d7e35093-c68f-45b0-89e0-9e33cfe56e95n%40googlegroups.com.

[syzbot]

Auto-closing this bug as obsolete.
Crashes did not happen for a while, no reproducer and no activity.