After looking everything over there should never be a time when we need to set a length longer than 255. Therefore, unless anyone has any other ideas, we should just revert this patch and use the u8 type for all lengths (or at least for the one in nxt200x_writebytes). It seemed like it would make more sense to use int, but it is really not necessary, and it is a security concern. Kirk On 11/3/05, Michael Krufky <mkrufky@xxxxxxx> wrote: > > Johannes Stezenbach wrote: > > >On Fri, Nov 04, 2005 at 12:49:51AM -0500, Michael Krufky wrote: > > > > > >>Kirk Lapray wrote: > >> > >> > >> > >>>This patch changes all lengths from u8 to int types. It seems to make > >>>more sense that we use int instead of u8. I am not sure why I didn't > >>>do that in the first place. > >>> > >>>*nxt200x.c: > >>>- Change length types from u8 to int > >>> > >>>Signed-off-by: Kirk Lapray <kirk.lapray@xxxxxxxxx > >>><mailto:kirk.lapray@xxxxxxxxx>> > >>> > >>> > >>Applied, Thanks. > >> > >> > > > >This bit is problematic: > > > >-static int nxt200x_writebytes (struct nxt200x_state* state, u8 reg, u8 > *buf, u8 len) > >+static int nxt200x_writebytes (struct nxt200x_state* state, u8 reg, u8 > *buf, int len) > > { > > u8 buf2 [len+1]; > > > > > >akpm already complained about the variable length array on the stack, > >now with int instead of u8 it could easily overflow the stack. > >How do you guaranteee that this is not going to happen? > > > > > Johannes beat me to the question... This is the only part of the code > that has the variable length array. We can revert back to u8 on here > and the callers, (hmm... that might actually mean reverting that last > patch, entirely... i'll check)... or if you could find a way to > eliminate the variable length array, it would be much better. > > -Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.linuxtv.org/pipermail/linux-dvb/attachments/20051104/9f3f65dc/attachment.htm
