linux-kernel - [PATCH 0/1] usb: xhci: Fix NULL pointer dereference on certain command aborts

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-next>] [day] [month] [year] [list]

Message-ID: <20241203205123.05b32413@foxbook>
Date: Tue, 3 Dec 2024 20:51:23 +0100
From: Michal Pecio <michal.pecio@...il.com>
To: Mathias Nyman <mathias.nyman@...el.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/1]  usb: xhci: Fix NULL pointer dereference on certain
 command aborts

Hi,

This fixes an issue discovered by code review prompted by this crash:
https://bugzilla.kernel.org/show_bug.cgi?id=219532

It has not been confirmed by the reporter and doesn't agree with some
of his own analysis, but:

1. it is consistent with logs provided by the reporter
2. it looks like a real bug in its own right anyway
3. it is rare enough that it may not happen again soon

I tried to minimize this patch and only address the potential crash.
The code looks like it could use more cleanup, though. Any comments
regarding the following suggestions?

1. It looks like we don't really need to ring the doorbell if cmd_list
   and cur_cmd are empty. Even if commands were no-oped, they are still
   on the list. And if there is anything between enqueue and dequeue
   which is not a link TRB and not on the list, we will have no idea
   how to handle the resulting event. IOW, it's not supposed to happen
   and probably never happening, or we would hear about it.

2. The whole business about turning commands into no-ops doesn't seem
   to happen in mainline today. Only the pending command gets aborted
   and it is removed from the list before the no-op loop runs.

3. xhci->current_cmd seems redundant - is there ever a valid reason for
   it being anything other than xhci->cmd_list first element?

   I find it suspicious that handle_cmd_completion() complains if the
   completed command isn't the first on cmd_list, but not if it doesn't
   match current_cmd and that current_cmd is then left unchanged.

Regards,
Michal