All of lore.kernel.org
 help / color / mirror / Atom feed
From: hewei-gikaku <skyexpoc@gmail.com>
To: Christian Lamparter <chunkeey@googlemail.com>
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	HE WEI <skyexpoc@gmail.com>,
	syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com
Subject: [PATCH] wifi: carl9170: bail out on invalid command response to fix stack-out-of-bounds write
Date: Wed, 24 Jun 2026 14:32:45 +0900	[thread overview]
Message-ID: <20260624053246.74617-1-skyexpoc@gmail.com> (raw)

From: HE WEI (ギカク) <skyexpoc@gmail.com>

carl9170_cmd_callback() copies a command response coming from the USB
device into ar->readbuf using the device-reported length:

	memcpy(ar->readbuf, buffer + 4, len - 4);

ar->readbuf points at the buffer supplied by the caller of
carl9170_exec_cmd(), which is frequently an on-stack buffer sized to the
expected response length (ar->readlen).

The preceding sanity check only emits a warning and schedules a restart
when ar->readlen != len - 4; it does not stop processing, so the
memcpy() still runs with the attacker-controlled length.  A malicious or
malfunctioning AR9170 USB device can therefore answer a pending command
with an over-sized response and overflow ar->readbuf, as reported by
syzbot:

  BUG: KASAN: stack-out-of-bounds Write in carl9170_handle_command_response

The comment in that branch already documents the intended behaviour
("Do not complete.  The command times out, and we get a stack trace from
there."), but the return statement was missing.  Return after
carl9170_restart() so an over-/under-sized response is neither copied
into ar->readbuf nor completed; carl9170_exec_cmd() then times out and
clears readbuf in its error path.

Reported-by: syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac
Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend")
Signed-off-by: HE WEI (ギカク) <skyexpoc@gmail.com>
---
 drivers/net/wireless/ath/carl9170/rx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/carl9170/rx.c b/drivers/net/wireless/ath/carl9170/rx.c
--- a/drivers/net/wireless/ath/carl9170/rx.c
+++ b/drivers/net/wireless/ath/carl9170/rx.c
@@ -145,6 +145,7 @@ 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);
+		return;
 	}

 	spin_lock(&ar->cmd_lock);
--
2.43.0

                 reply	other threads:[~2026-06-24  5:33 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=20260624053246.74617-1-skyexpoc@gmail.com \
    --to=skyexpoc@gmail.com \
    --cc=chunkeey@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.