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

[Sang-Hoon Choi]

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()
    -------------------              -------------------------
    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@xxxxxxxxx>
Assisted-by: LLM

Thanks,
Sang-Hoon Choi