[SRU][F][PATCH 0/4] CVE-2021-3428

[Thadeu Lima de Souza Cascardo]

On Fri, Oct 08, 2021 at 10:10:31AM -0700, Luke Nowakowski-Krijger wrote:
> Hi Thadeu,
> 
> Not hard. I already had one prepared but saw that those commits were easy
> enough to find and apply. They do add a lot but the changes seemed
> straightforward enough. Do you think it would be better to exclude those
> other patches?
> 
> (p.s. resent the message because forgot to cc ML)
> 
> - Luke

They do make it harder to review, specially given they are not clean
cherry-picks. And the diffstat does give me the chills. Given this is an SRU,
by the quick look at the patch you sent, I thought about asking, in case this
was only around some error reporting.

By trying a quick cherry-pick, it turns out it isn't that trivial, so perhaps
not worth it, given you already have tested your version and we get better
error reporting as a result of this. I have the impression that the potential
regression will be similar.

So just fixup your backport annotations for the v2.

Thanks.
Cascardo.

> 
> On Fri, Oct 8, 2021 at 6:04 AM Thadeu Lima de Souza Cascardo <
> cascardo at canonical.com> wrote:
> 
> > On Thu, Oct 07, 2021 at 01:05:46PM -0700, Luke Nowakowski-Krijger wrote:
> > > [Impact]
> > > Mounting a crafted ext4 filesystem can trigger an integer overflow
> > > that occurs in ext4_es_cache_extent(). This yields a kernel bug that can
> > > lead to a system crash and denial of service.
> > >
> > > [Backports]
> > > Updated minor context changes in fs/ext4/ext4.h to include
> > sbi_array_rcu_deref
> > > define.
> > >
> >
> > Hey, Luke.
> >
> > How hard would the backport of "ext4: check journal inode extents more
> > carefully" be without the other commits?
> >
> > Cascardo.
> >
> > > [Test case]
> > > Reproduced the bug using the reproducer here
> > > (https://bugzilla.suse.com/show_bug.cgi?id=1173485),
> > > confirmed that after the patches are applied that the system reports a
> > > malformed filesystem and mounting fails.
> > >
> > > [Potential regression]
> > > Journal inodes are no longer a special case when checking extent trees
> > > which means that some filesystems that could be mounted could now fail.
> > >
> > > Jan Kara (1):
> > >   ext4: check journal inode extents more carefully
> > >
> > > Theodore Ts'o (3):
> > >   ext4: save the error code which triggered an ext4_error() in the
> > >     superblock
> > >   ext4: simulate various I/O and checksum errors when reading metadata
> > >   ext4: save all error info in save_error_info() and drop
> > >     ext4_set_errno()
> > >
> > >  fs/ext4/balloc.c         |  10 ++--
> > >  fs/ext4/block_validity.c |  59 +++++++++---------
> > >  fs/ext4/ext4.h           | 125 ++++++++++++++++++++++++++++++++-------
> > >  fs/ext4/ext4_jbd2.c      |  10 ++--
> > >  fs/ext4/extents.c        |  42 ++++++-------
> > >  fs/ext4/ialloc.c         |  15 +++--
> > >  fs/ext4/indirect.c       |   8 +--
> > >  fs/ext4/inline.c         |  11 ++--
> > >  fs/ext4/inode.c          |  38 ++++++------
> > >  fs/ext4/mballoc.c        |  21 +++----
> > >  fs/ext4/mmp.c            |  13 ++--
> > >  fs/ext4/move_extent.c    |   4 +-
> > >  fs/ext4/namei.c          |  31 ++++++----
> > >  fs/ext4/super.c          | 106 +++++++++++++++++++++++++--------
> > >  fs/ext4/sysfs.c          |  23 +++++++
> > >  fs/ext4/xattr.c          |  12 ++--
> > >  16 files changed, 351 insertions(+), 177 deletions(-)
> > >
> > > --
> > > 2.30.2
> > >
> > >
> > > --
> > > kernel-team mailing list
> > > kernel-team at lists.ubuntu.com
> > > https://lists.ubuntu.com/mailman/listinfo/kernel-team
> >