linux-kernel - Re: Bug: use-after-free in udf

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: <7826F499-9A45-4F25-B3E5-1327A28676BB@m.fudan.edu.cn>
Date: Tue, 7 Jan 2025 18:09:31 +0800
From: Kun Hu <huk23@...udan.edu.cn>
To: Jan Kara <jack@...e.cz>
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



> 2025年1月6日 23:17，Jan Kara <jack@...e.cz> 写道：
> 
> On Mon 06-01-25 23:08:36, Kun Hu wrote:
>>> 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.
>> 
>> There was a bug report with the wrong subject link subject, but the error
>> reported was actually in udf_final_lvid as well, here is the link to the
>> bug
>> 
>> link: https://lore.kernel.org/lkml/7BCBA139-3942-436A-B7B1-72EDDE51072F@m.fudan.edu.cn/T/
>> 
>> Regarding why this link is mentioned above, it's because the current bug in the email we tried several times to get a replicator for c and syzlang, but the location of this bug report changed (see below for the replicator). The bug still seems to be the same bug that was previously found in the rc3 version, which is the link above.
>> 
>> c reproducer: https://drive.google.com/file/d/13R46qr1MD07VrFICxeBoeuwbuFVzJVBK/view?usp=sharing
>> syzlang reproducer: https://drive.google.com/file/d/1hQiJGYG3Dy1z9mGmsxtDKqJ1BElES2Hh/view?usp=sharing
>> 
>> I may be focusing on the Fuzzing method itself, locating this issue is a
>> bit difficult for me, and this new c replicator is very redundant and
>> doesn't seem to have much value? Do you see if I can provide any test
>> information to find the root cause of this problem?
>> 
>> The above reproducer is the result I just got, I haven't disabled
>> CONFIG_BLK_DEV_WRITE_MOUNTED yet. Do I need to disable it and then test
>> to observe the result?
> 
> Yes, please disable CONFIG_BLK_DEV_WRITE_MOUNTED. The reproducer is still
> messing with multiple filesystems and underlying devices so it is very
> likely it actually manages to corrupt the device under a live filesystem.
> 
> Honza
> -- 
> Jan Kara <jack@...e.com>
> SUSE Labs, CR
> 

Hi, Jan.

I'd like to ask a question: about this option should I have it all turned off for testing? If I don't turn it off it's equivalent to having absolute read/write access to the kernel, or even fault injection. Although the use of fault injection is a way to observe the stability of the system, but even if the bug found may not be able to be further exploited from the user state and lead to security vulnerabilities? Is that right?

———
Thanks,
Kun Hu