* [PATCH] prevent possible infinite loop in fs/select.c::do_pollfd()
@ 2005-04-23 23:22 Jesper Juhl
2005-04-24 8:51 ` Andrew Morton
0 siblings, 1 reply; 3+ messages in thread
From: Jesper Juhl @ 2005-04-23 23:22 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm
If a sufficiently large 'num' is passed to the function, the for loop
becomes an infinite loop - as far as I can see, that's a bug waiting to
happen. Sure, 'len' in struct poll_list is currently an int, so currently
this can't happen, but that might change in the future. In my oppinion,
a function should be able to function correctly with the complete range
of values that can potentially be passed via its parameters, and without
the patch below that's just not true for this function.
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
--- linux-2.6.12-rc2-mm3-orig/fs/select.c 2005-04-05 21:21:47.000000000 +0200
+++ linux-2.6.12-rc2-mm3/fs/select.c 2005-04-24 01:11:13.000000000 +0200
@@ -397,7 +397,7 @@ struct poll_list {
static void do_pollfd(unsigned int num, struct pollfd * fdpage,
poll_table ** pwait, int *count)
{
- int i;
+ unsigned int i;
for (i = 0; i < num; i++) {
int fd;
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] prevent possible infinite loop in fs/select.c::do_pollfd()
2005-04-23 23:22 [PATCH] prevent possible infinite loop in fs/select.c::do_pollfd() Jesper Juhl
@ 2005-04-24 8:51 ` Andrew Morton
2005-04-24 22:55 ` Jesper Juhl
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2005-04-24 8:51 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linux-kernel
Jesper Juhl <juhl-lkml@dif.dk> wrote:
>
> If a sufficiently large 'num' is passed to the function, the for loop
> becomes an infinite loop - as far as I can see, that's a bug waiting to
> happen. Sure, 'len' in struct poll_list is currently an int, so currently
> this can't happen, but that might change in the future. In my oppinion,
> a function should be able to function correctly with the complete range
> of values that can potentially be passed via its parameters, and without
> the patch below that's just not true for this function.
>
> Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
>
> --- linux-2.6.12-rc2-mm3-orig/fs/select.c 2005-04-05 21:21:47.000000000 +0200
> +++ linux-2.6.12-rc2-mm3/fs/select.c 2005-04-24 01:11:13.000000000 +0200
> @@ -397,7 +397,7 @@ struct poll_list {
> static void do_pollfd(unsigned int num, struct pollfd * fdpage,
> poll_table ** pwait, int *count)
> {
> - int i;
> + unsigned int i;
>
> for (i = 0; i < num; i++) {
> int fd;
An expression such as the above which mixes signed and unsigned types will
promote the signed types to unsigned. So there is no bug in the above
`for' statement.
But there's a bug a bit further on:
> unsigned int mask;
> struct pollfd *fdp;
>
> mask = 0;
> fdp = fdpage+i;
This will oops the kernel if there are more than 2^31 pollfd's at *fdpage.
Yes, like most signed variables in the kernel, `i' should really be
unsigned, but I don't think it's worth raising a patch to change it.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] prevent possible infinite loop in fs/select.c::do_pollfd()
2005-04-24 8:51 ` Andrew Morton
@ 2005-04-24 22:55 ` Jesper Juhl
0 siblings, 0 replies; 3+ messages in thread
From: Jesper Juhl @ 2005-04-24 22:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sun, 24 Apr 2005, Andrew Morton wrote:
> Jesper Juhl <juhl-lkml@dif.dk> wrote:
> >
> > If a sufficiently large 'num' is passed to the function, the for loop
> > becomes an infinite loop - as far as I can see, that's a bug waiting to
> > happen. Sure, 'len' in struct poll_list is currently an int, so currently
> > this can't happen, but that might change in the future. In my oppinion,
> > a function should be able to function correctly with the complete range
> > of values that can potentially be passed via its parameters, and without
> > the patch below that's just not true for this function.
> >
> > Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
> >
> > --- linux-2.6.12-rc2-mm3-orig/fs/select.c 2005-04-05 21:21:47.000000000 +0200
> > +++ linux-2.6.12-rc2-mm3/fs/select.c 2005-04-24 01:11:13.000000000 +0200
> > @@ -397,7 +397,7 @@ struct poll_list {
> > static void do_pollfd(unsigned int num, struct pollfd * fdpage,
> > poll_table ** pwait, int *count)
> > {
> > - int i;
> > + unsigned int i;
> >
> > for (i = 0; i < num; i++) {
> > int fd;
>
> An expression such as the above which mixes signed and unsigned types will
> promote the signed types to unsigned. So there is no bug in the above
> `for' statement.
>
You are right of course, I need to remember the promotion rules :)
Still, unsigned int is the logical type to use for `i'.
> But there's a bug a bit further on:
>
> > unsigned int mask;
> > struct pollfd *fdp;
> >
> > mask = 0;
> > fdp = fdpage+i;
>
> This will oops the kernel if there are more than 2^31 pollfd's at *fdpage.
>
Hmm, if you mean that i will overflow and become negative so we'll actully
be subtracting from fdpage, then I'm not so sure - won't gcc actually
promote i to unsigned int here as well? I did a little test app, and it
seems that's the case (well, `i' of course still ought to be unsigned).
But I guess we'll probably cause fdpage to wrap with such a large i (but
then we should never have managed to allocate so many fd's in the first
place).
> Yes, like most signed variables in the kernel, `i' should really be
> unsigned, but I don't think it's worth raising a patch to change it.
>
Why not? I thought we were trying to make the kernel as perfect as
possible. I agree with you that there are many bigger issues that have
priority, but even the little things (like this) ought to get fixed as
well IMHO (and when the patch is already done, why not apply it?).
--
Jesper
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-04-24 22:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-23 23:22 [PATCH] prevent possible infinite loop in fs/select.c::do_pollfd() Jesper Juhl
2005-04-24 8:51 ` Andrew Morton
2005-04-24 22:55 ` Jesper Juhl
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.