Linux wireless drivers development
 help / color / mirror / Atom feed
From: Alexander Bendezu <alexanderbendezu10@gmail.com>
To: Christian Lamparter <chunkeey@googlemail.com>
Cc: linux-wireless@vger.kernel.org,
	Alexander Bendezu <alexanderbendezu10@gmail.com>,
	syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com
Subject: [PATCH] carl9170: fix out-of-bounds write on bad command response
Date: Mon, 13 Jul 2026 22:00:37 +0000	[thread overview]
Message-ID: <20260713220037.109649-1-alexanderbendezu10@gmail.com> (raw)

carl9170_cmd_callback() checks if the response length matches what
was expected (ar->readlen). If it doesn't match, it warns and calls
carl9170_restart(), but the code below still runs anyway and copies
the response into ar->readbuf using the actual (wrong) length.

ar->readbuf is only sized for the expected length, so a bad response
larger than expected overflows it. This showed up as a KASAN
stack-out-of-bounds write, found by syzbot with a fuzzed USB device
sending a 60-byte response when 0 bytes were expected.

Move the memcpy() and complete() into an else branch so they only
run when the length actually matches, instead of falling through
after the mismatch is already detected.

Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend")
Reported-by: syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac
Signed-off-by: Alexander Bendezu <alexanderbendezu10@gmail.com>
---
 drivers/net/wireless/ath/carl9170/rx.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ath/carl9170/rx.c b/drivers/net/wireless/ath/carl9170/rx.c
index 6833430130f4..3460b0ca0360 100644
--- a/drivers/net/wireless/ath/carl9170/rx.c
+++ b/drivers/net/wireless/ath/carl9170/rx.c
@@ -145,17 +145,17 @@ static void carl9170_cmd_callback(struct ar9170 *ar, u32 len, void *buffer)
 		 * and we get a stack trace from there.
 		 */
 		carl9170_restart(ar, CARL9170_RR_INVALID_RSP);
-	}
-
-	spin_lock(&ar->cmd_lock);
-	if (ar->readbuf) {
-		if (len >= 4)
-			memcpy(ar->readbuf, buffer + 4, len - 4);
+	} else {
+		spin_lock(&ar->cmd_lock);
+		if (ar->readbuf) {
+			if (len >= 4)
+				memcpy(ar->readbuf, buffer + 4, len - 4);
 
-		ar->readbuf = NULL;
+			ar->readbuf = NULL;
+		}
+		complete(&ar->cmd_wait);
+		spin_unlock(&ar->cmd_lock);
 	}
-	complete(&ar->cmd_wait);
-	spin_unlock(&ar->cmd_lock);
 }
 
 void carl9170_handle_command_response(struct ar9170 *ar, void *buf, u32 len)
-- 
2.53.0


                 reply	other threads:[~2026-07-13 22:00 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20260713220037.109649-1-alexanderbendezu10@gmail.com \
    --to=alexanderbendezu10@gmail.com \
    --cc=chunkeey@googlemail.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com \
    /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