Gagan Grover [Tue, 22 Nov 2016 10:13:19 +0000 (15:43 +0530)]
video: tegra: host: use lock to get syncpt name
Use sp->syncpt_mutex lock to get syncpt name in
syncpt_name_show()
Without the lock, it is possible for user to read
syncpt name in corrupted state if user read
coincides with syncpt free
Nick Desaulniers [Mon, 16 Jan 2017 12:58:30 +0000 (18:28 +0530)]
BACKPORT: aio: mark AIO pseudo-fs noexec
This ensures that do_mmap() won't implicitly make AIO memory mappings
executable if the READ_IMPLIES_EXEC personality flag is set. Such
behavior is problematic because the security_mmap_file LSM hook doesn't
catch this case, potentially permitting an attacker to bypass a W^X
policy enforced by SELinux.
Adrian Salido [Mon, 16 Jan 2017 11:56:05 +0000 (17:26 +0530)]
fs/proc/array.c: make safe access to group_leader
As mentioned in commit 52ee2dfdd4f51cf422ea6a96a0846dc94244aa37
("pids: refactor vnr/nr_ns helpers to make them safe"). *_nr_ns
helpers used to be buggy. The commit addresses most of the helpers but
is missing task_tgid_xxx()
Without this protection there is a possible use after free reported by
kasan instrumented kernel:
Handle the race condition between malicious fd close and
copy_to_user error, which can create use after free condition.
This is fixed by deferring the fd install, which eliminates
the race that leads to use after free condition.
Fixing Google Bug 32160775.
David Howells [Wed, 26 Oct 2016 14:01:54 +0000 (15:01 +0100)]
KEYS: Fix short sprintf buffer in /proc/keys show function
This fixes CVE-2016-7042.
Fix a short sprintf buffer in proc_keys_show(). If the gcc stack protector
is turned on, this can cause a panic due to stack corruption.
The problem is that xbuf[] is not big enough to hold a 64-bit timeout
rendered as weeks:
(gdb) p 0xffffffffffffffffULL/(60*60*24*7)
$2 = 30500568904943
That's 14 chars plus NUL, not 11 chars plus NUL.
Expand the buffer to 16 chars.
I think the unpatched code apparently works if the stack-protector is not
enabled because on a 32-bit machine the buffer won't be overflowed and on a
64-bit machine there's a 64-bit aligned pointer at one side and an int that
isn't checked again on the other side.
John Dias [Mon, 16 Jan 2017 08:22:04 +0000 (13:52 +0530)]
perf: don't leave group_entry on sibling list(use-after-free)
When perf_group_detach is called on a group leader,
it should empty its sibling list. Otherwise, when
a sibling is later deallocated, list_del_event()
removes the sibling's group_entry from its current
list, which can be the now-deallocated group leader's
sibling list (use-after-free bug).
Siqi Lin [Mon, 16 Jan 2017 08:28:01 +0000 (13:58 +0530)]
ALSA: info: Check for integer overflow in snd_info_entry_write()
snd_info_entry_write() resizes the buffer with an unsigned long
size argument that gets truncated because resize_info_buffer()
takes the size parameter as an unsigned int. On 64-bit kernels,
this causes the following copy_to_user() to write out-of-bounds
if (pos + count) can't be represented by an unsigned int.
Thus it overflows and the resulting number is less than 4080, which makes
3823 / 4080 = 0
an nr_pages is set to this. As we already checked against the minimum that
nr_pages may be, this causes the logic to fail as well, and we crash the
kernel.
There's no reason to have the two DIV_ROUND_UP() (that's just result of
historical code changes), clean up the code and fix this bug.
Deepak Nibade [Mon, 23 Jan 2017 11:32:07 +0000 (17:02 +0530)]
gpu: nvgpu: serialize debug session IOCTLs
Hold debug_s->ioctl_lock for all debug session IOCTLs to prevent
multi-threaded user space IOCTL calls.
Debug session IOCTL calls are not thread-safe and hence this
serialization is required.
Aly Hirani [Fri, 3 Feb 2017 00:06:55 +0000 (16:06 -0800)]
video: tegra: hdmi: Disable HDCP for BlackMagic
BlackMagic 12G has a bug where it spams us with a constant stream of
hotplugs 130 ms apart if we enable HDCP. This stream of hotplugs end up
as a "blank screen" since we are stuck in a loop of modeset and display
teardown.
Since it doesn't support HDCP, this change blacklists it from HDCP. Once
done, it never sends us a hotplug and the device works perfectly after.
Mahantesh Kumbar [Wed, 25 Jan 2017 10:00:45 +0000 (15:30 +0530)]
gpu: nvgpu: sysfs node to read PMU state
sysfs node to know PMU state whether PMU
boot completed & its ready with state
"pmu->pmu_state == PMU_STATE_STARTED" to
process command request.
issue: enable/disable request for ELPG/AELPG
through sysfs node during init stage of boot process
causing PMU halt error due to unknown state of
PMU at boot time.
Fix: Provided node to read PMU state if ready then
send commands else wait till gets ready.
Change-Id: Ibd151f775f51f7a299aa61af4fbb34287b1cae64 Signed-off-by: Martin Gao <marting@nvidia.com>
Reviewed-on: http://git-master/r/1296821 Reviewed-by: David Dastous St Hilaire <ddastoussthi@nvidia.com> Tested-by: David Dastous St Hilaire <ddastoussthi@nvidia.com> Reviewed-by: Vinayak Pane <vpane@nvidia.com>
Mahantesh Kumbar [Wed, 25 Jan 2017 07:38:47 +0000 (13:08 +0530)]
gpu: nvgpu: elpg/aelpg sysfs update
check g->power_on & pmu->pmu_state flags
to know the status of PMU whether ready to take
commands for PG request or not. If not ready
then update ELPG/AELPG global flags
used within kernel driver & skip sending
commands to PMU
issue: enable/disable request for ELPG/AELPG
through sysfs node during init stage of boot process
causing PMU halt error
Aly Hirani [Wed, 11 Jan 2017 07:29:58 +0000 (23:29 -0800)]
video: tegra: dc: Add quick for Vizio P series
The Vizio SmartCast P series 4K TVs fail 1/3 hotplugs with "No Signal".
Experiments showed that enabling HDMI 2.0 scrambling and HDCP at the
same time causes this failure from Vizio's side.
This change adds a WAR to introduce a 5 second delay after modeset to
start the hdcp (instead of the standard 100ms delay).
This change also adds edid quirks to limit the 5 second delay to only
the P cast series.
- Accelerometer sensor is HW disabled when suspending. When resuming, if
the gyroscope sensor is enabled first, it didn't account for HW enabling
the accelerometer as well if previously enabled before suspending. This
was intermittent behavior depending on the wake source and resume timing
of the external sensors on the auxiliary ports, as well as resume enable
from user space.
Erik Lilliebjerg [Sat, 31 Dec 2016 21:37:41 +0000 (14:37 -0700)]
iio: imu: nvi: Fix false error message
- Due to Invensense parts being register incompatible (even the HW ID),
there were false error messages during the driver process of identifying
the part. This patch suppresses those error messages until the part is
identified and the errors become legitimate.
Anand Prasad [Wed, 28 Dec 2016 19:45:29 +0000 (11:45 -0800)]
sysedp_reactive_capping: Fix warning string check
The current implementation incorrectly checks if a pointer value is
NULL when actually referencing an array.
Instead, use a pointer to read the threshold warning string from
device-tree so that the pointer NULL check now works.
Federico Sauter [Tue, 17 Mar 2015 16:45:28 +0000 (17:45 +0100)]
CIFS: Fix race condition on RFC1002_NEGATIVE_SESSION_RESPONSE
This patch fixes a race condition that occurs when connecting
to a NT 3.51 host without specifying a NetBIOS name.
In that case a RFC1002_NEGATIVE_SESSION_RESPONSE is received
and the SMB negotiation is reattempted, but under some conditions
it leads SendReceive() to hang forever while waiting for srv_mutex.
This, in turn, sets the calling process to an uninterruptible sleep
state and makes it unkillable.
The solution is to unlock the srv_mutex acquired in the demux
thread *before* going to sleep (after the reconnect error) and
before reattempting the connection.
If the sink is DTSHD/MLP decode capable, but not supporting
8ch/192k in its ELD, ALSA card doesn't add these in supported
rates & ch. Add these in ALSA card for HD decode capable sinks,
so that user-space can open pcm device and play HD content.
Andrew Chen [Tue, 13 Dec 2016 09:16:29 +0000 (17:16 +0800)]
hid: jarvis: fake button release events for pepper
Fake button release events when not receiving them from pepper.
Also provide sysfs interface for shieldtech to set the timeout value
according to firmware version.
This change disables scdc when disabling hdmi controller.
This fixes issue if we are going to fastboot mode which is
set at 1080p where we should not enable scdc. This causes
issue for some TVs specially HDR 4K.
Change-Id: Ifa8ad45db43aa1b70810b92b4a39fc64d17e5df7 Signed-off-by: Santosh Reddy Galma <galmar@nvidia.com>
Reviewed-on: http://git-master/r/1272521 Reviewed-by: Automatic_Commit_Validation_User Reviewed-by: Vinayak Pane <vpane@nvidia.com> Reviewed-by: Aly Hirani <ahirani@nvidia.com> Tested-by: Aly Hirani <ahirani@nvidia.com> Reviewed-by: Mitch Luban <mluban@nvidia.com>
GVS: Gerrit_Virtual_Submit
When we don't have any file in cpu/cpufreq directory we shouldn't
create it. Specially with the introduction of per-policy governor
instance patchset, even governors are moved to
cpu/cpu*/cpufreq/governor-name directory and so this directory is
just not required.
Sai Gurrappadi [Fri, 22 May 2015 19:50:50 +0000 (12:50 -0700)]
misc: Remove stale code in cpuload
cpuloadmon no longer needs a timer to sample load as it uses the
idle-counter delta to determine load over an interval. Removed the timer
along with a lot of unused code most of which was copied over from
cpufreq_interactive.c.
Mithun Maragiri [Thu, 8 Dec 2016 20:39:48 +0000 (12:39 -0800)]
hid: jarvis: Supress kernel debug prints in atvr_raw_event()
There is a spew of debug prints when handling debug HID reports
sent by Thunderstrike. This report has debug information about
the current status of TS.
Nicolin Chen [Sat, 23 Jan 2016 00:00:48 +0000 (16:00 -0800)]
cpufreq: Synchronize the cpufreq store_*() routines with CPU hotplug
The functions that are used to write to cpufreq sysfs files (such as
store_scaling_max_freq()) are not hotplug safe. They can race with CPU
hotplug tasks and lead to problems such as trying to acquire an already
destroyed timer-mutex etc.
So use get_online_cpus()/put_online_cpus() in the store_*() functions, to
synchronize with CPU hotplug.
[ Merging the same patch from the Linux mainline, commited by Srivatsa
S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>; could not do cherry-pick
due to conflicts. Also revised the commit log to make less confusion
as the original commit log mentioned an issue that isn't included in
our 3.10 branch.
This commit could be treated as a fix to the Bug 200152270 as there
is a race condition here between SYSFS operations and a cpu hotplug
that when the init process tries to GOV_START all online cpus via
SYSFS, a cpu hotplug may happen to turn off one cpu without updating
the new_policy->cpus in time. So the new_policy->cpus might contain
an offlined cpu which is the root cause of this bug. Adding a lock
of hotplug here ensures no race would happen during the SYSFS access.
As policy->cpus is always updated during hotplug in its add/remove
functions, we don't need to worry that it gets out-of-date as long
as any hotplug operation is locked during the store_*().
I applied this change and passed both the cpufreqhotplugstress and
the following test:
while true; do echo 0 > /sys/devices/system/cpu/cpu3/online; echo 1 > /sys/devices/system/cpu/cpu3/online; done&
while true; do echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor; echo interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor; done&
Andrew Chen [Wed, 30 Nov 2016 03:48:04 +0000 (11:48 +0800)]
hid: jarvis: do tsfw_icm's probe in workqueue
tsfw_icm probe takes around 2 seconds to be finished and this
causes incoming HID data to be dropped at stack layer in the
duration. Make it running in workqueue to fix this problem.
Alex Waterman [Tue, 29 Nov 2016 00:25:28 +0000 (16:25 -0800)]
gpu: nvgpu: Fix CDE bind channel usage
Use the shared bind channel code from CDE instead of custom
channel binding cide. The CDE code was using its own bind
channel code because the bind channel API took a gk20a_as_share
argument to define the VM. However, the core bind channel API
is trivially abstractable so that the core API can take a
vm_gk20a struct directly.
Alex Waterman [Thu, 13 Oct 2016 17:03:59 +0000 (10:03 -0700)]
gpu: nvgpu: Add ref counting to channels
Make sure that the VM owned by a channel lives for at least
as long as that channel does. If the channel's VM is cleaned
up before the channel then use-after-free bugs can occur.
It seems like the gk20a_vm_get() was simply missing from the
bind channel. This patch adds it. The corresponding
gk20a_vm_put() happens during channel close.
Mithun Maragiri [Wed, 30 Nov 2016 06:54:51 +0000 (22:54 -0800)]
DNI: hid: jarvis: Fix lost key events
The issue of key events getting lost happens when the HID report
is of the report->id = SENSOR_REPORT_ID_COMBINED.
Sensor report data from the data buffer was handled properly
however the button report part was not handled properly
Bring ideas from the following upstream commits
- commit "cadc2125e" (iio: fix: Keep a reference to the IIO device
for open file descriptors)
- commit "d2f0a48f3" (iio: Wakeup poll and blocking reads when the
device is unregistered)
Gagan Grover [Sun, 4 Dec 2016 11:42:33 +0000 (17:12 +0530)]
ARM: config: tegra12: auto generated diff
No change done manually. Diff is auto generated by performing
these three steps on tot:
1) ksetup tegra12_android_defconfig
2) kconfig (just touched one config, no change made)
3) ksavedefconfig tegra12_android_defconfig
Mithun Maragiri [Tue, 29 Nov 2016 01:54:46 +0000 (17:54 -0800)]
Elevation of privilege vulnerability in kernel networking subsystem
An elevation of privilege vulnerability in the kernel networking
subsystem could enable a local malicious application to execute
arbitrary code within the context of the kernel. This issue is
rated as Moderate because it first requires compromising a
privileged process and current compiler optimizations restrict
access to the vulnerable code.
There is no validation of the len variable passed to the
ping_common_sendmsg function to check if it is less than
icmph_len leading to a potential overflow. The fix is designed
to add additional validation to prevent the potential overflow.
Mithun Maragiri [Tue, 29 Nov 2016 04:11:18 +0000 (20:11 -0800)]
Denial of service vulnerability in kernel sound driver
A denial of service vulnerability in the kernel could allow a
local malicious application to cause a device reboot.
This issue is rated as Low because it is a temporary denial of
service.
The original fix used -EIO as the error return code but
the function signatures had unsigned int as the return type.
The updated fix uses -1 as the error return code instead of -EIO
so the error return code is more clearly defined.
Paul Moore [Tue, 19 Jul 2016 21:42:57 +0000 (17:42 -0400)]
audit: fix a double fetch in audit_log_single_execve_arg()
There is a double fetch problem in audit_log_single_execve_arg()
where we first check the execve(2) argumnets for any "bad" characters
which would require hex encoding and then re-fetch the arguments for
logging in the audit record[1]. Of course this leaves a window of
opportunity for an unsavory application to munge with the data.
This patch reworks things by only fetching the argument data once[2]
into a buffer where it is scanned and logged into the audit
records(s). In addition to fixing the double fetch, this patch
improves on the original code in a few other ways: better handling
of large arguments which require encoding, stricter record length
checking, and some performance improvements (completely unverified,
but we got rid of some strlen() calls, that's got to be a good
thing).
As part of the development of this patch, I've also created a basic
regression test for the audit-testsuite, the test can be tracked on
GitHub at the following link:
[1] If you pay careful attention, there is actually a triple fetch
problem due to a strnlen_user() call at the top of the function.
[2] This is a tiny white lie, we do make a call to strnlen_user()
prior to fetching the argument data. I don't like it, but due to the
way the audit record is structured we really have no choice unless we
copy the entire argument at once (which would require a rather
wasteful allocation). The good news is that with this patch the
kernel no longer relies on this strnlen_user() value for anything
beyond recording it in the log, we also update it with a trustworthy
value whenever possible.
Mark Rutland [Thu, 8 Jan 2015 11:42:59 +0000 (11:42 +0000)]
arm64: make sys_call_table const
As with x86, mark the sys_call_table const such that it will be placed
in the .rodata section. This will cause attempts to modify the table
(accidental or deliberate) to fail when strict page permissions are in
place. In the absence of strict page permissions, there should be no
functional change.
EunTaik Lee [Wed, 24 Feb 2016 04:38:06 +0000 (04:38 +0000)]
staging/android/ion : fix a race condition in the ion driver
There is a use-after-free problem in the ion driver.
This is caused by a race condition in the ion_ioctl()
function.
A handle has ref count of 1 and two tasks on different
cpus calls ION_IOC_FREE simultaneously.
cpu 0 cpu 1
-------------------------------------------------------
ion_handle_get_by_id()
(ref == 2)
ion_handle_get_by_id()
(ref == 3)
ion_free()
(ref == 2)
ion_handle_put()
(ref == 1)
ion_free()
(ref == 0 so ion_handle_destroy() is
called
and the handle is freed.)
ion_handle_put() is called and it
decreases the slub's next free pointer
The problem is detected as an unaligned access in the
spin lock functions since it uses load exclusive
instruction. In some cases it corrupts the slub's
free pointer which causes a mis-aligned access to the
next free pointer.(kmalloc returns a pointer like ffffc0745b4580aa). And it causes lots of other
hard-to-debug problems.
This symptom is caused since the first member in the
ion_handle structure is the reference count and the
ion driver decrements the reference after it has been
freed.
To fix this problem client->lock mutex is extended
to protect all the codes that uses the handle.
Tejun Heo [Wed, 25 May 2016 15:48:25 +0000 (11:48 -0400)]
percpu: fix synchronization between synchronous map extension and chunk destruction
For non-atomic allocations, pcpu_alloc() can try to extend the area
map synchronously after dropping pcpu_lock; however, the extension
wasn't synchronized against chunk destruction and the chunk might get
freed while extension is in progress.
This patch fixes the bug by putting most of non-atomic allocations
under pcpu_alloc_mutex to synchronize against pcpu_balance_work which
is responsible for async chunk management including destruction.
Gagan Grover [Fri, 25 Nov 2016 17:22:19 +0000 (22:52 +0530)]
cgroup: Correct the address format specifier
The format specifier %p can leak kernel addresses while not valuing
the kptr_restrict system settings.
The fix is designed to use %pK instead of %p, which also evaluates
whether kptr_restrict is set.
Vladis Dronov [Thu, 31 Mar 2016 16:05:43 +0000 (12:05 -0400)]
ALSA: usb-audio: Fix double-free in error paths after snd_usb_add_audio_stream() call
create_fixed_stream_quirk(), snd_usb_parse_audio_interface() and
create_uaxx_quirk() functions allocate the audioformat object by themselves
and free it upon error before returning. However, once the object is linked
to a stream, it's freed again in snd_usb_audio_pcm_free(), thus it'll be
double-freed, eventually resulting in a memory corruption.
This patch fixes these failures in the error paths by unlinking the audioformat
object before freeing it.
Based on a patch by Takashi Iwai <tiwai@suse.de>
[Note for stable backports:
this patch requires the commit 902eb7fd1e4a ('ALSA: usb-audio: Minor
code cleanup in create_fixed_stream_quirk()')]
Peter Zijlstra [Tue, 15 Dec 2015 12:49:05 +0000 (13:49 +0100)]
perf: Fix race in swevent hash
There's a race on CPU unplug where we free the swevent hash array
while it can still have events on. This will result in a
use-after-free which is BAD.
Simply do not free the hash array on unplug. This leaves the thing
around and no use-after-free takes place.
When the last swevent dies, we do a for_each_possible_cpu() iteration
anyway to clean these up, at which time we'll free it, so no leakage
will occur.
Eric Dumazet [Wed, 17 Aug 2016 12:56:26 +0000 (05:56 -0700)]
tcp: fix use after free in tcp_xmit_retransmit_queue()
When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the
tail of the write queue using tcp_add_write_queue_tail()
Then it attempts to copy user data into this fresh skb.
If the copy fails, we undo the work and remove the fresh skb.
Unfortunately, this undo lacks the change done to tp->highest_sack and
we can leave a dangling pointer (to a freed skb)
Later, tcp_xmit_retransmit_queue() can dereference this pointer and
access freed memory. For regular kernels where memory is not unmapped,
this might cause SACK bugs because tcp_highest_sack_seq() is buggy,
returning garbage instead of tp->snd_nxt, but with various debug
features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel.
This bug was found by Marco Grassi thanks to syzkaller.
Lukas Czerner [Sun, 18 Oct 2015 02:57:06 +0000 (22:57 -0400)]
ext4: fix potential use after free in __ext4_journal_stop
There is a use-after-free possibility in __ext4_journal_stop() in the
case that we free the handle in the first jbd2_journal_stop() because
we're referencing handle->h_err afterwards. This was introduced in 9705acd63b125dee8b15c705216d7186daea4625 and it is wrong. Fix it by
storing the handle->h_err value beforehand and avoid referencing
potentially freed handle.
get_task_ioprio() accesses the task->io_context without holding the task
lock and thus can race with exit_io_context(), leading to a
use-after-free. The reproducer below hits this within a few seconds on
my 4-core QEMU VM:
int main(int argc, char **argv)
{
pid_t pid, child;
long nproc, i;
This problem can occur in the following situation:
open()
- pread()
- .seq_start()
- iter = kmalloc() // succeeds
- seqf->private = iter
- .seq_stop()
- kfree(seqf->private)
- pread()
- .seq_start()
- iter = kmalloc() // fails
- .seq_stop()
- class_dev_iter_exit(seqf->private) // boom! old pointer
As the comment in disk_seqf_stop() says, stop is called even if start
failed, so we need to reinitialise the private pointer to NULL when seq
iteration stops.
An alternative would be to set the private pointer to NULL when the
kmalloc() in disk_seqf_start() fails.
Calvin Owens [Fri, 30 Oct 2015 23:57:00 +0000 (16:57 -0700)]
sg: Fix double-free when drives detach during SG_IO
In sg_common_write(), we free the block request and return -ENODEV if
the device is detached in the middle of the SG_IO ioctl().
Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we
end up freeing rq->cmd in the already free rq object, and then free
the object itself out from under the current user.
This ends up corrupting random memory via the list_head on the rq
object. The most common crash trace I saw is this:
The solution is straightforward: just set srp->rq to NULL in the
failure branch so that sg_finish_rem_req() doesn't attempt to re-free
it.
Additionally, since sg_rq_end_io() will never be called on the object
when this happens, we need to free memory backing ->cmd if it isn't
embedded in the object itself.
KASAN was extremely helpful in finding the root cause of this bug.
Rainer Weikusat [Thu, 11 Feb 2016 19:37:27 +0000 (19:37 +0000)]
af_unix: Guard against other == sk in unix_dgram_sendmsg
The unix_dgram_sendmsg routine use the following test
if (unlikely(unix_peer(other) != sk && unix_recvq_full(other))) {
to determine if sk and other are in an n:1 association (either
established via connect or by using sendto to send messages to an
unrelated socket identified by address). This isn't correct as the
specified address could have been bound to the sending socket itself or
because this socket could have been connected to itself by the time of
the unix_peer_get but disconnected before the unix_state_lock(other). In
both cases, the if-block would be entered despite other == sk which
might either block the sender unintentionally or lead to trying to unlock
the same spin lock twice for a non-blocking send. Add a other != sk
check to guard against this.
Mathias Krause [Thu, 5 May 2016 23:22:26 +0000 (16:22 -0700)]
proc: prevent accessing /proc/<PID>/environ until it's ready
If /proc/<PID>/environ gets read before the envp[] array is fully set up
in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying to
read more bytes than are actually written, as env_start will already be
set but env_end will still be zero, making the range calculation
underflow, allowing to read beyond the end of what has been written.
Fix this as it is done for /proc/<PID>/cmdline by testing env_end for
zero. It is, apparently, intentionally set last in create_*_tables().
This bug was found by the PaX size_overflow plugin that detected the
arithmetic underflow of 'this_len = env_end - (env_start + src)' when
env_end is still zero.
The expected consequence is that userland trying to access
/proc/<PID>/environ of a not yet fully set up process may get
inconsistent data as we're in the middle of copying in the environment
variables.
Plugging a Logitech DJ receiver with KASAN activated raises a bunch of
out-of-bound readings.
The fields are allocated up to MAX_USAGE, meaning that potentially, we do
not have enough fields to fit the incoming values.
Add checks and silence KASAN.
Peter Hurley [Fri, 27 Nov 2015 19:30:21 +0000 (14:30 -0500)]
tty: Prevent ldisc drivers from re-using stale tty fields
Line discipline drivers may mistakenly misuse ldisc-related fields
when initializing. For example, a failure to initialize tty->receive_room
in the N_GIGASET_M101 line discipline was recently found and fixed [1].
Now, the N_X25 line discipline has been discovered accessing the previous
line discipline's already-freed private data [2].
Harden the ldisc interface against misuse by initializing revelant
tty fields before instancing the new line discipline.
Alan Stern [Tue, 2 Sep 2014 15:39:15 +0000 (11:39 -0400)]
HID: usbhid: improve handling of Clear-Halt and reset
This patch changes the way usbhid carries out Clear-Halt and reset.
Currently, after a Clear-Halt on the interrupt-IN endpoint, the driver
immediately restarts the interrupt URB, even if the Clear-Halt failed.
This doesn't work out well when the reason for the failure was that
the device was disconnected (when a low- or full-speed device is
connected through a hub to an EHCI controller, transfer errors caused
by disconnection are reported as stalls by the hub). Instead now the
driver will attempt a reset after a failed Clear-Halt.
The way resets are carried out is also changed. Now the driver will
call usb_queue_reset_device() instead of calling usb_reset_device()
directly. This avoids a deadlock that would arise when a device is
unplugged: The hid_reset() routine runs as a workqueue item, a reset
attempt after the device has been unplugged will fail, failure will
cause usbhid to be unbound, and the disconnect routine will try to do
cancel_work_sync(). The usb_queue_reset_device() implementation is
carefully written to handle scenarios like this one properly.
Haley Teng [Thu, 25 Aug 2016 09:29:01 +0000 (17:29 +0800)]
hdmi: fix a dead lock in tegra_hdmi_hpd_worker()
We should not call cancel_delayed_work_sync() in tegra_hdmi_hpd_worker()
since tegra_hdmi_hpd_worker() is a function called by workqueue.
Replacing cancel_delayed_work_sync() by cancel_delayed_work() in
tegra_hdmi_hpd_worker().
The below backtrace is an example of the dead lock issue.
video: tegra: nvmap: Check if handle holds a buffer before map
Consider the following case:
1. NVMAP_IOC_CREATE gives a valid fd to user space
2. user space calls NVMAP_IOC_ALLOC and it fails. So, all
of the handle's allocation fields are zero.
3. Subsequent dma_buf_vmap, mmap on fd leads to __nvmap_mmap
call.
4. handle is valid but h->alloc, h->carveout, h->heap_pgalloc,
h->vaddr all are 0.
5. We check for h->heap_pgalloc which is false, so proceed and
dereference h->carveout leading to NULL pointer exception.
A valid __nvmap_mmap should occur only when h->alloc is true.
So, add check for it.
Save the port statistics before handling serial
interrupt and dump the current port stats when
too much work is done in serial irq handler to
know which interrupt is causing this.