Re: [BUG] Oops in sidtab_context_to_sid

[Vijay Balakrishna]

On 4/3/2021 8:21 AM, Ondrej Mosnacek wrote:
> On Sat, Apr 3, 2021 at 4:33 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
> > <vijayb@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx/
> > >
> > > 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@xxxxxxxxxx
>
> 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.