* [PATCH] USB: serial: opticon: fix UAF in write callback during port removal
@ 2026-03-09 14:27 Fan Wu
2026-03-10 8:56 ` Johan Hovold
0 siblings, 1 reply; 6+ messages in thread
From: Fan Wu @ 2026-03-09 14:27 UTC (permalink / raw)
To: Johan Hovold, Greg Kroah-Hartman; +Cc: linux-usb, linux-kernel, Fan Wu
The opticon driver anchors write URBs to priv->anchor in opticon_write()
and frees priv in opticon_port_remove() without first killing these
anchored URBs. The completion callback opticon_write_control_callback()
may dereference priv via usb_get_serial_port_data() and access
priv->lock, priv->outstanding_urbs, and priv->outstanding_bytes after
it has been freed.
If a write URB is in flight when the port is removed:
CPU 0 (remove path) CPU 1 (URB completion)
--------------------- ---------------------
opticon_port_remove()
kfree(priv) <--+
| --> opticon_write_control_callback()
| priv = usb_get_serial_port_data()
| spin_lock_irqsave(&priv->lock)
| --priv->outstanding_urbs // possible UAF
return |
usb_free_urb()
Fix this by calling usb_kill_anchored_urbs(&priv->anchor) before
kfree(priv) so that all in-flight URBs have finished before the private
data is freed.
Note that opticon_close() already correctly kills anchored URBs; this
fix addresses the port_remove path which was overlooked.
Fixes: 648d4e16567e ("USB: serial: opticon: add write support")
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
---
drivers/usb/serial/opticon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/opticon.c b/drivers/usb/serial/opticon.c
index e2bed477ad57..80e332e14384 100644
--- a/drivers/usb/serial/opticon.c
+++ b/drivers/usb/serial/opticon.c
@@ -370,6 +370,7 @@ static void opticon_port_remove(struct usb_serial_port *port)
{
struct opticon_private *priv = usb_get_serial_port_data(port);
+ usb_kill_anchored_urbs(&priv->anchor);
kfree(priv);
}
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] USB: serial: opticon: fix UAF in write callback during port removal
2026-03-09 14:27 [PATCH] USB: serial: opticon: fix UAF in write callback during port removal Fan Wu
@ 2026-03-10 8:56 ` Johan Hovold
2026-03-10 17:04 ` Fan Wu
0 siblings, 1 reply; 6+ messages in thread
From: Johan Hovold @ 2026-03-10 8:56 UTC (permalink / raw)
To: Fan Wu; +Cc: Greg Kroah-Hartman, linux-usb, linux-kernel
On Mon, Mar 09, 2026 at 02:27:57PM +0000, Fan Wu wrote:
> The opticon driver anchors write URBs to priv->anchor in opticon_write()
> and frees priv in opticon_port_remove() without first killing these
> anchored URBs. The completion callback opticon_write_control_callback()
> may dereference priv via usb_get_serial_port_data() and access
> priv->lock, priv->outstanding_urbs, and priv->outstanding_bytes after
> it has been freed.
>
> If a write URB is in flight when the port is removed:
>
> CPU 0 (remove path) CPU 1 (URB completion)
> --------------------- ---------------------
> opticon_port_remove()
> kfree(priv) <--+
> | --> opticon_write_control_callback()
> | priv = usb_get_serial_port_data()
> | spin_lock_irqsave(&priv->lock)
> | --priv->outstanding_urbs // possible UAF
> return |
> usb_free_urb()
This cannot happen as ports are always shut down before being
deregistered (see usb_serial_disconnect()).
It used to be possible to trigger something like this by manually
unbinding a port device through sysfs as root but even that's no longer
possible since commit fdb838efa31e ("USB: serial: suppress driver bind
attributes").
> Fix this by calling usb_kill_anchored_urbs(&priv->anchor) before
> kfree(priv) so that all in-flight URBs have finished before the private
> data is freed.
>
> Note that opticon_close() already correctly kills anchored URBs; this
> fix addresses the port_remove path which was overlooked.
>
> Fixes: 648d4e16567e ("USB: serial: opticon: add write support")
> Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
How was this potential issue found? Are you using some kind of LLM or
other tool?
Johan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] USB: serial: opticon: fix UAF in write callback during port removal
2026-03-10 8:56 ` Johan Hovold
@ 2026-03-10 17:04 ` Fan Wu
2026-03-11 12:14 ` Greg Kroah-Hartman
0 siblings, 1 reply; 6+ messages in thread
From: Fan Wu @ 2026-03-10 17:04 UTC (permalink / raw)
To: Johan Hovold; +Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, Fan Wu
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
On Tue, Mar 10, 2026 at 09:56:48 +0100, Johan Hovold wrote:
> How was this potential issue found? Are you using some kind of LLM or
> other tool?
Hi Johan,
Thanks for the explanation. You're right — I missed the lifecycle guarantees
provided by usb_serial_disconnect(), and since opticon_close() already handles
the URB cleanup, this report is a false positive.
I'm currently researching static analysis techniques (CodeQL combined with LLM
assistance) for detecting UAF bugs, particularly around cross-entry lifetimes.
In this case, the analysis missed the subsystem-level guarantee that close runs
before remove.
Thanks for pointing out commit fdb838efa31e and the relevant mechanism — this
is very helpful feedback for my research.
Please disregard this patch, and apologies for the noise.
Best regards,
Fan Wu
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] USB: serial: opticon: fix UAF in write callback during port removal
2026-03-10 17:04 ` Fan Wu
@ 2026-03-11 12:14 ` Greg Kroah-Hartman
2026-03-11 14:26 ` Fan Wu
0 siblings, 1 reply; 6+ messages in thread
From: Greg Kroah-Hartman @ 2026-03-11 12:14 UTC (permalink / raw)
To: Fan Wu; +Cc: Johan Hovold, linux-usb, linux-kernel
On Tue, Mar 10, 2026 at 05:04:24PM +0000, Fan Wu wrote:
> On Tue, Mar 10, 2026 at 09:56:48 +0100, Johan Hovold wrote:
> > How was this potential issue found? Are you using some kind of LLM or
> > other tool?
>
> Hi Johan,
>
> Thanks for the explanation. You're right — I missed the lifecycle guarantees
> provided by usb_serial_disconnect(), and since opticon_close() already handles
> the URB cleanup, this report is a false positive.
>
> I'm currently researching static analysis techniques (CodeQL combined with LLM
> assistance) for detecting UAF bugs, particularly around cross-entry lifetimes.
> In this case, the analysis missed the subsystem-level guarantee that close runs
> before remove.
As is required, you always have to document this type of thing in the
changelog text.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] USB: serial: opticon: fix UAF in write callback during port removal
2026-03-11 12:14 ` Greg Kroah-Hartman
@ 2026-03-11 14:26 ` Fan Wu
2026-03-11 15:41 ` Johan Hovold
0 siblings, 1 reply; 6+ messages in thread
From: Fan Wu @ 2026-03-11 14:26 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Fan Wu, Johan Hovold, linux-usb, linux-kernel
> On Mar 11, 2026, at 20:14, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Tue, Mar 10, 2026 at 05:04:24PM +0000, Fan Wu wrote:
>> On Tue, Mar 10, 2026 at 09:56:48 +0100, Johan Hovold wrote:
>>> How was this potential issue found? Are you using some kind of LLM or
>>> other tool?
>>
>> Hi Johan,
>>
>> Thanks for the explanation. You're right — I missed the lifecycle guarantees
>> provided by usb_serial_disconnect(), and since opticon_close() already handles
>> the URB cleanup, this report is a false positive.
>>
>> I'm currently researching static analysis techniques (CodeQL combined with LLM
>> assistance) for detecting UAF bugs, particularly around cross-entry lifetimes.
>> In this case, the analysis missed the subsystem-level guarantee that close runs
>> before remove.
>
> As is required, you always have to document this type of thing in the
> changelog text.
>
> thanks,
>
> greg k-h
Hi Johan,
Thanks for the reminder. Understood — I'll make sure to explicitly document the
search method and tool assistance in the changelog for any future patches.
Best regards,
Fan Wu
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] USB: serial: opticon: fix UAF in write callback during port removal
2026-03-11 14:26 ` Fan Wu
@ 2026-03-11 15:41 ` Johan Hovold
0 siblings, 0 replies; 6+ messages in thread
From: Johan Hovold @ 2026-03-11 15:41 UTC (permalink / raw)
To: Fan Wu; +Cc: Greg Kroah-Hartman, Fan Wu, linux-usb, linux-kernel
On Wed, Mar 11, 2026 at 10:26:33PM +0800, Fan Wu wrote:
> > On Mar 11, 2026, at 20:14, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Tue, Mar 10, 2026 at 05:04:24PM +0000, Fan Wu wrote:
> >> On Tue, Mar 10, 2026 at 09:56:48 +0100, Johan Hovold wrote:
> >>> How was this potential issue found? Are you using some kind of LLM or
> >>> other tool?
> >> I'm currently researching static analysis techniques (CodeQL combined with LLM
> >> assistance) for detecting UAF bugs, particularly around cross-entry lifetimes.
> >> In this case, the analysis missed the subsystem-level guarantee that close runs
> >> before remove.
> >
> > As is required, you always have to document this type of thing in the
> > changelog text.
> Thanks for the reminder. Understood — I'll make sure to explicitly document the
> search method and tool assistance in the changelog for any future patches.
Here's a link to the guidelines if you haven't found them already (under
Documentation/ in the kernel tree):
https://docs.kernel.org/process/researcher-guidelines.html
Johan
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-03-11 15:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-09 14:27 [PATCH] USB: serial: opticon: fix UAF in write callback during port removal Fan Wu
2026-03-10 8:56 ` Johan Hovold
2026-03-10 17:04 ` Fan Wu
2026-03-11 12:14 ` Greg Kroah-Hartman
2026-03-11 14:26 ` Fan Wu
2026-03-11 15:41 ` Johan Hovold
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox