linux-kernel

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAKHoSAutgu+oKbVv9+mXmAiYtTJFKrdOAdR3Y2JP_bFDLszK4w@mail.gmail.com>
Date: Fri, 3 Jan 2025 15:53:53 +0800
From: cheung wall <zzqq0103.hey@...il.com>
To: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Will Deacon <will@...nel.org>
Cc: Waiman Long <longman@...hat.com>, Boqun Feng <boqun.feng@...il.com>, 
	linux-kernel@...r.kernel.org
Subject: 

Hello,

I am writing to report a potential vulnerability identified in the
Linux Kernel version 5.15.169. This issue was discovered using our
custom vulnerability discovery tool.

Affected File: kernel/locking/lockdep.c

File: kernel/locking/lockdep.c

Function: look_up_lock_class

Detailed Call Stack:

------------[ cut here begin]------------

RIP: 0010:look_up_lock_class+0x86/0x110 kernel/locking/lockdep.c:895
Code: 24 e8 8e 02 00 00 4d 85 e4 74 2c 49 39 5c 24 40 75 eb 48 8b 45
18 49 39 84 24 b0 00 00 00 74 1a 48 81 7d 00 00 04 15 86 74 10 <0f> 0b
eb 0c e8 51 88 12 fe 85 c0 75 50 45 31 e4 48 83 c4 08 4c 89
RSP: 0018:ffff88801e48f608 EFLAGS: 00010006
RAX: ffffffff8453bd20 RBX: ffffffff871b6361 RCX: 0000000000000000
RDX: 0000000000000046 RSI: 0000000000000001 RDI: ffff888007d31618
RBP: ffff888007d31618 R08: 0000000000000000 R09: 0000000000000000
R10: fffffbfff0ad07aa R11: 0000000000000001 R12: ffffffff868bad00
R13: ffffffff86bf38e0 R14: 0000000000000001 R15: 0000000000000000
FS: 00007f0bef4716c0(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020010000 CR3: 0000000113c48000 CR4: 0000000000350ee0
Call Trace:
<TASK>
register_lock_class+0xbd/0x1870 kernel/locking/lockdep.c:1245
__lock_acquire+0x102/0x6070 kernel/locking/lockdep.c:4891
lock_acquire kernel/locking/lockdep.c:5623 [inline]
lock_acquire+0x194/0x470 kernel/locking/lockdep.c:5588
down_write_nested+0x94/0x1f0 kernel/locking/rwsem.c:1667
ext4_double_down_write_data_sem fs/ext4/move_extent.c:54 [inline]
ext4_double_down_write_data_sem fs/ext4/move_extent.c:50 [inline]
ext4_move_extents+0x39e/0x3280 fs/ext4/move_extent.c:609
__ext4_ioctl+0x2d5f/0x36c0 fs/ext4/ioctl.c:990
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x33/0x80 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x6c/0xd6
<TASK>

------------[ cut here end]------------

Root Cause:

The kernel crash was caused by a locking issue detected by the Linux
kernel's lock dependency checker (lockdep) within the ext4 filesystem.
Specifically, the crash occurred in the look_up_lock_class function of
lockdep.c when the ext4_move_extents function attempted to acquire a
write lock using down_write_nested. This sequence suggests that there
was a violation in the lock acquisition order or an improper lock
usage pattern in the ext4 code handling extent movements. Such a
locking inconsistency likely led to a potential deadlock scenario,
prompting lockdep to identify the problem and trigger a kernel panic
to prevent further system instability. In summary, the root cause of
the crash is a lock dependency violation in the ext4 filesystem's
extent management code, resulting in lockdep detecting an unsafe lock
acquisition sequence and halting the system to avoid a deadlock.

Thank you for your time and attention.

Best regards

Wall