linux-kernel - Re: [PATCH] pty: do tty_flip_buffer_push without port->lock in pty

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 4 Sep 2020 16:43:33 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:     Artem Savkov <asavkov@...hat.com>
Cc:     gregkh@...uxfoundation.org, jirislaby@...nel.org,
        threeearcat@...il.com, sergey.senozhatsky@...il.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pty: do tty_flip_buffer_push without port->lock in
 pty_write

On (20/09/01 14:01), Artem Savkov wrote:
[..]
> It looks like the commit was aimed to protect tty_insert_flip_string and
> there is no need for tty_flip_buffer_push to be under this lock.
>
[..]
> @@ -120,10 +120,10 @@ static int pty_write(struct tty_struct *tty, const unsigned char *buf, int c)
>  		spin_lock_irqsave(&to->port->lock, flags);
>  		/* Stuff the data into the input queue of the other end */
>  		c = tty_insert_flip_string(to->port, buf, c);
> +		spin_unlock_irqrestore(&to->port->lock, flags);
>  		/* And shovel */
>  		if (c)
>  			tty_flip_buffer_push(to->port);
> -		spin_unlock_irqrestore(&to->port->lock, flags);

Performing unprotected

	smp_store_release(&buf->tail->commit, buf->tail->used);

does not look safe to me.


This path can be called concurrently - "pty_write vs console's IRQ handler
(TX/RX)", for instance.

Doing this

	queue_work(system_unbound_wq, &buf->work);

outside of port->lock scope also sounds like possible concurrent data
modification.

I'm not sure I see how this patch is safe.

	-ss