linux-kernel - Re: CVE-2024-26774: ext4: avoid dividing by 0 in mb_update_avg_fragment

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: <20240417145446.uh2rqcbxlebnkbfm@quack3>
Date: Wed, 17 Apr 2024 16:54:46 +0200
From: Jan Kara <jack@...e.cz>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Jan Kara <jack@...e.cz>, cve@...nel.org, linux-kernel@...r.kernel.org,
	linux-cve-announce@...r.kernel.org
Subject: Re: CVE-2024-26774: ext4: avoid dividing by 0 in
 mb_update_avg_fragment_size() when block bitmap corrupt

On Wed 17-04-24 15:30:03, Greg Kroah-Hartman wrote:
> On Wed, Apr 17, 2024 at 01:43:24PM +0200, Jan Kara wrote:
> > Hello!
> > 
> > On Wed 03-04-24 19:31:41, Greg Kroah-Hartman wrote:
> > > Description
> > > ===========
> > > 
> > > In the Linux kernel, the following vulnerability has been resolved:
> > > 
> > > ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt
> > > 
> > > Determine if bb_fragments is 0 instead of determining bb_free to eliminate
> > > the risk of dividing by zero when the block bitmap is corrupted.
> > > 
> > > The Linux kernel CVE team has assigned CVE-2024-26774 to this issue.
> > 
> > I'd like to understand what is the imagined security threat fixed by this
> > patch (as multiple patches of similar nature got assigned a CVE). The patch
> > fixes a bug that if a corrupted filesystem is read-write mounted, we can do
> > division-by-zero. Now if you can make the system mount a corrupted
> > filesystem, you can do many interesting things to the system other than
> > create a division by zero... So what is the presumed threat model here?
> 
> Exactly what you said, "if you mount a corrupted file system, you will
> get a divide by zero fault."
> 
> Many systems auto-mount any filesystem plugged into it.  If yours do
> not, then yours does not need to worry about this type of CVE.

OK, understood. But let me state that with the current state of affairs in
the filesystem land, it will not take a determined attacker long to get
arbitrary code execution out of "maliciously corrupted fs mounted". The
code of most filesystems has simply never been written with the assumption
that it can be presented with malicious data and we have hundreds of
thousands lines of code like that. We have fixed the most glaring problems
but by far not all (partly because of performance and maintenance costs,
partly because they are baked into on-disk formats).

So if we should honestly state the situation (and filesystem folks are
trying to get this message across for a few years already), we should issue
a CVE for "mounting untrusted fs image can crash your kernel or install
rootkit to your system". And yes, I know most distros will happily mount
whatever is plugged into the USB port because that is what users expect and
it is convenient. So if anybody wants a practical solution to this security
problem, I'd suggest working on FUSE drivers for filesystems you care about
and make distros use that when mounting removable media... That is actually
pretty secure and robust solution if you don't care about performance
*that* much.

								Honza

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