From: Jan Kara <jack@suse.cz>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jan Kara <jack@suse.cz>,
cve@kernel.org, linux-kernel@vger.kernel.org,
linux-cve-announce@vger.kernel.org
Subject: Re: CVE-2024-26774: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt
Date: Wed, 17 Apr 2024 16:54:46 +0200 [thread overview]
Message-ID: <20240417145446.uh2rqcbxlebnkbfm@quack3> (raw)
In-Reply-To: <2024041711-chapter-uninstall-b1d3@gregkh>
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@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2024-04-17 14:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2024040308-CVE-2024-26774-52d9@gregkh>
2024-04-17 11:43 ` Jan Kara
2024-04-17 13:30 ` Greg Kroah-Hartman
2024-04-17 14:54 ` Jan Kara [this message]
2024-04-17 15:29 ` Theodore Ts'o
2024-04-17 16:12 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240417145446.uh2rqcbxlebnkbfm@quack3 \
--to=jack@suse.cz \
--cc=cve@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®