linux-kernel - Re: [PATCH RFC v3] auxdisplay: charlcd: Fix and clean up handling of x/y commands

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:   Wed, 28 Feb 2018 00:23:41 +0100
From:   Robert Abel <rabel@...ertabel.eu>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, w@....eu,
        geert@...ux-m68k.org, andy.shevchenko@...il.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC v3] auxdisplay: charlcd: Fix and clean up handling of
 x/y commands

On 27 Feb 2018 23:09, Miguel Ojeda wrote:> @@ -469,24 +543,11 @@ static
inline int handle_lcd_special_code(struct charlcd *lcd)
>  	}
>  	case 'x':	/* gotoxy : LxXXX[yYYY]; */
>  	case 'y':	/* gotoxy : LyYYY[xXXX]; */
> -		if (!strchr(esc, ';'))
> -			break;

Might want to keep this. It's in line with all other cases and prevents
calling parse_xy with input that has no chance of being correct due to
missing final ';'.

> +		/* If the command is valid, move to the new address */
> +		if (parse_xy(esc, &priv->addr.x, &priv->addr.y))
> +			charlcd_gotoxy(lcd);

While not in the original code, the inputs are now not clamped to width
and height.
That means for a two-line display ^[[Ly02; will actually end up on line
y = 1, not y = 2 % 2 = 0, because the four-line display logic bumps the
address up.
The same goes for going over lcd->width/lcd->bwidth in the x coordinate.
For four-line displays that ends up going to the line y + 2, because the
buffer is split in the middle.
The distinction between lcd->width and lcd->bwidth depends on whether it
makes sense to put the cursor outside the visible area or not.

Regards,

Robert