In article <[EMAIL PROTECTED]> you wrote:
>> I believe we can make that a short. Arjan?
> Is the general way to fix these too-large stack vars to heap allocate
> them? Or is it preferable to put a "static" in front of them, if the
> routine is non-reentrant?
You're not always allowed to allocat
> Disagree
>
> > ahc = ahc_alloc(NULL, name);
>
> ahc_alloc frees name on error
Wow. That would have been a really nasty "fix." Sorry about that -- the
name "ahc_alloc" is a little counter-intuitive ;-)
Thanks for the quick feedback.
Dawson
-
To unsubscribe from this list: send the line
> These are all now either fixed or obsoleted in my tree, and I will send a
> patch to Linus shortly. Thankyou.
Good deal. Thanks for letting us know!
> Do you find it useful to get a response such as this? Are you keeping track
> of the bugs you find? (Or is it simply reassuring to confirm t
[EMAIL PROTECTED] said:
> 1 | drivers/mtd/mtdchar.c
> 1 | fs/jffs/jffs_fm.c
> 2 | fs/jffs/intrep.c
> 1 | drivers/mtd/slram.c
> 1 | drivers/mtd/ftl.c
> 1 | drivers/mtd/mtdram.c
These are all now either fixed or obsoleted in my tree, an
Hi All,
This checker warns when you do not free allocated memory on failure paths.
The error messages with "type=SECURITY" were emitted when the error path
was triggered by a failed copy_*_user or eqvuivalent --- bad people can
easily use these to make the kernel lose memory.
Summary for
5 matches
Mail list logo