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

tpm-dev-common: Reject too short writes

2018-02-13T18:32:10+00:00

commit ee70bc1e7b63ac8023c9ff9475d8741e397316e7 upstream.

tpm_transmit() does not offer an explicit interface to indicate the number
of valid bytes in the communication buffer. Instead, it relies on the
commandSize field in the TPM header that is encoded within the buffer.
Therefore, ensure that a) enough data has been written to the buffer, so
that the commandSize field is present and b) the commandSize field does not
announce more data than has been written to the buffer.

This should have been fixed with CVE-2011-1161 long ago, but apparently
a correct version of that patch never made it into the kernel.

Signed-off-by: Alexander Steffen 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
[bwh: Backported to 3.2:
 - s/priv/chip/
 - Adjust filename, context]
Signed-off-by: Ben Hutchings

tpm: fix a kernel memory leak in tpm-sysfs.c

2017-10-12T14:27:15+00:00

commit 13b47cfcfc60495cde216eef4c01040d76174cbe upstream.

While cleaning up sysfs callback that prints EK we discovered a kernel
memory leak. This commit fixes the issue by zeroing the buffer used for
TPM command/response.

The leak happen when we use either tpm_vtpm_proxy, tpm_ibmvtpm or
xen-tpmfront.

Fixes: 0883743825e3 ("TPM: sysfs functions consolidation")
Reported-by: Jason Gunthorpe 
Tested-by: Stefan Berger 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: James Morris 
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings

drivers: char: mem: Fix wraparound check to allow mappings up to the end

2017-09-15T17:30:49+00:00

commit 32829da54d9368103a2f03269a5120aa9ee4d5da upstream.

A recent fix to /dev/mem prevents mappings from wrapping around the end
of physical address space. However, the check was written in a way that
also prevents a mapping reaching just up to the end of physical address
space, which may be a valid use case (especially on 32-bit systems).
This patch fixes it by checking the last mapped address (instead of the
first address behind that) for overflow.

Fixes: b299cde245 ("drivers: char: mem: Check for address space wraparound with mmap()")
Reported-by: Nico Huber 
Signed-off-by: Julius Werner 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

drivers: char: mem: Check for address space wraparound with mmap()

2017-09-15T17:30:45+00:00

commit b299cde245b0b76c977f4291162cf668e087b408 upstream.

/dev/mem currently allows mmap() mappings that wrap around the end of
the physical address space, which should probably be illegal. It
circumvents the existing STRICT_DEVMEM permission check because the loop
immediately terminates (as the start address is already higher than the
end address). On the x86_64 architecture it will then cause a panic
(from the BUG(start >= end) in arch/x86/mm/pat.c:reserve_memtype()).

This patch adds an explicit check to make sure offset + size will not
wrap around in the physical address type.

Signed-off-by: Julius Werner 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

char: lp: fix possible integer overflow in lp_setup()

2017-07-18T17:38:45+00:00

commit 3e21f4af170bebf47c187c1ff8bf155583c9f3b1 upstream.

The lp_setup() code doesn't apply any bounds checking when passing
"lp=none", and only in this case, resulting in an overflow of the
parport_nr[] array. All versions in Git history are affected.

Reported-By: Roee Hay 
Cc: Ben Hutchings 
Signed-off-by: Willy Tarreau 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

mm: Tighten x86 /dev/mem with zeroing reads

2017-07-18T17:38:44+00:00

commit a4866aa812518ed1a37d8ea0c881dc946409de94 upstream.

Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
disallowed. However, on x86, the first 1MB was always allowed for BIOS
and similar things, regardless of it actually being System RAM. It was
possible for heap to end up getting allocated in low 1MB RAM, and then
read by things like x86info or dd, which would trip hardened usercopy:

usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)

This changes the x86 exception for the low 1MB by reading back zeros for
System RAM areas instead of blindly allowing them. More work is needed to
extend this to mmap, but currently mmap doesn't go through usercopy, so
hardened usercopy won't Oops the kernel.

Reported-by: Tommi Rantala 
Tested-by: Tommi Rantala 
Signed-off-by: Kees Cook 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

tpm: read burstcount from TPM_STS in one 32-bit transaction

2016-11-20T01:01:27+00:00

commit 9754d45e997000ad4021bc4606cc266bb38d876f upstream.

Some chips incorrectly support partial reads from TPM_STS register
at non-zero offsets. Read the entire 32-bits register instead of
making two 8-bit reads to support such devices and reduce the number
of bus transactions when obtaining the burstcount from TPM_STS.

Fixes: 27084efee0c3 ("tpm: driver for next generation TPM chips")
Signed-off-by: Andrey Pronin 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
[bwh: Backported to 3.2:
 - Use raw ioread32() instead of tpm_tis_read32()
 - Adjust filename, context]
Signed-off-by: Ben Hutchings

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