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?
Honza
> 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
--
Jan Kara <[email protected]>
SUSE Labs, CR
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
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 <[email protected]>
SUSE Labs, CR
On Wed, Apr 17, 2024 at 04:54:46PM +0200, Jan Kara wrote:
> 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.
I will note that the insistence of enabling the automounter is
apparently the fault of some Red Hat product manager. Alas, our
requests to "cut that out" have been ignored.
I'll also note that Darrick and I have included udev rules in xfsprogs
and e2fsprogs to disable the automounter for ext4 and xfs file
systems. I believe the xfsprogs udev rules have already been
released, and the ext4 udev rules in e2fsprogs will be released in the
next upstream release.
It will be interesting to see how many distributions explicitly decide
to override our udev rules.... If they do, hopefully the security
liability will attach to those distributions, and they will get
everything that they deserve.
Humming "Flexing like a godd*mn acrobat ; Karma and I vibe like that",
- Ted
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