oss-security - Re: CVE-2021-3428 Linux kernel: integer overflow in ext4_es_cache

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 17 Mar 2021 09:05:14 -0400
From: Brad Spengler <spender@...ecurity.net>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2021-3428 Linux kernel: integer overflow in
 ext4_es_cache_extent

Hi Greg,

> Please include what kernel version things like this were "found in" and
> when it was fixed, otherwise you force everyone to go scramble just to
> find that this was reported in July of 2020 and fixed then in the 5.9
> kernel release and has already been backported to all relevant stable
> kernel releases in August of last year.

Those are a lot of assumptions there.  I do wonder how you feel you can
ignore the CVE process the rest of the world is engaged in, while at the
same time boss around those engaged in it.  But setting aside the irony
of someone telling the world "if you want to know what was fixed or not,
we publish the source, figure it out for yourself" being irate at being
handed the same terms, I went ahead and did the investigation for you.

The fix (part of the patch series https://www.spinics.net/lists/linux-ext4/msg73471.html):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce9f24cccdc019229b70a5c15e2b09ad9c0ab5d1
was included in 5.9, and was backported through to 5.7.  However, you'll
note the fixes tag points to a commit first appearing in 5.2.  That commit
commit itself was backported to some earlier stable kernels, like 4.14.

Why wasn't the fix for this CVE backported to kernels older than 5.7? For
the same reason many other bugs/vulnerabilities don't get backported: small,
often trivial conflicts.

In this instance, it becomes clear the reason why it wasn't backported any
further than 5.7 is because 5.7 contained the following commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54d3adbc29f0c7c53890da1683e629cd220d7201

without which there is a small conflict in fs/ext4/block_validity.c:
<<<<<<< HEAD
                else {
                        sbi->s_es->s_last_error_block = cpu_to_le64(start_blk);
                        return 0;
                }
=======
                else
                        return entry->ino == ino;
>>>>>>> ce9f24cccdc0... ext4: check journal inode extents more carefully

Thanks,
-Brad

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.