linux-kernel - Re: [RFC][PATCH] Privilege dropping security module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 Sep 2009 07:36:12 +0000
From:	Andy Spencer <andy753421@...il.com>
To:	David Wagner <daw-news@...berkeley.edu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] Privilege dropping security module

> 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..

Content of type "application/pgp-signature" skipped