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

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

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

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

> 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

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