carl9170_cmd_callback() copies len - 4 bytes from the device command response into ar->readbuf, which was allocated by the caller with ar->readlen bytes. When the firmware/device returns a response whose payload is larger than the requested ar->readlen, the mismatch is only logged (and the device is restarted via carl9170_restart()); the code then still performs the full-length memcpy(), writing past the end of ar->readbuf -- an out-of-bounds write driven by an attacker-controlled (malicious/compromised) carl9170 USB device. Clamp the copy to ar->readlen so an over-sized response can never write past the caller's buffer. A response that fails the length check is already discarded by the restart, so copying only the buffer-sized prefix changes nothing for the valid path. Reported-by: syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com Tested-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") Cc: stable@vger.kernel.org Signed-off-by: Doruk Tan Ozturk --- Verified with syzbot via "#syz test" against the public C reproducer (Tested-by above); I do not have carl9170 hardware locally. drivers/net/wireless/ath/carl9170/rx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/carl9170/rx.c b/drivers/net/wireless/ath/carl9170/rx.c index 908c4c8..897e682 100644 --- a/drivers/net/wireless/ath/carl9170/rx.c +++ b/drivers/net/wireless/ath/carl9170/rx.c @@ -150,7 +150,8 @@ static void carl9170_cmd_callback(struct ar9170 *ar, u32 len, void *buffer) spin_lock(&ar->cmd_lock); if (ar->readbuf) { if (len >= 4) - memcpy(ar->readbuf, buffer + 4, len - 4); + memcpy(ar->readbuf, buffer + 4, + min_t(unsigned int, len - 4, ar->readlen)); ar->readbuf = NULL; } -- 2.43.0