]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
usb: xhci: Fix NULL pointer dereference on certain command aborts
authorMichal Pecio <michal.pecio@gmail.com>
Fri, 27 Dec 2024 12:01:40 +0000 (14:01 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 13 Mar 2025 11:50:21 +0000 (12:50 +0100)
commitcf30300a216a4f8dce94e11781a866a09d4b50d4
tree03f28e62dce9a1862d1899b3295c2e29b7bfa80b
parentb27f10764d800d6875fef8649099bacaba15b0bf
usb: xhci: Fix NULL pointer dereference on certain command aborts

[ Upstream commit 1e0a19912adb68a4b2b74fd77001c96cd83eb073 ]

If a command is queued to the final usable TRB of a ring segment, the
enqueue pointer is advanced to the subsequent link TRB and no further.
If the command is later aborted, when the abort completion is handled
the dequeue pointer is advanced to the first TRB of the next segment.

If no further commands are queued, xhci_handle_stopped_cmd_ring() sees
the ring pointers unequal and assumes that there is a pending command,
so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.

Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell
ring likely is unnecessary too, but it's harmless. Leave it alone.

This is probably Bug 219532, but no confirmation has been received.

The issue has been independently reproduced and confirmed fixed using
a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.
Everything continued working normally after several prevented crashes.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=219532
Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,")
CC: stable@vger.kernel.org
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20241227120142.1035206-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/usb/host/xhci-ring.c