On 13. 06. 20, 14:51, Xiyu Yang wrote: > uart_shutdown() invokes uart_port_lock(), which returns a reference of > the uart_port object if increases the refcount of the uart_state object > successfully or returns NULL if fails. > > However, uart_shutdown() don't take the return value of uart_port_lock() > as the new uart_port object to "uport" and use the old "uport" instead > to balance refcount in uart_port_unlock(), which may cause a redundant > decrement of refcount occurred when the new "uport" equals to NULL and > then cause a potential memory leak. uport should be valid at that point and both the returned one and the used one should be the same. > Fix this issue by update the "uport" object to the return value of > uart_port_lock() when invoking uart_port_lock(). Do you actually encounter the issue or is this some static analyzer result? > Signed-off-by: Xiyu Yang <xiyuyang19@xxxxxxxxxxxx> > Signed-off-by: Xin Tan <tanxin.ctf@xxxxxxxxx> > --- > drivers/tty/serial/serial_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c > index 57840cf90388..ab8756ef2b60 100644 > --- a/drivers/tty/serial/serial_core.c > +++ b/drivers/tty/serial/serial_core.c > @@ -313,7 +313,7 @@ static void uart_shutdown(struct tty_struct *tty, struct uart_state *state) > * console driver may need to allocate/free a debug object, which > * can endup in printk() recursion. > */ > - uart_port_lock(state, flags); > + uport = uart_port_lock(state, flags); > xmit_buf = state->xmit.buf; > state->xmit.buf = NULL; > uart_port_unlock(uport, flags); > thanks, -- js suse labs
