[BUG] mac80211: lockdep warning from key debugfs creation

[BUG] mac80211: lockdep warning from key debugfs creation

[Wxm-233]

Hello,

We hit a lockdep warning in the mac80211 key-add path under
syzkaller-style workloads.

We reproduced this on 6.19.0-rc5-00042-g944aacb68baf. In the same bug
bucket, later runs still show the same warning on
7.0.0-rc2-g0031c06807cf.

The warning is:

  WARNING: possible circular locking dependency detected

The observed path is:

  nl80211_new_key()
    -> rdev_add_key()
    -> ieee80211_add_key()
    -> ieee80211_key_link()
    -> ieee80211_debugfs_key_add()
    -> debugfs_create_dir()
    -> start_dirop()

nl80211_pre_doit() keeps wiphy.mtx held across nl80211_new_key().
After ieee80211_key_replace() succeeds, ieee80211_key_link()
immediately creates per-key debugfs entries.

That debugfs_create_dir() call goes through debugfs_start_creating(),
simple_start_creating(), and start_dirop(). start_dirop() takes the
parent inode rwsem and lookup_one_qstr_excl() then allocates a dentry
with GFP_KERNEL, which introduces fs_reclaim into the lock chain.

The warning becomes possible because there is already an existing
dependency from relay_open_buf()/relay_create_buf_file(): that path
holds relay_channels_mutex and then enters the same debugfs/VFS
creation flow, which reaches the directory inode lock.

With both chains present, lockdep reports the cycle:

  fs_reclaim -> relay_channels_mutex -> inode rwsem -> fs_reclaim

This looks more like a real locking problem than a pure fuzzing
artifact. The trigger is a syzkaller-style key creation workload, but
the questionable part is that mac80211 performs non-essential debugfs
creation inside the locked key installation path.

A possible fix direction would be to avoid creating per-key debugfs
entries while still in the locked add-key path, for example by
deferring the debugfs population until after the critical section or by
moving it to a safer asynchronous context.

Relevant source locations in current trees are:

  net/wireless/nl80211.c: nl80211_pre_doit(), nl80211_new_key()
  net/mac80211/key.c: ieee80211_key_link()
  net/mac80211/debugfs_key.c: ieee80211_debugfs_key_add()
  fs/namei.c: start_dirop()

If useful, I can also send the full report/log pair.

Thanks,

Re: [BUG] mac80211: lockdep warning from key debugfs creation

[Greg KH]

On Sat, Apr 18, 2026 at 01:12:53AM +0800, Wxm-233 wrote:
> Hello,
> 
> We hit a lockdep warning in the mac80211 key-add path under
> syzkaller-style workloads.
> 
> We reproduced this on 6.19.0-rc5-00042-g944aacb68baf. In the same bug
> bucket, later runs still show the same warning on
> 7.0.0-rc2-g0031c06807cf.
> 
> The warning is:
> 
>   WARNING: possible circular locking dependency detected
> 
> The observed path is:
> 
>   nl80211_new_key()
>     -> rdev_add_key()
>     -> ieee80211_add_key()
>     -> ieee80211_key_link()
>     -> ieee80211_debugfs_key_add()
>     -> debugfs_create_dir()
>     -> start_dirop()
> 
> nl80211_pre_doit() keeps wiphy.mtx held across nl80211_new_key().
> After ieee80211_key_replace() succeeds, ieee80211_key_link()
> immediately creates per-key debugfs entries.
> 
> That debugfs_create_dir() call goes through debugfs_start_creating(),
> simple_start_creating(), and start_dirop(). start_dirop() takes the
> parent inode rwsem and lookup_one_qstr_excl() then allocates a dentry
> with GFP_KERNEL, which introduces fs_reclaim into the lock chain.
> 
> The warning becomes possible because there is already an existing
> dependency from relay_open_buf()/relay_create_buf_file(): that path
> holds relay_channels_mutex and then enters the same debugfs/VFS
> creation flow, which reaches the directory inode lock.
> 
> With both chains present, lockdep reports the cycle:
> 
>   fs_reclaim -> relay_channels_mutex -> inode rwsem -> fs_reclaim
> 
> This looks more like a real locking problem than a pure fuzzing
> artifact. The trigger is a syzkaller-style key creation workload, but
> the questionable part is that mac80211 performs non-essential debugfs
> creation inside the locked key installation path.
> 
> A possible fix direction would be to avoid creating per-key debugfs
> entries while still in the locked add-key path, for example by
> deferring the debugfs population until after the critical section or by
> moving it to a safer asynchronous context.
> 
> Relevant source locations in current trees are:
> 
>   net/wireless/nl80211.c: nl80211_pre_doit(), nl80211_new_key()
>   net/mac80211/key.c: ieee80211_key_link()
>   net/mac80211/debugfs_key.c: ieee80211_debugfs_key_add()
>   fs/namei.c: start_dirop()
> 
> If useful, I can also send the full report/log pair.

Why not send a fix for this so you get full credit for it?

thanks,

greg k-h

Re: [BUG] mac80211: lockdep warning from key debugfs creation

[Johannes Berg]

On Sun, 2026-04-19 at 08:48 +0200, Greg KH wrote:
> > The warning becomes possible because there is already an existing
> > dependency from relay_open_buf()/relay_create_buf_file(): that path
> > holds relay_channels_mutex and then enters the same debugfs/VFS
> > creation flow, which reaches the directory inode lock.

For the record, I have no idea what code path you're talking about here,
perhaps that's hidden away in some driver?

> > With both chains present, lockdep reports the cycle:
> > 
> >   fs_reclaim -> relay_channels_mutex -> inode rwsem -> fs_reclaim
> > 
> > This looks more like a real locking problem than a pure fuzzing
> > artifact. The trigger is a syzkaller-style key creation workload, but
> > the questionable part is that mac80211 performs non-essential debugfs
> > creation inside the locked key installation path.
> > 
> > A possible fix direction would be to avoid creating per-key debugfs
> > entries while still in the locked add-key path, for example by
> > deferring the debugfs population until after the critical section or by
> > moving it to a safer asynchronous context.
> > 
> > Relevant source locations in current trees are:
> > 
> >   net/wireless/nl80211.c: nl80211_pre_doit(), nl80211_new_key()
> >   net/mac80211/key.c: ieee80211_key_link()
> >   net/mac80211/debugfs_key.c: ieee80211_debugfs_key_add()
> >   fs/namei.c: start_dirop()
> > 
> > If useful, I can also send the full report/log pair.
> 
> Why not send a fix for this so you get full credit for it?

Agree, that'd be nice, especially since you can actually reproduce and
therefore test it.

Note though that trying to fix this on the mac80211 side as you suggest
above ("A possible fix direction ...") is not going to work, you'll need
to address this on the other side (that relay thing.)

johannes