Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [BUG] Oops in sidtab_context_to_sid
To:     Ondrej Mosnacek <omosnace@redhat.com>,
        Paul Moore <paul@paul-moore.com>
Cc:     Tyler Hicks <tyhicks@linux.microsoft.com>,
        Stephen Smalley <stephen.smalley.work@gmail.com>,
        SElinux list <selinux@vger.kernel.org>,
        Linux kernel mailing list <linux-kernel@vger.kernel.org>
References: <3c63e34b-e54f-9b01-bad4-8fde8528a64d@linux.microsoft.com>
 <CAHC9VhTD2iXw7CkxgwnOx1zNN_AqMV+x1Vy8FijdMQE1m4AOJA@mail.gmail.com>
 <CAFqZXNvZCiE=cKhjBqvxOmebDi3vNr0gS563cCMqTTwpcM6JAw@mail.gmail.com>
From:   Vijay Balakrishna <vijayb@linux.microsoft.com>
Message-ID: <af058f59-ce8a-7648-25e8-f8b8a2dbb0ba@linux.microsoft.com>
Date:   Mon, 5 Apr 2021 16:39:22 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <CAFqZXNvZCiE=cKhjBqvxOmebDi3vNr0gS563cCMqTTwpcM6JAw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


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.