Re: [RFC] tty: rpmsg: possible lookup-to-reference lifetime race

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Sep 22, 2026 at 01:28:34AM +0900, Sang-Hoon Choi wrote:
> Hi,
> 
> I would like to report a possible lifetime gap between looking up a port
> in tty_idr and acquiring its reference in rpmsg_tty_install().
> 
> The source reviewed is mainline commit
> 5dd1818b15d98d4a20806cd00b1b40320b06004f.
> 
> The install path calls idr_find() without idr_lock, stores the result in
> tty->driver_data, and calls tty_port_get(&cport->port). The port destructor
> removes the IDR entry under idr_lock, drops the mutex, and frees cport.
> 
> If the last reference is dropped during that lookup-to-get interval, the
> following order appears possible:
> 
>     rpmsg_tty_install()              rpmsg_tty_destruct_port()
>     -------------------              -------------------------

Why would these ever run at the same time?  How can that happen?


>     cport = idr_find(...)
>                                      take idr_lock
>                                      idr_remove(...)
>                                      drop idr_lock
>                                      kfree(cport)
>     tty_port_get(&cport->port)
> 
> tty_port_get() uses kref_get_unless_zero(), but this cannot protect memory
> that has already been freed. The install path also does not check for a
> missing ID or a failed reference acquisition before tty_port_install().
> 
> TTY installation is serialized by tty_mutex, but the RPMsg remove path
> does not explicitly take that mutex around its final tty_port_put().
> The destructor can consequently run from RPMsg removal, not just from
> TTY cleanup. I have not established all cross-subsystem ordering rules.
> 
> A draft takes idr_lock across idr_find() and tty_port_get(), and returns
> -ENODEV if no live reference is obtained. This uses the mutex already
> taken by the destructor before removing the entry. Its scope is this
> lookup/destruction gap; it does not establish safety of every probe or
> remove interaction.
> 
> The draft was compile-checked as rpmsg_tty.o with W=1 in an x86
> allmodconfig build at the commit above and passed checkpatch. There is
> no runtime reproducer with an RPMsg endpoint or sanitizer trace. Device
> permissions and the ability to remove the endpoint also remain relevant
> to any security assessment.
> 
> Does another TTY or RPMsg lifetime rule prevent this particular overlap?
> 
> Reported-by: Changyul Lee <lcy8047@gmail.com>
> Assisted-by: LLM

Why not have your LLM make a patch for this that you can test and get
credit for the fix if there really is an issue?

And again, how can those two things ever run at the same time in a real
system controlled by a normal user (i.e. not root permissions)?

thanks,

greg k-h