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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <rfm3midn4sz32sx2wpmg5hnrktw3pjdy7nqr442b2zhm2qptjv@35s3k4tdyaho>
Date: Mon, 6 Jan 2025 10:26:58 +0100
From: Jan Kara <jack@...e.cz>
To: Kun Hu <huk23@...udan.edu.cn>
Cc: jack@...e.com, linux-kernel@...r.kernel.org, 
	"jjtan24@...udan.edu.cn" <jjtan24@...udan.edu.cn>
Subject: Re: Bug: use-after-free in udf_statfs in fs/udf/super.c:2415

On Mon 06-01-25 14:42:00, Kun Hu wrote:
> > 2025年1月2日 10:10,Kun Hu <huk23@...udan.edu.cn> 写道:
> >> HEAD commit: dbfac60febfa806abb2d384cb6441e77335d2799
> >> git tree: upstream
> >> Console output: https://drive.google.com/file/d/1-YGytaKuh9M4hI6x27YjsE0vSyRFngf5/view?usp=sharing
> >> Kernel config: https://drive.google.com/file/d/1m1mk_YusR-tyusNHFuRbzdj8KUzhkeHC/view?usp=sharing
> >> C reproducer: /
> >> Syzlang reproducer: /
> >> 
> >> It seems that the issue originates from the udf_statfs function at line 2415, where 
> >> lvidiu might have been prematurely freed, leading to a Use-After-Free (UAF). 
> >> This could potentially pose some security risks. However, there is currently 
> >> no stable reproducer for this issue.
> >> It is also unclear whether this might have been caused by a race condition, potentially 
> >> involving premature freeing in another thread.
> >> 
> > 
> > Hi, we found this same issue again. I'm guessing it's necessary to put a lock around the if in the udf_sb_lvidiu function on line 115 in super.c aka udf_sb_lvidiu function to protect the pointer's lifecycle? A similar call stack would look like this:
> > 
> > BUG: unable to handle page fault for address: ffe21c001059f6e7
> > #PF: supervisor read access in kernel mode
> > #PF: error_code(0x0000) - not-present page
> > PGD 7fdd7067 P4D 7fdd6067 PUD 7fdd5067 PMD 0 
> > Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
> > CPU: 3 UID: 0 PID: 10494 Comm: syz.7.1124 Not tainted 6.13.0-rc4 #1
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
> > RIP: 0010:udf_statfs+0x61e/0x12c0 fs/udf/super.c:2415
> > Code: 4c 89 7b 20 4c 89 fd 4d 85 f6 0f 84 c0 00 00 00 e8 27 74 cd fe 49 8d 7e 20 48 b9 00 00 00 00 00 fc ff df 48 89 f8 48 c1 e8 03 <0f> b6 14 08 49 8d 46 23 48 89 c6 48 c1 ee 03 0f b6 0c 0e 48 89 fe
> > RSP: 0018:ffa0000003937c20 EFLAGS: 00010216
> > RAX: 1fe220001059f6e7 RBX: ffa0000003937e48 RCX: dffffc0000000000
> > RDX: ffa000000d347000 RSI: ff11000049e58000 RDI: ff11000082cfb738
> > RBP: 00000000f8b31fcb R08: 0000000000000001 R09: ff11000049e58a38
> > R10: fffffbfff2377aaa R11: ffffffff91bbd557 R12: 00000000f8b31fcb
> > R13: 0000000000000000 R14: ff11000082cfb718 R15: 00000000f8b31fcb
> > FS:  00007f6b73608700(0000) GS:ff1100006a380000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: ffe21c001059f6e7 CR3: 000000001dff8001 CR4: 0000000000771ef0
> > PKRU: 80000000
> > Call Trace:
> > <TASK>
> > statfs_by_dentry+0x138/0x220 fs/statfs.c:66
> > vfs_statfs+0x44/0x2f0 fs/statfs.c:90
> > fd_statfs+0x49/0x90 fs/statfs.c:121
> > __do_sys_fstatfs+0x7a/0xf0 fs/statfs.c:214
> > do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> > do_syscall_64+0xc3/0x1d0 arch/x86/entry/common.c:83
> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
> > RIP: 0033:0x7f6b749b471d
> > Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 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:00007f6b73607ba8 EFLAGS: 00000246 ORIG_RAX: 000000000000008a
> > RAX: ffffffffffffffda RBX: 00007f6b74b76f80 RCX: 00007f6b749b471d
> > RDX: 0000000000000000 RSI: 0000000020000d40 RDI: 0000000000000005
> > RBP: 00007f6b74a29425 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> > R13: 00007f6b74b76f8c R14: 00007f6b74b77018 R15: 00007f6b73607d40
> > </TASK>
> > Modules linked in:
> > CR2: ffe21c001059f6e7
> > ---[ end trace 0000000000000000 ]---
> > RIP: 0010:udf_statfs+0x61e/0x12c0 fs/udf/super.c:2415
> > Code: 4c 89 7b 20 4c 89 fd 4d 85 f6 0f 84 c0 00 00 00 e8 27 74 cd fe 49 8d 7e 20 48 b9 00 00 00 00 00 fc ff df 48 89 f8 48 c1 e8 03 <0f> b6 14 08 49 8d 46 23 48 89 c6 48 c1 ee 03 0f b6 0c 0e 48 89 fe
> > RSP: 0018:ffa0000003937c20 EFLAGS: 00010216
> > RAX: 1fe220001059f6e7 RBX: ffa0000003937e48 RCX: dffffc0000000000
> > RDX: ffa000000d347000 RSI: ff11000049e58000 RDI: ff11000082cfb738

Well, checking the assembly RDI should contain the partition number but it
is apparently some pointer. So the buffer for LVID got corrupted. How that
happened is really impossible to say without a reproducer. The problem
needn't even be in UDF code. So for now it is sadly impossible to do
anything meaningful about this bug.

								Honza

-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