All of lore.kernel.org
 help / color / mirror / Atom feed
* [GIT PATCH] thinkpad-acpi 2.6.31-rc fixes
@ 2009-08-01 15:04 Henrique de Moraes Holschuh
  2009-08-01 15:04 ` [PATCH 1/4] thinkpad-acpi: disable broken bay and dock subdrivers Henrique de Moraes Holschuh
                   ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: Henrique de Moraes Holschuh @ 2009-08-01 15:04 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, ibm-acpi-devel

Len,

This patchset has important fixes (two are security fixes, one is
known-dangerous code removal, and one is a regression fix) for
thinkpad-acpi.  Not all of them have bugzilla entries.

It includes the patches I already sent you, but which were not sent to
mainline yet.

Please send them to Linus for merging on 2.6.31-rc.

Thank you!

Patches:
[PATCH 1/4] thinkpad-acpi: disable broken bay and dock subdrivers
[PATCH 2/4] thinkpad-acpi: remove dock and bay subdrivers
[PATCH 3/4] thinkpad-acpi: Avoid heap buffer overrun
[PATCH 4/4] thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 1/4] thinkpad-acpi: disable broken bay and dock subdrivers
  2009-08-01 15:04 [GIT PATCH] thinkpad-acpi 2.6.31-rc fixes Henrique de Moraes Holschuh
@ 2009-08-01 15:04 ` Henrique de Moraes Holschuh
  2009-08-02  3:39   ` Len Brown
  2009-08-01 15:04 ` [PATCH 2/4] thinkpad-acpi: remove dock and bay subdrivers Henrique de Moraes Holschuh
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 13+ messages in thread
From: Henrique de Moraes Holschuh @ 2009-08-01 15:04 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, ibm-acpi-devel, Henrique de Moraes Holschuh, stable

Currently, the ThinkPad-ACPI bay and dock drivers are completely
broken, and cause a NULL pointer derreference in kernel mode (and,
therefore, an OOPS) when they try to issue events (i.e. on dock,
undock, bay ejection, etc).

OTOH, the standard ACPI dock driver can handle the hotplug bays and
docks of the ThinkPads just fine (including batteries) as of 2.6.27.
In fact, it does a much better job of it than thinkpad-acpi ever did.

It is just not worth the hassle to find a way to fix this crap without
breaking the (deprecated) thinkpad-acpi dock/bay ABI.  This is old,
deprecated code that sees little testing or use.

As a quick fix suitable for -stable backports, mark the thinkpad-acpi
bay and dock subdrivers as BROKEN in Kconfig.  The dead code will be
removed by a later patch.

This fixes bugzilla #13669, and should be applied to 2.6.27 and later.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Reported-by: Joerg Platte <jplatte@naasa.net>
Cc: stable@kernel.org
---
 drivers/platform/x86/Kconfig |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 46dad12..6335f63 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -281,6 +281,7 @@ config THINKPAD_ACPI_DOCK
 	bool "Legacy Docking Station Support"
 	depends on THINKPAD_ACPI
 	depends on ACPI_DOCK=n
+	depends on BROKEN
 	default n
 	---help---
 	  Allows the thinkpad_acpi driver to handle docking station events.
@@ -294,7 +295,8 @@ config THINKPAD_ACPI_DOCK
 config THINKPAD_ACPI_BAY
 	bool "Legacy Removable Bay Support"
 	depends on THINKPAD_ACPI
-	default y
+	depends on BROKEN
+	default n
 	---help---
 	  Allows the thinkpad_acpi driver to handle removable bays.  It will
 	  electrically disable the device in the bay, and also generate
