linux-stable.git/drivers/char, branch v3.2.83

hwmon: (dell-smm) Restrict fan control and serial number to CAP_SYS_ADMIN by default

2016-08-22T21:37:15+00:00

commit 7613663cc186f8f3c50279390ddc60286758001c upstream.

For security reasons ordinary user must not be able to control fan speed
via /proc/i8k by default. Some malicious software running under "nobody"
user could be able to turn fan off and cause HW problems. So this patch
changes default value of "restricted" parameter to 1.

Also restrict reading of DMI_PRODUCT_SERIAL from /proc/i8k via "restricted"
parameter. It is because non root user cannot read DMI_PRODUCT_SERIAL from
sysfs file /sys/class/dmi/id/product_serial.

Old non secure behaviour of file /proc/i8k can be achieved by loading this
module with "restricted" parameter set to 0.

Note that this patch has effects only for kernels compiled with CONFIG_I8K
and only for file /proc/i8k. Hwmon interface provided by this driver was
not changed and root access for setting fan speed was needed also before.

Reported-by: Mario Limonciello 
Signed-off-by: Pali Rohár 
Signed-off-by: Guenter Roeck 
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings

char: Drop bogus dependency of DEVPORT on !M68K

2016-08-22T21:37:09+00:00

commit 309124e2648d668a0c23539c5078815660a4a850 upstream.

