From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 48DAB146A66 for ; Sat, 20 Jun 2026 01:39:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781919573; cv=none; b=TfX4v7mZvTX0htl/knbHHcmX4eeUWNPkLxuUFGZ9wbvEfVe9yOqzsxwZphx7m2qxAEdYyE2urHyJrGVTC6PLG/cslZmV5xWOU+l635qPKB7DHz7UP0twt9/q/c2YFp4TMoRvqsTHbA89BihrwA9TIsmYpqTiFC6WT3YrV5avgxw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781919573; c=relaxed/simple; bh=rDuOoxdcgI0KszSBN3TWAKf4cpLef362S2a5BVx5o1w=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Ky8APd0Dj7lMhl+pgjQuxUEjKAHZI/L8Twcae20BhwqTGUVD148AEmCidrMGr0TUIC4Z45eQfJjaiQTMm/01ag1m4OOiQe74KY9HU8DU5bb5ZzrP8A0rrRCBdwahBp7xooKpfOBqPQ8oDifxiMI7qb11vaR4i8bQHdowAIRLNQc= 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=lCXPucMK; arc=none smtp.client-ip=209.85.128.51 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="lCXPucMK" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4922244f7c7so22123815e9.0 for ; Fri, 19 Jun 2026 18:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781919571; x=1782524371; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=lQml/dQoNRoOrtzXJcX3X8rhBdmWU63cHcWrMzfMNtE=; b=lCXPucMK5Xt6xh5yFCQA8iKuZ4JWCNRLYK0ZTYmIw+G/3Uaae3oHF6SNc9MmMhVir3 DkQmzvAju/QaNPmwqeybBgcop4/zrIyFDxaLAkPg7LF+QX3NRY8k9ekywLeM6g/tlCpb hwTAQaYOQfPZjCXKldT9LunKoKRYBrgZeO6OddMcBsJyY5TsxlD+rObEQ8wwKyar2EMF lxDFttTYnGE4pjGZ5TwAtK2ctNA364kRPqlktnnZgUdFSQhMIKDUj76BFWL1xz+ILc8e lSAJswO6CEUTxk7qUMVPhCWAw5mwF9Rg16Kw6CIK5Dkj3JQeocyFwoNV/wj3gKim6K8q F2ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781919571; x=1782524371; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lQml/dQoNRoOrtzXJcX3X8rhBdmWU63cHcWrMzfMNtE=; b=TlOGrLhs8Tkvf/YhpZ+EqPxGA8Aq1MHOmpol0pV4KV/oCAubtILoD59xtl4EGP3sbc 0P1WstyBo3ddfh5gFrrND4cqliPMJaHw4do6uAT6Ozj1lBuFNwJWviwbPB2KyrcWUrsj q2XmSJ9LovO/yVVO2awzDF7YJFqvLfDqKwB10puc6XPu12uHmIfG5c4fsekknY5lVpd3 xc9YHZpyiBLJZ6qS7sSLPxVngdizvxbQOxvH99sBqKi46QE0SvlFI+4Kz5isoMxODhfY xqpsiIXvS0YoEHO4aYMPkU02XXo16+9s3CBGzfnJVHq2VOZzNBq8DppSIf7okkkY8Ab4 1BZg== X-Forwarded-Encrypted: i=1; AFNElJ8EiH9lxJj+WBBy+vwdo4wZUGZHsaSAS0vD8W1Kk0TOGPTWATvYmQ7wIok4J5BHOuY4JQPMMT2KWc8DYTs=@vger.kernel.org X-Gm-Message-State: AOJu0Yz5RfqmtZO/fPBFMavLdxcBW9lM8nt46EQV/3KiBDvsr9t87+W3 7OTAVMxuLQTN1fn7d0D172tqcDg7kVBRUGhPaZQsP7oK9WRCzr10npGZ X-Gm-Gg: AfdE7cn4mCHKV5Hm5O7dK7RI9lw7ClR7xFVC2KZRxflOOuWdmUgPalaiRDF2CljU1f6 BKEXX+/epLw291WktrmTOcGAY4FbWBMXaMCOIog7fyoRixAGpXiFiwWf9CxCEznM7OZHaEz6naW 7/ahoUMjwuNvYySOANgnHIJ+NYysXfVoVULSn+oUwE3EqjYtF29G3MYeRudVNFAIKoCNWe7qF+h STVnhyUNKxCKbbIzsUDBdy+jgsRqkkPLN6YAw3rD5xkAlDeUbFmbMM3uNbxKupvjVrXCxViaghv HjoqMZnahNPUprI3AQoPPulLi3ujjvRVMI3RWymUi4OrCgzSdB8TbpShlo9xLPSYNoyW4j/Fk33 iJRHoCbWwjT1KjHwUXBXbAK5YWs4HXFELd7859TvpheI/sz05L17Lcx2IuRSDyUxyzlWzQUjuEO tvMFmQGdllA7kHg7X2djCACF3vP8ZDD6qTxWdKkyX+ X-Received: by 2002:a05:600c:1f94:b0:490:d354:bcef with SMTP id 5b1f17b1804b1-4923f59cd4amr106655995e9.33.1781919570536; Fri, 19 Jun 2026 18:39:30 -0700 (PDT) Received: from localhost.localdomain ([2a00:23c7:f906:cb01:1464:e869:8c77:e722]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4923fc47720sm166454045e9.0.2026.06.19.18.39.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jun 2026 18:39:29 -0700 (PDT) From: Christopher Mackle To: Greg Kroah-Hartman Cc: Minu Jin , linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH] staging: rtl8723bs: don't drop short TX frames in _rtw_pktfile_read() Date: Sat, 20 Jun 2026 01:39:16 +0000 Message-ID: <20260620013916.7148-1-christophermackle01@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Commit bc4df274dca6 ("staging: rtl8723bs: update _rtw_pktfile_read() to return error codes") changed _rtw_pktfile_read() to fail when the caller asks for more bytes than remain in the packet: if (rtw_remainder_len(pfile) < rlen) return -EINVAL; That breaks the assumption made by the data TX path. In rtw_xmitframe_coalesce() (core/rtw_xmit.c) the per-fragment copy is issued with the full fragment length, mpdu_len, which is derived from pxmitpriv->frag_len (~2300 bytes), and the code relies on the historical behaviour of copying only what is left and returning the number of bytes actually copied: mem_sz = _rtw_pktfile_read(&pktfile, pframe, mpdu_len); if (mem_sz < 0) return mem_sz; So for every outbound packet smaller than the fragmentation threshold - i.e. essentially all normal traffic, including the EAPOL frames of the WPA 4-way handshake and DHCP - rlen is larger than the bytes remaining, _rtw_pktfile_read() returns -EINVAL, rtw_xmitframe_coalesce() aborts, and the frame is dropped before it is queued to the hardware. The driver floods the log with: rtl8723bs ...: xmit_xmitframes: coalesce failed with error -22 Management frames (authentication/association) use a different path and still go out, so the interface scans and associates, but no data frame is ever transmitted. The 4-way handshake therefore never completes and wpa_supplicant misreports it as: WPA: 4-Way Handshake failed - pre-shared key may be incorrect AP mode is unaffected. The net effect is that the chip is unusable in station mode on any kernel carrying the offending commit. This was confirmed with a wpa_supplicant -dd trace on an RTL8723BS SDIO adapter (Bay Trail): message 1/4 is received and the PTK is derived, but each "Sending EAPOL-Key 2/4" coincides 1:1 with a "coalesce failed with error -22", so message 2/4 never reaches the AP, which keeps retrying message 1/4 until the handshake times out. Restore the original semantics: clamp the requested length to the bytes remaining in the packet and return that length. The skb_copy_bits() error path is kept, so genuine copy failures are still propagated. Fixes: bc4df274dca6 ("staging: rtl8723bs: update _rtw_pktfile_read() to return error codes") Cc: stable@vger.kernel.org Tested-by: Christopher Mackle Signed-off-by: Christopher Mackle --- drivers/staging/rtl8723bs/os_dep/xmit_linux.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8723bs/os_dep/xmit_linux.c b/drivers/staging/rtl8723bs/os_dep/xmit_linux.c index dc0b77f38..9bdb67a8a 100644 --- a/drivers/staging/rtl8723bs/os_dep/xmit_linux.c +++ b/drivers/staging/rtl8723bs/os_dep/xmit_linux.c @@ -24,9 +24,11 @@ void _rtw_open_pktfile(struct sk_buff *pktptr, struct pkt_file *pfile) int _rtw_pktfile_read(struct pkt_file *pfile, u8 *rmem, unsigned int rlen) { int ret; + unsigned int remain = rtw_remainder_len(pfile); - if (rtw_remainder_len(pfile) < rlen) - return -EINVAL; + /* clamp to bytes remaining; the coalesce loop relies on short reads */ + if (rlen > remain) + rlen = remain; if (rmem) { ret = skb_copy_bits(pfile->pkt, pfile->buf_len - pfile->pkt_len, rmem, rlen); -- 2.53.0