From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: linux1394-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: [PATCH v3] firewire: cdev: check write quadlet request length to avoid buffer overflow
Date: Wed, 7 Jul 2010 12:01:58 +0200 (CEST) [thread overview]
Message-ID: <tkrat.b2582c62a3eaf0ab@s5r6.in-berlin.de> (raw)
In-Reply-To: <tkrat.e922615a6f88a33e@s5r6.in-berlin.de>
Check that the data length of a write quadlet request actually is large
enough for a quadlet. Otherwise, fw_fill_request could access the four
bytes after the end of the outbound_transaction_event structure.
Reported-by: Clemens Ladisch <clemens@ladisch.de>
Since struct outbound_transaction_event *e is slab-allocated, such an
access may hit unallocated memory only if sizeof(*e) == 256 or 512 or
any other power of 2 above 2**2. In kernel 2.6.34, sizeof(*e) is > 128
and < 256 on 32bit architectures, and > 256 and < 512 on 64bit
architectures. Thus the only problem is that a bogus write quadlet
request with user-specified length of < 3 will put 1...4 random bytes
into the packet payload. But this is the user's problem then, not the
kernel's.
Hence the corner case handling can be optimized by a size is_power_of_2
check. This is a constant expression and will cause the whole check to
be omitted by the compiler's dead code elimination.
Of course this relies on certain behavior of the slab allocator.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/firewire/core-cdev.c | 6 ++++++
1 file changed, 6 insertions(+)
Index: b/drivers/firewire/core-cdev.c
===================================================================
--- a/drivers/firewire/core-cdev.c
+++ b/drivers/firewire/core-cdev.c
@@ -29,6 +29,7 @@
#include <linux/jiffies.h>
#include <linux/kernel.h>
#include <linux/kref.h>
+#include <linux/log2.h>
#include <linux/mm.h>
#include <linux/module.h>
#include <linux/mutex.h>
@@ -564,6 +565,11 @@ static int init_request(struct client *c
(request->length > 4096 || request->length > 512 << speed))
return -EIO;
+ /* Corner case: Access past the end of *e in fw_fill_request() */
+ if (request->tcode == TCODE_WRITE_QUADLET_REQUEST &&
+ request->length < 4 && is_power_of_2(sizeof(*e)))
+ return -EINVAL;
+
e = kmalloc(sizeof(*e) + request->length, GFP_KERNEL);
if (e == NULL)
return -ENOMEM;
--
Stefan Richter
-=====-==-=- -=== --===
http://arcgraph.de/sr/
next prev parent reply other threads:[~2010-07-07 10:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4C29C1CA.1050705@ladisch.de>
2010-07-07 8:46 ` [PATCH] " Stefan Richter
2010-07-07 9:50 ` [PATCH v2] " Stefan Richter
2010-07-07 10:01 ` Stefan Richter [this message]
2010-07-07 11:55 ` [PATCH v3] " Clemens Ladisch
2010-07-07 12:20 ` Stefan Richter
2010-07-07 12:37 ` [PATCH v4] " Stefan Richter
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=tkrat.b2582c62a3eaf0ab@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=clemens@ladisch.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
/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®