From: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
To: syzbot <syzbot@kernel.org>,
syzkaller-bugs@googlegroups.com, Slawomir Stepien <sst@poczta.fm>,
linux-wireless@vger.kernel.org, Daniel Drake <dsd@gentoo.org>
Cc: johannes.berg@intel.com, kees@kernel.org,
linux-kernel@vger.kernel.org, nihaal@cse.iitm.ac.in,
syzbot@lists.linux.dev, workflows@vger.kernel.org
Subject: Re: [PATCH] wifi: zd1211rw: reject secondary interfaces to prevent conflicts
Date: Fri, 31 Jul 2026 10:36:42 -0700 [thread overview]
Message-ID: <dbe5b96e-c95c-474e-aca0-8227fee4682a@oss.qualcomm.com> (raw)
In-Reply-To: <0720e3ad-d98e-47d7-89af-4d22416b0fbc@mail.kernel.org>
On 7/29/2026 1:04 AM, syzbot wrote:
> From: Slawomir Stepien <sst@poczta.fm>
>
> 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: syzbot+0ec3d1a6cf1fbe79c153@syzkaller.appspotmail.com
> 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 <sst@poczta.fm>
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
next prev parent reply other threads:[~2026-07-31 17:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 8:04 [PATCH] wifi: zd1211rw: reject secondary interfaces to prevent conflicts syzbot
2026-07-29 18:53 ` Jeff Johnson
2026-07-31 17:36 ` Jeff Johnson [this message]
2026-07-31 19:45 ` Vlastimil Babka (SUSE)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dbe5b96e-c95c-474e-aca0-8227fee4682a@oss.qualcomm.com \
--to=jeff.johnson@oss.qualcomm.com \
--cc=dsd@gentoo.org \
--cc=johannes.berg@intel.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=nihaal@cse.iitm.ac.in \
--cc=sst@poczta.fm \
--cc=syzbot@kernel.org \
--cc=syzbot@lists.linux.dev \
--cc=syzkaller-bugs@googlegroups.com \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox