From: Vegard Nossum <vegard.nossum@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Subject: [RFC][PATCH] utsname: completely overwrite prior information
Date: Fri, 12 Sep 2008 22:36:24 +0200 [thread overview]
Message-ID: <20080912203624.GA25965@damson.getinternet.no> (raw)
>From 25c69de4760e20cf7562cf92a55b65a71546093e Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@gmail.com>
Date: Thu, 11 Sep 2008 19:59:50 +0200
Subject: [PATCH] utsname: completely overwrite prior information
On sethostname() and setdomainname(), previous information may be
retained if it was longer than than the new hostname/domainname.
This can be demonstrated trivially by calling sethostname() first
with a long name, then with a short name, and then calling uname()
to retrieve the full buffer that contains the hostname (and
possibly parts of the old hostname), one just has to look past the
terminating zero.
I don't know if we should really care that much (hence the RFC);
the only scenarios I can possibly think of is administrator
putting something sensitive in the hostname (or domain name) by
accident, and changing it back will not undo the mistake entirely,
though it's not like we can recover gracefully from "rm -rf /"
either... The other scenario is namespaces (CLONE_NEWUTS) where
some information may be unintentionally "inherited" from the
previous namespace (a program wants to hide the original name and
does clone + sethostname, but some information is still left).
I think the patch may be defended on grounds of the principle of
least surprise. But I am not adamant :-)
(I guess the question now is whether userspace should be able to
write embedded NULs into the buffer or not...)
At least the observation has been made and the patch has been
presented.
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
---
kernel/sys.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index 038a7bc..78b4515 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1352,7 +1352,8 @@ asmlinkage long sys_sethostname(char __user *name, int len)
errno = -EFAULT;
if (!copy_from_user(tmp, name, len)) {
memcpy(utsname()->nodename, tmp, len);
- utsname()->nodename[len] = 0;
+ memset(utsname()->nodename + len, 0,
+ sizeof(utsname()->nodename) - len);
errno = 0;
}
up_write(&uts_sem);
@@ -1398,7 +1399,8 @@ asmlinkage long sys_setdomainname(char __user *name, int len)
errno = -EFAULT;
if (!copy_from_user(tmp, name, len)) {
memcpy(utsname()->domainname, tmp, len);
- utsname()->domainname[len] = 0;
+ memset(utsname()->domainname + len, 0,
+ sizeof(utsname()->domainname) - len);
errno = 0;
}
up_write(&uts_sem);
--
1.5.5.1
next reply other threads:[~2008-09-12 20:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-12 20:36 Vegard Nossum [this message]
2008-09-12 22:11 ` [RFC][PATCH] utsname: completely overwrite prior information Andrew Morton
2008-09-13 7:25 ` Vegard Nossum
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=20080912203624.GA25965@damson.getinternet.no \
--to=vegard.nossum@gmail.com \
--cc=akpm@linux-foundation.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