Re: [BUG] Oops in sidtab_context_to_sid

[Vijay Balakrishna <vijayb@linux.microsoft.com>]

On 4/3/2021 8:21 AM, Ondrej Mosnacek wrote:
> On Sat, Apr 3, 2021 at 4:33 PM Paul Moore <paul@paul-moore.com> wrote:
>> On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
>> <vijayb@linux.microsoft.com> wrote:
>>>
>>> Seeing oops in 5.4.83 sidtab_context_to_sid().  I checked with Tyler (copied),  he said it might be
>>>
>>> https://lore.kernel.org/selinux/CAFqZXNu8s5edDbSZuSutetTsy58i08vPuP2h-n9=kT34HcPc4w@mail.gmail.com/
>>>
>>> Ondrej, can you confirm?  Unfortunately, we don't have a on demand repro.
>>
>> I'm guessing this may be the problem that Tyler reported earlier and
>> which appeared to be fixed by the patch below:
>>
>> https://lore.kernel.org/selinux/20210318215303.2578052-3-omosnace@redhat.com
> 
> Nope, if that's really 5.4.83 with no extra backports, then it can't
> be this issue as it has been introduced only in v5.10.
> 
> Looking at the code in 5.4.83, my initial guess is that it could be a
> memory ordering race between
> sidtab_reverse_lookup()/sidtab_rcache_push() and
> sidtab_rcache_search(). I think the sidtab_rcache_push() call at
> security/selinux/ss/security.c:326 should in fact be after the
> smp_store_release() call. Note that the sidtab_rcache_*() functions
> have been replaced in commit 66f8e2f03c02 ("selinux: sidtab reverse
> lookup hash table") with a different mechanism, which AFAICT doesn't
> have the same issue.
> 
> If that's really it, it will likely be *very* hard to reproduce, so
> you may be unable to verify the fix.
> 
Thank you Ondrej.  We may rebase our kernel in a couple of months.