Vulmon
<!--X-Body-Begin-->
<!--X-User-Header-->
oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->
By Date
By Thread
</form>
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
From: Sasha Levin <sashal () kernel org>
Date: Fri, 19 Mar 2021 18:00:02 -0400
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
On Fri, Mar 19, 2021 at 05:00:08PM -0400, Brad Spengler wrote:
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 :)
And this is exactly my point: you are advocating for tens of people to
do detective work instead of just linking basic things like the commit
id in the announcement mail.
Specially when the commits in question have been upstream for
months/years.
--
Thanks,
Sasha
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
By Date
By Thread
Current thread:
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS, (continued)
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Kurt H Maier (Mar 18)
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Sasha Levin (Mar 18)
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Solar Designer (Mar 18)
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Greg KH (Mar 19)
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Sasha Levin (Mar 19)
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Brad Spengler (Mar 19)
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Sasha Levin (Mar 19)
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Brad Spengler (Mar 19)
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Sasha Levin (Mar 19)
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Brad Spengler (Mar 19)
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Sasha Levin (Mar 19)
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Eddie Chapman (Mar 19)
Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Petr Matousek (Mar 23)
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->