Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS

[Brad Spengler <spender () grsecurity net>]

Hi Sasha,

> So this CVE link above is exactly what I referred to: how do you go from
> CVE-2021-3428 to the commit in question?

For that particular one, the original email was:
https://seclists.org/oss-sec/2021/q1/212
to which I had already replied here:
https://seclists.org/oss-sec/2021/q1/220

The investigation for that email took only a few minutes.  It didn't have to
be done via the CVE link, as https://bugzilla.suse.com/show_bug.cgi?id=1173485
was provided in the email.  At that link was the report from Wolfgang Frisch.
A simple git log --grep "Wolfgang Frisch" -- fs/ext4 immediately gets you:

commit ce9f24cccdc019229b70a5c15e2b09ad9c0ab5d1
Author: Jan Kara <jack () suse cz>
Date:   Tue Jul 28 15:04:34 2020 +0200

    ext4: check journal inode extents more carefully
    
    Currently, system zones just track ranges of block, that are "important"
    fs metadata (bitmaps, group descriptors, journal blocks, etc.). This
    however complicates how extent tree (or indirect blocks) can be checked
    for inodes that actually track such metadata - currently the journal
    inode but arguably we should be treating quota files or resize inode
    similarly. We cannot run __ext4_ext_check() on such metadata inodes when
    loading their extents as that would immediately trigger the validity
    checks and so we just hack around that and special-case the journal
    inode. This however leads to a situation that a journal inode which has
    extent tree of depth at least one can have invalid extent tree that gets
    unnoticed until ext4_cache_extents() crashes.
    
    To overcome this limitation, track inode number each system zone belongs
    to (0 is used for zones not belonging to any inode). We can then verify
    inode number matches the expected one when verifying extent tree and
    thus avoid the false errors. With this there's no need to to
    special-case journal inode during extent tree checking anymore so remove
    it.
    
    Fixes: 0a944e8a6c66 ("ext4: don't perform block validity checks on the journal inode")
    Reported-by: Wolfgang Frisch <wolfgang.frisch () suse com>

Or you could look at the comment from the bugzilla:
https://bugzilla.suse.com/show_bug.cgi?id=1173485#c6

which provided commit titles to grep for, including the one above.

For https://seclists.org/oss-sec/2021/q1/228, it was already familiar to me,
but visiting: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-35519
an (upstream) patch is included to net/x25/af_x25.c.  Even something very
basic like:
git log --grep "x25_bind" -- net/x25/af_x25.c gets you the same patch posted:

commit 07632721dc2d4d2e30ec3010edfbd2f251884912
Author: Dan Carpenter <dan.carpenter () oracle com>
Date:   Tue Dec 1 18:15:12 2020 +0300

    net/x25: prevent a couple of overflows
    
    The .x25_addr[] address comes from the user and is not necessarily
    NUL terminated.  This leads to a couple problems.  The first problem is
    that the strlen() in x25_bind() can read beyond the end of the buffer.
    
    The second problem is more subtle and could result in memory corruption.
    The call tree is:
      x25_connect()
      --> x25_write_internal()
          --> x25_addr_aton()
    
    The .x25_addr[] buffers are copied to the "addresses" buffer from
    x25_write_internal() so it will lead to stack corruption.
    
    Verify that the strings are NUL terminated and return -EINVAL if they
    are not.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Fixes: a9288525d2ae ("X25: Dont let x25_bind use addresses containing characters")
    Reported-by: "kiyin(尹亮)" <kiyin () tencent com>
    Signed-off-by: Dan Carpenter <dan.carpenter () oracle com>
    Acked-by: Martin Schiller <ms () dev tdt de>
    Link: https://lore.kernel.org/r/X8ZeAKm8FnFpN//B@mwanda
    Signed-off-by: Jakub Kicinski <kuba () kernel org>

I would expect stable maintainers to be capable of this same basic analysis with similar
speed :)

Thanks,
-Brad

Attachment: signature.asc
Description: Digital signature