On Saturday 01 August 2009 17:04:19 Henrique de Moraes Holschuh wrote:
> From: Michael Buesch
>
> Avoid a heap buffer overrun triggered by an integer overflow of the
> userspace controlled "count" variable.
>
> If userspace passes in a "count" of (size_t)-1l, the kmalloc size will
> overflow to
On Sunday 02 August 2009 03:50:12 Henrique de Moraes Holschuh wrote:
> > Note that it turns out this is not a real-life bug after all.
> > The VFS code checks count for signedness (high bit set) and bails
> > out if this is the case.
> > Well, it might probably be a good idea to restrict the count
On Sunday 02 August 2009 06:11:13 Len Brown wrote:
> applied w/ simplified check-in commment
>
> thanks,
> Len Brown, Intel Open Source Technology Center
Thanks.
The same discussion applies to the toshiba_acpi patch I sent to you.
--
Greetings, Michael.
applied w/ simplified check-in commment
thanks,
Len Brown, Intel Open Source Technology Center
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integrat
On Sat, 01 Aug 2009, Michael Buesch wrote:
> On Saturday 01 August 2009 17:04:19 Henrique de Moraes Holschuh wrote:
> > From: Michael Buesch
> >
> > Avoid a heap buffer overrun triggered by an integer overflow of the
> > userspace controlled "count" variable.
> >
> > If userspace passes in a "co
From: Michael Buesch
Avoid a heap buffer overrun triggered by an integer overflow of the
userspace controlled "count" variable.
If userspace passes in a "count" of (size_t)-1l, the kmalloc size will
overflow to ((size_t)-1l + 2) = 1, so only one byte will be allocated.
However, copy_from_user()
