[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210112163450.GB2212@openwall.com>
Date: Tue, 12 Jan 2021 17:34:50 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2021-20177 kernel: iptables string match rule could result in kernel panic
On Tue, Jan 12, 2021 at 09:04:49AM +0100, Greg KH wrote:
> On Tue, Jan 12, 2021 at 04:58:07PM +1000, Wade Mealing wrote:
> > A flaw was found in the Linux kernels implementation of string matching
> > within a packet. A privileged user
> > (with root or CAP_NET_ADMIN ) when inserting iptables rules could insert a
> > rule which can panic the system.
> >
> > Likely a user with these permissions could do worse, however it crashes the
> > system (DOS) and the user is going to have a bad day
> > especially if the rule is inserted and restored on every boot.
> >
> > At this time it doesn't affect RHEL releases, and there are fixes already
> > in multiple upstream trees.
> >
> > Thanks,
> >
> > Wade Mealing
> >
> > Upstream patch:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ca58fbe06c54
> >
> > Upstream bugzilla:
> > https://bugzilla.kernel.org/show_bug.cgi?id=209823
> >
> > Red Hat Bugzilla:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1914719
>
> I still do not understand why you report issues that are fixed over a
> year ago (October 2019) and assign them a CVE like this. Who does this
> help out?
I think this specific issue is relevant to projects providing container
virtualization with a security boundary, yet letting container root
manage the local iptables rules for the container. Wade's posting is a
useful heads-up for such projects. I've just forwarded it to
Virtuozzo/OpenVZ developers, so they don't miss it.
> And what about the thousands of other issues that are fixed
> in the kernel and not assigned a CVE like this, are they somehow not as
> important to your group?
>
> What determines what you want to give a CVE to and what you do not?
These are good questions. My guess is most issues simply haven't been
analyzed enough, or not considered at all, for CVE ID (non-)allocation.
Visiting the URLs above, the upstream commit message does not make it
clear the issue's security relevance was understood back then. Perhaps
it simply was not. The two Bugzilla entries make the security relevance
much clearer, and are more recent. So perhaps this is not sudden CVE ID
assignment to an old issue; this is recent new understanding and its
correspondingly timely assignment.
I have no idea why Red Hat in particular looked into this now. My guess
is it's because the issue was recently reported to Red Hat by some means.
Alexander
Powered by blists - more mailing lists
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.
