Re: [RFC][PATCH] Privilege dropping security module

[Andy Spencer]

> Can 'length+1' overflow?
> (Can the caller arrange to pass MAX_SIZE_T as the length parameter?
> If yes, that's a vulnerability.)
> I haven't checked how dpriv_stage_write() is called, to see whether
> this is possible.

It's called by vfs_write so it could be a problem. I couldn't find any
standard macros, I added a check to ensure that

  (length < (ssize_t)(~0ULL))
  
which should fix this and ensure that length will fit in the returned
value.


> What if kbuffer isn't '\0'-terminated?  Won't this read past the end
> of kbuffer?

Allocating kbuffer to length+1 zeros should ensure that it's '\0'
terminated, but it changed it to use kmalloc and explicitly set the
terminator instead.


> Are you certain that perm_end and path_start will be within bounds?
> If the user supplies a sufficiently large string (more than MAX_INT
> characters long), could perm_end or path_start be negative?

Limiting length should fix this as well. I also change the markers to
size_t.


Unfortunately I only noticed a few of these things after posting the
second patch against the mainline, so not all of these changes are
included in that post..

Attachment: pgp00000.pgp
Description: PGP signature