According to full-history-linux commit d3794f4fa7c3edc3 ("[PATCH] M68k
update (part 25)"), port operations are allowed on m68k if CONFIG_ISA is
defined.

However, commit 153dcc54df826d2f ("[PATCH] mem driver: fix conditional
on isa i/o support") accidentally changed an "||" into an "&&",
disabling it completely on m68k. This logic was retained when
introducing the DEVPORT symbol in commit 4f911d64e04a44c4 ("Make
/dev/port conditional on config symbol").

Drop the bogus dependency on !M68K to fix this.

Fixes: 153dcc54df826d2f ("[PATCH] mem driver: fix conditional on isa i/o support")
Signed-off-by: Geert Uytterhoeven 
Tested-by: Al Stone 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

ipmi: fix timeout calculation when bmc is disconnected

2016-06-15T20:28:10+00:00

commit e21404dc0ac7ac971c1e36274b48bb460463f4e5 upstream.

Loading ipmi_si module while bmc is disconnected, we found the timeout
is longer than 5 secs.  Actually it takes about 3 mins and 20
secs.(HZ=250)

error message as below:
  Dec 12 19:08:59 linux kernel: IPMI BT: timeout in RD_WAIT [ ] 1 retries left
  Dec 12 19:08:59 linux kernel: BT: write 4 bytes seq=0x01 03 18 00 01
  [...]
  Dec 12 19:12:19 linux kernel: IPMI BT: timeout in RD_WAIT [ ]
  Dec 12 19:12:19 linux kernel: failed 2 retries, sending error response
  Dec 12 19:12:19 linux kernel: IPMI: BT reset (takes 5 secs)
  Dec 12 19:12:19 linux kernel: IPMI BT: flag reset [ ]

Function wait_for_msg_done() use schedule_timeout_uninterruptible(1) to
sleep 1 tick, so we should subtract jiffies_to_usecs(1) instead of 100
usecs from timeout.

Reported-by: Hu Shiyuan 
Signed-off-by: Xie XiuQi 
Signed-off-by: Corey Minyard 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
Cc: sebastian.riemer@profitbricks.com
Cc: cminyard@mvista.com
Cc: openipmi-developer@lists.sourceforge.net

ipmi: move timer init to before irq is setup

2015-12-30T02:26:00+00:00

commit 27f972d3e00b50639deb4cc1392afaeb08d3cecc upstream.

We encountered a panic on boot in ipmi_si on a dell per320 due to an
uninitialized timer as follows.

static int smi_start_processing(void       *send_info,
                                ipmi_smi_t intf)
{
        /* Try to claim any interrupts. */
        if (new_smi->irq_setup)
                new_smi->irq_setup(new_smi);

 --> IRQ arrives here and irq handler tries to modify uninitialized timer

    which triggers BUG_ON(!timer->function) in __mod_timer().

 Call Trace:
   
   [] start_new_msg+0x47/0x80 [ipmi_si]
   [] start_check_enables+0x4e/0x60 [ipmi_si]
   [] smi_event_handler+0x1e8/0x640 [ipmi_si]
   [] ? __rcu_process_callbacks+0x54/0x350
   [] si_irq_handler+0x3c/0x60 [ipmi_si]
   [] handle_IRQ_event+0x60/0x170
   [] handle_edge_irq+0xde/0x180
   [] handle_irq+0x49/0xa0
   [] do_IRQ+0x6c/0xf0
   [] ret_from_intr+0x0/0x11

        /* Set up the timer that drives the interface. */
        setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi);

The following patch fixes the problem.

To: Openipmi-developer@lists.sourceforge.net
To: Corey Minyard 
CC: linux-kernel@vger.kernel.org

Signed-off-by: Jan Stancek 
Signed-off-by: Tony Camuso 
Signed-off-by: Corey Minyard 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

agp/intel: Fix typo in needs_ilk_vtd_wa()

2015-08-12T14:33:17+00:00

commit 8b572a4200828b4e75cc22ed2f494b58d5372d65 upstream.

In needs_ilk_vtd_wa(), we pass in the GPU device but compared it against
the ids for the mobile GPU and the mobile host bridge. That latter is
impossible and so likely was just a typo for the desktop GPU device id
(which is also buggy).

Fixes commit da88a5f7f7d434e2cde1b3e19d952e6d84533662
Author: Chris Wilson 
Date:   Wed Feb 13 09:31:53 2013 +0000

    drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK

Reported-by: Ting-Wei Lan 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91127
References: https://bugzilla.freedesktop.org/show_bug.cgi?id=60391
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Ben Hutchings

virtio_console: avoid config access from irq

2015-05-09T22:16:26+00:00

commit eeb8a7e8bb123e84daeef84f5a2eab99ad2839a2 upstream.

when multiport is off, virtio console invokes config access from irq
context, config access is blocking on s390.
Fix this up by scheduling work from config irq - similar to what we do
for multiport configs.

Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Amit Shah 
Signed-off-by: Rusty Russell 
[bwh: Backported to 3.2:
 - Adjust context
 - Drop changes to virtcons_freeze()]
Signed-off-by: Ben Hutchings

TPM: Add new TPMs to the tail of the list to prevent inadvertent change of dev

2015-05-09T22:16:12+00:00

commit 398a1e71dc827b994b7f2f56c7c2186fea7f8d75 upstream.

Add newly registered TPMs to the tail of the list, not the beginning, so that
things that are specifying TPM_ANY_NUM don't find that the device they're
using has inadvertently changed.  Adding a second device would break IMA, for
instance.

Signed-off-by: David Howells 
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Peter Huewe 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

random: add and use memzero_explicit() for clearing data

2014-12-14T16:23:49+00:00

commit d4c5efdb97773f59a2b711754ca0953f24516739 upstream.

zatimend has reported that in his environment (3.16/gcc4.8.3/corei7)
memset() calls which clear out sensitive data in extract_{buf,entropy,
entropy_user}() in random driver are being optimized away by gcc.

Add a helper memzero_explicit() (similarly as explicit_bzero() variants)
that can be used in such cases where a variable with sensitive data is
being cleared out in the end. Other use cases might also be in crypto
code. [ I have put this into lib/string.c though, as it's always built-in
and doesn't need any dependencies then. ]

Fixes kernel bugzilla: 82041

Reported-by: zatimend@hotmail.co.uk
Signed-off-by: Daniel Borkmann 
Acked-by: Hannes Frederic Sowa 
Cc: Alexey Dobriyan 
Signed-off-by: Theodore Ts'o 
[bwh: Backported to 3.2:
 - extract_buf() needs to use this for the 'extract' array as well
 - Adjust context]
Signed-off-by: Ben Hutchings

tpm: Provide a generic means to override the chip returned timeouts

2014-09-13T22:41:40+00:00

commit 8e54caf407b98efa05409e1fee0e5381abd2b088 upstream.

Some Atmel TPMs provide completely wrong timeouts from their
TPM_CAP_PROP_TIS_TIMEOUT query. This patch detects that and returns
new correct values via a DID/VID table in the TIS driver.

Tested on ARM using an AT97SC3204T FW version 37.16

[PHuewe: without this fix these 'broken' Atmel TPMs won't function on
older kernels]
Signed-off-by: "Berg, Christopher" 
Signed-off-by: Jason Gunthorpe 

Signed-off-by: Peter Huewe 
[bwh: Backported to 3.2:
 - Adjust filename, context
 - s/chip->ops->/chip->vendor./]
Signed-off-by: Ben Hutchings

applicom: dereferencing NULL on error path

2014-08-06T17:07:41+00:00

commit 8bab797c6e5724a43b7666ad70860712365cdb71 upstream.

This is a static checker fix.  The "dev" variable is always NULL after
the while statement so we would be dereferencing a NULL pointer here.

Fixes: 819a3eba4233 ('[PATCH] applicom: fix error handling')
Signed-off-by: Dan Carpenter 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings