mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Eric Paris <eparis@parisplace.org>
To: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: [PATCH] selinux_sb_copy_data should not require a whole page
Date: Wed, 29 Jun 2005 16:46:56 -0400	[thread overview]
Message-ID: <1120078016.9967.34.camel@localhost.localdomain> (raw)

Currently selinux_sb_copy_data requires an entire page be allocated to
*orig when the function is called.  This "requirement" is based on the
fact that we call copy_page(in_save, nosec_save) and in_save = orig when
the data is not FS_BINARY_MOUNTDATA.  This means that if a caller were
to call do_kern_mount with only about 10 bytes of options, they would
get passed here and then we would corrupt PAGE_SIZE - 10 bytes of memory
(with all zeros.)  

Currently it appears all in kernel FS's use one page of data so this has
not been a problem.  An out of kernel FS did just what is described
above and it would almost always panic shortly after they tried to
mount.  From looking else where in the kernel it is obvious that this
string of data must always be null terminated.  (See example in do_mount
where it always zeros the last byte.)  Thus I suggest we use strcpy in
place of copy_page.  In this way we make sure the amount we copy is
always less than or equal to the amount we received and since do_mount
is zeroing the last byte this should be safe for all.

-Eric

Signed-off-by: Eric Paris <eparis@parisplace.org>

--- linux-2.6.12.1/security/selinux/hooks.c.eric	2005-06-29 14:48:54.000000000 -0400
+++ linux-2.6.12.1/security/selinux/hooks.c	2005-06-29 14:50:38.000000000 -0400
@@ -68,6 +68,7 @@
 #include <linux/personality.h>
 #include <linux/sysctl.h>
 #include <linux/audit.h>
+#include <linux/string.h>
 
 #include "avc.h"
 #include "objsec.h"
@@ -1943,7 +1944,7 @@ static int selinux_sb_copy_data(struct f
 		}
 	} while (*in_end++);
 
-	copy_page(in_save, nosec_save);
+	strcpy(in_save, nosec_save);
 	free_page((unsigned long)nosec_save);
 out:
 	return rc;



             reply	other threads:[~2005-06-29 20:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-29 20:46 Eric Paris [this message]
2005-06-29 21:17 ` James Morris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1120078016.9967.34.camel@localhost.localdomain \
    --to=eparis@parisplace.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®