lkml.org 
[lkml]   [2021]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [BUG] Oops in sidtab_context_to_sid
From
Date


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.

\
 
 \ /
  Last update: 2021-04-06 01:40    [W:0.057 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site