linux-kernel - Re: [PATCH AUTOSEL 4.4 28/29] serial: core: Keep mctrl register state and cached copy in sync

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:   Tue, 18 Jan 2022 07:03:06 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Sasha Levin <sashal@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Lukas Wunner <lukas@...ner.de>, jirislaby@...nel.org,
        linux-serial@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 4.4 28/29] serial: core: Keep mctrl register
 state and cached copy in sync

On Mon, Jan 17, 2022 at 10:08:21PM -0500, Sasha Levin wrote:
> From: Lukas Wunner <lukas@...ner.de>
> 
> [ Upstream commit 93a770b7e16772530196674ffc79bb13fa927dc6 ]
> 
> struct uart_port contains a cached copy of the Modem Control signals.
> It is used to skip register writes in uart_update_mctrl() if the new
> signal state equals the old signal state.  It also avoids a register
> read to obtain the current state of output signals.
> 
> When a uart_port is registered, uart_configure_port() changes signal
> state but neglects to keep the cached copy in sync.  That may cause
> a subsequent register write to be incorrectly skipped.  Fix it before
> it trips somebody up.
> 
> This behavior has been present ever since the serial core was introduced
> in 2002:
> https://git.kernel.org/history/history/c/33c0d1b0c3eb
> 
> So far it was never an issue because the cached copy is initialized to 0
> by kzalloc() and when uart_configure_port() is executed, at most DTR has
> been set by uart_set_options() or sunsu_console_setup().  Therefore,
> a stable designation seems unnecessary.

As per the text here, this is not needed in any stable trees, so can you
please drop it from all of your autosel queues now?

thanks,

greg k-h