linux-kernel - Re: [PATCH V2] selinux: access sid under READ/WRITE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAEjxPJ6QZwprWRXme4S2pAD9X-DmWSfMpoHL8NR+YufMdicZ2g@mail.gmail.com>
Date: Wed, 12 Mar 2025 09:23:13 -0400
From: Stephen Smalley <stephen.smalley.work@...il.com>
To: Edward Adam Davis <eadavis@...com>
Cc: linux-kernel@...r.kernel.org, omosnace@...hat.com, paul@...l-moore.com, 
	selinux@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH V2] selinux: access sid under READ/WRITE_ONCE

On Tue, Mar 11, 2025 at 9:05 PM Edward Adam Davis <eadavis@...com> wrote:
>
> On Tue, 11 Mar 2025 11:19:49 -0400, Stephen Smalley wrote:
> > > Reported-by: syzbot+00c633585760c05507c3@...kaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=00c633585760c05507c3
> > > Signed-off-by: Edward Adam Davis <eadavis@...com>
> > > ---
> > > V1 -> V2: replace with READ_ONCE/WRITE_ONCE
> >
> > Thanks for the patch. Did you audit all other users of sksec->sid to
> > see if they too should be wrapped with READ_ONCE()/WRITE_ONCE() or are
> > already safe?
> This fix is only for the issues reported by syzbot+00c633585760c05507c3.
> I have confirmed that there are many contexts related to "sksec->sid" (at
> least 29). I am not familiar with selinux, and it is unnecessary to do
> excessive fixes before syzbot reports other issues.
>
> Maybe the subject of my patch is not appropriate, and it may be more
> appropriate to adjust it to "selinux: fix data race in socket create and
> receive skb".

We don't want to just silence warnings but rather identify and fix
root causes, and do so comprehensively.
Looking more closely at the syzbot report, it appears that a sock that
initially has SID 3 (aka SECINITSID_UNLABELED) is being assigned a
specific SID via socket_post_create at a point where it might already
be receiving packets.
That seems like it requires a more general fix to ensure that the sock
is correctly labeled before it can start receiving packets.