-- 
1.6.3.3


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH 2/4] thinkpad-acpi: remove dock and bay subdrivers
  2009-08-01 15:04 [GIT PATCH] thinkpad-acpi 2.6.31-rc fixes Henrique de Moraes Holschuh
  2009-08-01 15:04 ` [PATCH 1/4] thinkpad-acpi: disable broken bay and dock subdrivers Henrique de Moraes Holschuh
@ 2009-08-01 15:04 ` Henrique de Moraes Holschuh
  2009-08-02  4:05   ` Len Brown
  2009-08-01 15:04 ` [PATCH 3/4] thinkpad-acpi: Avoid heap buffer overrun Henrique de Moraes Holschuh
  2009-08-01 15:04 ` [PATCH 4/4] thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM Henrique de Moraes Holschuh
  3 siblings, 1 reply; 13+ messages in thread
From: Henrique de Moraes Holschuh @ 2009-08-01 15:04 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, ibm-acpi-devel, Henrique de Moraes Holschuh

The standard ACPI dock driver can handle the hotplug bays and docks of
the ThinkPads just fine (including batteries) as of 2.6.27, and the
code in thinkpad-acpi for the dock and bay subdrivers is currently
broken anyway...

Userspace needs some love to support the two-stage ejection nicely,
but it is simple enough to do through udev rules (you don't even need
HAL) so this wouldn't justify fixing the dock and bay subdrivers,
either.

That leaves warm-swap bays (_EJ3) support for thinkpad-acpi, as well
as support for the weird dock of the model 570, but since such support
has never left the "experimental" stage, it is also not a strong
enough reason to find a way to fix this code.

Users of ThinkPads with warm-swap bays are urged to request that _EJ3
support be added to the regular ACPI dock driver, if such feature is
indeed useful for them.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
---
 Documentation/laptops/thinkpad-acpi.txt |  127 ------------
 drivers/platform/x86/Kconfig            |   27 ---
 drivers/platform/x86/thinkpad_acpi.c    |  327 -------------------------------
 3 files changed, 0 insertions(+), 481 deletions(-)

diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt
index f2296ec..e2ddcde 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -36,8 +36,6 @@ detailed description):
 	- Bluetooth enable and disable
 	- video output switching, expansion control
 	- ThinkLight on and off
-	- limited docking and undocking
-	- UltraBay eject
 	- CMOS/UCMS control
 	- LED control
 	- ACPI sounds
@@ -729,131 +727,6 @@ cannot be read or if it is unknown, thinkpad-acpi will report it as "off".
 It is impossible to know if the status returned through sysfs is valid.
 
 
-Docking / undocking -- /proc/acpi/ibm/dock
-------------------------------------------
-
-Docking and undocking (e.g. with the X4 UltraBase) requires some
-actions to be taken by the operating system to safely make or break
-the electrical connections with the dock.
-
-The docking feature of this driver generates the following ACPI events:
-
-	ibm/dock GDCK 00000003 00000001 -- eject request
-	ibm/dock GDCK 00000003 00000002 -- undocked
-	ibm/dock GDCK 00000000 00000003 -- docked
-
-NOTE: These events will only be generated if the laptop was docked
-when originally booted. This is due to the current lack of support for
-hot plugging of devices in the Linux ACPI framework. If the laptop was
-booted while not in the dock, the following message is shown in the
-logs:
-
-	Mar 17 01:42:34 aero kernel: thinkpad_acpi: dock device not present
-
-In this case, no dock-related events are generated but the dock and
-undock commands described below still work. They can be executed
-manually or triggered by Fn key combinations (see the example acpid
-configuration files included in the driver tarball package available
-on the web site).
-
-When the eject request button on the dock is pressed, the first event
-above is generated. The handler for this event should issue the
-following command:
-
-	echo undock > /proc/acpi/ibm/dock
-
-After the LED on the dock goes off, it is safe to eject the laptop.
-Note: if you pressed this key by mistake, go ahead and eject the
-laptop, then dock it back in. Otherwise, the dock may not function as
-expected.
-
-When the laptop is docked, the third event above is generated. The
-handler for this event should issue the following command to fully
-enable the dock:
-
-	echo dock > /proc/acpi/ibm/dock
-
-The contents of the /proc/acpi/ibm/dock file shows the current status
-of the dock, as provided by the ACPI framework.
-
-The docking support in this driver does not take care of enabling or
-disabling any other devices you may have attached to the dock. For
-example, a CD drive plugged into the UltraBase needs to be disabled or
-enabled separately. See the provided example acpid configuration files
-for how this can be accomplished.
-
-There is no support yet for PCI devices that may be attached to a
-docking station, e.g. in the ThinkPad Dock II. The driver currently
-does not recognize, enable or disable such devices. This means that
-the only docking stations currently supported are the X-series
-UltraBase docks and "dumb" port replicators like the Mini Dock (the
-latter don't need any ACPI support, actually).
-
-
-UltraBay eject -- /proc/acpi/ibm/bay
-------------------------------------
-
-Inserting or ejecting an UltraBay device requires some actions to be
-taken by the operating system to safely make or break the electrical
-connections with the device.
-
-This feature generates the following ACPI events:
-
-	ibm/bay MSTR 00000003 00000000 -- eject request
-	ibm/bay MSTR 00000001 00000000 -- eject lever inserted
-
-NOTE: These events will only be generated if the UltraBay was present
-when the laptop was originally booted (on the X series, the UltraBay
-is in the dock, so it may not be present if the laptop was undocked).
-This is due to the current lack of support for hot plugging of devices
-in the Linux ACPI framework. If the laptop was booted without the
-UltraBay, the following message is shown in the logs:
-
-	Mar 17 01:42:34 aero kernel: thinkpad_acpi: bay device not present
-
-In this case, no bay-related events are generated but the eject
-command described below still works. It can be executed manually or
-triggered by a hot key combination.
-
-Sliding the eject lever generates the first event shown above. The
-handler for this event should take whatever actions are necessary to
-shut down the device in the UltraBay (e.g. call idectl), then issue
-the following command:
-
-	echo eject > /proc/acpi/ibm/bay
-
-After the LED on the UltraBay goes off, it is safe to pull out the
-device.
-
-When the eject lever is inserted, the second event above is
-generated. The handler for this event should take whatever actions are
-necessary to enable the UltraBay device (e.g. call idectl).
-
-The contents of the /proc/acpi/ibm/bay file shows the current status
-of the UltraBay, as provided by the ACPI framework.
-
-EXPERIMENTAL warm eject support on the 600e/x, A22p and A3x (To use
-this feature, you need to supply the experimental=1 parameter when
-loading the module):
-
-These models do not have a button near the UltraBay device to request
-a hot eject but rather require the laptop to be put to sleep
-(suspend-to-ram) before the bay device is ejected or inserted).
-The sequence of steps to eject the device is as follows:
-
-	echo eject > /proc/acpi/ibm/bay
-	put the ThinkPad to sleep
-	remove the drive
-	resume from sleep
-	cat /proc/acpi/ibm/bay should show that the drive was removed
-
-On the A3x, both the UltraBay 2000 and UltraBay Plus devices are
-supported. Use "eject2" instead of "eject" for the second bay.
-
-Note: the UltraBay eject support on the 600e/x, A22p and A3x is
-EXPERIMENTAL and may not work as expected. USE WITH CAUTION!
-
-
 CMOS/UCMS control
 -----------------
 
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 6335f63..77c6097 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -277,33 +277,6 @@ config THINKPAD_ACPI_UNSAFE_LEDS
 	  Say N here, unless you are building a kernel for your own
 	  use, and need to control the important firmware LEDs.
 
-config THINKPAD_ACPI_DOCK
-	bool "Legacy Docking Station Support"
-	depends on THINKPAD_ACPI
-	depends on ACPI_DOCK=n
-	depends on BROKEN
-	default n
-	---help---
-	  Allows the thinkpad_acpi driver to handle docking station events.
-	  This support was made obsolete by the generic ACPI docking station
-	  support (CONFIG_ACPI_DOCK).  It will allow locking and removing the
-	  laptop from the docking station, but will not properly connect PCI
-	  devices.
-
-	  If you are not sure, say N here.
-
-config THINKPAD_ACPI_BAY
-	bool "Legacy Removable Bay Support"
-	depends on THINKPAD_ACPI
-	depends on BROKEN
-	default n
-	---help---
-	  Allows the thinkpad_acpi driver to handle removable bays.  It will
-	  electrically disable the device in the bay, and also generate
-	  notifications when the bay lever is ejected or inserted.
-
-	  If you are not sure, say Y here.
-
 config THINKPAD_ACPI_VIDEO
 	bool "Video output control support"
 	depends on THINKPAD_ACPI
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index a463fd7..27d68e7 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -239,12 +239,6 @@ struct ibm_init_struct {
 };
 
 static struct {
-#ifdef CONFIG_THINKPAD_ACPI_BAY
-	u32 bay_status:1;
-	u32 bay_eject:1;
-	u32 bay_status2:1;
-	u32 bay_eject2:1;
-#endif
 	u32 bluetooth:1;
 	u32 hotkey:1;
 	u32 hotkey_mask:1;
@@ -589,18 +583,6 @@ static int acpi_ec_write(int i, u8 v)
 	return 1;
 }
 
-#if defined(CONFIG_THINKPAD_ACPI_DOCK) || defined(CONFIG_THINKPAD_ACPI_BAY)
-static int _sta(acpi_handle handle)
-{
-	int status;
-
-	if (!handle || !acpi_evalf(handle, &status, "_STA", "d"))
-		status = 0;
-
-	return status;
-}
-#endif
-
 static int issue_thinkpad_cmos_command(int cmos_cmd)
 {
 	if (!cmos_handle)
@@ -4442,293 +4424,6 @@ static struct ibm_struct light_driver_data = {
 };
 
 /*************************************************************************
- * Dock subdriver
- */
-
-#ifdef CONFIG_THINKPAD_ACPI_DOCK
-
-static void dock_notify(struct ibm_struct *ibm, u32 event);
-static int dock_read(char *p);
-static int dock_write(char *buf);
-
-TPACPI_HANDLE(dock, root, "\\_SB.GDCK",	/* X30, X31, X40 */
-	   "\\_SB.PCI0.DOCK",	/* 600e/x,770e,770x,A2xm/p,T20-22,X20-21 */
-	   "\\_SB.PCI0.PCI1.DOCK",	/* all others */
-	   "\\_SB.PCI.ISA.SLCE",	/* 570 */
-    );				/* A21e,G4x,R30,R31,R32,R40,R40e,R50e */
-
-/* don't list other alternatives as we install a notify handler on the 570 */
-TPACPI_HANDLE(pci, root, "\\_SB.PCI");	/* 570 */
-
-static const struct acpi_device_id ibm_pci_device_ids[] = {
-	{PCI_ROOT_HID_STRING, 0},
-	{"", 0},
-};
-
-static struct tp_acpi_drv_struct ibm_dock_acpidriver[2] = {
-	{
-	 .notify = dock_notify,
-	 .handle = &dock_handle,
-	 .type = ACPI_SYSTEM_NOTIFY,
-	},
-	{
-	/* THIS ONE MUST NEVER BE USED FOR DRIVER AUTOLOADING.
-	 * We just use it to get notifications of dock hotplug
-	 * in very old thinkpads */
-	 .hid = ibm_pci_device_ids,
-	 .notify = dock_notify,
-	 .handle = &pci_handle,
-	 .type = ACPI_SYSTEM_NOTIFY,
-	},
-};
-
-static struct ibm_struct dock_driver_data[2] = {
-	{
-	 .name = "dock",
-	 .read = dock_read,
-	 .write = dock_write,
-	 .acpi = &ibm_dock_acpidriver[0],
-	},
-	{
-	 .name = "dock",
-	 .acpi = &ibm_dock_acpidriver[1],
-	},
-};
-
-#define dock_docked() (_sta(dock_handle) & 1)
-
-static int __init dock_init(struct ibm_init_struct *iibm)
-{
-	vdbg_printk(TPACPI_DBG_INIT, "initializing dock subdriver\n");
-
-	TPACPI_ACPIHANDLE_INIT(dock);
-
-	vdbg_printk(TPACPI_DBG_INIT, "dock is %s\n",
-		str_supported(dock_handle != NULL));
-
-	return (dock_handle)? 0 : 1;
-}
-
-static int __init dock_init2(struct ibm_init_struct *iibm)
-{
-	int dock2_needed;
-
-	vdbg_printk(TPACPI_DBG_INIT, "initializing dock subdriver part 2\n");
-
-	if (dock_driver_data[0].flags.acpi_driver_registered &&
-	    dock_driver_data[0].flags.acpi_notify_installed) {
-		TPACPI_ACPIHANDLE_INIT(pci);
-		dock2_needed = (pci_handle != NULL);
-		vdbg_printk(TPACPI_DBG_INIT,
-			    "dock PCI handler for the TP 570 is %s\n",
-			    str_supported(dock2_needed));
-	} else {
-		vdbg_printk(TPACPI_DBG_INIT,
-		"dock subdriver part 2 not required\n");
-		dock2_needed = 0;
-	}
-
-	return (dock2_needed)? 0 : 1;
-}
-
-static void dock_notify(struct ibm_struct *ibm, u32 event)
-{
-	int docked = dock_docked();
-	int pci = ibm->acpi->hid && ibm->acpi->device &&
-		acpi_match_device_ids(ibm->acpi->device, ibm_pci_device_ids);
-	int data;
-
-	if (event == 1 && !pci)	/* 570 */
-		data = 1;	/* button */
-	else if (event == 1 && pci)	/* 570 */
-		data = 3;	/* dock */
-	else if (event == 3 && docked)
-		data = 1;	/* button */
-	else if (event == 3 && !docked)
-		data = 2;	/* undock */
-	else if (event == 0 && docked)
-		data = 3;	/* dock */
-	else {
-		printk(TPACPI_ERR "unknown dock event %d, status %d\n",
-		       event, _sta(dock_handle));
-		data = 0;	/* unknown */
-	}
-	acpi_bus_generate_proc_event(ibm->acpi->device, event, data);
-	acpi_bus_generate_netlink_event(ibm->acpi->device->pnp.device_class,
-					  dev_name(&ibm->acpi->device->dev),
-					  event, data);
-}
-
-static int dock_read(char *p)
-{
-	int len = 0;
-	int docked = dock_docked();
-
-	if (!dock_handle)
-		len += sprintf(p + len, "status:\t\tnot supported\n");
-	else if (!docked)
-		len += sprintf(p + len, "status:\t\tundocked\n");
-	else {
-		len += sprintf(p + len, "status:\t\tdocked\n");
-		len += sprintf(p + len, "commands:\tdock, undock\n");
-	}
-
-	return len;
-}
-
-static int dock_write(char *buf)
-{
-	char *cmd;
-
-	if (!dock_docked())
-		return -ENODEV;
-
-	while ((cmd = next_cmd(&buf))) {
-		if (strlencmp(cmd, "undock") == 0) {
-			if (!acpi_evalf(dock_handle, NULL, "_DCK", "vd", 0) ||
-			    !acpi_evalf(dock_handle, NULL, "_EJ0", "vd", 1))
-				return -EIO;
-		} else if (strlencmp(cmd, "dock") == 0) {
-			if (!acpi_evalf(dock_handle, NULL, "_DCK", "vd", 1))
-				return -EIO;
-		} else
-			return -EINVAL;
-	}
-
-	return 0;
-}
-
-#endif /* CONFIG_THINKPAD_ACPI_DOCK */
-
-/*************************************************************************
- * Bay subdriver
- */
-
-#ifdef CONFIG_THINKPAD_ACPI_BAY
-
-TPACPI_HANDLE(bay, root, "\\_SB.PCI.IDE.SECN.MAST",	/* 570 */
-	   "\\_SB.PCI0.IDE0.IDES.IDSM",	/* 600e/x, 770e, 770x */
-	   "\\_SB.PCI0.SATA.SCND.MSTR",	/* T60, X60, Z60 */
-	   "\\_SB.PCI0.IDE0.SCND.MSTR",	/* all others */
-	   );				/* A21e, R30, R31 */
-TPACPI_HANDLE(bay_ej, bay, "_EJ3",	/* 600e/x, A2xm/p, A3x */
-	   "_EJ0",		/* all others */
-	   );			/* 570,A21e,G4x,R30,R31,R32,R40e,R50e */
-TPACPI_HANDLE(bay2, root, "\\_SB.PCI0.IDE0.PRIM.SLAV",	/* A3x, R32 */
-	   "\\_SB.PCI0.IDE0.IDEP.IDPS",	/* 600e/x, 770e, 770x */
-	   );				/* all others */
-TPACPI_HANDLE(bay2_ej, bay2, "_EJ3",	/* 600e/x, 770e, A3x */
-	   "_EJ0",			/* 770x */
-	   );				/* all others */
-
-static int __init bay_init(struct ibm_init_struct *iibm)
-{
-	vdbg_printk(TPACPI_DBG_INIT, "initializing bay subdriver\n");
-
-	TPACPI_ACPIHANDLE_INIT(bay);
-	if (bay_handle)
-		TPACPI_ACPIHANDLE_INIT(bay_ej);
-	TPACPI_ACPIHANDLE_INIT(bay2);
-	if (bay2_handle)
-		TPACPI_ACPIHANDLE_INIT(bay2_ej);
-
-	tp_features.bay_status = bay_handle &&
-		acpi_evalf(bay_handle, NULL, "_STA", "qv");
-	tp_features.bay_status2 = bay2_handle &&
-		acpi_evalf(bay2_handle, NULL, "_STA", "qv");
-
-	tp_features.bay_eject = bay_handle && bay_ej_handle &&
-		(strlencmp(bay_ej_path, "_EJ0") == 0 || experimental);
-	tp_features.bay_eject2 = bay2_handle && bay2_ej_handle &&
-		(strlencmp(bay2_ej_path, "_EJ0") == 0 || experimental);
-
-	vdbg_printk(TPACPI_DBG_INIT,
-		"bay 1: status %s, eject %s; bay 2: status %s, eject %s\n",
-		str_supported(tp_features.bay_status),
-		str_supported(tp_features.bay_eject),
-		str_supported(tp_features.bay_status2),
-		str_supported(tp_features.bay_eject2));
-
-	return (tp_features.bay_status || tp_features.bay_eject ||
-		tp_features.bay_status2 || tp_features.bay_eject2)? 0 : 1;
-}
-
-static void bay_notify(struct ibm_struct *ibm, u32 event)
-{
-	acpi_bus_generate_proc_event(ibm->acpi->device, event, 0);
-	acpi_bus_generate_netlink_event(ibm->acpi->device->pnp.device_class,
-					  dev_name(&ibm->acpi->device->dev),
-					  event, 0);
-}
-
-#define bay_occupied(b) (_sta(b##_handle) & 1)
-
-static int bay_read(char *p)
-{
-	int len = 0;
-	int occupied = bay_occupied(bay);
-	int occupied2 = bay_occupied(bay2);
-	int eject, eject2;
-
-	len += sprintf(p + len, "status:\t\t%s\n",
-		tp_features.bay_status ?
-			(occupied ? "occupied" : "unoccupied") :
-				"not supported");
-	if (tp_features.bay_status2)
-		len += sprintf(p + len, "status2:\t%s\n", occupied2 ?
-			       "occupied" : "unoccupied");
-
-	eject = tp_features.bay_eject && occupied;
-	eject2 = tp_features.bay_eject2 && occupied2;
-
-	if (eject && eject2)
-		len += sprintf(p + len, "commands:\teject, eject2\n");
-	else if (eject)
-		len += sprintf(p + len, "commands:\teject\n");
-	else if (eject2)
-		len += sprintf(p + len, "commands:\teject2\n");
-
-	return len;
-}
-
-static int bay_write(char *buf)
-{
-	char *cmd;
-
-	if (!tp_features.bay_eject && !tp_features.bay_eject2)
-		return -ENODEV;
-
-	while ((cmd = next_cmd(&buf))) {
-		if (tp_features.bay_eject && strlencmp(cmd, "eject") == 0) {
-			if (!acpi_evalf(bay_ej_handle, NULL, NULL, "vd", 1))
-				return -EIO;
-		} else if (tp_features.bay_eject2 &&
-			   strlencmp(cmd, "eject2") == 0) {
-			if (!acpi_evalf(bay2_ej_handle, NULL, NULL, "vd", 1))
-				return -EIO;
-		} else
-			return -EINVAL;
-	}
-
-	return 0;
-}
-
-static struct tp_acpi_drv_struct ibm_bay_acpidriver = {
-	.notify = bay_notify,
-	.handle = &bay_handle,
-	.type = ACPI_SYSTEM_NOTIFY,
-};
-
-static struct ibm_struct bay_driver_data = {
-	.name = "bay",
-	.read = bay_read,
-	.write = bay_write,
-	.acpi = &ibm_bay_acpidriver,
-};
-
-#endif /* CONFIG_THINKPAD_ACPI_BAY */
-
-/*************************************************************************
  * CMOS subdriver
  */
 
@@ -7854,22 +7549,6 @@ static struct ibm_init_struct ibms_init[] __initdata = {
 		.init = light_init,
 		.data = &light_driver_data,
 	},
-#ifdef CONFIG_THINKPAD_ACPI_DOCK
-	{
-		.init = dock_init,
-		.data = &dock_driver_data[0],
-	},
-	{
-		.init = dock_init2,
-		.data = &dock_driver_data[1],
-	},
-#endif
-#ifdef CONFIG_THINKPAD_ACPI_BAY
-	{
-		.init = bay_init,
-		.data = &bay_driver_data,
-	},
-#endif
 	{
 		.init = cmos_init,
 		.data = &cmos_driver_data,
@@ -7968,12 +7647,6 @@ TPACPI_PARAM(hotkey);
 TPACPI_PARAM(bluetooth);
 TPACPI_PARAM(video);
 TPACPI_PARAM(light);
-#ifdef CONFIG_THINKPAD_ACPI_DOCK
-TPACPI_PARAM(dock);
-#endif
-#ifdef CONFIG_THINKPAD_ACPI_BAY
-TPACPI_PARAM(bay);
-#endif /* CONFIG_THINKPAD_ACPI_BAY */
 TPACPI_PARAM(cmos);
 TPACPI_PARAM(led);
 TPACPI_PARAM(beep);
-- 
1.6.3.3


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH 3/4] thinkpad-acpi: Avoid heap buffer overrun
  2009-08-01 15:04 [GIT PATCH] thinkpad-acpi 2.6.31-rc fixes Henrique de Moraes Holschuh
  2009-08-01 15:04 ` [PATCH 1/4] thinkpad-acpi: disable broken bay and dock subdrivers Henrique de Moraes Holschuh
  2009-08-01 15:04 ` [PATCH 2/4] thinkpad-acpi: remove dock and bay subdrivers Henrique de Moraes Holschuh
@ 2009-08-01 15:04 ` Henrique de Moraes Holschuh
  2009-08-01 15:54   ` Michael Buesch
  2009-08-01 15:04 ` [PATCH 4/4] thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM Henrique de Moraes Holschuh
  3 siblings, 1 reply; 13+ messages in thread
