Messages in this thread | | | Date | Wed, 17 Apr 2024 16:54:46 +0200 | From | Jan Kara <> | 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@suse.com> SUSE Labs, CR
| |