On Thu, Apr 24, 2025 at 3:34 PM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On 4/24/25 4:45 AM, Ondrej Mosnacek wrote: > > On Thu, Apr 24, 2025 at 12:37 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > >> > >> On Tue, Apr 15, 2025 at 5:22 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > >>> On Tue, Apr 15, 2025 at 10:06 AM Li Lingfeng <lilingfeng3@xxxxxxxxxx> wrote: > >>>> > >>>> Hi, > >>>> Thank you for reporting this issue and sharing the detailed reproducer. > >>>> Apologies for the gap in my knowledge regarding security_label. > >>>> Would need some time to study its implementation in the security subsystem. > >>>> > >>>> To begin validating the problem, I attempted to run the reproducer on > >>>> Fedora 26(with kernel -- master 8ffd015db85f). However, I didn't observe > >>>> the reported mislabeling of the root directory. > >>> > >>> Hm... Fedora 26 is *very* outdated and not maintained any more - I'd > >>> recommend using 41, which is the current latest stable release. Hard > >>> to say if it affects the reproducibility of this bug, but it's always > >>> possible that userspace is also somehow involved. > >>> > >>>> > >>>> The modifications introduced by commit fc2a169c56de specifically affect > >>>> scenarios where the /proc/net/rpc/xxx/flush interface is frequently > >>>> invoked within a 1-second window. During the reproducer execution, I > >>>> indeed observed repeated calls to this flush interface, though I'm > >>>> currently uncertain about its precise impact on the security_label > >>>> mechanism. > >>>> [ 124.108016][ T2754] call write_flush > >>>> [ 124.108878][ T2754] call write_flush > >>>> [ 124.147886][ T2757] call write_flush > >>>> [ 124.148604][ T2757] call write_flush > >>>> [ 124.149258][ T2757] call write_flush > >>>> [ 124.149911][ T2757] call write_flush > >>>> > >>>> Once I have a solid understanding of the security_label mechanism, I will > >>>> conduct a more thorough analysis. > >>> > >>> I'm not sure how the two affect each other either... It almost looks > >>> like the last mount command somehow ends up mounting the "old" export > >>> without security_label in some cases, even though the exportfs > >>> commands that re-export the dir without security_label had completed > >>> successfully by that time. > >>> > >>> Thank you for looking into it! > >> > >> I just wanted to check and see how things were progressing? I haven't > >> noticed any failures lately on my Fedora Rawhide + patches kernel > >> builds, but I wasn't sure if the problem had been fixed or if I've > >> just been really lucky :) > > > > I can still reproduce the bug on the latest Fedora Rawhide kernel > > (6.15.0-0.rc3.20250422gita33b5a08cbbd.29.fc43.x86_64), which is based > > on commit a33b5a08cbbdd7aadff95f40cbb45ab86841679e in Linus' tree. > > > > Can we perhaps have the commit reverted for now while the bug is being > > investigated? The change doesn't look essential and should be easy to > > reintroduce once the bug is addressed. > > I've queued up a patch to revert fc2a169c56de in the nfsd-fixes tree > for v6.15-rc. Thanks! -- Ondrej Mosnacek Senior Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