From: Henrique de Moraes Holschuh @ 2009-08-01 15:04 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, ibm-acpi-devel, Michael Buesch, stable

From: Michael Buesch <mb@bu3sch.de>

Avoid a heap buffer overrun triggered by an integer overflow of the
userspace controlled "count" variable.

If userspace passes in a "count" of (size_t)-1l, the kmalloc size will
overflow to ((size_t)-1l + 2) = 1, so only one byte will be allocated.
However, copy_from_user() will attempt to copy 0xFFFFFFFF (or
0xFFFFFFFFFFFFFFFF on 64bit) bytes to the buffer.

A possible testcase could look like this:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>

int main(int argc, char **argv)
{
	int fd;
	char c;

	if (argc != 2) {
		printf("Usage: %s /proc/acpi/ibm/filename\n", argv[0]);
		return 1;
	}
	fd = open(argv[1], O_RDWR);
	if (fd < 0) {
		printf("Could not open proc file\n");
		return 1;
	}
	write(fd, &c, (size_t)-1l);
}

We avoid the integer overrun by putting an arbitrary limit on the count.
PAGE_SIZE sounds like a sane limit.

(note: this bug exists at least since kernel 2.6.12...)

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org
---
 drivers/platform/x86/thinkpad_acpi.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 27d68e7..18f9ee6 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -766,6 +766,8 @@ static int dispatch_procfs_write(struct file *file,
 
 	if (!ibm || !ibm->write)
 		return -EINVAL;
+	if (count > PAGE_SIZE - 2)
+		return -EINVAL;
 
 	kernbuf = kmalloc(count + 2, GFP_KERNEL);
 	if (!kernbuf)
-- 
1.6.3.3


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH 4/4] thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM
  2009-08-01 15:04 [GIT PATCH] thinkpad-acpi 2.6.31-rc fixes Henrique de Moraes Holschuh
                   ` (2 preceding siblings ...)
  2009-08-01 15:04 ` [PATCH 3/4] thinkpad-acpi: Avoid heap buffer overrun Henrique de Moraes Holschuh
