Bug 1180098 - (CVE-2020-27066) VUL-1: CVE-2020-27066: kernel-source: In xfrm6_tunnel_free_spi of net/ipv6/xfrm6_tunnel.c, there is a possible use after free due to improper locking. This could lead to local escalation of privilege with System execution privileges needed.
(CVE-2020-27066)
VUL-1: CVE-2020-27066: kernel-source: In xfrm6_tunnel_free_spi of net/ipv6/xf...
Status: RESOLVED INVALID
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P4 - Low : Minor
: ---
Assigned To: Kernel Bugs
Security Team bot
https://smash.suse.de/issue/273511/
CVSSv3.1:SUSE:CVE-2020-27066:6.7:(AV:...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-12-16 10:19 UTC by Marcus Meissner
Modified: 2021-06-07 13:56 UTC (History)
5 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2020-12-16 10:19:42 UTC
CVE-2020-27066

In xfrm6_tunnel_free_spi of net/ipv6/xfrm6_tunnel.c, there is a possible use
after free due to improper locking. This could lead to local escalation of
privilege with System execution privileges needed. User interaction is not
needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID:
A-168043318

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27066
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27066
https://source.android.com/security/bulletin/pixel/2020-12-01
Comment 1 Marcus Meissner 2020-12-16 10:37:19 UTC
it has no git link in the pixel advisory. fix might not be upstream
Comment 2 Michal Kubeček 2020-12-21 21:35:12 UTC
Not only git link, I couldn't find any description of the problem anywhere
that would go beyond what's in the initial description.

Looking at xfrm6_tunnel_free_spi(), the only thing that comes to my mind is
that we might need to replace hlist_for_each_entry_safe() with
hlist_for_each_entry_rcu(). But I'll need to refresh my knowledge of how
RCU lists work to be sure if it's really a problem if the whole loop is
performed under a spinlock.
Comment 3 Marcus Meissner 2021-01-04 07:56:24 UTC
i also poked through some branches of the android kernel git https://android.googlesource.com/kernel/common/

so far nothing stood out.

closest thing might be this mainline commit

commit d12f3827e04b58f617c43f4d44ad3ad788d852b7
Author: Reshetova, Elena <elena.reshetova@intel.com>
Date:   Tue Jul 4 09:34:59 2017 +0300

    net, ipv6: convert xfrm6_tunnel_spi.refcnt from atomic_t to refcount_t
    
    refcount_t type and corresponding API should be
    used instead of atomic_t when the variable is used as
    a reference counter. This allows to avoid accidental
    refcounter overflows that might lead to use-after-free
    situations.
    
    Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
    Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: David Windsor <dwindsor@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
Comment 4 Michal Kubeček 2021-01-04 08:12:19 UTC
(In reply to Marcus Meissner from comment #3)
> closest thing might be this mainline commit
> 
> commit d12f3827e04b58f617c43f4d44ad3ad788d852b7
> Author: Reshetova, Elena <elena.reshetova@intel.com>
> Date:   Tue Jul 4 09:34:59 2017 +0300
> 
>     net, ipv6: convert xfrm6_tunnel_spi.refcnt from atomic_t to refcount_t

This is part of a treewide conversion. While switching from atomic_t to
refcount_t could help with finding refcount overflow issues and even prevent
some of them from being exploitable, it cannot be really considered a fix
as triggering the overflow would eventually result in code not working
properly.
Comment 5 Marcus Meissner 2021-01-18 09:23:31 UTC
I mailed the Android CNA for more info.
Comment 6 Marcus Meissner 2021-01-20 07:09:22 UTC
From Android CNA:

Thank you for the contact regarding CVE-2020-27066. From our research a
code change between 4.14.170 and 4.14.180 fixed this vulnerability. Due to
the number of changes between 4.14.170 and 4.14.180 it is not clear exactly
which commit resolved the vulnerability. However, kernel versions 4.14.180
or higher are no longer impacted by this issue. Let me know if this helps
address your question or if we can provide any other information.

---- 

I looked over
git log v4.4.169..v4.4.180 net/

but could not correlate the description with any fixes so far.

Any idea what I should request? backtrace of their original report?
Comment 7 Michal Kubeček 2021-01-25 23:54:24 UTC
(In reply to Marcus Meissner from comment #6)
> Any idea what I should request? backtrace of their original report?

A backtrace might be helpful but for this kind of bugs (use after free), it
often shows the less relevant part of the picture - the victim rather than
the culprit.

I'm rather interested in the "in ... there is a possible use after free due
to improper locking" part of the original report. This claim is very specific
which would indicate that it's result of a code analysis so that whoever
got to this conclusion should be able to provide more details about this
possible use after free (and improper locking). On the other hand, the
newest claim that the issue has been fixed between 4.4.170 and 4.4.180 rather
looks like result of a partial bisect. Could it be based on lockdep warnings?
In any case, it would be useful to have more details about what research led
them to these statements.
Comment 8 Marcus Meissner 2021-06-07 13:56:11 UTC
CVE is insufficiently documented.



we were not able to identify the exact place this was fixed.

likely either tracked or needs to be researched differently.

giving up on it for now.