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.