it has no git link in the pixel advisory. fix might not be upstream

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.

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>

(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.

I mailed the Android CNA for more info.

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?

(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.

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.