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

hpet: Fix division by zero in hpet_time_div()

2019-11-22T15:57:06+00:00

commit 0c7d37f4d9b8446956e97b7c5e61173cdb7c8522 upstream.

The base value in do_div() called by hpet_time_div() is truncated from
unsigned long to uint32_t, resulting in a divide-by-zero exception.

UBSAN: Undefined behaviour in ../drivers/char/hpet.c:572:2
division by zero
CPU: 1 PID: 23682 Comm: syz-executor.3 Not tainted 4.4.184.x86_64+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
 0000000000000000 b573382df1853d00 ffff8800a3287b98 ffffffff81ad7561
 ffff8800a3287c00 ffffffff838b35b0 ffffffff838b3860 ffff8800a3287c20
 0000000000000000 ffff8800a3287bb0 ffffffff81b8f25e ffffffff838b35a0
Call Trace:
 [] __dump_stack lib/dump_stack.c:15 [inline]
 [] dump_stack+0xc1/0x120 lib/dump_stack.c:51
 [] ubsan_epilogue+0x12/0x8d lib/ubsan.c:166
 [] __ubsan_handle_divrem_overflow+0x282/0x2c8 lib/ubsan.c:262
 [] hpet_time_div drivers/char/hpet.c:572 [inline]
 [] hpet_ioctl_common drivers/char/hpet.c:663 [inline]
 [] hpet_ioctl_common.cold+0xa8/0xad drivers/char/hpet.c:577
 [] hpet_ioctl+0xc6/0x180 drivers/char/hpet.c:676
 [] vfs_ioctl fs/ioctl.c:43 [inline]
 [] file_ioctl fs/ioctl.c:470 [inline]
 [] do_vfs_ioctl+0x6e0/0xf70 fs/ioctl.c:605
 [] SYSC_ioctl fs/ioctl.c:622 [inline]
 [] SyS_ioctl+0x94/0xc0 fs/ioctl.c:613
 [] tracesys_phase2+0x90/0x95

The main C reproducer autogenerated by syzkaller,

  syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0);
  memcpy((void*)0x20000100, "/dev/hpet\000", 10);
  syscall(__NR_openat, 0xffffffffffffff9c, 0x20000100, 0, 0);
  syscall(__NR_ioctl, r[0], 0x40086806, 0x40000000000000);

Fix it by using div64_ul().

Signed-off-by: Kefeng Wang 
Signed-off-by: Zhang HongJun 
Reviewed-by: Arnd Bergmann 
Link: https://lore.kernel.org/r/20190711132757.130092-1-wangkefeng.wang@huawei.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

tpm: Fix off-by-one when reading binary_bios_measurements

2019-07-09T21:04:00+00:00

commit 64494d39ff630a63b5308042b20132b491e3706b upstream.

It is unable to read the entry when it is the only one in
binary_bios_measurements:

00000000  00 00 00 00 08 00 00 00  c4 2f ed ad 26 82 00 cb
00000010  1d 15 f9 78 41 c3 44 e7  9d ae 33 20 00 00 00 00
00000020

This is obviously a firmware problem on my linux machine:

	Manufacturer: Inspur
	Product Name: SA5212M4
	Version: 01

However, binary_bios_measurements should return it any way,
rather than nothing, after all its content is completely
valid.

Fixes: 55a82ab3181b ("tpm: add bios measurement log")
Signed-off-by: Jia Zhang 
Reviewd-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
[bwh: Backported to 3.16:
 - Fix an additional comparison in tpm1_bios_measurements_start()
 - Adjust filename, context]
Signed-off-by: Ben Hutchings

tpm/tpm_i2c_atmel: Return -E2BIG when the transfer is incomplete

2019-07-09T21:04:00+00:00

commit 442601e87a4769a8daba4976ec3afa5222ca211d upstream.

Return -E2BIG when the transfer is incomplete. The upper layer does
not retry, so not doing that is incorrect behaviour.

Fixes: a2871c62e186 ("tpm: Add support for Atmel I2C TPMs")
Signed-off-by: Jarkko Sakkinen 
Reviewed-by: Stefan Berger 
Reviewed-by: Jerry Snitselaar 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

applicom: Fix potential Spectre v1 vulnerabilities

2019-07-09T21:03:50+00:00

commit d7ac3c6ef5d8ce14b6381d52eb7adafdd6c8bb3c upstream.

IndexCard is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/char/applicom.c:418 ac_write() warn: potential spectre issue 'apbs' [r]
drivers/char/applicom.c:728 ac_ioctl() warn: potential spectre issue 'apbs' [r] (local cap)

Fix this by sanitizing IndexCard before using it to index apbs.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

hpet: Fix missing '=' character in the __setup() code of hpet_mmap_enable

2019-07-09T21:03:49+00:00

commit 24d48a61f2666630da130cc2ec2e526eacf229e3 upstream.

Commit '3d035f580699 ("drivers/char/hpet.c: allow user controlled mmap for
user processes")' introduced a new kernel command line parameter hpet_mmap,
that is required to expose the memory map of the HPET registers to
user-space. Unfortunately the kernel command line parameter 'hpet_mmap' is
broken and never takes effect due to missing '=' character in the __setup()
code of hpet_mmap_enable.

Before this patch:

dmesg output with the kernel command line parameter hpet_mmap=1

[    0.204152] HPET mmap disabled

