linux-kernel - Re: [PATCH] usb: xhci: fix a possible null-pointer dereference in xhci_setup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241002141454.6efded4e@foxbook>
Date: Wed, 2 Oct 2024 14:14:54 +0200
From: Michał Pecio <michal.pecio@...il.com>
To: islituo@...il.com
Cc: baijiaju1990@...il.com, gregkh@...uxfoundation.org,
 linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
 mathias.nyman@...el.com
Subject: Re: [PATCH] usb: xhci: fix a possible null-pointer dereference in
 xhci_setup_device()

> By the way, is your analyzer not finding the issue that any call to
> xhci_mem_cleanup() wakes up everybody waiting on the command queue and
> then sets a bunch of things (including xhci->dcbaa) to NULL shortly
> thereafter? This race looks like it shouldn't be harder to detect than
> the things you are doing already.

Actually, I think neither the above nor the issue you reported is a
problem at all, because xhci_setup_device() checks if command->status
is COMP_COMMAND_ABORTED and returns early in this case. At a quick
glance, other command handlers do the same.

This status code is always assigned by xhci_cleanup_command_queue().

Regards,
Michal