The of_is_ancestor_of() function was renamed from of_link_is_valid()
based on review feedback. The rename meant the semantics of the function
had to be inverted, but this was missed in the earlier patch.
So, fix the semantics of of_is_ancestor_of() and invert the conditional
expressions where it is used.
Fixes: a3e1d1a7f5fc ("of: property: Add functional dependency link from DT bindings")
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20191120080230.16007-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from 3883539140b8ce67ad000938c3cd3b3e59498520)
Change-Id: I6ba531820df33c6a555990e02c08d96820ed8a4f
This allows the of_devlink feature to work across i2c devices too. This
avoid unnecessary probe deferrals of i2c devices, defers consumers of
i2c devices till the i2c devices probe, and allows i2c drivers to
implement sync_state() callbacks.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Link: https://lore.kernel.org/r/20191115045049.261104-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from 60774d2af07a465dc916321e7428a4c5b7867ed4)
Change-Id: I843f57f35be8dac96d9903c86350ef6186dce3b4
device_link_add() might not always succeed depending on the type of
device link and the rest of the dependencies in the system. If
device_link_add() didn't succeed, then we shouldn't try to remove the
link later on as it might remove a link someone else created.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20191115000438.45970-1-saravanak@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry-picked from b59b654478093fa429ad4c7897ae29f201146a00)
Change-Id: I6cffa3ca884b74122307931e8f6615f31c33ef55
The wording was a bit ambiguous. So update it to make it clear.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20191113023559.62295-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from bee3bbe616a2c8de641a64d874f9206835bd4401)
Change-Id: I55b9fe1e97324a453bda33206fe57cfaf711aba8
Set the default for CONFIG_IIO=y, a requirement for bandwidth,
latency and proper synchronization of the sensor hub with camera.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 145377190
Change-Id: If4d6b09cc4fc4807404311d793713557ee88f66b
Leaf changes summary: 4 artifacts changed
Changed leaf types summary: 4 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct snd_pcm_substream at pcm.h:438:1' changed:
type size hasn't changed
1 data member insertion:
'unsigned int snd_pcm_substream::hw_no_buffer', at offset 30 (in bits) at pcm.h:478:1
163 impacted interfaces
'struct snd_soc_dai_driver at soc-dai.h:279:1' changed:
type size changed from 1920 to 2048 (in bits)
there are data member changes:
type 'struct snd_soc_pcm_stream' of 'snd_soc_dai_driver::capture' changed:
type size changed from 320 to 384 (in bits)
1 data member insertion:
'const char* snd_soc_pcm_stream::aif_name', at offset 320 (in bits) at soc.h:730:1
108 impacted interfaces
type 'struct snd_soc_pcm_stream' of 'snd_soc_dai_driver::playback' changed as reported earlier
and offset changed from 1472 to 1536 (in bits) (by +64 bits), size changed from 320 to 384 (in bits) (by +64 bits)
'int snd_soc_dai_driver::probe_order' offset changed from 1824 to 1952 (in bits) (by +128 bits)
'int snd_soc_dai_driver::remove_order' offset changed from 1856 to 1984 (in bits) (by +128 bits)
108 impacted interfaces
'struct snd_soc_dai_link at soc.h:763:1' changed:
type size hasn't changed
1 data member insertion:
'unsigned int snd_soc_dai_link::no_host_mode', at offset 14 (in bits) at soc.h:849:1
there are data member changes:
'unsigned int snd_soc_dai_link::ignore' offset changed from 9 to 7 (in bits) (by -2 bits)
'unsigned int snd_soc_dai_link::ignore_pmdown_time' offset changed from 10 to 8 (in bits) (by -2 bits)
'unsigned int snd_soc_dai_link::dpcm_merged_rate' offset changed from 11 to 9 (in bits) (by -2 bits)
'unsigned int snd_soc_dai_link::dpcm_merged_chan' offset changed from 12 to 10 (in bits) (by -2 bits)
'unsigned int snd_soc_dai_link::dpcm_merged_format' offset changed from 13 to 11 (in bits) (by -2 bits)
'unsigned int snd_soc_dai_link::dpcm_playback' offset changed from 14 to 12 (in bits) (by -2 bits)
'unsigned int snd_soc_dai_link::dpcm_capture' offset changed from 15 to 13 (in bits) (by -2 bits)
108 impacted interfaces
'struct snd_soc_pcm_stream at soc.h:717:1' changed:
details were reported earlier
Fixes: 7fe5afb291 ("ANDROID: ASoC: core - add hostless DAI support")
Change-Id: Ic4813a65ec885400ac56f53cf2bf9e616e267dd3
Signed-off-by: Matthias Maennich <maennich@google.com>
Allow DAI's to be hostless so that no PCM data is sent between DAI
and CPU. This allows for power savings as there is no DMA or CPU
interaction required.
BUG: 144369166
Change-Id: I8947f1ad2c4a7013e92e21078b35e3cad332cf6f
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Patrick Lai <plai@codeaurora.org>
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
Signed-off-by: Meng Wang <mwang@codeaurora.org>
Signed-off-by: Gopikrishnaiah Anandan <agopik@codeaurora.org>
Signed-off-by: Neema Shetty <nshetty@codeaurora.org>
Signed-off-by: Vidyakumar Athota <vathota@codeaurora.org>
Signed-off-by: Anish Kumar <kanish@codeaurora.org>
Signed-off-by: Shiv Maliyappanahalli <smaliyap@codeaurora.org>
Signed-off-by: Sudheer Papothi <spapothi@codeaurora.org>
ABI changes as follows:
Leaf changes summary: 3 artifacts changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 1 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
1 function with some sub-type change:
'struct task_struct at sched.h:624:1' changed:
type size changed from 28672 to 29184 (in bits)
2 data member insertions:
'mutex task_struct::futex_exit_mutex', at offset 18048 (in bits) at sched.h:1061:1
'unsigned int task_struct::futex_state', at offset 18304 (in bits) at sched.h:1062:1
there are data member changes:
'perf_event_context* task_struct::perf_event_ctxp[2]' offset changed from 18048 to 18368 (in bits) (by +320 bits)
'mutex task_struct::perf_event_mutex' offset changed from 18176 to 18496 (in bits) (by +320 bits)
'list_head task_struct::perf_event_list' offset changed from 18432 to 18752 (in bits) (by +320 bits)
'unsigned long int task_struct::preempt_disable_ip' offset changed from 18560 to 18880 (in bits) (by +320 bits)
'tlbflush_unmap_batch task_struct::tlb_ubc' offset changed from 18624 to 18944 (in bits) (by +320 bits)
offset changed from 18624 to 18944 (in bits) (by +320 bits)
'pipe_inode_info* task_struct::splice_pipe' offset changed from 18752 to 19072 (in bits) (by +320 bits)
'page_frag task_struct::task_frag' offset changed from 18816 to 19136 (in bits) (by +320 bits)
'int task_struct::nr_dirtied' offset changed from 18944 to 19264 (in bits) (by +320 bits)
'int task_struct::nr_dirtied_pause' offset changed from 18976 to 19296 (in bits) (by +320 bits)
'unsigned long int task_struct::dirty_paused_when' offset changed from 19008 to 19328 (in bits) (by +320 bits)
'u64 task_struct::timer_slack_ns' offset changed from 19072 to 19392 (in bits) (by +320 bits)
'u64 task_struct::default_timer_slack_ns' offset changed from 19136 to 19456 (in bits) (by +320 bits)
'unsigned long int task_struct::trace' offset changed from 19200 to 19520 (in bits) (by +320 bits)
'unsigned long int task_struct::trace_recursion' offset changed from 19264 to 19584 (in bits) (by +320 bits)
'mem_cgroup* task_struct::memcg_in_oom' offset changed from 19328 to 19648 (in bits) (by +320 bits)
'gfp_t task_struct::memcg_oom_gfp_mask' offset changed from 19392 to 19712 (in bits) (by +320 bits)
'int task_struct::memcg_oom_order' offset changed from 19424 to 19744 (in bits) (by +320 bits)
'unsigned int task_struct::memcg_nr_pages_over_high' offset changed from 19456 to 19776 (in bits) (by +320 bits)
'mem_cgroup* task_struct::active_memcg' offset changed from 19520 to 19840 (in bits) (by +320 bits)
'request_queue* task_struct::throttle_queue' offset changed from 19584 to 19904 (in bits) (by +320 bits)
'uprobe_task* task_struct::utask' offset changed from 19648 to 19968 (in bits) (by +320 bits)
'int task_struct::pagefault_disabled' offset changed from 19712 to 20032 (in bits) (by +320 bits)
'task_struct* task_struct::oom_reaper_list' offset changed from 19776 to 20096 (in bits) (by +320 bits)
'vm_struct* task_struct::stack_vm_area' offset changed from 19840 to 20160 (in bits) (by +320 bits)
'refcount_t task_struct::stack_refcount' offset changed from 19904 to 20224 (in bits) (by +320 bits)
'void* task_struct::security' offset changed from 19968 to 20288 (in bits) (by +320 bits)
'thread_struct task_struct::thread' offset changed from 20096 to 20352 (in bits) (by +256 bits)
7421 impacted interfaces
Change-Id: I30f5296d24905028695ed09c1a5ec2f7e660c801
Cc: Greg Kroah-Hartman <gregkh@google.com>
Signed-off-by: Matthias Maennich <maennich@google.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl3g4IgACgkQONu9yGCS
aT67PhAAm6Ee49V6f6imspR7PUZHuO85Sd54eegpOQ9VYDvNn89EylEoLIv0Vcfg
eIVk8M6L0YxIlQraezP/7+XyHtv40url/ccseqD3o1ialftL1/RbcSL6MST5IdFY
KWRq6TT84rihsUg6/Ev5NnDJIu8khgVJWO7voTlz+7nHr+RnhQoDNlQX4So28Gnd
db2i+kxYN/wXXGn2R5ZkV2ny43bzXBBrO7NWHihnWNbkXDeF+ixHEURkM2wJCPNS
r+rOlEeUuBOM/YgyvNtHLDnVHfIbJzU62EVq6XAffMqQ2/wA4nfpT1qEpMpK7df9
LdLC2fWmC/Tplc4DSAVtkTbyRTgvj0QGZkg6UNH2Z3gOEiPCnsQY5oE2VcQ3FkZM
x0YeDvZ4JUm1w+KikhFZw2dUWWjb4nxzj6p2PHgWA6nOU9JrdIVJeONp+Em7mpSx
DcYfJeMzOG70s7Vv93JGgFai5R0300DByA4/xh/mlWD/1SeMfF5HTx6O/J9k19VK
R7UhoUD+AHTqDAU1VkrXY2la5esNBZKCnTCgDBaXf7FUiddPcWCgvHrSJy1B00YS
l19eQ9u+ip6ONmK5gEg+dMfkyf6A3RY2VGrBvQ7Ba63IaZY54DFcTPvwMYbexa9c
2joWXl4hPRMInqLWvYbYtrT+utuydSDRl2Y0ZxNjHjg8pL57ttE=
=Mvcj
-----END PGP SIGNATURE-----
Merge 5.4.1 into android-5.4
Changes in 5.4.1
Bluetooth: Fix invalid-free in bcsp_close()
ath9k_hw: fix uninitialized variable data
ath10k: Fix a NULL-ptr-deref bug in ath10k_usb_alloc_urb_from_pipe
ath10k: Fix HOST capability QMI incompatibility
ath10k: restore QCA9880-AR1A (v1) detection
Revert "Bluetooth: hci_ll: set operational frequency earlier"
Revert "dm crypt: use WQ_HIGHPRI for the IO and crypt workqueues"
md/raid10: prevent access of uninitialized resync_pages offset
x86/insn: Fix awk regexp warnings
x86/speculation: Fix incorrect MDS/TAA mitigation status
x86/speculation: Fix redundant MDS mitigation message
nbd: prevent memory leak
x86/stackframe/32: Repair 32-bit Xen PV
x86/xen/32: Make xen_iret_crit_fixup() independent of frame layout
x86/xen/32: Simplify ring check in xen_iret_crit_fixup()
x86/doublefault/32: Fix stack canaries in the double fault handler
x86/pti/32: Size initial_page_table correctly
x86/cpu_entry_area: Add guard page for entry stack on 32bit
x86/entry/32: Fix IRET exception
x86/entry/32: Use %ss segment where required
x86/entry/32: Move FIXUP_FRAME after pushing %fs in SAVE_ALL
x86/entry/32: Unwind the ESPFIX stack earlier on exception entry
x86/entry/32: Fix NMI vs ESPFIX
selftests/x86/mov_ss_trap: Fix the SYSENTER test
selftests/x86/sigreturn/32: Invalidate DS and ES when abusing the kernel
x86/pti/32: Calculate the various PTI cpu_entry_area sizes correctly, make the CPU_ENTRY_AREA_PAGES assert precise
x86/entry/32: Fix FIXUP_ESPFIX_STACK with user CR3
futex: Prevent robust futex exit race
ALSA: usb-audio: Fix NULL dereference at parsing BADD
ALSA: usb-audio: Fix Scarlett 6i6 Gen 2 port data
media: vivid: Set vid_cap_streaming and vid_out_streaming to true
media: vivid: Fix wrong locking that causes race conditions on streaming stop
media: usbvision: Fix invalid accesses after device disconnect
media: usbvision: Fix races among open, close, and disconnect
cpufreq: Add NULL checks to show() and store() methods of cpufreq
futex: Move futex exit handling into futex code
futex: Replace PF_EXITPIDONE with a state
exit/exec: Seperate mm_release()
futex: Split futex_mm_release() for exit/exec
futex: Set task::futex_state to DEAD right after handling futex exit
futex: Mark the begin of futex exit explicitly
futex: Sanitize exit state handling
futex: Provide state handling for exec() as well
futex: Add mutex around futex exit
futex: Provide distinct return value when owner is exiting
futex: Prevent exit livelock
media: uvcvideo: Fix error path in control parsing failure
media: b2c2-flexcop-usb: add sanity checking
media: cxusb: detect cxusb_ctrl_msg error in query
media: imon: invalid dereference in imon_touch_event
media: mceusb: fix out of bounds read in MCE receiver buffer
ALSA: hda - Disable audio component for legacy Nvidia HDMI codecs
USBIP: add config dependency for SGL_ALLOC
usbip: tools: fix fd leakage in the function of read_attr_usbip_status
usbip: Fix uninitialized symbol 'nents' in stub_recv_cmd_submit()
usb-serial: cp201x: support Mark-10 digital force gauge
USB: chaoskey: fix error case of a timeout
appledisplay: fix error handling in the scheduled work
USB: serial: mos7840: add USB ID to support Moxa UPort 2210
USB: serial: mos7720: fix remote wakeup
USB: serial: mos7840: fix remote wakeup
USB: serial: option: add support for DW5821e with eSIM support
USB: serial: option: add support for Foxconn T77W968 LTE modules
staging: comedi: usbduxfast: usbduxfast_ai_cmdtest rounding error
powerpc/book3s64: Fix link stack flush on context switch
KVM: PPC: Book3S HV: Flush link stack on guest exit to host kernel
Linux 5.4.1
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id50109953b5638956d150e4fc648a94b6e347fb5
commit af2e8c68b9c5403f77096969c516f742f5bb29e0 upstream.
On some systems that are vulnerable to Spectre v2, it is up to
software to flush the link stack (return address stack), in order to
protect against Spectre-RSB.
When exiting from a guest we do some house keeping and then
potentially exit to C code which is several stack frames deep in the
host kernel. We will then execute a series of returns without
preceeding calls, opening up the possiblity that the guest could have
poisoned the link stack, and direct speculative execution of the host
to a gadget of some sort.
To prevent this we add a flush of the link stack on exit from a guest.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 39e72bf96f5847ba87cc5bd7a3ce0fed813dc9ad upstream.
In commit ee13cb249f ("powerpc/64s: Add support for software count
cache flush"), I added support for software to flush the count
cache (indirect branch cache) on context switch if firmware told us
that was the required mitigation for Spectre v2.
As part of that code we also added a software flush of the link
stack (return address stack), which protects against Spectre-RSB
between user processes.
That is all correct for CPUs that activate that mitigation, which is
currently Power9 Nimbus DD2.3.
What I got wrong is that on older CPUs, where firmware has disabled
the count cache, we also need to flush the link stack on context
switch.
To fix it we create a new feature bit which is not set by firmware,
which tells us we need to flush the link stack. We set that when
firmware tells us that either of the existing Spectre v2 mitigations
are enabled.
Then we adjust the patching code so that if we see that feature bit we
enable the link stack flush. If we're also told to flush the count
cache in software then we fall through and do that also.
On the older CPUs we don't need to do do the software count cache
flush, firmware has disabled it, so in that case we patch in an early
return after the link stack flush.
The naming of some of the functions is awkward after this patch,
because they're called "count cache" but they also do link stack. But
we'll fix that up in a later commit to ease backporting.
This is the fix for CVE-2019-18660.
Reported-by: Anthony Steinhauser <asteinhauser@google.com>
Fixes: ee13cb249f ("powerpc/64s: Add support for software count cache flush")
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5618332e5b955b4bff06d0b88146b971c8dd7b32 upstream.
The userspace comedilib function 'get_cmd_generic_timed' fills
the cmd structure with an informed guess and then calls the
function 'usbduxfast_ai_cmdtest' in this driver repeatedly while
'usbduxfast_ai_cmdtest' is modifying the cmd struct until it
no longer changes. However, because of rounding errors this never
converged because 'steps = (cmd->convert_arg * 30) / 1000' and then
back to 'cmd->convert_arg = (steps * 1000) / 30' won't be the same
because of rounding errors. 'Steps' should only be converted back to
the 'convert_arg' if 'steps' has actually been modified. In addition
the case of steps being 0 wasn't checked which is also now done.
Signed-off-by: Bernd Porr <mail@berndporr.me.uk>
Cc: <stable@vger.kernel.org> # 4.4+
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20191118230759.1727-1-mail@berndporr.me.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 92fe35fb9c70a00d8fbbf5bd6172c921dd9c7815 upstream.
The driver was setting the device remote-wakeup feature during probe in
violation of the USB specification (which says it should only be set
just prior to suspending the device). This could potentially waste
power during suspend as well as lead to spurious wakeups.
Note that USB core would clear the remote-wakeup feature at first
resume.
Fixes: 3f5429746d ("USB: Moschip 7840 USB-Serial Driver")
Cc: stable <stable@vger.kernel.org> # 2.6.19
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ea422312a462696093b5db59d294439796cba4ad upstream.
The driver was setting the device remote-wakeup feature during probe in
violation of the USB specification (which says it should only be set
just prior to suspending the device). This could potentially waste
power during suspend as well as lead to spurious wakeups.
Note that USB core would clear the remote-wakeup feature at first
resume.
Fixes: 0f64478cbc ("USB: add USB serial mos7720 driver")
Cc: stable <stable@vger.kernel.org> # 2.6.19
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e696d00e65e81d46e911f24b12e441037bf11b38 upstream.
Add USB ID for MOXA UPort 2210. This device contains mos7820 but
it passes GPIO0 check implemented by driver and it's detected as
mos7840. Hence product id check is added to force mos7820 mode.
Signed-off-by: Pavel Löbl <pavel@loebl.cz>
Cc: stable <stable@vger.kernel.org>
[ johan: rename id defines and add vendor-id check ]
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 91feb01596e5efc0cc922cc73f5583114dccf4d2 upstream.
The work item can operate on
1. stale memory left over from the last transfer
the actual length of the data transfered needs to be checked
2. memory already freed
the error handling in appledisplay_probe() needs
to cancel the work in that case
Reported-and-tested-by: syzbot+495dab1f175edc9c2f13@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191106124902.7765-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 92aa5986f4f7b5a8bf282ca0f50967f4326559f5 upstream.
In case of a timeout or if a signal aborts a read
communication with the device needs to be ended
lest we overwrite an active URB the next time we
do IO to the device, as the URB may still be active.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191107142856.16774-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 347bc8cb26388791c5881a3775cb14a3f765a674 upstream.
Add support for the Mark-10 digital force gauge device to the cp201x
driver.
Based on a report and a larger patch from Joel Jennings
Reported-by: Joel Jennings <joel.jennings@makeitlabs.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191118092119.GA153852@kroah.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2a9125317b247f2cf35c196f968906dcf062ae2d upstream.
Smatch reported that nents is not initialized and used in
stub_recv_cmd_submit(). nents is currently initialized by sgl_alloc()
and used to allocate multiple URBs when host controller doesn't
support scatter-gather DMA. The use of uninitialized nents means that
buf_len is zero and use_sg is true. But buffer length should not be
zero when an URB uses scatter-gather DMA.
To prevent this situation, add the conditional that checks buf_len
and use_sg. And move the use of nents right after the sgl_alloc() to
avoid the use of uninitialized nents.
If the error occurs, it adds SDEV_EVENT_ERROR_MALLOC and stub_priv
will be released by stub event handler and connection will be shut
down.
Fixes: ea44d19076 ("usbip: Implement SG support to vhci-hcd and stub driver")
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Suwan Kim <suwan.kim027@gmail.com>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191111141035.27788-1-suwan.kim027@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 26a4d4c00f85cb844dd11dd35e848b079c2f5e8f upstream.
We should close the fd before the return of read_attr_usbip_status.
Fixes: 3391ba0e27 ("usbip: tools: Extract generic code to be shared with vudc backend")
Signed-off-by: Hewenliang <hewenliang4@huawei.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191025043515.20053-1-hewenliang4@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5a858e79c911330678b5a9be91a24830e94a0dc9 upstream.
The old Nvidia chips have multiple HD-audio codecs on the same
HD-audio controller, and this doesn't work as expected with the current
audio component binding that is implemented under the one-codec-per-
controller assumption; at the probe time, the driver leads to several
kernel WARNING messages.
For the proper support, we may change the pin2port and port2pin to
traverse the codec list per the given pin number, but this needs more
development and testing.
As a quick workaround, instead, this patch drops the binding in the
audio side for these legacy chips since the audio component support in
nouveau graphics driver is still not merged (hence it's basically
unused).
[ Unlike the original commit, this patch actually disables the audio
component binding for all Nvidia chips, not only for legacy chips.
It doesn't matter much, though: nouveau gfx driver still doesn't
provide the audio component binding on 5.4.y, so it's only a
placeholder for now. Also, another difference from the original
commit is that this removes the nvhdmi_audio_ops and other
definitions completely in order to avoid a compile warning due to
unused stuff. -- tiwai ]
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205625
Fixes: ade49db337 ("ALSA: hda/hdmi - Allow audio component for AMD/ATI and Nvidia HDMI")
Link: https://lore.kernel.org/r/20191122132000.4460-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e43148645d18efc3072b1ba45afaa3f385299e55 upstream.
Fix multiple cases of out of bounds (OOB) read associated with
MCE device receive/input data handling.
In reference for the OOB cases below, the incoming/read (byte) data
format when the MCE device responds to a command is:
{ cmd_prefix, subcmd, data0, data1, ... }
where cmd_prefix are:
MCE_CMD_PORT_SYS
MCE_CMD_PORT_IR
and subcmd examples are:
MCE_RSP_GETPORTSTATUS
MCE_RSP_EQIRNUMPORTS
...
Response size dynamically depends on cmd_prefix and subcmd.
So data0, data1, ... may or may not be present on input.
Multiple responses may return in a single receiver buffer.
The trigger condition for OOB read is typically random or
corrupt input data that fills the mceusb receiver buffer.
Case 1:
mceusb_handle_command() reads data0 (var hi) and data1 (var lo)
regardless of whether the response includes such data.
If { cmd_prefix, subcmd } is at the end of the receiver buffer,
read past end of buffer occurs.
This case was reported by
KASAN: slab-out-of-bounds Read in mceusb_dev_recv
https://syzkaller.appspot.com/bug?extid=c7fdb6cb36e65f2fe8c9
Fix: In mceusb_handle_command(), change variable hi and lo to
pointers, and dereference only when required.
Case 2:
If response with data is truncated at end of buffer after
{ cmd_prefix, subcmd }, mceusb_handle_command() reads past
end of buffer for data0, data1, ...
Fix: In mceusb_process_ir_data(), check response size with
remaining buffer size before invoking mceusb_handle_command().
+ if (i + ir->rem < buf_len)
mceusb_handle_command(ir, &ir->buf_in[i - 1]);
Case 3:
mceusb_handle_command() handles invalid/bad response such as
{ 0x??, MCE_RSP_GETPORTSTATUS } of length 2 as a response
{ MCE_CMD_PORT_SYS, MCE_RSP_GETPORTSTATUS, data0, ... }
of length 7. Read OOB occurs for non-existent data0, data1, ...
Cause is mceusb_handle_command() does not check cmd_prefix value.
Fix: mceusb_handle_command() must test both cmd_prefix and subcmd.
Case 4:
mceusb_process_ir_data() receiver parser state SUBCMD is
possible at start (i=0) of receiver buffer resulting in buffer
offset=-1 passed to mceusb_dev_printdata().
Bad offset results in OOB read before start of buffer.
[1214218.580308] mceusb 1-1.3:1.0: rx data[0]: 00 80 (length=2)
[1214218.580323] mceusb 1-1.3:1.0: Unknown command 0x00 0x80
...
[1214218.580406] mceusb 1-1.3:1.0: rx data[14]: 7f 7f (length=2)
[1214218.679311] mceusb 1-1.3:1.0: rx data[-1]: 80 90 (length=2)
[1214218.679325] mceusb 1-1.3:1.0: End of raw IR data
[1214218.679340] mceusb 1-1.3:1.0: rx data[1]: 7f 7f (length=2)
Fix: If parser_state is SUBCMD after processing receiver buffer,
reset parser_state to CMD_HEADER.
In effect, discard cmd_prefix at end of receiver buffer.
In mceusb_dev_printdata(), abort if buffer offset is out of bounds.
Case 5:
If response with data is truncated at end of buffer after
{ cmd_prefix, subcmd }, mceusb_dev_printdata() reads past
end of buffer for data0, data1, ...
while decoding the response to print out.
Fix: In mceusb_dev_printdata(), remove unneeded buffer offset
adjustments (var start and var skip) associated with MCE gen1 header.
Test for truncated MCE cmd response (compare offset+len with buf_len)
and skip decoding of incomplete response.
Move IR data tracing to execute before the truncation test.
Signed-off-by: A Sun <as1033x@comcast.net>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1b976fc6d684e3282914cdbe7a8d68fdce19095c upstream.
The driver needs an isochronous endpoint to be present. It will
oops in its absence. Add checking for it.
Reported-by: syzbot+d93dff37e6a89431c158@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8c279e9394cade640ed86ec6c6645a0e7df5e0b6 upstream.
When parsing the UVC control descriptors fails, the error path tries to
cleanup a media device that hasn't been initialised, potentially
resulting in a crash. Fix this by initialising the media device before
the error handling path can be reached.
Fixes: 5a254d751e ("[media] uvcvideo: Register a v4l2_device")
Reported-by: syzbot+c86454eb3af9e8a4da20@syzkaller.appspotmail.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3ef240eaff36b8119ac9e2ea17cbf41179c930ba upstream.
Oleg provided the following test case:
int main(void)
{
struct sched_param sp = {};
sp.sched_priority = 2;
assert(sched_setscheduler(0, SCHED_FIFO, &sp) == 0);
int lock = vfork();
if (!lock) {
sp.sched_priority = 1;
assert(sched_setscheduler(0, SCHED_FIFO, &sp) == 0);
_exit(0);
}
syscall(__NR_futex, &lock, FUTEX_LOCK_PI, 0,0,0);
return 0;
}
This creates an unkillable RT process spinning in futex_lock_pi() on a UP
machine or if the process is affine to a single CPU. The reason is:
parent child
set FIFO prio 2
vfork() -> set FIFO prio 1
implies wait_for_child() sched_setscheduler(...)
exit()
do_exit()
....
mm_release()
tsk->futex_state = FUTEX_STATE_EXITING;
exit_futex(); (NOOP in this case)
complete() --> wakes parent
sys_futex()
loop infinite because
tsk->futex_state == FUTEX_STATE_EXITING
The same problem can happen just by regular preemption as well:
task holds futex
...
do_exit()
tsk->futex_state = FUTEX_STATE_EXITING;
--> preemption (unrelated wakeup of some other higher prio task, e.g. timer)
switch_to(other_task)
return to user
sys_futex()
loop infinite as above
Just for the fun of it the futex exit cleanup could trigger the wakeup
itself before the task sets its futex state to DEAD.
To cure this, the handling of the exiting owner is changed so:
- A refcount is held on the task
- The task pointer is stored in a caller visible location
- The caller drops all locks (hash bucket, mmap_sem) and blocks
on task::futex_exit_mutex. When the mutex is acquired then
the exiting task has completed the cleanup and the state
is consistent and can be reevaluated.
This is not a pretty solution, but there is no choice other than returning
an error code to user space, which would break the state consistency
guarantee and open another can of problems including regressions.
For stable backports the preparatory commits ac31c7ff8624 .. ba31c1a48538
are required as well, but for anything older than 5.3.y the backports are
going to be provided when this hits mainline as the other dependencies for
those kernels are definitely not stable material.
Fixes: 778e9a9c3e ("pi-futex: fix exit races and locking problems")
Reported-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Stable Team <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20191106224557.041676471@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ac31c7ff8624409ba3c4901df9237a616c187a5d upstream.
attach_to_pi_owner() returns -EAGAIN for various cases:
- Owner task is exiting
- Futex value has changed
The caller drops the held locks (hash bucket, mmap_sem) and retries the
operation. In case of the owner task exiting this can result in a live
lock.
As a preparatory step for seperating those cases, provide a distinct return
value (EBUSY) for the owner exiting case.
No functional change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20191106224556.935606117@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f186d974826847a07bc7964d79ec4eded475ad9 upstream.
The mutex will be used in subsequent changes to replace the busy looping of
a waiter when the futex owner is currently executing the exit cleanup to
prevent a potential live lock.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20191106224556.845798895@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit af8cbda2cfcaa5515d61ec500498d46e9a8247e2 upstream.
exec() attempts to handle potentially held futexes gracefully by running
the futex exit handling code like exit() does.
The current implementation has no protection against concurrent incoming
waiters. The reason is that the futex state cannot be set to
FUTEX_STATE_DEAD after the cleanup because the task struct is still active
and just about to execute the new binary.
While its arguably buggy when a task holds a futex over exec(), for
consistency sake the state handling can at least cover the actual futex
exit cleanup section. This provides state consistency protection accross
the cleanup. As the futex state of the task becomes FUTEX_STATE_OK after the
cleanup has been finished, this cannot prevent subsequent attempts to
attach to the task in case that the cleanup was not successfull in mopping
up all leftovers.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20191106224556.753355618@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4a8e991b91aca9e20705d434677ac013974e0e30 upstream.
Instead of having a smp_mb() and an empty lock/unlock of task::pi_lock move
the state setting into to the lock section.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20191106224556.645603214@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 18f694385c4fd77a09851fd301236746ca83f3cb upstream.
Instead of relying on PF_EXITING use an explicit state for the futex exit
and set it in the futex exit function. This moves the smp barrier and the
lock/unlock serialization into the futex code.
As with the DEAD state this is restricted to the exit path as exec
continues to use the same task struct.
This allows to simplify that logic in a next step.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20191106224556.539409004@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f24f22435dcc11389acc87e5586239c1819d217c upstream.
Setting task::futex_state in do_exit() is rather arbitrarily placed for no
reason. Move it into the futex code.
Note, this is only done for the exit cleanup as the exec cleanup cannot set
the state to FUTEX_STATE_DEAD because the task struct is still in active
use.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20191106224556.439511191@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 150d71584b12809144b8145b817e83b81158ae5f upstream.
To allow separate handling of the futex exit state in the futex exit code
for exit and exec, split futex_mm_release() into two functions and invoke
them from the corresponding exit/exec_mm_release() callsites.
Preparatory only, no functional change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20191106224556.332094221@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4610ba7ad877fafc0a25a30c6c82015304120426 upstream.
mm_release() contains the futex exit handling. mm_release() is called from
do_exit()->exit_mm() and from exec()->exec_mm().
In the exit_mm() case PF_EXITING and the futex state is updated. In the
exec_mm() case these states are not touched.
As the futex exit code needs further protections against exit races, this
needs to be split into two functions.
Preparatory only, no functional change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20191106224556.240518241@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3d4775df0a89240f671861c6ab6e8d59af8e9e41 upstream.
The futex exit handling relies on PF_ flags. That's suboptimal as it
requires a smp_mb() and an ugly lock/unlock of the exiting tasks pi_lock in
the middle of do_exit() to enforce the observability of PF_EXITING in the
futex code.
Add a futex_state member to task_struct and convert the PF_EXITPIDONE logic
over to the new state. The PF_EXITING dependency will be cleaned up in a
later step.
This prepares for handling various futex exit issues later.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20191106224556.149449274@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ba31c1a48538992316cc71ce94fa9cd3e7b427c0 upstream.
The futex exit handling is #ifdeffed into mm_release() which is not pretty
to begin with. But upcoming changes to address futex exit races need to add
more functionality to this exit code.
Split it out into a function, move it into futex code and make the various
futex exit functions static.
Preparatory only and no functional change.
Folded build fix from Borislav.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20191106224556.049705556@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e6e8df07268c1f75dd9215536e2ce4587b70f977 upstream.
Add NULL checks to show() and store() in cpufreq.c to avoid attempts
to invoke a NULL callback.
Though some interfaces of cpufreq are set as read-only, users can
still get write permission using chmod which can lead to a kernel
crash, as follows:
chmod +w /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
This bug was found in linux 4.19.
Signed-off-by: Kai Shen <shenkai8@huawei.com>
Reported-by: Feilong Lin <linfeilong@huawei.com>
Reviewed-by: Feilong Lin <linfeilong@huawei.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
[ rjw: Subject & changelog ]
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9e08117c9d4efc1e1bc6fce83dab856d9fd284b6 upstream.
Visual inspection of the usbvision driver shows that it suffers from
three races between its open, close, and disconnect handlers. In
particular, the driver is careful to update its usbvision->user and
usbvision->remove_pending flags while holding the private mutex, but:
usbvision_v4l2_close() and usbvision_radio_close() don't hold
the mutex while they check the value of
usbvision->remove_pending;
usbvision_disconnect() doesn't hold the mutex while checking
the value of usbvision->user; and
also, usbvision_v4l2_open() and usbvision_radio_open() don't
check whether the device has been unplugged before allowing
the user to open the device files.
Each of these can potentially lead to usbvision_release() being called
twice and use-after-free errors.
This patch fixes the races by reading the flags while the mutex is
still held and checking for pending removes before allowing an open to
succeed.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c7a191464078262bf799136317c95824e26a222b upstream.
The syzbot fuzzer found two invalid-access bugs in the usbvision
driver. These bugs occur when userspace keeps the device file open
after the device has been disconnected and usbvision_disconnect() has
set usbvision->dev to NULL:
When the device file is closed, usbvision_radio_close() tries
to issue a usb_set_interface() call, passing the NULL pointer
as its first argument.
If userspace performs a querycap ioctl call, vidioc_querycap()
calls usb_make_path() with the same NULL pointer.
This patch fixes the problems by making the appropriate tests
beforehand. Note that vidioc_querycap() is protected by
usbvision->v4l2_lock, acquired in a higher layer of the V4L2
subsystem.
Reported-and-tested-by: syzbot+7fa38a608b1075dfd634@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6dcd5d7a7a29c1e4b8016a06aed78cd650cd8c27 upstream.
There is the same incorrect approach to locking implemented in
vivid_stop_generating_vid_cap(), vivid_stop_generating_vid_out() and
sdr_cap_stop_streaming().
These functions are called during streaming stopping with vivid_dev.mutex
locked. And they all do the same mistake while stopping their kthreads,
which need to lock this mutex as well. See the example from
vivid_stop_generating_vid_cap():
/* shutdown control thread */
vivid_grab_controls(dev, false);
mutex_unlock(&dev->mutex);
kthread_stop(dev->kthread_vid_cap);
dev->kthread_vid_cap = NULL;
mutex_lock(&dev->mutex);
But when this mutex is unlocked, another vb2_fop_read() can lock it
instead of vivid_thread_vid_cap() and manipulate the buffer queue.
That causes a use-after-free access later.
To fix those issues let's:
1. avoid unlocking the mutex in vivid_stop_generating_vid_cap(),
vivid_stop_generating_vid_out() and sdr_cap_stop_streaming();
2. use mutex_trylock() with schedule_timeout_uninterruptible() in
the loops of the vivid kthread handlers.
Signed-off-by: Alexander Popov <alex.popov@linux.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: <stable@vger.kernel.org> # for v3.18 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b4add02d2236fd5f568db141cfd8eb4290972eb3 upstream.
When vbi stream is started, followed by video streaming,
the vid_cap_streaming and vid_out_streaming were not being set to true,
which would cause the video stream to stop when vbi stream is stopped.
This patch allows to set vid_cap_streaming and vid_out_streaming to true.
According to Hans Verkuil it appears that these 'if (dev->kthread_vid_cap)'
checks are a left-over from the original vivid development and should never
have been there.
Signed-off-by: Vandana BN <bnvandana@gmail.com>
Cc: <stable@vger.kernel.org> # for v3.18 and up
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