dmesg output with the kernel command line parameter hpet_mmap=0

[    0.204192] HPET mmap disabled

After this patch:

dmesg output with the kernel command line parameter hpet_mmap=1

[    0.203945] HPET mmap enabled

dmesg output with the kernel command line parameter hpet_mmap=0

[    0.204652] HPET mmap disabled

Fixes: 3d035f580699 ("drivers/char/hpet.c: allow user controlled mmap for user processes")
Signed-off-by: Buland Singh 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

tty: mark Siemens R3964 line discipline as BROKEN

2019-05-02T20:42:07+00:00

commit c7084edc3f6d67750f50d4183134c4fb5712a5c8 upstream.

The n_r3964 line discipline driver was written in a different time, when
SMP machines were rare, and users were trusted to do the right thing.
Since then, the world has moved on but not this code, it has stayed
rooted in the past with its lovely hand-crafted list structures and
loads of "interesting" race conditions all over the place.

After attempting to clean up most of the issues, I just gave up and am
now marking the driver as BROKEN so that hopefully someone who has this
hardware will show up out of the woodwork (I know you are out there!)
and will help with debugging a raft of changes that I had laying around
for the code, but was too afraid to commit as odds are they would break
things.

Many thanks to Jann and Linus for pointing out the initial problems in
this codebase, as well as many reviews of my attempts to fix the issues.
It was a case of whack-a-mole, and as you can see, the mole won.

Reported-by: Jann Horn 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

ipmi: msghandler: Fix potential Spectre v1 vulnerabilities

2019-05-02T20:41:27+00:00

commit a7102c7461794a5bb31af24b08e9e0f50038897a upstream.

channel and addr->channel are indirectly controlled by user-space,
hence leading to a potential exploitation of the Spectre variant 1
vulnerability.

These issues were detected with the help of Smatch:

drivers/char/ipmi/ipmi_msghandler.c:1381 ipmi_set_my_address() warn: potential spectre issue 'user->intf->addrinfo' [w] (local cap)
drivers/char/ipmi/ipmi_msghandler.c:1401 ipmi_get_my_address() warn: potential spectre issue 'user->intf->addrinfo' [r] (local cap)
drivers/char/ipmi/ipmi_msghandler.c:1421 ipmi_set_my_LUN() warn: potential spectre issue 'user->intf->addrinfo' [w] (local cap)
drivers/char/ipmi/ipmi_msghandler.c:1441 ipmi_get_my_LUN() warn: potential spectre issue 'user->intf->addrinfo' [r] (local cap)
drivers/char/ipmi/ipmi_msghandler.c:2260 check_addr() warn: potential spectre issue 'intf->addrinfo' [r] (local cap)

Fix this by sanitizing channel and addr->channel before using them to
index user->intf->addrinfo and intf->addrinfo, correspondingly.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Corey Minyard 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

char/mwave: fix potential Spectre v1 vulnerability

2019-05-02T20:41:26+00:00

commit 701956d4018e5d5438570e39e8bda47edd32c489 upstream.

ipcnum is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/char/mwave/mwavedd.c:299 mwave_ioctl() warn: potential spectre issue 'pDrvData->IPCs' [w] (local cap)

Fix this by sanitizing ipcnum before using it to index pDrvData->IPCs.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

ipmi: Move BT capabilities detection to the detect call

2018-12-16T22:08:57+00:00

commit c86ba91be75702c013bbf7379542920b6920e98f upstream.

The capabilities detection was being done as part of the normal
state machine, but it was possible for it to be running while
the upper layers of the IPMI driver were initializing the
device, resulting in error and failure to initialize.

Move the capabilities detection to the the detect function,
so it's done before anything else runs on the device.  This also
simplifies the state machine and removes some code, as a bonus.

Signed-off-by: Corey Minyard 
Reported-by: Andrew Banman 
Tested-by: Andrew Banman 
[bwh: Backported to 3.16:
 - struct si_sm_data doesn't include a dev pointer, so use pr_* functions
   for logging
 - Include  for schedule_timeout_uninterruptible()]
Signed-off-by: Ben Hutchings

random: mix rdrand with entropy sent in from userspace

2018-11-20T18:05:44+00:00

commit 81e69df38e2911b642ec121dec319fad2a4782f3 upstream.

Fedora has integrated the jitter entropy daemon to work around slow
boot problems, especially on VM's that don't support virtio-rng:

    https://bugzilla.redhat.com/show_bug.cgi?id=1572944

It's understandable why they did this, but the Jitter entropy daemon
works fundamentally on the principle: "the CPU microarchitecture is
**so** complicated and we can't figure it out, so it *must* be
random".  Yes, it uses statistical tests to "prove" it is secure, but
AES_ENCRYPT(NSA_KEY, COUNTER++) will also pass statistical tests with
flying colors.

So if RDRAND is available, mix it into entropy submitted from
userspace.  It can't hurt, and if you believe the NSA has backdoored
RDRAND, then they probably have enough details about the Intel
microarchitecture that they can reverse engineer how the Jitter
entropy daemon affects the microarchitecture, and attack its output
stream.  And if RDRAND is in fact an honest DRNG, it will immeasurably
improve on what the Jitter entropy daemon might produce.

This also provides some protection against someone who is able to read
or set the entropy seed file.

Signed-off-by: Theodore Ts'o 
Cc: Arnd Bergmann 
Signed-off-by: Ben Hutchings