Messages in this thread | | | Subject | Re: [BUG] Oops in sidtab_context_to_sid | From | Vijay Balakrishna <> | Date | Mon, 5 Apr 2021 16:39:22 -0700 |
| |
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.
| |