From: Jesper Juhl <jesper.juhl@gmail.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Tom Zanussi <zanussi@us.ibm.com>,
Karim Yaghmour <karim@opersys.com>,
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
Paul Mundt <lethal@linux-sh.org>
Subject: [PATCH] Fix a use after free bug in kernel->userspace relay file support
Date: Wed, 18 Jul 2007 23:11:10 +0200 [thread overview]
Message-ID: <200707182311.10538.jesper.juhl@gmail.com> (raw)
Hi,
Coverity spotted what looks like a real possible case of using a
variable after it has been freed.
The problem is in kernel/relay.c::relay_open_buf()
If the code hits "goto free_buf;" it ends up in this code :
free_buf:
relay_destroy_buf(buf); <--- calls kfree() on 'buf'.
free_name:
kfree(tmpname);
end:
return buf; <-- use after free of 'buf'.
I read through the callers and they all handle a NULL return
from this function as an error (and hitting the 'free_buf' label
only happens on failure to chan->cb->create_buf_file(), so that
looks like a clear error to me).
The patch simply sets 'buf' to NULL after the call to
relay_destroy_buf(buf); - as far as I can see that should take
care of the problem.
The patch also corrects a reference to a documentation file while
I was at it.
Warning: I don't know this code at all and I've only read through
it quickly to try and work out what to do here, so I'd really
apreciate it if someone who actually knows how this code should
behave could ACK or NACK the patch before it gets merged anywhere
since I did this pretty blind.
Patch has been compile tested only.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---
diff --git a/kernel/relay.c b/kernel/relay.c
index a615a8f..c55e399 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -1,7 +1,7 @@
/*
* Public API and common code for kernel->userspace relay file support.
*
- * See Documentation/filesystems/relayfs.txt for an overview of relayfs.
+ * See Documentation/filesystems/relay.txt for an overview.
*
* Copyright (C) 2002-2005 - Tom Zanussi (zanussi@us.ibm.com), IBM Corp
* Copyright (C) 1999-2005 - Karim Yaghmour (karim@opersys.com)
@@ -427,6 +427,7 @@ static struct rchan_buf *relay_open_buf(struct rchan *chan, unsigned int cpu)
free_buf:
relay_destroy_buf(buf);
+ buf = NULL;
free_name:
kfree(tmpname);
end:
next reply other threads:[~2007-07-18 21:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-18 21:11 Jesper Juhl [this message]
2007-07-19 19:22 ` David J. Wilder
2007-07-20 0:55 ` Jesper Juhl
2007-07-19 19:36 ` Mathieu Desnoyers
2007-07-20 1:09 Mathieu Desnoyers
2007-07-20 1:29 ` Andrew Morton
2007-07-20 1:42 ` Mathieu Desnoyers
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=200707182311.10538.jesper.juhl@gmail.com \
--to=jesper.juhl@gmail.com \
--cc=karim@opersys.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=zanussi@us.ibm.com \
/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
Powered by JetHome