From nobody Sat Jul 25 22:03:16 2026 Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D6808396572 for ; Mon, 13 Jul 2026 07:56:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783929397; cv=none; b=Z9bqIbMAoDl1rpI+yYVn3BJN8RnaqzZCEW/Xk1ECWr1EEmzTib30FcLuwTXKm4xeF9bwZb8mDgmVbbCt+0yEY8Nyf6eWOPDr26/4UVBNyefryc51Ixa/T17rX/yrZVbofl0XoD0FgYpMQduGSRzL5SfOdzlC0EMEIYEoIUSec8U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783929397; c=relaxed/simple; bh=aGkpEpTijLt0R3GXttmk2ZIDwTaP52BLkUHmqoWvkU4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mU+s8FzB0m8Zzaix1ZCbuTvBrg+N6QreASCOJBsuljp/qh07WumPP3IWUxEr9NWmuC0HVMaCvLD2R2+7XF5gNtWagr0D+5Olcjhd7ocq0ehVg9c5R4WF+IHsfpAzeQzapR4xgpWKOi06ylDdUE1fxhmboWxJALT+TOiSN3MyIZM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=nNdzuSIh; arc=none smtp.client-ip=209.85.215.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nNdzuSIh" Received: by mail-pg1-f176.google.com with SMTP id 41be03b00d2f7-caf707e3a70so365488a12.1 for ; Mon, 13 Jul 2026 00:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783929395; x=1784534195; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=UhytyvXbvQFMyOYt3QqcgjFZGx9N0GayBY1QWmFTxaY=; b=nNdzuSIhfW/rWJOA+0UOSQja5ocAextfnvIYQKiM+w3gOmOkXROb0oPRw6nlz9jNqs kD+dwXpJSSZQNZFqZNwaPOOs32Xv/wX9gi9BkFzMPCZvpF9c1CvrkW3mK/tGVFZBV0w8 cUljl3wrGRQVmC3UMEL7A/5oxk9ZD4+1BIcNpT8D8qZJNJ+6g0lddmyLEn6zlY4qKPdO dcN0LvLmI+r8DXaD6hIPYS0Zh/y9oX9sGqAwuv5p/FgaKPDm/EI95Wd74tVm0XdGDYLv HUE8tg9Y6LajNtkZ7u6JpsucNrIETO7CaEtGZKM7zrxfCGzowzd4Awm/IZfV1V0yyKQ7 C+QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783929395; x=1784534195; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=UhytyvXbvQFMyOYt3QqcgjFZGx9N0GayBY1QWmFTxaY=; b=Pj+7vQHvjeJ6nRloZSQlbqAJgscJyVW77dHRfBlwVLDDXYDznousNPKBywykreuk1x Hlu/wX5Q9FDhrHwgyu4TmHjHO2uWZzw/8UL2gnz9E+FHmwKHvj73bie+x3EIXqtyDEeV 9nHkTrredEZESasA7utloni4ugY2MtWXw/hOLVTheAapHfT0RKnjEDxcC5JMt1y3+F+t qk1Df56l2hKFNboMOjm7LwKiKR/8XbVopRkaxrMgHt9MqCpEASjtLZKflJiw9FZnEelb VqUauUh2Wrh5bWw7IXTWKHGXVokLXtmfbMG0R7zOozN58gb/acGvTdVd6y1XtUyjIJmB agpw== X-Forwarded-Encrypted: i=1; AHgh+RoJbDbqbcaxlhhIWJQjPv1H5UOWg1TkjrYTZLppl9MaBiRM7TQkLDR/R0cgccY8PZzyVvPtu+VZEObqGcE=@vger.kernel.org X-Gm-Message-State: AOJu0YzWpJWPjkoiazZZ2UH2gXtOGr+Xbqci6L8KRFNwFJdjOo5srvJu ojWkygWNNpi12l5wDaWeugUoA6Ih3pldKGNjW4i8Ksb8oQ2xU3lwTw21 X-Gm-Gg: AfdE7cmxhWJ0RSY4FC8bL2rG1f60m8wwpdWimUb567kOqK9WzGvbdkxeGUFgQPj8Mcu nAXgy8Ae5ebmYi+9nZfEWWDffykxctdkhvi4rp+ZWojMDAGyK4d8pgT7fjj9/W0uG5lFR7DPjAi +yYrLg2qjeHyt8cs6p4h7lN3aC0pXY/s+x/91ONcarN4TV+qecMAT6WtrJrht41oxNCgW6EJmOf SenVcnMGuDxfXSsFuOhTdORyvavTRCW2YQk/Cm+lXVUmP3NmrqJOxLtDOKrEJLmnKvRRKsIbxoI r5Dq7aNRIplKXtrlta0vLI3WF+1Wj3EGzyIbP5562nN9dCBGwxd7xxynTZCzzl2rm2Bzs50uzDr /osmeNr9YUONGTSwzVgyK4QlhIW8vONoEUk0Icsa+To2xNuctMsRi8BkXK4VDJQ8lsIKNBRQ9oX RLS9F1K8P4ffmgFfjLBrGH7qC0/q/peS8lkV+rfAcXFYRdAWgIMMsfOsZYuYW2PQdANdWT4DwvV d6H+ZfgpVCLsnPpHshgNXYSZz5C9ueojQ8sU6A8Om/rfpbzp/EnI0yQRbOhw4ON/VOVNE33Pxyi nRWmTgbC0Aaue9Lu3rt2EueB+BDI5WZ+Ehs/CsSaKAMtnGz5UnXC9tvZ/4NZmXEN3e6HKCGr15h LXxvK/0wKpMNJibebGU63TEnbeNsXmG6eaORYmXpe04c+cg== X-Received: by 2002:a05:6a21:7007:b0:3b4:6af4:bdd5 with SMTP id adf61e73a8af0-3c0f093fc0fmr14622290637.15.1783929395089; Mon, 13 Jul 2026 00:56:35 -0700 (PDT) Received: from HEXER.localdomain ([175.157.29.69]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3119d5cf176sm43194336eec.12.2026.07.13.00.56.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jul 2026 00:56:34 -0700 (PDT) From: Kanishka De Silva To: Greg KH Cc: Oliver Neukum , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Kanishka De Silva Subject: [PATCH v2] usb: adutux: take buflock when resetting read_buffer_length in adu_open() Date: Mon, 13 Jul 2026 13:26:16 +0530 Message-ID: <20260713075616.1625-1-kpskanna1915@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" dev->read_buffer_length is otherwise only ever touched under dev->buflock (by adu_interrupt_in_callback() and adu_read()), per the locking scheme documented in the comment above struct adu_device. adu_open() resets it to 0 without holding buflock. In the current code this is not a reachable race. adu_open() and adu_release() are fully serialized by adutux_mutex, and adu_release_internal() calls usb_kill_urb() (via adu_abort_transfers()) before that mutex is dropped, which blocks until any in-flight adu_interrupt_in_callback() has returned. The write in adu_open() also precedes the urb (re)submission in program order, so the callback cannot observe or race with it there either. This change brings the assignment under buflock purely so the field's locking is locally consistent with the driver's documented scheme, making the invariant easy to verify without having to reason across adu_open(), adu_release_internal(), and usb_kill_urb()'s blocking semantics. No behavioral or functional change intended. v2: - Retitled and reframed from "fix unlocked read_buffer_length write in adu_open() (data race)" to a lock-discipline consistency change. Discussion on the RFC (with Oliver Neukum) established that adutux_mutex serialization plus usb_kill_urb()'s blocking semantics rule out any runtime-reachable race here, so this is no longer presented as a bugfix. (Oliver Neukum, Greg Kroah-Hartman) Signed-off-by: Kanishka De Silva --- drivers/usb/misc/adutux.c | 3 ++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/misc/adutux.c b/drivers/usb/misc/adutux.c index 1111111..2222222 100644 --- a/drivers/usb/misc/adutux.c +++ b/drivers/usb/misc/adutux.c @@ -337,7 +337,8 @@ static int adu_open(struct inode *inode, struct file *f= ile) file->private_data =3D dev; =20 /* initialize in direction */ - dev->read_buffer_length =3D 0; + spin_lock_irq(&dev->buflock); + dev->read_buffer_length =3D 0; + spin_unlock_irq(&dev->buflock); =20 /* fixup first read by having urb waiting for it */ usb_fill_int_urb(dev->interrupt_in_urb, dev->udev, -- 2.43.0