Message-ID: <gehihzgtjkbbwn6sexavsbrnv4f5khir43zcrhg7hbkrr3kfjq@ufcgfbxvros5>
Date: Tue, 7 Jan 2025 12:58:52 +0100
From: Jan Kara <jack@...e.cz>
To: Kun Hu <huk23@...udan.edu.cn>
Cc: Jan Kara <jack@...e.cz>, 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 Tue 07-01-25 18:09:31, Kun Hu wrote:
> > 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?

Yes.

> 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?

So this is about your threat model. Writing to the device while a filesystem
is mounted there is corrupting its cached state - i.e., it is effectively
equivalent to corrupting memory. Generally only system administrator can do
this and hence there is not any security vulnerability because the system
administrator has better means of compromising the machine.

That being said there are locked down configurations where even root is not
expected to be able to get full control of the kernel but then you must
have this properly configured and disabling CONFIG_BLK_DEV_WRITE_MOUNTED is
one of the things you should do in such case.

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

Powered by blists - more mailing lists