@ 2009-08-01 15:04 ` Henrique de Moraes Holschuh
  2009-08-02  3:51   ` Len Brown
  3 siblings, 1 reply; 13+ messages in thread
From: Henrique de Moraes Holschuh @ 2009-08-01 15:04 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, ibm-acpi-devel, Henrique de Moraes Holschuh, stable

HBRV-based default selection of backlight control strategy didn't work
well, at least the X41 defines it but doesn't use it and I don't think
it will stop there.

Switch to a white/blacklist.  All models that have HBRV defined have
been included in the list, and initially all ATI GPUs will get
ECNVRAM, and the Intel GPUs will get UCMS_STEP.

Symptoms of incorrect backlight mode selection are:

1. Non-working backlight control through sysfs;

2. Backlight gets reset to the lowest level at every shutdown, reboot
   and when thinkpad-acpi gets unloaded;

This fixes a regression in 2.6.30, bugzilla #13826

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Reported-by: Tobias Diedrich <ranma+kernel@tdiedrich.de>
Cc: stable@kernel.org
---
 drivers/platform/x86/thinkpad_acpi.c |   61 ++++++++++++++++++++++++++--------
 1 files changed, 47 insertions(+), 14 deletions(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 18f9ee6..e856008 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -5642,14 +5642,48 @@ static struct backlight_ops ibm_backlight_data = {
 
 /* --------------------------------------------------------------------- */
 
+/*
+ * These are only useful for models that have only one possibility
+ * of GPU.  If the BIOS model handles both ATI and Intel, don't use
+ * these quirks.
+ */
+#define TPACPI_BRGHT_Q_NOEC	0x0001	/* Must NOT use EC HBRV */
+#define TPACPI_BRGHT_Q_EC	0x0002  /* Should or must use EC HBRV */
+#define TPACPI_BRGHT_Q_ASK	0x8000	/* Ask for user report */
+
+static const struct tpacpi_quirk brightness_quirk_table[] __initconst = {
+	/* Models with ATI GPUs known to require ECNVRAM mode */
+	TPACPI_Q_IBM('1', 'Y', TPACPI_BRGHT_Q_EC),	/* T43/p ATI */
+
+	/* Models with ATI GPUs (waiting confirmation) */
+	TPACPI_Q_IBM('1', 'R', TPACPI_BRGHT_Q_ASK|TPACPI_BRGHT_Q_EC),
+	TPACPI_Q_IBM('1', 'Q', TPACPI_BRGHT_Q_ASK|TPACPI_BRGHT_Q_EC),
+	TPACPI_Q_IBM('7', '6', TPACPI_BRGHT_Q_ASK|TPACPI_BRGHT_Q_EC),
+	TPACPI_Q_IBM('7', '8', TPACPI_BRGHT_Q_ASK|TPACPI_BRGHT_Q_EC),
+
+	/* Models with Intel Extreme Graphics 2 (waiting confirmation) */
+	TPACPI_Q_IBM('1', 'V', TPACPI_BRGHT_Q_ASK|TPACPI_BRGHT_Q_NOEC),
+	TPACPI_Q_IBM('1', 'W', TPACPI_BRGHT_Q_ASK|TPACPI_BRGHT_Q_NOEC),
+	TPACPI_Q_IBM('1', 'U', TPACPI_BRGHT_Q_ASK|TPACPI_BRGHT_Q_NOEC),
+
+	/* Models with Intel GMA900 */
+	TPACPI_Q_IBM('7', '0', TPACPI_BRGHT_Q_NOEC),	/* T43, R52 */
+	TPACPI_Q_IBM('7', '4', TPACPI_BRGHT_Q_NOEC),	/* X41 */
+	TPACPI_Q_IBM('7', '5', TPACPI_BRGHT_Q_NOEC),	/* X41 Tablet */
+};
+
 static int __init brightness_init(struct ibm_init_struct *iibm)
 {
 	int b;
+	unsigned long quirks;
 
 	vdbg_printk(TPACPI_DBG_INIT, "initializing brightness subdriver\n");
 
 	mutex_init(&brightness_mutex);
 
+	quirks = tpacpi_check_quirks(brightness_quirk_table,
+				ARRAY_SIZE(brightness_quirk_table));
+
 	/*
 	 * We always attempt to detect acpi support, so as to switch
 	 * Lenovo Vista BIOS to ACPI brightness mode even if we are not
@@ -5706,23 +5740,13 @@ static int __init brightness_init(struct ibm_init_struct *iibm)
 	/* TPACPI_BRGHT_MODE_AUTO not implemented yet, just use default */
 	if (brightness_mode == TPACPI_BRGHT_MODE_AUTO ||
 	    brightness_mode == TPACPI_BRGHT_MODE_MAX) {
-		if (thinkpad_id.vendor == PCI_VENDOR_ID_IBM) {
-			/*
-			 * IBM models that define HBRV probably have
-			 * EC-based backlight level control
-			 */
-			if (acpi_evalf(ec_handle, NULL, "HBRV", "qd"))
-				/* T40-T43, R50-R52, R50e, R51e, X31-X41 */
-				brightness_mode = TPACPI_BRGHT_MODE_ECNVRAM;
-			else
-				/* all other IBM ThinkPads */
-				brightness_mode = TPACPI_BRGHT_MODE_UCMS_STEP;
-		} else
-			/* All Lenovo ThinkPads */
+		if (quirks & TPACPI_BRGHT_Q_EC)
+			brightness_mode = TPACPI_BRGHT_MODE_ECNVRAM;
+		else
 			brightness_mode = TPACPI_BRGHT_MODE_UCMS_STEP;
 
 		dbg_printk(TPACPI_DBG_BRGHT,
-			   "selected brightness_mode=%d\n",
+			   "driver auto-selected brightness_mode=%d\n",
 			   brightness_mode);
 	}
 
@@ -5749,6 +5773,15 @@ static int __init brightness_init(struct ibm_init_struct *iibm)
 	vdbg_printk(TPACPI_DBG_INIT | TPACPI_DBG_BRGHT,
 			"brightness is supported\n");
 
+	if (quirks & TPACPI_BRGHT_Q_ASK) {
+		printk(TPACPI_NOTICE
+			"brightness: will use unverified default: "
+			"brightness_mode=%d\n", brightness_mode);
+		printk(TPACPI_NOTICE
+			"brightness: please report to %s whether it works well "
+			"or not on your ThinkPad\n", TPACPI_MAIL);
+	}
+
 	ibm_backlight_device->props.max_brightness =
 				(tp_features.bright_16levels)? 15 : 7;
 	ibm_backlight_device->props.brightness = b & TP_EC_BACKLIGHT_LVLMSK;
-- 
1.6.3.3


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH 3/4] thinkpad-acpi: Avoid heap buffer overrun
  2009-08-01 15:04 ` [PATCH 3/4] thinkpad-acpi: Avoid heap buffer overrun Henrique de Moraes Holschuh
@ 2009-08-01 15:54   ` Michael Buesch
  2009-08-02  1:50     ` Henrique de Moraes Holschuh
  0 siblings, 1 reply; 13+ messages in thread
From: Michael Buesch @ 2009-08-01 15:54 UTC (permalink / raw)
  To: Henrique de Moraes Holschuh; +Cc: Len Brown, linux-acpi, ibm-acpi-devel, stable

On Saturday 01 August 2009 17:04:19 Henrique de Moraes Holschuh wrote:
> From: Michael Buesch <mb@bu3sch.de>
> 
> Avoid a heap buffer overrun triggered by an integer overflow of the
> userspace controlled "count" variable.
> 
> If userspace passes in a "count" of (size_t)-1l, the kmalloc size will
> overflow to ((size_t)-1l + 2) = 1, so only one byte will be allocated.
> However, copy_from_user() will attempt to copy 0xFFFFFFFF (or
> 0xFFFFFFFFFFFFFFFF on 64bit) bytes to the buffer.
> 
> A possible testcase could look like this:
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <fcntl.h>
> 
> int main(int argc, char **argv)
> {
> 	int fd;
> 	char c;
> 
> 	if (argc != 2) {
> 		printf("Usage: %s /proc/acpi/ibm/filename\n", argv[0]);
> 		return 1;
> 	}
> 	fd = open(argv[1], O_RDWR);
> 	if (fd < 0) {
> 		printf("Could not open proc file\n");
> 		return 1;
> 	}
> 	write(fd, &c, (size_t)-1l);
> }
> 
> We avoid the integer overrun by putting an arbitrary limit on the count.
> PAGE_SIZE sounds like a sane limit.
> 
> (note: this bug exists at least since kernel 2.6.12...)
> 
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Cc: stable@kernel.org
> ---
>  drivers/platform/x86/thinkpad_acpi.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
> index 27d68e7..18f9ee6 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -766,6 +766,8 @@ static int dispatch_procfs_write(struct file *file,
>  
>  	if (!ibm || !ibm->write)
>  		return -EINVAL;
> +	if (count > PAGE_SIZE - 2)
> +		return -EINVAL;
>  
>  	kernbuf = kmalloc(count + 2, GFP_KERNEL);
>  	if (!kernbuf)

Note that it turns out this is not a real-life bug after all.
The VFS code checks count for signedness (high bit set) and bails
out if this is the case.
Well, it might probably be a good idea to restrict the count range to
something sane here anyway, so...

-- 
Greetings, Michael.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 3/4] thinkpad-acpi: Avoid heap buffer overrun
  2009-08-01 15:54   ` Michael Buesch
@ 2009-08-02  1:50     ` Henrique de Moraes Holschuh
  2009-08-02  4:11       ` Len Brown
  2009-08-02  9:53       ` Michael Buesch
  0 siblings, 2 replies; 13+ messages in thread
From: Henrique de Moraes Holschuh @ 2009-08-02  1:50 UTC (permalink / raw)
  To: Michael Buesch; +Cc: Len Brown, linux-acpi, ibm-acpi-devel, stable

On Sat, 01 Aug 2009, Michael Buesch wrote:
> On Saturday 01 August 2009 17:04:19 Henrique de Moraes Holschuh wrote:
> > From: Michael Buesch <mb@bu3sch.de>
> > 
> > Avoid a heap buffer overrun triggered by an integer overflow of the
> > userspace controlled "count" variable.
> > 
> > If userspace passes in a "count" of (size_t)-1l, the kmalloc size will
> > overflow to ((size_t)-1l + 2) = 1, so only one byte will be allocated.
> > However, copy_from_user() will attempt to copy 0xFFFFFFFF (or
> > 0xFFFFFFFFFFFFFFFF on 64bit) bytes to the buffer.
> > 
> > A possible testcase could look like this:
> > 
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <unistd.h>
> > #include <fcntl.h>
> > 
> > int main(int argc, char **argv)
> > {
> > 	int fd;
> > 	char c;
> > 
> > 	if (argc != 2) {
> > 		printf("Usage: %s /proc/acpi/ibm/filename\n", argv[0]);
> > 		return 1;
> > 	}
> > 	fd = open(argv[1], O_RDWR);
> > 	if (fd < 0) {
> > 		printf("Could not open proc file\n");
> > 		return 1;
> > 	}
> > 	write(fd, &c, (size_t)-1l);
> > }
> > 
> > We avoid the integer overrun by putting an arbitrary limit on the count.
> > PAGE_SIZE sounds like a sane limit.
> > 
> > (note: this bug exists at least since kernel 2.6.12...)
> > 
> > Signed-off-by: Michael Buesch <mb@bu3sch.de>
> > Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> > Cc: stable@kernel.org
> > ---
> >  drivers/platform/x86/thinkpad_acpi.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
> > index 27d68e7..18f9ee6 100644
> > --- a/drivers/platform/x86/thinkpad_acpi.c
> > +++ b/drivers/platform/x86/thinkpad_acpi.c
> > @@ -766,6 +766,8 @@ static int dispatch_procfs_write(struct file *file,
> >  
> >  	if (!ibm || !ibm->write)
> >  		return -EINVAL;
> > +	if (count > PAGE_SIZE - 2)
> > +		return -EINVAL;
> >  
> >  	kernbuf = kmalloc(count + 2, GFP_KERNEL);
> >  	if (!kernbuf)
> 
> Note that it turns out this is not a real-life bug after all.
> The VFS code checks count for signedness (high bit set) and bails
> out if this is the case.
> Well, it might probably be a good idea to restrict the count range to
> something sane here anyway, so...

It is a good idea to restrict the maximum size to something sane anyway.

But the commit message needs to be fixed if there is no security hole.

Anyway, in which function and file is the VFS code that restricts the
maximum size?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/4] thinkpad-acpi: disable broken bay and dock subdrivers
  2009-08-01 15:04 ` [PATCH 1/4] thinkpad-acpi: disable broken bay and dock subdrivers Henrique de Moraes Holschuh
@ 2009-08-02  3:39   ` Len Brown
  0 siblings, 0 replies; 13+ messages in thread
From: Len Brown @ 2009-08-02  3:39 UTC (permalink / raw)
  To: Henrique de Moraes Holschuh; +Cc: linux-acpi, ibm-acpi-devel, stable

applied

thanks,
Len Brown, Intel Open Source Technology Center



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 4/4] thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM
  2009-08-01 15:04 ` [PATCH 4/4] thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM Henrique de Moraes Holschuh
@ 2009-08-02  3:51   ` Len Brown
  0 siblings, 0 replies; 13+ messages in thread
From: Len Brown @ 2009-08-02  3:51 UTC (permalink / raw)
  To: Henrique de Moraes Holschuh; +Cc: linux-acpi, ibm-acpi-devel, stable

applied

thanks,
Len Brown, Intel Open Source Technology Center



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/4] thinkpad-acpi: remove dock and bay subdrivers
  2009-08-01 15:04 ` [PATCH 2/4] thinkpad-acpi: remove dock and bay subdrivers Henrique de Moraes Holschuh
@ 2009-08-02  4:05   ` Len Brown
  0 siblings, 0 replies; 13+ messages in thread
From: Len Brown @ 2009-08-02  4:05 UTC (permalink / raw)
  To: Henrique de Moraes Holschuh; +Cc: linux-acpi, ibm-acpi-devel

applied

thanks,
Len Brown, Intel Open Source Technology Center



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 3/4] thinkpad-acpi: Avoid heap buffer overrun
  2009-08-02  1:50     ` Henrique de Moraes Holschuh
@ 2009-08-02  4:11       ` Len Brown
  2009-08-02  9:54         ` Michael Buesch
  2009-08-02  9:53       ` Michael Buesch
  1 sibling, 1 reply; 13+ messages in thread
From: Len Brown @ 2009-08-02  4:11 UTC (permalink / raw)
  To: Henrique de Moraes Holschuh
  Cc: Michael Buesch, linux-acpi, ibm-acpi-devel, stable

applied w/ simplified check-in commment

thanks,
Len Brown, Intel Open Source Technology Center



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 3/4] thinkpad-acpi: Avoid heap buffer overrun
  2009-08-02  1:50     ` Henrique de Moraes Holschuh
  2009-08-02  4:11       ` Len Brown
@ 2009-08-02  9:53       ` Michael Buesch
  1 sibling, 0 replies; 13+ messages in thread
From: Michael Buesch @ 2009-08-02  9:53 UTC (permalink / raw)
  To: Henrique de Moraes Holschuh; +Cc: Len Brown, linux-acpi, ibm-acpi-devel, stable

On Sunday 02 August 2009 03:50:12 Henrique de Moraes Holschuh wrote:
> > Note that it turns out this is not a real-life bug after all.
> > The VFS code checks count for signedness (high bit set) and bails
> > out if this is the case.
> > Well, it might probably be a good idea to restrict the count range to
> > something sane here anyway, so...
> 
> It is a good idea to restrict the maximum size to something sane anyway.
> 
> But the commit message needs to be fixed if there is no security hole.
> 
> Anyway, in which function and file is the VFS code that restricts the
> maximum size?
> 

Well there are two things. It happens that access_ok() on x86 does such a
check. It does _not_ do this on all arches, but as a thinkpad is x86...
And there are sanity checks in fs/read_write.c:

208 /*
209  * rw_verify_area doesn't like huge counts. We limit
210  * them to something that fits in "int" so that others
211  * won't have to do range checks all the time.
212  */
213 #define MAX_RW_COUNT (INT_MAX & PAGE_CACHE_MASK)
214 
215 int rw_verify_area(int read_write, struct file *file, loff_t *ppos, size_t count)
216 {
217         struct inode *inode;
218         loff_t pos;
219         int retval = -EINVAL;
220 
221         inode = file->f_path.dentry->d_inode;
222         if (unlikely((ssize_t) count < 0))
223                 return retval;
224         pos = *ppos;
225         if (unlikely((pos < 0) || (loff_t) (pos + count) < 0))
226                 return retval;
227 
228         if (unlikely(inode->i_flock && mandatory_lock(inode))) {
229                 retval = locks_mandatory_area(
230                         read_write == READ ? FLOCK_VERIFY_READ : FLOCK_VERIFY_WRITE,
231                         inode, file, pos, count);
232                 if (retval < 0)
233                         return retval;
234         }
235         retval = security_file_permission(file,
236                                 read_write == READ ? MAY_READ : MAY_WRITE);
237         if (retval)
238                 return retval;
239         return count > MAX_RW_COUNT ? MAX_RW_COUNT : count;
240 }

-- 
Greetings, Michael.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 3/4] thinkpad-acpi: Avoid heap buffer overrun
  2009-08-02  4:11       ` Len Brown
@ 2009-08-02  9:54         ` Michael Buesch
  0 siblings, 0 replies; 13+ messages in thread
From: Michael Buesch @ 2009-08-02  9:54 UTC (permalink / raw)
  To: Len Brown; +Cc: Henrique de Moraes Holschuh, linux-acpi, ibm-acpi-devel, stable

On Sunday 02 August 2009 06:11:13 Len Brown wrote:
> applied w/ simplified check-in commment
> 
> thanks,
> Len Brown, Intel Open Source Technology Center

Thanks.
The same discussion applies to the toshiba_acpi patch I sent to you.

-- 
Greetings, Michael.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2009-08-02  9:54 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-01 15:04 [GIT PATCH] thinkpad-acpi 2.6.31-rc fixes Henrique de Moraes Holschuh
2009-08-01 15:04 ` [PATCH 1/4] thinkpad-acpi: disable broken bay and dock subdrivers Henrique de Moraes Holschuh
2009-08-02  3:39   ` Len Brown
2009-08-01 15:04 ` [PATCH 2/4] thinkpad-acpi: remove dock and bay subdrivers Henrique de Moraes Holschuh
2009-08-02  4:05   ` Len Brown
2009-08-01 15:04 ` [PATCH 3/4] thinkpad-acpi: Avoid heap buffer overrun Henrique de Moraes Holschuh
2009-08-01 15:54   ` Michael Buesch
2009-08-02  1:50     ` Henrique de Moraes Holschuh
2009-08-02  4:11       ` Len Brown
2009-08-02  9:54         ` Michael Buesch
2009-08-02  9:53       ` Michael Buesch
2009-08-01 15:04 ` [PATCH 4/4] thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM Henrique de Moraes Holschuh
2009-08-02  3:51   ` Len Brown

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.