| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <aEFl9FWQHEJqnl2Q@pathway.suse.cz>
Date: Thu, 5 Jun 2025 11:40:04 +0200
From: Petr Mladek <pmladek@...e.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: syzbot <syzbot+23de6daeb71241d36a18@...kaller.appspotmail.com>,
Liam.Howlett@...cle.com, akpm@...ux-foundation.org,
jannh@...gle.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
lorenzo.stoakes@...cle.com, pfalcato@...e.de,
syzkaller-bugs@...glegroups.com,
Suren Baghdasaryan <surenb@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
John Ogness <john.ogness@...utronix.de>
Subject: Re: [syzbot] [mm?] possible deadlock in __vma_start_write
On Wed 2025-06-04 09:52:24, Vlastimil Babka wrote:
> On 5/29/25 17:40, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: d7fa1af5b33e Merge branch 'for-next/core' into for-kernelci
> > git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
> > console output: https://syzkaller.appspot.com/x/log.txt?x=12bbdad4580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=89c13de706fbf07a
> > dashboard link: https://syzkaller.appspot.com/bug?extid=23de6daeb71241d36a18
> > compiler: Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6
> > userspace arch: arm64
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/da97ad659b2c/disk-d7fa1af5.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/659e123552a8/vmlinux-d7fa1af5.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/6ec5dbf4643e/Image-d7fa1af5.gz.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+23de6daeb71241d36a18@...kaller.appspotmail.com
> >
> > SQUASHFS error: zstd decompression failed, data probably corrupt
> > SQUASHFS error: Failed to read block 0x60: -5
> > ======================================================
> > WARNING: possible circular locking dependency detected
> > 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 Not tainted
> > ------------------------------------------------------
> > syz.1.261/8150 is trying to acquire lock:
> > ffff0000d7ffcbc8 (vm_lock){++++}-{0:0}, at: __vma_start_write+0x34/0x158 mm/memory.c:6497
> >
> > but task is already holding lock:
> > ffff0000d572df50 (&mm->mmap_lock){++++}-{4:4}, at: mmap_write_lock include/linux/mmap_lock.h:128 [inline]
> > ffff0000d572df50 (&mm->mmap_lock){++++}-{4:4}, at: exit_mmap+0x200/0xbec mm/mmap.c:1292
> >
> > which lock already depends on the new lock.
> >
> >
> > the existing dependency chain (in reverse order) is:
> >
> > -> #6 (&mm->mmap_lock){++++}-{4:4}:
> > __might_fault+0xc4/0x124 mm/memory.c:7151
> > drm_mode_get_lease_ioctl+0x2bc/0x53c drivers/gpu/drm/drm_lease.c:673
> > drm_ioctl_kernel+0x238/0x310 drivers/gpu/drm/drm_ioctl.c:796
> > drm_ioctl+0x65c/0xa5c drivers/gpu/drm/drm_ioctl.c:893
> > vfs_ioctl fs/ioctl.c:51 [inline]
> > __do_sys_ioctl fs/ioctl.c:906 [inline]
> > __se_sys_ioctl fs/ioctl.c:892 [inline]
> > __arm64_sys_ioctl+0x14c/0x1c4 fs/ioctl.c:892
> > __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
> > invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
> > el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
> > do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
> > el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767
> > el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786
> > el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
> >
> > -> #5 (&dev->mode_config.idr_mutex){+.+.}-{4:4}:
> > __mutex_lock_common+0x1d0/0x2190 kernel/locking/mutex.c:601
> > __mutex_lock kernel/locking/mutex.c:746 [inline]
> > mutex_lock_nested+0x2c/0x38 kernel/locking/mutex.c:798
> > __drm_mode_object_add+0xa8/0x1f0 drivers/gpu/drm/drm_mode_object.c:47
> > drm_framebuffer_init+0x14c/0x2bc drivers/gpu/drm/drm_framebuffer.c:875
> > drm_gem_fb_init drivers/gpu/drm/drm_gem_framebuffer_helper.c:82 [inline]
> > drm_gem_fb_init_with_funcs+0xa60/0xda4 drivers/gpu/drm/drm_gem_framebuffer_helper.c:202
> > drm_gem_fb_create_with_funcs drivers/gpu/drm/drm_gem_framebuffer_helper.c:245 [inline]
> > drm_gem_fb_create+0x84/0xd4 drivers/gpu/drm/drm_gem_framebuffer_helper.c:286
> > drm_internal_framebuffer_create+0xfcc/0x19dc drivers/gpu/drm/drm_framebuffer.c:304
> > drm_mode_addfb2+0xac/0x2a0 drivers/gpu/drm/drm_framebuffer.c:338
> > drm_client_buffer_addfb drivers/gpu/drm/drm_client.c:386 [inline]
> > drm_client_framebuffer_create+0x2d0/0x55c drivers/gpu/drm/drm_client.c:428
> > drm_fbdev_shmem_driver_fbdev_probe+0x180/0x70c drivers/gpu/drm/drm_fbdev_shmem.c:151
> > drm_fb_helper_single_fb_probe drivers/gpu/drm/drm_fb_helper.c:1649 [inline]
> > __drm_fb_helper_initial_config_and_unlock+0xf94/0x159c drivers/gpu/drm/drm_fb_helper.c:1829
> > drm_fb_helper_initial_config+0x3c/0x58 drivers/gpu/drm/drm_fb_helper.c:1916
> > drm_fbdev_client_hotplug+0x154/0x22c drivers/gpu/drm/clients/drm_fbdev_client.c:52
> > drm_client_register+0x13c/0x1d4 drivers/gpu/drm/drm_client.c:140
> > drm_fbdev_client_setup+0x194/0x3d0 drivers/gpu/drm/clients/drm_fbdev_client.c:159
> > drm_client_setup+0x78/0x140 drivers/gpu/drm/clients/drm_client_setup.c:39
> > vkms_create drivers/gpu/drm/vkms/vkms_drv.c:218 [inline]
> > vkms_init+0x4b8/0x5ac drivers/gpu/drm/vkms/vkms_drv.c:242
> > do_one_initcall+0x250/0x990 init/main.c:1257
> > do_initcall_level+0x154/0x214 init/main.c:1319
> > do_initcalls+0x84/0xf4 init/main.c:1335
> > do_basic_setup+0x8c/0xa0 init/main.c:1354
> > kernel_init_freeable+0x2dc/0x444 init/main.c:1567
> > kernel_init+0x24/0x1dc init/main.c:1457
> > ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847
> >
> > -> #4 (&helper->lock){+.+.}-{4:4}:
> > __mutex_lock_common+0x1d0/0x2190 kernel/locking/mutex.c:601
> > __mutex_lock kernel/locking/mutex.c:746 [inline]
> > mutex_lock_nested+0x2c/0x38 kernel/locking/mutex.c:798
> > __drm_fb_helper_restore_fbdev_mode_unlocked+0x74/0x198 drivers/gpu/drm/drm_fb_helper.c:228
> > drm_fb_helper_set_par+0xa4/0x108 drivers/gpu/drm/drm_fb_helper.c:1359
> > fbcon_init+0xe4c/0x1d18 drivers/video/fbdev/core/fbcon.c:1112
> > visual_init+0x27c/0x540 drivers/tty/vt/vt.c:1011
> > do_bind_con_driver+0x7b8/0xdd8 drivers/tty/vt/vt.c:3831
> > do_take_over_console+0x824/0x97c drivers/tty/vt/vt.c:4397
> > do_fbcon_takeover+0x158/0x25c drivers/video/fbdev/core/fbcon.c:548
> > do_fb_registered drivers/video/fbdev/core/fbcon.c:2989 [inline]
> > fbcon_fb_registered+0x354/0x4c8 drivers/video/fbdev/core/fbcon.c:3009
> > do_register_framebuffer drivers/video/fbdev/core/fbmem.c:449 [inline]
> > register_framebuffer+0x44c/0x5ec drivers/video/fbdev/core/fbmem.c:515
> > __drm_fb_helper_initial_config_and_unlock+0x103c/0x159c drivers/gpu/drm/drm_fb_helper.c:1851
> > drm_fb_helper_initial_config+0x3c/0x58 drivers/gpu/drm/drm_fb_helper.c:1916
> > drm_fbdev_client_hotplug+0x154/0x22c drivers/gpu/drm/clients/drm_fbdev_client.c:52
> > drm_client_register+0x13c/0x1d4 drivers/gpu/drm/drm_client.c:140
> > drm_fbdev_client_setup+0x194/0x3d0 drivers/gpu/drm/clients/drm_fbdev_client.c:159
> > drm_client_setup+0x78/0x140 drivers/gpu/drm/clients/drm_client_setup.c:39
> > vkms_create drivers/gpu/drm/vkms/vkms_drv.c:218 [inline]
> > vkms_init+0x4b8/0x5ac drivers/gpu/drm/vkms/vkms_drv.c:242
> > do_one_initcall+0x250/0x990 init/main.c:1257
> > do_initcall_level+0x154/0x214 init/main.c:1319
> > do_initcalls+0x84/0xf4 init/main.c:1335
> > do_basic_setup+0x8c/0xa0 init/main.c:1354
> > kernel_init_freeable+0x2dc/0x444 init/main.c:1567
> > kernel_init+0x24/0x1dc init/main.c:1457
> > ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847
I just wanted to better understand what was going on here ;-)
Let me share my thoughts.
First, the deadlock might happen only when all these (or similar) code
paths might be called in parallel.
The two backtraces, right above, are from initcalls. It is possible
that the code path in the 1st backtrace can't be called before
the device is initialized. So, it is possible that the deadlock
can't happen in the real life.
I guess that this is the reason why people say that the deadlock
is very unlikely.
Second. if we wanted to remove the cyclic dependency then we would
need to break the chain somewhere.
I am not familiar with th fbcon code. But my guess is that we take
console_lock() here to prevent using the graphical console by printk()
while we are switching the driver behind the console.
I am afraid that we might have similar problem even after removing
console_lock. It just would be replaced by another tty-specific lock or so.
Just an idea. A solution would be to temporary pause the related
console. I mean to do something like:
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index ac3c99ed92d1..12ec99b69068 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3002,14 +3002,14 @@ int fbcon_fb_registered(struct fb_info *info)
int ret;
if (!lockless_register_fb)
- console_lock();
+ pause_tty_console();
else
atomic_inc(&ignore_console_lock_warning);
ret = do_fb_registered(info);
if (!lockless_register_fb)
- console_unlock();
+ unpause_tty_console();
else
atomic_dec(&ignore_console_lock_warning);
Where pause_tty_console()/unpause_tty_console() would just set a flag
or manipulate a counter in struct console.
The trick is that do_fb_registered() could then be called
without console_lock(). I hope that it might broke the chain.
Is it worth investigating this approach?
Does it make any sense?
Best Regards,
Petr
Powered by blists - more mailing lists