From: "Alexey V. Vissarionov" <gremlin@altlinux.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Alexey V. Vissarionov" <gremlin@altlinux.org>,
Jon Hunter <jonathanh@nvidia.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Thierry Reding <thierry.reding@gmail.com>,
Uwe Kleine-Knig <u.kleine-koenig@baylibre.com>,
Nagarjuna Kristam <nkristam@nvidia.com>,
linux-usb@vger.kernel.org, linux-tegra@vger.kernel.org,
lvc-project@linuxtesting.org
Subject: Re: [PATCH v2] usb: tegra-xudc: check ep and ep->desc before deref
Date: Mon, 21 Apr 2025 18:07:28 +0300 [thread overview]
Message-ID: <20250421150728.GA32725@altlinux.org> (raw)
In-Reply-To: <f17d63cd-14a0-44bf-af9c-358d2a36b69d@rowland.harvard.edu>
Good ${greeting_time}!
On 2025-04-16 10:13:05 -0400, Alan Stern wrote:
>> + /* trb_phys_to_virt() dereferences ep; check it here */
>> + if (!ep) {
>> + dev_err(xudc->dev, "unexpected NULL pointer: ep\n");
>> + return;
>> + }
> Is this condition something that is totally under the kernel's
> control? That is, is ep always passed in by a driver and there's
> never a valid reason for it to be NULL?
IIUC, the endpoints are reported by the device. But the device
may be something like STM32 uC with malicious firmware.
> Then there's really no need for this check. In real life it
> will never trigger.
With real devices. But ready-to-use STM32F103C8T6 boards are sold
for only 10...15 CNY, so one would need only to write a firmware
and to flash it in the board using 20 CNY program-and-debug tool.
> Of course, if it is reasonable for ep or ep->desc to sometimes
> be NULL, then the checks should be made. But if that were true,
> I don't know why you would call dev_err().
This was suggested by Jon Hunter on 16 Apr 2025 08:43:58 +0100 and
I've agreed that would be wise.
--
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
next prev parent reply other threads:[~2025-04-21 15:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 17:42 [PATCH] usb: tegra-xudc: check ep->desc before dereferencing Alexey V. Vissarionov
2025-04-16 7:43 ` Jon Hunter
2025-04-16 9:53 ` Alexey V. Vissarionov
2025-04-16 9:55 ` [PATCH v1] usb: tegra-xudc: check ep and ep->desc before deref Alexey V. Vissarionov
2025-04-16 10:20 ` Jon Hunter
2025-04-16 11:54 ` Alexey V. Vissarionov
2025-04-16 12:00 ` [PATCH v2] " Alexey V. Vissarionov
2025-04-16 14:13 ` Alan Stern
2025-04-21 15:07 ` Alexey V. Vissarionov [this message]
2025-04-21 15:41 ` Alan Stern
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=20250421150728.GA32725@altlinux.org \
--to=gremlin@altlinux.org \
--cc=gregkh@linuxfoundation.org \
--cc=jonathanh@nvidia.com \
--cc=linux-tegra@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=nkristam@nvidia.com \
--cc=stern@rowland.harvard.edu \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@baylibre.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.