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. -- Ondrej Mosnacek Senior Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
