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] [thread-next>] [day] [month] [year] [list]
Message-ID: <d7ab53b2-6b26-4e66-8ae1-cb63d98cee88@kernel.org>
Date: Fri, 2 Jan 2026 11:00:57 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Johannes Berg <johannes@...solutions.net>,
 syzbot <syzbot+16210d09509730207241@...kaller.appspotmail.com>,
 linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
 netdev@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [wireless?] WARNING in rfkill_unregister

On 01/01/2026 13:07, Johannes Berg wrote:
> Hi,
> 
>> ------------[ cut here ]------------
>> rtmutex deadlock detected
>> WARNING: kernel/locking/rtmutex.c:1674 at rt_mutex_handle_deadlock+0x21/0xb0 kernel/locking/rtmutex.c:1674, CPU#0: syz.7.2908/15923
>> Modules linked in:
>> CPU: 0 UID: 0 PID: 15923 Comm: syz.7.2908 Not tainted syzkaller #0 PREEMPT_{RT,(full)} 
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
>> RIP: 0010:rt_mutex_handle_deadlock+0x21/0xb0 kernel/locking/rtmutex.c:1674
>> Code: 90 90 90 90 90 90 90 90 90 41 57 41 56 41 55 41 54 53 83 ff dd 0f 85 86 00 00 00 48 89 f7 e8 a6 39 01 00 48 8d 3d af 7c 0a 04 <67> 48 0f b9 3a 4c 8d 3d 00 00 00 00 65 48 8b 1c 25 08 10 b3 91 4c
>> RSP: 0018:ffffc90004617710 EFLAGS: 00010286
>> RAX: 0000000080000000 RBX: ffffc900046177a0 RCX: 0000000000000000
>> RDX: 0000000000000006 RSI: ffffffff8ce0bbf9 RDI: ffffffff8ede5760
>> RBP: ffffc900046178c0 R08: ffffffff8edb3477 R09: 1ffffffff1db668e
>> R10: dffffc0000000000 R11: fffffbfff1db668f R12: 1ffff920008c2ef0
>> R13: ffffffff8ad3d599 R14: ffffffff8eb910e0 R15: dffffc0000000000
>> FS:  0000000000000000(0000) GS:ffff888126cef000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 000056422df5abe0 CR3: 000000005929c000 CR4: 00000000003526f0
>> Call Trace:
>>  <TASK>
>>  __rt_mutex_slowlock kernel/locking/rtmutex.c:1734 [inline]
>>  __rt_mutex_slowlock_locked kernel/locking/rtmutex.c:1760 [inline]
>>  rt_mutex_slowlock+0x666/0x6b0 kernel/locking/rtmutex.c:1800
>>  __rt_mutex_lock kernel/locking/rtmutex.c:1815 [inline]
>>  __mutex_lock_common kernel/locking/rtmutex_api.c:534 [inline]
>>  mutex_lock_nested+0x16a/0x1d0 kernel/locking/rtmutex_api.c:552
>>  rfkill_unregister+0xd1/0x230 net/rfkill/core.c:1145
>>  nfc_unregister_device+0x96/0x300 net/nfc/core.c:1167
>>  virtual_ncidev_close+0x59/0x90 drivers/nfc/virtual_ncidev.c:172
> 
> NFC has been issues with this for *years*. Technically, Krzysztof is
> listed as a maintainer but I suspect that's mostly dead.

And I have little time nowadays to do any real maintenance. I am
thinking that NFC should be marked Odd Fixes.

> 
> Is there a way you could route rfkill issues to NFC (and have them
> ignored there) if NFC is involved?
> 
> Clearly they're not useful if nobody is interested in fixing NFC, so
> maybe we should just disable the virtual NFC driver completely and just
> not have syzbot run on anything there...

Great benefit of virtual NFC driver was to show how buggy the NFC stack
is :)

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