linux-cve-announce.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* CVE-2024-26774: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt
@ 2024-04-03 17:31 Greg Kroah-Hartman
       [not found] ` <20240417114324.c77wuw5hvjbm6ok5@quack3>
  0 siblings, 1 reply; 3+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-03 17:31 UTC (permalink / raw)
  To: linux-cve-announce; +Cc: Greg Kroah-Hartman

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.


Affected and fixed versions
===========================

	Fixed in 5.15.150 with commit 687061cfaa2a
	Fixed in 6.1.80 with commit 8b40eb2e716b
	Fixed in 6.6.19 with commit f32d2a745b02
	Fixed in 6.7.7 with commit 8cf9cc602cfb
	Fixed in 6.8 with commit 993bf0f4c393

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-26774
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/ext4/mballoc.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/687061cfaa2ac3095170e136dd9c29a4974f41d4
	https://git.kernel.org/stable/c/8b40eb2e716b503f7a4e1090815a17b1341b2150
	https://git.kernel.org/stable/c/f32d2a745b02123258026e105a008f474f896d6a
	https://git.kernel.org/stable/c/8cf9cc602cfb40085967c0d140e32691c8b71cf3
	https://git.kernel.org/stable/c/993bf0f4c393b3667830918f9247438a8f6fdb5b

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: CVE-2024-26774: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt
       [not found] ` <20240417114324.c77wuw5hvjbm6ok5@quack3>
@ 2024-04-17 13:30   ` Greg Kroah-Hartman
       [not found]     ` <20240417145446.uh2rqcbxlebnkbfm@quack3>
  0 siblings, 1 reply; 3+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-17 13:30 UTC (permalink / raw)
  To: Jan Kara; +Cc: cve, linux-kernel, linux-cve-announce

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.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: CVE-2024-26774: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt
       [not found]     ` <20240417145446.uh2rqcbxlebnkbfm@quack3>
@ 2024-04-17 16:12       ` Greg Kroah-Hartman
  0 siblings, 0 replies; 3+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-17 16:12 UTC (permalink / raw)
  To: Jan Kara; +Cc: cve, linux-kernel, linux-cve-announce

On Wed, Apr 17, 2024 at 04:54:46PM +0200, Jan Kara wrote:
> 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).

I totally agree.  It's up to the distros to stop doing this if they wish
to stop this problem from happening.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-04-17 16:12 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-03 17:31 CVE-2024-26774: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt Greg Kroah-Hartman
     [not found] ` <20240417114324.c77wuw5hvjbm6ok5@quack3>
2024-04-17 13:30   ` Greg Kroah-Hartman
     [not found]     ` <20240417145446.uh2rqcbxlebnkbfm@quack3>
2024-04-17 16:12       ` Greg Kroah-Hartman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).