From: Quentin Casasnovas <quentin.casasnovas@oracle.com>
To: David Airlie <airlied@linux.ie>
Cc: stable@vger.kernel.org, linux-kernel@vger.kernel.org,
Quentin Casasnovas <quentin.casasnovas@oracle.com>
Subject: [PATCH] i915: stack address leak when failing to read registers.
Date: Mon, 2 Feb 2015 14:58:36 +0100 [thread overview]
Message-ID: <1422885516-533-1-git-send-email-quentin.casasnovas@oracle.com> (raw)
It is possible for the *_read*() functions to fail, in which case it'll
leave its third argument untouched. Most of the code do not check the
return value of *_read*() functions, and will happily use garbage from the
stack to test various things. For example, ch7xxx_dump_regs() will leak 1
byte from the stack in case of failure, ivch_dump_regs() 2 bytes, etc.
Instead of fixing every caller to check the return value, just clear the
output variable so this patch can easily go to -stable. A proper fix would
probably to check the return value everywhere though, since it does not
make much sense to carry on talking to the ship after some error.
This issue was found by code review while preparing Ksplice updates.
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
---
drivers/gpu/drm/i915/dvo_ch7017.c | 1 +
drivers/gpu/drm/i915/dvo_ch7xxx.c | 1 +
drivers/gpu/drm/i915/dvo_ivch.c | 1 +
drivers/gpu/drm/i915/dvo_ns2501.c | 2 +-
drivers/gpu/drm/i915/dvo_sil164.c | 1 +
drivers/gpu/drm/i915/dvo_tfp410.c | 1 +
6 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/dvo_ch7017.c b/drivers/gpu/drm/i915/dvo_ch7017.c
index 86b27d1..826ac6c 100644
--- a/drivers/gpu/drm/i915/dvo_ch7017.c
+++ b/drivers/gpu/drm/i915/dvo_ch7017.c
@@ -181,6 +181,7 @@ static bool ch7017_read(struct intel_dvo_device *dvo, u8 addr, u8 *val)
.buf = val,
}
};
+ *val = 0;
return i2c_transfer(dvo->i2c_bus, msgs, 2) == 2;
}
diff --git a/drivers/gpu/drm/i915/dvo_ch7xxx.c b/drivers/gpu/drm/i915/dvo_ch7xxx.c
index 80449f4..4ebbeef 100644
--- a/drivers/gpu/drm/i915/dvo_ch7xxx.c
+++ b/drivers/gpu/drm/i915/dvo_ch7xxx.c
@@ -166,6 +166,7 @@ static bool ch7xxx_readb(struct intel_dvo_device *dvo, int addr, uint8_t *ch)
DRM_DEBUG_KMS("Unable to read register 0x%02x from %s:%02x.\n",
addr, adapter->name, dvo->slave_addr);
}
+ *ch = 0;
return false;
}
diff --git a/drivers/gpu/drm/i915/dvo_ivch.c b/drivers/gpu/drm/i915/dvo_ivch.c
index 0f2587f..43604f0a 100644
--- a/drivers/gpu/drm/i915/dvo_ivch.c
+++ b/drivers/gpu/drm/i915/dvo_ivch.c
@@ -202,6 +202,7 @@ static bool ivch_read(struct intel_dvo_device *dvo, int addr, uint16_t *data)
"%s:%02x.\n",
addr, adapter->name, dvo->slave_addr);
}
+ *data = 0;
return false;
}
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c b/drivers/gpu/drm/i915/dvo_ns2501.c
index 44163043..b314f64 100644
--- a/drivers/gpu/drm/i915/dvo_ns2501.c
+++ b/drivers/gpu/drm/i915/dvo_ns2501.c
@@ -409,7 +409,7 @@ static bool ns2501_readb(struct intel_dvo_device *dvo, int addr, uint8_t * ch)
("Unable to read register 0x%02x from %s:0x%02x.\n", addr,
adapter->name, dvo->slave_addr);
}
-
+ *ch = 0;
return false;
}
diff --git a/drivers/gpu/drm/i915/dvo_sil164.c b/drivers/gpu/drm/i915/dvo_sil164.c
index fa01149..7d5a440 100644
--- a/drivers/gpu/drm/i915/dvo_sil164.c
+++ b/drivers/gpu/drm/i915/dvo_sil164.c
@@ -99,6 +99,7 @@ static bool sil164_readb(struct intel_dvo_device *dvo, int addr, uint8_t *ch)
DRM_DEBUG_KMS("Unable to read register 0x%02x from %s:%02x.\n",
addr, adapter->name, dvo->slave_addr);
}
+ *ch = 0;
return false;
}
diff --git a/drivers/gpu/drm/i915/dvo_tfp410.c b/drivers/gpu/drm/i915/dvo_tfp410.c
index 7853719..2b66881 100644
--- a/drivers/gpu/drm/i915/dvo_tfp410.c
+++ b/drivers/gpu/drm/i915/dvo_tfp410.c
@@ -124,6 +124,7 @@ static bool tfp410_readb(struct intel_dvo_device *dvo, int addr, uint8_t *ch)
DRM_DEBUG_KMS("Unable to read register 0x%02x from %s:%02x.\n",
addr, adapter->name, dvo->slave_addr);
}
+ *ch = 0;
return false;
}
--
2.0.5
next reply other threads:[~2015-02-02 13:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-02 13:58 Quentin Casasnovas [this message]
2015-02-02 16:38 ` Greg KH
2015-02-26 16:03 ` Quentin Casasnovas
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=1422885516-533-1-git-send-email-quentin.casasnovas@oracle.com \
--to=quentin.casasnovas@oracle.com \
--cc=airlied@linux.ie \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@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®