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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <10b4e5f7-95b9-38e6-bcd5-1132d595301c@kernel.org>
Date:   Tue, 28 Jun 2022 10:08:12 +0200
From:   Jiri Slaby <jirislaby@...nel.org>
To:     Yangxi Xiang <xyangxi5@...il.com>, linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Johan Hovold <johan@...nel.org>,
        Igor Matheus Andrade Torrente <igormtorrente@...il.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        nick black <dankamongmen@...il.com>
Subject: Re: [PATCH v2] vt: fix memory overlapping when deleting chars in the
 buffer

On 27. 06. 22, 14:54, Yangxi Xiang wrote:
> A memory overlapping copy occurs when deleting a long line. This memory
> overlapping copy can cause data corruption when scr_memcpyw is optimized
> to memcpy because memcpy does not ensure its behavior if the destination
> buffer overlaps with the source buffer. The line buffer is not always
> broken, because the memcpy utilizes the hardware acceleration, whose
> result is not deterministic.
> 
> Fix this problem by using replacing the scr_memcpyw with scr_memmovew, and
> preserving the memcpy optimization when the buffers are not overlapping.
> 
> Fixes: 81732c3b2fed ("Fix line garbage in virtual console").
> Signed-off-by: Yangxi Xiang <xyangxi5@...il.com>
> ---
>   drivers/tty/vt/vt.c | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index f8c87c4d7399..d87bff9d8ed5 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -853,9 +853,13 @@ static void insert_char(struct vc_data *vc, unsigned int nr)
>   static void delete_char(struct vc_data *vc, unsigned int nr)
>   {
>   	unsigned short *p = (unsigned short *) vc->vc_pos;
> +	unsigned short cp = (vc->vc_cols - vc->state.x - nr) * 2;
>   
>   	vc_uniscr_delete(vc, nr);
> -	scr_memcpyw(p, p + nr, (vc->vc_cols - vc->state.x - nr) * 2);
> +	if (cp > nr)
> +		scr_memmovew(p, p + nr, cp);
> +	else
> +		scr_memcpyw(p, p + nr, cp);

Why not to use memmove in both cases? I.e. simply switch scr_memcpyw to 
scr_memmovew?

thanks,
-- 
js
suse labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