linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Rogers <brian@xyzw.org>
To: Jarod Wilson <jarod@redhat.com>
Cc: "David Härdeman" <david@hardeman.nu>,
	jarod@wilsonet.com, linux-media@vger.kernel.org,
	mchehab@redhat.com, linux-input@vger.kernel.org
Subject: [PATCH] ir-core: Fix null dereferences in the protocols sysfs interface
Date: Wed, 15 Sep 2010 05:57:10 -0700	[thread overview]
Message-ID: <4C90C2A6.1010408@xyzw.org> (raw)
In-Reply-To: <20100908141613.GB22323@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

  On 09/08/2010 07:16 AM, Jarod Wilson wrote:
> On Wed, Sep 08, 2010 at 07:04:03AM -0700, Brian Rogers wrote:
>> ir_dev->raw is also null. If I check these pointers before using
>> them, and bail out if both are null, then I get a working lircd, but
>> of course the file /sys/devices/virtual/rc/rc0/protocols no longer
>> does anything. On 2.6.35.4, the system never creates the
>> /sys/class/rc/rc0/current_protocol file. Is it the case that the
>> 'protocols' file should never appear, because my card can't support
>> this feature?
> Hm... So protocols is indeed intended for hardware that handles raw IR, as
> its a list of raw IR decoders available/enabled/disabled for the receiver.
> But some devices that do onboard decoding and deal with scancodes still
> need to support changing protocols, as they can be told "decode rc5" or
> "decode nec", etc... My memory is currently foggy on how it was exactly
> that it was supposed to be donee though. :) (Yet another reason I really
> need to poke at the imon driver code again).

How about the attached patch? Does this look like a reasonable solution 
for 2.6.36?

Brian


[-- Attachment #2: 0001-ir-core-Fix-null-dereferences-in-the-protocols-sysfs.patch --]
[-- Type: text/x-patch, Size: 2391 bytes --]

>From 7937051c5e2c8b5b0410172d48e62d54bd1906ee Mon Sep 17 00:00:00 2001
From: Brian Rogers <brian@xyzw.org>
Date: Wed, 8 Sep 2010 05:33:34 -0700
Subject: [PATCH] ir-core: Fix null dereferences in the protocols sysfs interface

For some cards, ir_dev->props and ir_dev->raw are both NULL. These cards are
using built-in IR decoding instead of raw, and can't easily be made to switch
protocols.

So upon reading /sys/class/rc/rc?/protocols on such a card, return 'builtin' as
the supported and enabled protocol. Return -EINVAL on any attempts to change
the protocol. And most important of all, don't crash.

Signed-off-by: Brian Rogers <brian@xyzw.org>
---
 drivers/media/IR/ir-sysfs.c |   17 +++++++++++------
 1 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index 96dafc4..46d4246 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -67,13 +67,14 @@ static ssize_t show_protocols(struct device *d,
 	char *tmp = buf;
 	int i;
 
-	if (ir_dev->props->driver_type == RC_DRIVER_SCANCODE) {
+	if (ir_dev->props && ir_dev->props->driver_type == RC_DRIVER_SCANCODE) {
 		enabled = ir_dev->rc_tab.ir_type;
 		allowed = ir_dev->props->allowed_protos;
-	} else {
+	} else if (ir_dev->raw) {
 		enabled = ir_dev->raw->enabled_protocols;
 		allowed = ir_raw_get_allowed_protocols();
-	}
+	} else
+		return sprintf(tmp, "[builtin]\n");
 
 	IR_dprintk(1, "allowed - 0x%llx, enabled - 0x%llx\n",
 		   (long long)allowed,
@@ -121,10 +122,14 @@ static ssize_t store_protocols(struct device *d,
 	int rc, i, count = 0;
 	unsigned long flags;
 
-	if (ir_dev->props->driver_type == RC_DRIVER_SCANCODE)
+	if (ir_dev->props && ir_dev->props->driver_type == RC_DRIVER_SCANCODE)
 		type = ir_dev->rc_tab.ir_type;
-	else
+	else if (ir_dev->raw)
 		type = ir_dev->raw->enabled_protocols;
+	else {
+		IR_dprintk(1, "Protocol switching not supported\n");
+		return -EINVAL;
+	}
 
 	while ((tmp = strsep((char **) &data, " \n")) != NULL) {
 		if (!*tmp)
@@ -185,7 +190,7 @@ static ssize_t store_protocols(struct device *d,
 		}
 	}
 
-	if (ir_dev->props->driver_type == RC_DRIVER_SCANCODE) {
+	if (ir_dev->props && ir_dev->props->driver_type == RC_DRIVER_SCANCODE) {
 		spin_lock_irqsave(&ir_dev->rc_tab.lock, flags);
 		ir_dev->rc_tab.ir_type = type;
 		spin_unlock_irqrestore(&ir_dev->rc_tab.lock, flags);
-- 
1.7.1


  parent reply	other threads:[~2010-09-15 12:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-13 20:29 [PATCH 0/2] ir-core: raw decoder framework changes David Härdeman
2010-06-13 20:29 ` [PATCH 1/2] ir-core: centralize sysfs raw decoder enabling/disabling David Härdeman
2010-06-16 20:05   ` Jarod Wilson
2010-06-16 20:39     ` Jarod Wilson
2010-06-28 16:56   ` Mauro Carvalho Chehab
2010-09-08 14:04   ` Brian Rogers
2010-09-08 14:16     ` Jarod Wilson
2010-09-08 21:22       ` David Härdeman
2010-09-15 12:57       ` Brian Rogers [this message]
2010-09-15 14:41         ` [PATCH] ir-core: Fix null dereferences in the protocols sysfs interface Jarod Wilson
2010-06-13 20:29 ` [PATCH 2/2] ir-core: move decoding state to ir_raw_event_ctrl David Härdeman
2010-06-16 20:06   ` Jarod Wilson
2010-06-16 20:39     ` Jarod Wilson
  -- strict thread matches above, loose matches on Subject: below --
2010-09-22 11:06 [PATCH] ir-core: Fix null dereferences in the protocols sysfs interface Brian Rogers

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=4C90C2A6.1010408@xyzw.org \
    --to=brian@xyzw.org \
    --cc=david@hardeman.nu \
    --cc=jarod@redhat.com \
    --cc=jarod@wilsonet.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.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;
as well as URLs for NNTP newsgroup(s).