[Konsole-devel] KDE/kdebase/apps/konsole/src

[Robert Knight]

Hi Dirk,

> this solution is also possible, I haven't traced however which other code 
> paths invoke Screen directly. would you prefer that fix?

I think it would be simpler and safer.

Emulation, Vt102Emulation and ScreenWindow are the only classes which
use Screen directly I believe.  Of those, only Emulation and
Vt102Emulation might send data which is filtered from the terminal
display.

> I'm also not sure if there is a way to overflow the lines/rows by repeatedly 
> increasing cursor position/screen size etc. being able to increase by 4096 is 
> still enough to run into dangerous areas. 

By 'dangerous' I presume you mean using silly amounts of memory or maybe
confusing some terminal programs?

On my laptop which has a fairly high-resolution screen (1400x1050) the
maximum window size I can get with a readable font is 200 columns x 65
lines.  I think say 512 columns x 256 lines would be a safe upper
limit.  

The mouse handling code uses single bytes to encode the column and line
positions sent to the terminal so that will wrap around before that -
this is part of the xterm spec.

> I'm also not sure if there is a way to overflow the lines/rows by repeatedly 
> increasing cursor position/screen size etc.

Some test cases are needed really.  The standard test I use for the
terminal is the vttest suite - which as far as I know only does positive
tests.

Regards,
Robert.

On Wed, 2008-05-14 at 17:11 +0200, Dirk Mueller wrote:
> On Wednesday 14 May 2008, Robert Knight wrote:
> 
> > An alternative solution might be to restrict the p and q arguments to
> > Vt102Emulation::tau() to a limited range (eg. 2^16) by changing
> > Vt102Emulation::addDigit() and avoid checking for overflows in Screen.
> > If I read the parser code correctly p and q are always >= 0 but there is
> > no upper limit although the maximum expected values of p and q will be
> > the size of a large window in columns and rows (a few hundred at most).
> 
> this solution is also possible, I haven't traced however which other code 
> paths invoke Screen directly. would you prefer that fix?
> 
> I'm also not sure if there is a way to overflow the lines/rows by repeatedly 
> increasing cursor position/screen size etc. being able to increase by 4096 is 
> still enough to run into dangerous areas. 
> 
> Greetings,
> Dirk
>