On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
<[email protected]> 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/[email protected]
... which was merged into Linus' tree during the v5.12-rcX development
phase, any chance you could try that patch to see if it resolves your
issue? There are still some issues to be sorted out, but if you
aren't reloading policy it shouldn't be a concern.
Tyler, since both of you are at Microsoft, do you have a patched
kernel that Vijay could try?
--
paul moore
http://www.paul-moore.com
On Sat, Apr 3, 2021 at 4:33 PM Paul Moore <[email protected]> wrote:
> On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
> <[email protected]> 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/[email protected]
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.
--
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
On Sat, Apr 3, 2021 at 11:21 AM Ondrej Mosnacek <[email protected]> wrote:
> On Sat, Apr 3, 2021 at 4:33 PM Paul Moore <[email protected]> wrote:
> > On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
> > <[email protected]> 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/[email protected]
>
> 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.
Of course, good catch.
--
paul moore
http://www.paul-moore.com
On 4/3/2021 8:21 AM, Ondrej Mosnacek wrote:
> On Sat, Apr 3, 2021 at 4:33 PM Paul Moore <[email protected]> wrote:
>> On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
>> <[email protected]> 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/[email protected]
>
> 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.