Re: [PATCH] wifi: zd1211rw: reject secondary interfaces to prevent conflicts
"Vlastimil Babka (SUSE)" <[email protected]> Fri, 31 Jul 2026 21:45:19 +0200
| Newsgroups | dev.linux.lists.syzbot,org.kernel.vger.linux-kernel,org.kernel.vger.linux-wireless,org.kernel.vger.workflows |
|---|---|
| Message-ID | <[email protected]> |
On 7/31/26 19:36, Jeff Johnson wrote: > On 7/29/2026 1:04 AM, syzbot wrote: >> From: Slawomir Stepien <[email protected]> >> >> The zd1211rw driver is designed for single-function Wi-Fi dongles and >> hardcodes its USB endpoints. When a malformed USB device exposes multiple >> interfaces that match the driver's device ID, the driver blindly binds to >> all of them. >> >> During probe(), the driver calls usb_reset_device(), which iterates over >> all interfaces and invokes the pre_reset() callback for each bound >> interface. Since multiple interfaces are bound to zd1211rw, pre_reset() is >> called sequentially for each instance, acquiring their respective >> &mac->chip.mutex. Because all instances initialize their mutexes with the >> same lock class, lockdep detects a task acquiring a lock of the same class >> it already holds and flags it as a possible recursive deadlock: >> >> WARNING: possible recursive locking detected >> kworker/0:1/11 is trying to acquire lock: >> ffff88810371dde0 (&chip->mutex){+.+.}-{4:4}, at: >> zd_chip_disable_rxtx+0x20/0x50 >> drivers/net/wireless/zydas/zd1211rw/zd_chip.c:1465 >> >> but task is already holding lock: >> ffff8881138ddde0 (&chip->mutex){+.+.}-{4:4}, at: pre_reset+0x28c/0x380 >> drivers/net/wireless/zydas/zd1211rw/zd_usb.c:1505 >> >> Fix this by explicitly rejecting secondary interfaces (bInterfaceNumber != >> 0) during probe(). This ensures that only a single instance of the driver >> binds to the device, eliminating the recursive locking scenario. >> >> Fixes: e85d0918b54f ("[PATCH] ZyDAS ZD1211 USB-WLAN driver") >> Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot >> Reported-by: [email protected] >> Closes: https://syzkaller.appspot.com/bug?extid=0ec3d1a6cf1fbe79c153 >> Link: https://syzkaller.appspot.com/ai_job?id=00724ef7-fd77-4cde-9779-895b8f63c2f6 >> Signed-off-by: Slawomir Stepien <[email protected]> > > E-mail from syzbot but SOB from a human? > > I read the trailer, but this seems to violate: > https://docs.kernel.org/process/coding-assistants.html > > Namely: > AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the > Developer Certificate of Origin (DCO). > > +workflows list The original mail [1] has this at the bottom: > See https://goo.gle/syzbot-ai-patches for information about AI-generated patches. Where it says: > Patches mailed to the kernel mailing lists were reviewed and Signed-off-by by at least one human developer in accordance with AI Coding Assistants guidelines. Since From: and S-o-b: refers to a human developer, and there's Assisted-by: it seems to be according to the rules. The "From: syzbot" seems to be just a sending mechanism, that wouldn't even make it to the git commit log. [1] https://lore.kernel.org/all/[email protected]/