Re: [PATCH 0/2] kernfs, autofs: fix pipe lock cycles through sysfs stores

[Ian Kent <raven@themaw.net>]

On Tue, 2026-10-27 at 01:57 +0100, Krystian Kaniewski wrote:
> Hi Ian,
> 
Thanks for replying, ;)

> On Tue, 2026-10-27 at 07:11 +0800, Ian Kent wrote:
> > Commit 1e8c813b083c ("PM: hibernate: don't use early_lookup_bdev
> > in resume_store") looks like it's been around for a while so I
> > assume the reproducer should work on 7.2.12?
> 
> Yes. That commit entered v6.5-rc1, so 7.2.12 contains the relevant
> code.
> 
> I used the unmodified C reproducer linked from the syzbot report:
> 
> https://syzkaller.appspot.com/text?tag=ReproC&x=11c0f4c9580000
> 
> I also used the configuration provided with the report:
> 
> https://syzkaller.appspot.com/text?tag=KernelConfig&x=7d012d9c67977ee4
> 
> > What should I expect, a hang, it doesn't.
> 
> A permanent hang is not expected. The result to look for is this
> lockdep warning in dmesg:
> 
>         WARNING: possible circular locking dependency detected
>         ...
>         &pipe->mutex --> &of->mutex --> &sbi->pipe_mutex
> 
> The reproducer records the first dependency by splicing into the
> cgroup v1 devices.deny file. It records the opposite dependencies
> through a normal write to /sys/power/resume. These operations use
> different lock instances, so the exact reproducer reports a possible
> cycle rather than deadlocking.
> 
> The write waits for an autofs daemon that never replies, but the C
> wrapper kills the blocked child after five seconds and starts another
> iteration. In my test the warning appeared in the first iteration.
> 
> The test needs lockdep and CONFIG_PROVE_LOCKING, the cgroup v1
> devices
> controller, autofs, and working hibernation support. It must also run
> as root. Without lockdep, the program can appear to do nothing
> useful.

Ok, I'll check on those, not sure about hibernation support in my
VM ...

> 
> > Also it looks to me like the reproducer is trying exploit an
> > invalid request similar to what I described earlier
> 
> Whether the string identifies a usable resume device is separate from
> the autofs request. resume_store() first passes it to lookup_bdev(),
> which performs a pathname lookup before the numeric fallback.
> 
> The reproducer changes its current directory to the root of a
> detached
> indirect autofs mount. It then opens /sys/power/resume using an
> absolute path and writes the relative name
> "0x0000000004000921".
> 
> The resulting lookup is therefore:
> 
>         <autofs root>/0x0000000004000921
> 
> For autofs, this is an ordinary lookup of a new immediate child of
> the
> indirect mount root, so it is a normal mount trigger. There is no
> autofs mount under /sys/power.

Right, enabling the autofs pr-debug logging and looking at the
reproducer verified the exection flow for me. I didn't see a
lockdep splat but my environment is probably not quite right.
I'll check what I can and see if I can reproduce.

> 
> In parallel, I am preparing a revised patch following Tejun's
> suggestion. It disables splice for writable opens of
> /sys/power/resume and gives its of->mutex a separate lockdep class.
> 
> If you send your autofs change, I can run the same reproducer against
> it and check both the request and the lockdep warning.
> 
> Thanks,
> Krystian